1 Introduction

From the information dissemination point of view, communication networks can be divided into three classes. Point-to-point networks, where one sender physically sends information to one and only one receiver. Broadcast networks, where one sender is able to physically send information to one or more receivers. Broadcast networks offer natural (on a level of a physical link) broadcast and multicast services, which is often associated with random access to a link shared by two or more stations. The third class is non-broadcast networks, which also offer one-to-N transmissions, where N is equal to or larger than 1, but their broadcast and multicast services are emulated in non-broadcast links. Core networks, typically built with the use of fiber optics or radiolinks (including satellite radiolinks), usually belong to point-to-point or non-broadcast classes. Access networks, including local area networks (LANs), often belong to the broadcast class.

The point-to-point and non-broadcast networks allow the network layer of the Open Systems Interconnection (OSI) model to assure quality of service (QoS) by the use of suitable buffering. Thus, the main efforts of the creators of the classic approach to quality of service (QoS) were focused on two fundamental QoS architectures, based on two alternative methods of signalling. They are the Integrated Services (IntServ), based on the Resource Reservation Protocol (RSVP) and the Differentiated Services (DiffServ), based on the differentiated services code point (DSCP). The broadcast environments are not able to assure end-to-end QoS in the same way because of the random access of sending stations to shared medium.

The classic approach to QoS works around the problem of BMA networks by the assumption that the performance of access networks, including local area networks (LANs), is both much larger than the performance of the core network and large enough to assure required QoS parameters. As a result, the problems with QoS should occur only in core networks. Nowadays this assumption is not always met, so the modern approach to QoS states that in broadcast networks QoS assurance in the network layer should be associated with the QoS assurance in the data link layer. An example that can be used is the popular wireless LAN technology, IEEE 802.11 (WiFi), which allows the user to associate DiffServ and 802.11 QoS assurance (formerly 802.11e, now included in 802.11). Mapping between the DiffServ’s DSCPs and IEEE 802.11 access categories and traffic classes are widely described in the literature ([3,4,5], just to list a few), although it still remains an open issue [6].

The Traffic Flow Description (TFD) is an experimental option of the Internet Protocol (IP), proposed in the IETF’s working document [1], intended for the description of traffic in real-time streams and non-real-time flows for Quality of Service (QoS) purposes. The option is devoted to conveying detailed knowledge about forthcoming traffic (valid in a short time horizon) from a sender, through intermediate nodes, to a receiver. This knowledge was successfully used for the individual (made for each flow or stream) dynamic resource allocation of multiple video streams [2]. However, to utilize TFD descriptions, TFD-capable intermediate nodes (routers) are needed and the connection of TFD-capable and TFD-incapable networks may result (and, usually, results) in the degradation of QoS.

In this paper, an unequivocal mapping between a subset of the TFD flags and IEEE 802.11 user priorities and access categories is proposed. The proposed method maps the static part of the TFD option into user priorities and access categories of IEEE 802.11 Wireless LAN. As a result, QoS-protected traffic avoids medium contention and receives QoS guarantees from a 802.11 network.

The rest of the paper is organized as follows. The next section describes the TFD option. The third section proposes the mapping between the TFD and IEEE 802.11 QoS signalling, while the fourth section describes implementation of proposed mapping in the Linux kernel. The fifth section presents experimental results. The sixth section summarizes our experiences.

2 Traffic Flow Description Option

The TFD option of the IP protocol is intended to be used as optional fields of the header of the IP version 4 (IPv4) datagram or as an optional header of the IP version 6 (IPv6) datagram.

The option conveys both dynamic knowledge about forthcoming traffic and static information about the described real-time stream or non-real-time flow. The dynamic part assures signalling that allows for the building of the dynamic resource allocation systems. The static part can be used as a code point, which enables the coding of QoS requirements.

The option consists of five fields (Fig. 1). The first two bytes are occupied by two option control fields. The next, Flags field occupies the next two bytes of the option. This field conveys, among other things, static information about data transmitted stream or flow. Each of the last two fields, Next Data and Next Time, occupy four bytes. They are designed for the transmission of dynamic knowledge about forthcoming traffic. The Next Data field includes the amount of data (in bytes) that will be transmitted during the time (in ms) given in the Next Time field.

The Flags field consists of seven 1-bit flags and one 9-bit field Res, reserved for future flags (Fig. 2). The first two flags describe features of the Next Data field (number format and indication of maximum value). The next two flags describe how data transmitted in the Next Data Field were acquired (buffer analysis or prediction). The last three fields describe properties of the transmitted traffic. The S and E fields indicate the type of traffic - streaming (inelastic) or elastic, respectively. The L field indicates that large amounts of data will be transmitted.

3 LSE-to-UP and LSE-to-AC Mappings

Apart from dynamic knowledge about forthcoming traffic, conveyed mainly in NextData and NextTime fields, the TFD option carries static general information (some bits of the Flags field) about the transmitted stream or flow. This information is too general to be able to serve as a basis of per-stream or per-flow reservations, but describes streams or flows well enough to serve as code points that indicate traffic classes. In this case the L, S and E bits of the Flags field are the most important.

Fig. 1.
figure 1

IPv6 traffic flow description option

Full size image

The L, S and E bits indicate QoS requirements of given traffic. The values of the so-defined code point (hereafter referred to as ‘LSE’) can be mapped to corresponding values of IEEE 802.11 user priorities (UP) and access categories (AC). The mapping table of LSE QoS information to IEEE 802.11 UP and AC is presented in Table 1.

Table 1. LSE to UP/AC mapping
Full size table

S and E bits equal to zero denote that TFD-based assurance is not in use and the transmission should be carried out using typical best effort service. This LSE code point is mapped to UP equal to zero (IEEE 802.1D Best Effort or BE). However, if the L bit is set and the nature of traffic allows, user priority can be set to 1 (IEEE 802.1D Background or BK). The S bit set indicates streaming traffic (voice or video transmission). The distinction between voice and video is based on the size of streaming information, indicated by the L flag. If the L bit is set, UP will be set to 5 (IEEE 802.1D Video or VI). If the L is clear, UP will be set to 6 (IEEE 802.1D Voice or VO). In the case of the above LSEs, mapping between UP and AC is in accordance with the IEEE 802.11 standard [7].

Elastic traffic (E bit set) is usually not covered by the QoS guarantees. However, such guarantees may be desirable for certain applications, such as the Internet of Things (IoT) or e-health. The Authors then propose to use UP equal to 3 (IEEE 802.1D Excellent Effort or EE) in the case of a small amount of transmitted data (L \(=\) 0) and UP equal to 4 (IEEE 802.1D Controlled Load or CL) otherwise (L \(=\) 1). AC set to AC_VI (video), in the case of UP set to 4, is compliant with IEEE 802.11 specification [7]. In the case of UP set to 3, the Authors propose to use the AC_VO (voice) access category rather than the AC_BE (best effort), specified in [7].

The situation where the S bit is set to 1 and the E bit is set to 1 is forbidden in the document [1].

Fig. 2.
figure 2

Flags field of the TFD option

Full size image

4 Implementation

The above mapping was implemented in the Linux kernel. The Linux kernel IEEE 802.11 framework consists of two main components: mac80211 and cfg80211. The mac80211 is a framework used for writing drivers for SoftMAC wireless devices. The cfg80211 is the configuration API for IEEE 802.11 devices in Linux. It bridges userspace and drivers and offers some utility functionality.

The implementation of mapping includes both LSE-to-UP mapping and the improvement of UP-to-AC mapping. In so far as LSE-to-UP mapping only needs changes in the kernel, the UP-to-AC mapping also needs changes in the driver of the network card, introduced as firmware extensions. Firmware extensions and some default parameters of 802.11 devices are sent from the Linux kernel drivers to 802.11 network adapters during startup of the operating system.

As a result, changes were made both to the mac80211 module (net/mac80211 - “Linux softmac layer”) and to the util.c module of the wireless section (net/wireless - “Wireless utility functions”). The implementation defines the QoS map structure (according to Table 1) and adds the TFD mapping to the cfg80211_classify8021d function, which determines the 802.1p/1d tag assignment. The QoS map is defined using the Linux kernel nl80211_set_qos_map function. Because, during transmission, TFD option fields are analyzed and user priorities and access categories are set and the ieee80211_select_queue function, which indicates the queue used for transmission, was also modified.

5 Experiments and Preliminary Results

Experiments were carried out in a local 802.11n network, working at 2.4 GHz, 144 Mbps. As foreground traffic, media streams from a VLC media server [8] or elastic flows transmitted by the Transmission Control Protocol (TCP) were used. As background traffic TCP flows were used. Foreground traffic was QoS protected with the use of the TFD option and background traffic was transmitted without QoS guarantees (the best effort service). End systems worked under the control of the Linux operating system. To enable TFD signalling, implementation [9] of the TFD option in the Linux kernel was used. Video streams were High Definition Television (HDTV) sequences [10], owned by NTIA/ITS, an agency of the U.S. Federal Government and created in 2008 under Project Number 3141012-300, Video Quality Research. TCP flows were generated by the iPerf tool [11]. Video streams and TCP flows were transmitted from senders, through the access point, to receivers. End systems were equipped with Archer T4U AC1200 and ASUS PCE-AC68 network cards. As an access point, the TP-LINK Archer C-7 AC1750 was used.

In the first experiment, a sequence of 8 video streams [10] were transmitted together with N TCP flows (\(N = 0, 1, ..., 10\)). The topology of the test network is depicted in Fig. 3. Each test sequence lasted about 760 s and was build by repeating the transmission of 8 clips five times (each clip lasts for 19 s and the target bit rate set to 20 Mbps), with clips starting from randomly chosen moments. Figure 4 shows the comparison of averaged (over 10 times) packet error rates (PER) of the video transmission with and without the TFD signalling. The LSE code point was set to 110 (L and S bits set, E bit clear), which gives UP equal to 5 and AC set to AC_VI (Tab. 1). As is depicted in the figure, LSE-to-UP mapping allowed for the achievement of nearly errorless transmission (only in the case of 9 and 10 competing TCP streams was PER larger than zero, i.e. 0.3% and 0.5%, respectively), while without QoS protection one competing TCP flow was enough to achieve average PER of 17.4% (and 36% for \(N=10\)).

In the second experiment, a single TCP transmission (bulk data transfer) competed for bandwidth with N TCP flows (\(N = 0, 1,..., 10\)). Topology of the test network is depicted in Fig. 5. The LSE code point was set to 001 (L and S bits clear, E bit set), which gives UP equal to 3 and AC set to AC_VO (Tab. 1). Each transmission lasted for 500 s and results were averaged over the 10 transmissions. Figure 6 presents average throughput achieved for transmissions with and without QoS protection based on the TFD option. As is shown in the figure, LSE-to-UP mapping allows one to obtain larger throughput if more than one TCP stream competes with QoS protected elastic traffic. In the case of \(N=6\) protected traffic achieved about two times larger throughput than non-protected (7.08 Mbps vs. 3.7 Mbps), and if \(N=10\), more than three times larger (7.01 Mbps vs. 2.3 Mbps).

Fig. 3.
figure 3

Topology of the test network used in the first experiment. Legend: MS - media (video) server, \(MR_i - i\)th media (video) receiver, \(i=1,...,8\), \(TCPS_j - j\)th TCP sender, \(TCPR_j - j\)th TCP receiver, \(j=1,...,N\)

Full size image
Fig. 4.
figure 4

Error rate of video transmission vs TCP background sources

Full size image
Fig. 5.
figure 5

Topology of the test network used in the second experiment. Legend: \(TCPS_p\) - TCP sender (QoS-protected traffic), \(TCPR_p\) - TCP receiver (QoS-protected traffic), \(TCPS_j - j\)th TCP sender, \(TCP_j - j\)th TCP receiver, \(j=1,...,N\)

Full size image
Fig. 6.
figure 6

Throughput of TCP transmission with multiple TCP background traffic connections

Full size image

For the sake of validation and verification of the implementation described in the Sect. 4, the first and the second experiments were repeated without the TFD option, and the DiffServ’s DSCP was used as the indicator of required traffic category. Values of the DSCP were so selected that the same traffic classes (AC_VI and AC_VO) [12] were used in repeated experiments. Results obtained for repeated experiment were the same as obtained for proposed TFD-to-802.11 mapping.

6 Conclusion

In this paper, the mapping of static information about transmitted flow or stream (described using the Traffic Flow Description option of the IP protocol) between chosen bits of the TFD option and IEEE 802.11 user priorities and access categories was proposed. Such mappings are created for QoS assurance purposes and are aimed at providing QoS guarantees in broadcast networks. The method of mapping is similar to classic DSCP-to-UP and DSCP-to-AC mappings that enable the preservation of DiffServ’s QoS guarantees in 802.11 networks. The proposed method was implemented in the Linux kernel and then tested in a laboratory 802.11n network, working at 2.4 GHz, 144 Mbps. Results show that the proposed mappings sufficiently promote traffic described by the TFD option in 802.11 WLAN and protect it against degradation.