PREFACE. The average Ph.D. thesis is nothing but a transference of bones from one graveyard to another. J. Frank Dobie ( )

Transcription

1 PREFACE The average Ph.D. thesis is nothing but a transference of bones from one graveyard to another. J. Frank Dobie ( ) The recent standard IEEE for fixed Broadband Wireless Access (BWA) is analyzed, with regard to the support provided at the Medium Access Control layer for Quality of Service. Chapter 1 introduces the IEEE in the field of wireless technologies for last-mile access to the Internet. The Medium Access Control (MAC) protocol of the IEEE is reviewed in details in Chapter 2, which also includes the design choices for QoS support that have been implemented in a prototypical simulator of the IEEE The Half-Duplex Allocation (HDA) algorithm, which can be employed by the Base Station to efficiently serve Subscriber Stations with half-duplex capabilities in Frequency Duplexing Mode, is described in Chapter 3. The analysis of the IEEE through extensive simulations is carried out in Chapter 4. Finally, conclusions are drawn in Chapter 5. In the Appendix, the related work of two competitors of the IEEE PMP for BWA, i.e. the IEEE Mesh and the IEEE e, is reviewed. This work has been submitted in partial fulfillment of the requirements for the Degree of Doctor of Philosophy in Information Engineering at the Information Engineering Department of the University of Pisa, Italy. ii

2 ABSTRACT The IEEE is establishing itself as one of the leader technologies in the context of fixed Broadband Wireless Access (BWA), as corroborated by the huge number companies that have joined the WiMAX Forum since it was formed in June of 2001 to promote the adoption of IEEE compliant equipment by operators of BWA systems. Since its first release in 2001, the IEEE standard included native support for Quality of Service (QoS) at the Medium Access Control (MAC) layer, with several mechanisms to support different types of applications, classified by the standard into four scheduling services. However, the standard does not specify the algorithms to actually provide QoS support by means of these mechanisms. This allows any manufacturer to implement its own optimized proprietary algorithms, thus gaining a competitive advantage over rivals. The IEEE standard provides four different scheduling services: Unsolicited Grant Service (UGS), real-time Polling Service (rtps), non-real-time Polling Service (nrtps), and Best Effort (BE). This work is aimed at verifying, via simulation, the effectiveness of rtps, nrtps and BE in managing traffic generated by data and multimedia sources. Performance is assessed for an IEEE wireless system working in Point-to-Multipoint (PMP) mode, with Frequency Division Duplex (FDD), and with full-duplex Subscriber Stations (SSs). Our results show that the performance of the system, in terms of (e.g.) throughput and delay, depends on several factors: the frame duration, the mechanisms for requesting bandwidth (uplink only), the multimedia traffic type, and the offered load partitioning, i.e. the way traffic is distributed among SSs, connections within each SS and traffic sources within each connection. Finally, we propose an algorithm, namely Half-Duplex Allocation algorithm (HDA), that can be employed by the BS to serve SSs with half-duplex capabilities (HD-SSs) in Frequency Division Duplexing (FDD) mode. Based on the extensive simulations, we show that the performance degradation of HD-SSs, with respect to SSs with full-duplex capabilities (FD-SSs), is negligible, provided that HDA is employed by the BS. iii

3 Contents PREFACE ABSTRACT ii iii 1 Introduction 1 2 IEEE MAC Protocol Physical layer MAC Architecture for QoS Support QoS Architecture Scheduling Services BS and SS Schedulers Half-Duplex Allocation Algorithm Motivation Half-Duplex Allocation Algorithm Definitions and Assumptions Theoretical Results HDA Algorithm Extension for Mixed HD-SSs and FD-SSs Extension for Non-Time-Aligned Uplink and Downlink Sub-Frames Performance Evaluation Introduction Simulation Environment Traffic Models Performance Metrics Simulator Choices Data traffic Throughput Analysis Bandwidth Request Analysis Real-time traffic Unsolicited Polling Interval Offered Load Partitioning Bandwidth Request rtps vs. nrtps Mixed Multimedia Traffic iv

4 4.5 Half-Duplex Subscriber Stations Conclusions 65 BIBLIOGRAPHY 67 A IEEE Mesh 72 B IEEE e 74 INDEX 76 v

5 List of Figures 2.1 Scope of the IEEE Data/control plane MAC frame structure with FDD and TDD Fragmentation/packing/concatenation of PDUs Bandwidth request/grant example QoS model of the IEEE Service flow transition diagram MAC architecture of the BS and SSs UGS guarantees Example of UGS grant allocation Example of rtps unicast poll allocation Backlog estimation error vs. time Service differentiation with DRR. Offered load Service differentiation with DRR. Reserved rate Grant scheduling and allocation in FDD Unfeasible grant scheduling in FDD HDA notations Pseudo-code of HDA HDA with non-time-aligned uplink and downlink sub-frames Average delay vs. number of SS Throughput vs. number of SS Utilization vs. offered load Throughput vs. offered load Average number of SSs served per frame vs. offered load Throughput vs. offered load Bandwidth requests per uplink sub-frame vs. offered load Average number of bytes requested (contention only) Average number of bytes requested (piggyback only) Average delay vs. BW min Throughput vs. BW min Delay variation vs. unsolicited polling interval Average stand-alone bandwidth request vs. unsolicited polling interval Preambles overhead vs. unsolicited polling interval Delay variation vs. offered load Delay CDF of the conn and SS with 30/60/90 VC sources Delay CDF of the source and SS with 30/60/90 VC sources Notification delay vs. offered load vi

6 4.19 Preambles overhead vs. offered load Average stand-alone request vs. offered load Average piggyback request vs. offered load Average number of piggyback requests per frame vs. offered load Average number of piggyback requests per frame, normalized to the number of connections, vs. offered load Delay variation vs. offered load Average bandwidth request vs. offered load Backlog estimation error vs. time Delay variation (downlink) vs. offered load Delay variation (uplink) vs. offered load Delay variation of VoIP connections vs. number of SSs CDF of the delay of downlink VoIP connections CDF of the delay of uplink VoIP connections Delay variation of VoIP connections vs. number of SSs Average delay of Web connections vs. number of SSs CDF of the buffer occupancy of Web connections vii

7 List of Tables 2.1 QoS parameters of different scheduling services Example of a static timetable to serve UGS connections Example of a static timetable to poll rtps connections HDA glossary Simulation and network configuration parameters Raw bandwidth per burst profile Workload characterization. Web sources Workload characterization. QoS traffic sources Offered load partitioning of the first set of data simulations Offered load partitioning of the second set of data simulations Offered load partitioning of VC traffic Average number of SSs served in both directions viii

8 Chapter 1 Introduction I do not think that the wireless waves I have discovered will have any practical application. Heinrich Rudolf Hertz ( ) Let it be so. This has been the first successful message sent across the Bristol Channel by Guglielmo Marconi, in 1896, using the so-called wireless telegraph. The transmission of that small message without the burden on laying 14 km of cables across water made an old dream come true. However, that was just the tiny tip of the enormous iceberg of Radio Frequency (RF) communications, which is not entirely unveiled, even though more than one hundred years elapsed since that modest attempt. In fact, new research challenges arose, which have led to new applications, which in turn have spun the wheel again and again, as is usually the case with technology advances. Initially RF communications have been mainly used as a means of broadcasting (e.g. radio and television were born in 1920s) and to reach destinations that by necessity cannot rely on a wired infrastructure (e.g. remote countries or emergency/rescue services) both in civil and military applications. Over time the focus of development relentlessly shifted towards applications for local and personal communication. The most obvious example are mobile phones, which can be considered nowadays as a body appendage by most people who live in more developed countries. Additionally we are witnessing an even more subtle dissemination of wireless devices based on Wireless Local Area Network (WLAN) and Wireless Personal Area Network (WPAN) technologies. The former refers to wireless networks with a transmission range in the order of tens (hundreds in open space) of meters, and is usually identified by the leading technology of IEEE /WiFi. In fact, most, if not all, recent laptops are shipped with a built-in IEEE device, which allows for intranet/internet wireless connection in many public and private buildings and facilities, such as airports, schools, hotels. Also, many industries are currently leveraging the low-cost of WLANs, with respect to a wired infrastructure based on Ethernet or other wired access technologies. On the other hand, WPAN wireless networks have a short range of a few meters, and are thus typically employed to connect personal devices, such as headphones, scanners, and printers, to a single laptop or desktop PC. During the last years, the aforementioned spread of low-cost WPAN and WLAN devices covers pretty well the need for anywhere-anytime connection of a user to her personal appendages, without the inconvenience of cables and wires laying around. However the full exploitation of the wireless experience requires a connection to the Internet, which is becoming more and more vital due to the countless services upon which we all rely, such as , instant messaging, and Voice over IP. This, by necessity, requires some infrastructure to be present. For instance, IEEE

9 hot-spots guarantee reasonably good connectivity. However, their limited transmission range makes them unfeasible to cover large areas. As an alternative, one might exploit 2.5G cellular technologies, such as the General Packet Radio Service (GPRS) or Enhanced Data rates for Global Evolution (EDGE), which however are not available everywhere and only allow a limited transmission rate. While this solution can be enough for sporadic check, it definitely fails to meet the requirements of advanced multimedia applications, such as Voice over IP or videoconference. Besides, 3G cellular technologies, such as UMTS HSDPA/HSUPA [36], which increase the transmission rate and include support for multimedia applications, are still in the infancy phase. This lack of technology to bridge the gap between local (i.e. WLAN/WPAN) and global (i.e. Internet) wireless connectivity drove the development of the first version of the IEEE , which was published in At about the same time, the WiMAX forum [29] was formed as a non-profit corporation to promote and certify the compatibility and interoperability of BWA products using the IEEE specifications. At the beginning of 2007 the WiMAX forum included more than 400 members, which confirms the positive trend experienced by the IEEE among equipment manufacturers and service providers. Initially, the IEEE was aimed at providing high-speed Internet access in a Point-to- Multipoint (PMP) manner only. The support of Quality of Service (QoS) was embedded since the first release, which clearly stated the role of IEEE as a leading technology for the support to advanced multimedia applications. However, Line-of-Sight (LOS) was required, because the air interface of the 2001 release was based on Single Carrier (SC) at very high frequencies, i.e. above 11 GHz. This constraint could severely affect the dissemination of the technology, since it significantly increased the cost of setup of both the Base Station (BS) and Subscriber Stations (SSs), e.g. due to the mounting of roof-top antennae. Thus, during the subsequent years the standard has been amended so as to include support to non-los deployment, the final version being published in 2004 as IEEE d [3]. This new release included three new air interfaces, tailored to different types of scenarios. First, the SCa interface is a modification of the original SC physical layer, with support to lower frequencies, i.e. below 10 GHz, and non-los. However, both research and industry soon abandoned this air interface, mostly because of its inefficiency in a urban environment. Second, the Orthogonal Frequency Division Multiplexing (OFDM) was specifically designed for fixed Broadband Wireless Access (BWA), in both urban and rural scenarios. With this air interface, support to a mesh mode of the MAC was also added, so as to allow SSs to relay packets directed to the BS or other SSs. Finally, the Orthogonal Frequency Division Multiple Access (OFDMA) was tailored to mobile BWA applications, even though support to mobile terminals was only added in the 2005 release of the IEEE standard, i.e. IEEE e [4]. Unlike the air interface definition, the core of the QoS support at the MAC layer of the IEEE has remained basically the same since its first version, with the following key features. First, the MAC is connection-oriented, and QoS is provisioned on a per-connection basis. In other words, multiple flows of traffic directed to/coming from the same SS might be treated in a different manner, provided that the packets belong to different connections. This is consistent with any application scenario where multiple users access the Internet through the same SS. In fact, they might use different applications and/or require varied quality profiles (e.g. premium vs. basic users), which would not be achievable if all data were aggregated, as with IEEE Second, the IEEE standard specifies four (five, if the IEEE e is included) classes of applications, each having a mandatory set of network-related QoS parameters, both traffic specifications (e.g. maximum burst, maximum sustained rate) and requirements (e.g. minimum rate, maximum delay). In this way, the manufacturers of IEEE devices can implement at the MAC layer of both the BS and SSs support to these well-known classes, whose parameters are then tuned by the network operator or the users based on the actual applications 2

10 and network configuration. However, the IEEE standard does not specify a mandatory nor an informative QoS module, i.e. scheduling and admission control functions, of the BS and SSs, so as to allow manufactures to differentiate their products based on the design of these performance-critical components. Finally, several mechanisms are defined to allow SSs to request bandwidth from the BS, in order to fit the QoS requirements of different applications. In this work we aim at analyzing in details the mechanisms available at the MAC layer of IEEE for QoS support and assess its effectiveness to efficiently serve data and multimedia traffic. Therefore, the MAC protocol of the IEEE is deeply analyzed and the related work is reviewed. The results available in the literature are then discussed and compared to our proposed architecture for QoS support, including (e.g.) the definition of the BS and SS schedulers. The issue of allocating resources to SSs with half-duplex capabilities in networks operated in the Frequency Division Duplexing mode is considered separately, since it requires careful design of an allocation procedure to avoid synchronization mismatch between the BS and SSs. Our design choices are analyzed through extensive simulations of an IEEE network consisting of SSs with both half- and full-duplex capabilities. 3

11 Chapter 2 IEEE This new form of communication could have some utility. Guglielmo Marconi ( ) about the wireless telegraph In this chapter we report the basic IEEE MAC and physical layer functions, respectively in Sec. 2.1 and Sec. 2.2, and introduce the notation that will be used in the performance evaluation. Furthermore, in Sec. 2.3, we describe the QoS architecture of IEEE and review the related work. The IEEE specifies the data and control plane of the MAC and physical layers, as illustrated in Fig More specifically, the MAC layer consists of three sub-layers: the Service- Specific Convergence Sublayer (SSCS), the MAC Common Part Sublayer (MAC CPS) and the Security Sublayer. The SSCS receives data from the upper layer entities that lie on top of the MAC layer, e.g. bridges, routers, hosts. A different SSCS is specified for each entity type, including support for Asynchronous Transfer Mode (ATM), IEEE and Internet Protocol version 4 (IPv4) services. The MAC CPS is the core logical module of the MAC architecture, and is responsible for bandwidth management and QoS enforcement. Finally, the Security Sublayer provides SSs with privacy across the wireless network, by encrypting data between the BS and SSs. 2.1 MAC Protocol In IEEE uplink (from SS to BS) and downlink (from BS to SS) data transmissions occur in separate time frames. In the downlink sub-frame the BS transmits a burst of MAC Payload Data Units (PDUs). Since the transmission is broadcast all SSs listen to the data transmitted by the BS. However, an SS is only required to process PDUs that are addressed to itself or that are explicitly intended for all the SSs. In the uplink sub-frame, on the other hand, any SS transmits a burst of MAC PDUs to the BS in a Time Division Multiple Access (TDMA) manner. Downlink and uplink sub-frames are duplexed using one of the following techniques, as shown in Fig. 2.2: Frequency Division Duplex (FDD), where downlink and uplink sub-frames occur simultaneously on separate frequencies, and Time Division Duplex (TDD), where downlink and uplink sub-frames occur at different times and usually share the same frequency. SSs can be either full-duplex (FD-SS), i.e. they can transmit and receive simultaneously 1, or half-duplex (HD-SS), i.e. they can transmit and receive at non-overlapping time intervals. 1 FD-SSs must be equipped with at least two radio transceivers to operate simultaneously in two frequency bands. 4

12 Figure 2.1: Scope of the IEEE Data/control plane. Figure 2.2: MAC frame structure with FDD and TDD. 5

13 Figure 2.3: Fragmentation/packing/concatenation of PDUs. The MAC protocol is connection-oriented: all data communications, for both transport and control, are in the context of a unidirectional connection that is uniquely identified through a 16-bit connection identifier (CID). The latter is included in the standard 6-byte MAC header that is appended to each PDU so as to identify the connection to which the encapsulated SDU belongs. In order to reduce the MAC overhead or improve the transmission efficiency the BS and SSs can fragment a MAC Service Data Unit (SDU) into multiple PDUs, or they can pack multiple SDUs into a single PDU. These operations are illustrated in Fig. 2.3, which also shows that a downlink/uplink burst usually consists of the concatenation of many PDUs (or part thereof). A hybrid analytical-simulation study of the impact on the performance of this feature of the MAC layer has been carried out by [38]. Results showed that, if the use of fragmentation is enabled, the frame can be filled almost completely, which can significantly increase the frame utilization, depending on the size of SDUs. These optional features have also been exploited in a cross-layer approach between the MAC and application layers, so as to optimize the performance of multimedia streaming [57]. At the start of each frame the BS schedules the uplink and downlink grants in order to meet the negotiated QoS requirements, which are described in Sec Each SS learns the boundaries of its allocation within the current uplink sub-frame by decoding the UL-MAP message. On the other hand, the DL-MAP message contains the timetable of the downlink grants in the forthcoming downlink sub-frame. Both maps are transmitted by the BS at the beginning of each downlink sub-frame, as shown in Fig However, the uplink sub-frame is delayed with respect to the downlink sub-frame by a fixed amount of time, called the uplink allocation start time, so as to give SSs enough time to decode the UL-MAP and take appropriate decisions. The IEEE specifies that this value must be at least as long as the maximum Round Trip Time delay (RTT), but no longer than the frame duration. The BS controls the access to the medium in the uplink direction. However, while the BS has perfect knowledge of the status of the local downlink connection queues, it is not aware of the amount of data that is waiting for transmission at each connection in the uplink direction, i.e., 6

14 the status of uplink connection queues which reside at SSs. Thus, bandwidth in uplink is granted to SSs on demand. Two types of bandwidth request/grant services are specified in the IEEE : unsolicited granting and demand assigned multiple access, which are detailed below. According to the standard, with unsolicited granting a fixed amount of bandwidth is requested on a periodic basis during the connection setup phase. After that, the requested bandwidth is granted automatically without any further explicit bandwidth request. With demand assigned multiple access, instead, bandwidth is granted on a demand assignment basis, as the need arises. To this aim, the IEEE provides SSs with dedicated control messages to notify the BS of bandwidth requests, and with a number of different mechanisms to convey such messages from the SSs to the BS. Bandwidth requests may be issued either by a 6-byte stand-alone Bandwidth Request (BR) PDU, or by a 2-byte Grant Management (GM) sub-header, which is piggybacked onto a generic user data PDU. In both cases, the message specifies the amount of requested bandwidth, expressed as a number of user data bytes, and it refers to a specific connection: in BR PDUs, the CID is explicitly specified, whereas, in GM sub-headers, it is implicitly specified by the CID of the carrying PDU. Furthermore, requests may be incremental or aggregate. An incremental request indicates that additional bandwidth is needed, with respect to that requested so far by the same connection. On the other hand, an aggregate request resets any previous bandwidth request from the same connection. A request carried by a BR PDU may be either aggregate or incremental, whereas bandwidth requests piggybacked on GM sub-headers are always incremental. Even though bandwidth requests are always per connection, the BS grants uplink capacity to each SS as a whole [3] (par ), i.e. there is no explicit information in the UL-MAP message regarding the connections the grant was actually addressed to. Thus, when an SS is assigned an uplink grant, it is non deterministic for which of its connections it was intended and, consequently, a scheduler needs be implemented also within the SS MAC to allocate the granted capacity to all (or some) of its connections [21]. Bandwidth requests themselves need bandwidth to be transmitted. A unicast poll consists of an uplink grant intended by the BS for a specific connection to transmit a bandwidth request. The grant is issued to the SS the connection belongs to, which will eventually schedule a BR PDU for that specific connection. On the other hand, broadcast polls are issued by the BS to all uplink connections, which contend for their use in a random access manner. We refer to a bandwidth request (carried by a BR PDU) sent in response to a broadcast poll from the BS as a contention bandwidth request. We now discuss in detail how the broadcast poll mechanism is used for transmitting bandwidth request. As an example, assume that a previously inactive connection becomes busy, i.e., the connection queue is empty and the MAC layer receives data for that connection from the application layer. The SS will then schedule a contention bandwidth request to be conveyed to the BS for that connection. Such an initial bandwidth request will be sent in response to a broadcast poll according to a truncated binary exponential backoff algorithm for contention resolution. In fact, a collision occurs whenever two or more connections send a bandwidth request by responding to the same poll. However, the standard does not specify a means for the BS to explicitly acknowledge that the bandwidth request has been received correctly. In fact, it states that any bandwidth grant allocated by the BS to the SS positively acknowledges the bandwidth request reception implicitly [3] (par ). Furthermore, a connection assumes that its bandwidth request has been lost after a timeout interval (referred to as T16 in [3]) has expired without receiving any grant from the BS. After T16 expires, the truncated binary exponential backoff algorithm is employed to select the next broadcast poll to respond to. Note that the actual value of T16 is a system parameter. 7

15 Figure 2.4: Bandwidth request/grant example (MAC overhead not reported). An example of initial contention bandwidth request transmission is illustrated in Fig Here, the first grant from the BS (50 bytes) acknowledges the reception of the contention bandwidth request sent by connection 1, even though the grant is not sufficient for the connection to empty its buffer (100 bytes). Additional bandwidth is then granted by the BS in forthcoming frames so as to consume the remaining data awaiting transmission, i.e. 50 bytes. Since bandwidth is requested on a per-connection basis, it may happen that two or more connections of the same SS have a pending contention bandwidth request at the same time. The policy that an SS should employ in this case is unspecified by the standard. In the following we assume that contention resolution processes at the same SS are managed serially: any connection can have at most one outstanding contention bandwidth request. Pending contention bandwidth requests from many connections at the same SS are served in a First-In-First-Out (FIFO) manner depending on the time when the connections became busy after an inactive period. This way only one T16 timer is needed per SS. After the initial bandwidth request has been successfully sent to the BS by responding to a broadcast poll, subsequent requests may be sent by means of bandwidth stealing: a connection uses part of the uplink grant assigned by the BS for data transmission to send a bandwidth request instead, either via a BR PDU, or piggybacked on a user data PDU, i.e. via the GM subheader. Unlike the initial request, subsequent standalone and piggybacked ones never collide, since they are sent during an interval which is reserved for transmission to a specific SS. In Fig. 2.4 we show an example of transmission of a piggybacked bandwidth request in response to the arrival of new data (50 bytes) during the activity period of connection 1, which also adds two bytes for the GM sub-header. 2.2 Physical layer The IEEE standard includes several non-interoperable physical layer specifications. However, all the profiles envisaged by the WiMAX forum for fixed BWA specify the use of Orthogonal Frequency Division Multiplexing (OFDM) with a Fast Fourier Transform (FFT) size of 256, which 8

16 is thus the primary focus of this study. This physical layer has been designed to support non-line of Sight (NLOS) and operates in the 2-11 GHz bands, both licensed and unlicensed. Transmitted data are conveyed through OFDM symbols, which are made up from 200 sub-carriers. Part of the OFDM symbol duration, named the Cyclic Prefix duration, is used to collect multi-path. The interested reader can find a technical introduction to the OFDM system of the IEEE in recent survey papers [33, 41]. In order to exploit the location-dependent wireless channel characteristics, the IEEE allows multiple burst profiles to coexist within the same network. In fact, SSs that are located near to the BS can employ a less robust modulation than those located far from the BS [38]. The combination of parameters that describe the transmission properties, in downlink or uplink direction, is called a burst profile. Each burst profile is associated with an Interval Usage Code (IUC), which is used as an identifier within the local scope of an IEEE network. The set of burst profiles that can be used is periodically advertised by the BS using specific management messages, i.e. Downlink Channel Descriptor (DCD) and Uplink Channel Descriptor (UCD). To maintain the quality of the radio frequency communication link between the BS and SSs, the wireless channel is continuously monitored to determine the optimal burst profile. Specifically, the burst profile is thus dynamically adjusted so as to employ the less robust profile such that the link quality does not drop below a given threshold, in terms of the Carrier-to-Interference-and-Noise Ratio (CINR) [27]. However, as a side-effect of the dynamic tuning of the transmission rate, it is not possible for the stations to compute the transmission time of MAC PDUs a priori. Therefore, SSs always issue bandwidth requests in terms of bytes instead of time, without including any overhead due to the MAC and physical layers. Even though the link quality lies above a given threshold, it is still possible that some data get corrupted. To reduce the amount of data that the receiver is not able to successfully decode, several Forward Error Correction (FEC) techniques are specified, e.g. Reed-Solomon with Convolutional Code (RS-CC), which are employed in conjunction with data randomization, puncturing and interleaving. Data corruption of a MAC PDU can be detected by the receiver via an optional 32-bit CRC. All SSs, both HD-SS and FD-SS, synchronize themselves with the BS by means of a long preamble transmitted at the beginning of the downlink sub-frame, so as to retrieve information from the DL-MAP and UL-MAP messages. The long preamble is a well-known sequence of pilot sub-carriers that synchronizes the receiver, whose duration is two OFDM symbols. FD- SSs will then keep themselves synchronized to the downlink channel by continuously listening to the BSs transmissions. On the other hand, an HD-SS keeps on being synchronized with the downlink channel only up until the beginning of its own uplink grant, if any. At this point, in fact, the HD-SS has to switch its radio transceiver from receiving to transmitting mode, thus losing the synchronization with the downlink channel. Even though that HD-SS switches back to receiving mode after transmission, synchronization with the downlink channel is lost, and cannot be restored, unless the BS transmits a new physical preamble. Therefore, the BS is required to add a physical short preamble, whose duration is one OFDM symbol, to each downlink burst which is addressed to an HD-SS whose uplink grant was scheduled after the occurrence of the last downlink sub-frame beginning. On the other hand, physical preambles are never added to downlink grants addressed to FD-SSs. Finally, in the uplink sub-frame, each SS, regardless of its duplexing capabilities, always incurs the overhead of one short preamble for each frame where it is served. 9

17 2.3 MAC Architecture for QoS Support In this section we describe the QoS architecture of the IEEE first. Then, we review the mechanisms available at the MAC layer of the IEEE for QoS support and discuss the prominent design choices of their implementation QoS Architecture In general, the process of requesting and granting QoS in a network can be logically split in two separate layers: application and network. The application layer provides the end-user with a simplified and standardized view of the quality level that it will be granted for a given service. This layer is not aware of the technicalities of service requirements (such as bandwidth, delay or jitter) and it does not depend on the technology issues related to the actual networks that will be traversed (such as a fiber-optic, wireless or xdsl). On the other hand, the network layer deals with a set of technical QoS parameters, which it maps on network-specific requirements that have to be fulfilled in order to provide the end-user with the negotiated quality level. Usually, in wired IP networks the mapping is performed at the network layer. However, such an approach is hardly suitable for wireless networks [14], where there are a number of factors that influence the resource allocation: (i) the availability of bandwidth is much more limited with respect to wired networks, (ii) there is high variability of the network capacity due, for instance, to environmental conditions, (iii) the link quality experienced by different terminals is location-dependent. Therefore, it is often necessary to implement QoS provisioning at the MAC layer, as in IEEE , so as to gain a better insight of the current technology-dependent network status and to react as soon as possible to changes that might negatively affect QoS. In IEEE the prominent QoS functions of network provisioning and admission control are logically located on the management plane. As already pointed out, the latter is outside the scope of the IEEE , which only covers the data/control plane, as illustrated in Fig Network provisioning refers to the process of approving a given type of service, by means of its network-layer set of QoS parameters, that might be activated later. Network provisioning can be either static or dynamic. Specifically, it is said to be static if the full set of services that the BS supports is decided a priori. This model is intended for a service provider wishing to specify the full set of services that its subscribers can request, by means of manual or semi-automatic configuration of the BSs Management Information Base (MIB). On the other hand, with dynamic network provisioning, each request to establish a new service is forwarded to an external policy server (not shown in Fig. 2.5), which decides whether to approve it or not. This model allows a higher degree of flexibility, in terms of the types of service that the provider is able to offer to its subscribers, but requires a signaling protocol between the BS and the policy server, thus incurring additional communication overhead and increased complexity. Unlike the network provisioning function, which only deals with services that might be activated later, and that are therefore said deferred, the admission control function is responsible for resource allocation. Thus, it will only accept a new service if (i) it would be possible to provide the full set of QoS guarantees that it has requested, and (ii) the QoS level of all the services that have been already admitted would remain above the negotiated threshold. Quite clearly, admission control acts on a time scale smaller than that of network provisioning. This is motivated by the latter being much more complex than the former, as pointed out by a recent study [51] on an integrated end-to-end QoS reservation protocol in a heterogeneous environment, with IEEE and IEEE e devices. Testbed results showed that the network provisioning latency of IEEE equipments currently available in the market is in the order of several seconds, whereas the activation latency is in the order of milliseconds. 10

18 Figure 2.5: QoS model of the IEEE In IEEE , the set of network-layer parameters that entirely defines the QoS of a unidirectional flow of packets resides into a Service Flow (SF) specification. Each SF can be in one of the following three states: provisioned, admitted, active. Provisioned SFs are not bound to any specific connection, because they are only intended to serve as an indication of what types of service are available at the BS. Then, when an application on the end-user side starts, the state of the provisioned SF will become admitted, thus booking resources that will be shortly needed to fulfill the application requirements. When the SF state becomes admitted, then it is also assigned a CID 2 that will be used to classify the SDUs among those belonging to different SFs. However, in this phase, resources are still not completely activated; for instance, the connection is not granted bandwidth yet. This last step is performed during the activation of the SF, which happens just before SDUs from the application starts flowing through the network. Thus a two-phase model is employed, where resources are booked before the application is started. This is the model employed in traditional telephony applications. At any time it is possible to put on hold the application by moving back the state of the SF from active to admitted. When the application stops, the SF is either set to provisioned or deleted; in any case, the one-to-one mapping between the SFID and the CID is lost, and the CID can be re-assigned for other purposes. The SF transition diagram is illustrated in Fig Figure 2.7 shows the blueprint of the functional entities for QoS support, which logically reside within the MAC CPS of the BS and SSs. Each downlink connection has a packet queue (or queue, for short) at the BS (represented with solid lines). In accordance with the set of QoS parameters and the status of the queues, the BS downlink scheduler selects from the downlink queues, on a frame basis, the next SDUs to be transmitted to SSs. On the other hand, uplink connection queues (represented in Fig. 2.7 with solid lines) reside at SSs. Bandwidth requests are used on the BS for estimating the residual backlog of uplink connec- 2 For the ease of notation, in the rest of this work we do not distinguish between a SF and the connection for which it has been enabled. 11

19 Figure 2.6: Service flow transition diagram. Figure 2.7: MAC architecture of the BS and SSs. 12

20 QoS parameter UGS rtps nrtps BE Minimum Reserved Traffic Rate Maximum Sustained Traffic Rate Maximum Latency Tolerated Jitter Traffic Priority Maximum Traffic Burst ( ) Unsolicited Grant Interval ( ) Unsolicited Polling Interval ( ) Bandwidth request mechanism UGS rtps nrtps BE Unsolicited granting Unicast polling Broadcast/Multicast polling Bandwidth stealing Piggybacking Table 2.1: QoS parameters of different scheduling services. Parameters with a symbol cannot be specified by SFs of that scheduling service. A instead means that the parameter is mandatory according to the IEEE standard. Finally, we tagged as ( ) the parameters that are specified as optional by the standard, but are used in our implementation of the IEEE The unsolicited grant and polling interval parameters appeared in the IEEE e amendment [4]. tions. In fact, based on the amount of bandwidth requested (and granted) so far, the BS uplink scheduler estimates the residual backlog at each uplink connection (represented in Fig. 2.7 as a virtual queue, with dashed lines), and allocates future uplink grants according to the respective set of QoS parameters and the (virtual) status of the queues. However, as already introduced, although bandwidth requests are per connection, the BS nevertheless grants uplink capacity to each SS as a whole. Thus, when an SS receives an uplink grant, it cannot deduce from the grant which of its connections it was intended for by the BS. Consequently, an SS scheduler must also be implemented within each SS MAC in order to redistribute the granted capacity to the SSs connections (see Fig. 2.7) Scheduling Services In IEEE each SF is characterized by a set of network-layer QoS parameters, which are used by the BS for both network provisioning and admission control, and to serve the uplink/downlink connections so as to meet the desired level of QoS while the SF is active. Both traffic requirements and traffic specifications are included, depending on the application type. Specifically, the BS scheduler is responsible for guaranteeing the traffic requirements of admitted SFs, provided that their traffic specifications are met by applications. As already introduced, four scheduling services exist in IEEE , which identify four classes of applications: Unsolicited Grant Service (UGS), real-time Polling Service (rtps), nonreal-time Polling Service (nrtps), and Best Effort (BE). Each scheduling service is characterized by a mandatory set of QoS parameters, reported in Table 2.1, which is tailored to best describe the guarantees required by the applications for which the scheduling service is designed. Furthermore, for uplink connections, it also specifies which mechanisms to use to request bandwidth. Traffic requirements are described first. The Minimum Reserved Traffic Rate specifies the minimum rate, in b/s, that must be reserved by the BS for this service flow. The Maximum 13

21 Figure 2.8: UGS guarantees. Latency 3, in s, upper bounds the interval between the time when an SDU is received by the MAC layer and the time when it is delivered to the physical layer. The Tolerated Jitter, in s, is the maximum delay variation that must be enforced. The Traffic Priority can be used by the BS to provide differentiated service to service flows that have the same QoS requirements. The Unsolicited Grant (Polling) Interval specifies the nominal interval between two consecutive grants (unicast polls) for the service flow. The Maximum Sustained Traffic Rate and the Maximum Traffic Burst instead are traffic specifications. Thus, if the SF does not comply with these traffic specifications, the BS is not required to provide the negotiated QoS level, in terms of the admitted requirements. Although not requested by the IEEE standard, the MAC layer can implement traffic filters, e.g. token buckets, so that traffic specifications are never exceeded. The QoS parameters in Table 2.1 can also be specified by means of service classes, which are collections of pre-specified sets of QoS parameters identified by a string, whose scope is local to the BS. Service classes can be used as macros by system administrators within the same service provider domain to refer to a complex set of parameters through an easy to remember identifier, such as G.711 or MPEG4. Unsolicited Grant Service UGS is designed to support real-time applications with strict delay requirements, that generate fixed-size data packets at periodic intervals, such as T1/E1 and VoIP without silence suppression. The guaranteed service, which is illustrated in Fig. 2.8, is defined so as to closely follow the packet arrival pattern: grants occur on a periodic basis, with the base period equal to the Unsolicited Grant Interval and the offset upper bounded by the Maximum Latency. With regard to uplink connections, capacity is granted by the BS regardless of the current backlog estimation, thus SSs never send bandwidth requests. In other words, grants are assigned with the same pace as that of packet generation. This can lead to undesirable delays if the synchronization between the application and the BS is lost due to clock mismatch. This issue has been addressed in [70]. Support of UGS connections can be easily implemented at the BS, due to the periodic nature of the traffic for which UGS has been designed. For instance, grants to the admitted UGS connection can be statically allocated by means of a static timetable updated whenever a new UGS connection is admitted. Specifically, the grant size is the expected size of the SDUs, which is equal to SDU x = UGI x R x, where UGI x is the Unsolicited Grant Interval and R x the Minimum 3 In IEEE terminology, the latency is the queueing delay of MAC SDUs. In the packet scheduling literature, the maximum latency is usually called delay bound. 14

22 Figure 2.9: Example of UGS grant allocation. The static timetable is reported in Table 2.2. Frame number Grant size CID 0 SDU SDU SDU 2 2 Table 2.2: Example of a static timetable to serve UGS connections (see Fig. 2.9). Reserved Traffic Rate of connection x. Moreover, the table has to be filled so as to comply with the QoS requirements, in terms of the Maximum Latency and Tolerated Jitter. An example of the UGS static allocation is illustrated in Fig. 2.9, with two connections 1 and 2, which belong to SS a and SS b, respectively. The UGI of connection 1 is such that one SDU is generated every two frames, while connection 2 is expected two produce one SDU each frame. The resulting static timetable is reported in Table 2.2. Note that the static allocation is periodic with the period equal to two frames. In general, the timetable span is equal to the least common multiple of the U GI values of all admitted connections. A drawback of UGS with uplink connections is that grants are assigned regardless of the actual backlog at SSs. For instance, UGS is not suitable for VoIP applications with silence suppression. In fact, while packets of fixed size are usually generated at a constant rate during talk-spurt (ON) periods, no packets are produced during silence (OFF) periods. Several modifications to the UGS have been proposed in the literature so as to efficiently support this kind of applications by reducing the MAC overhead of unnecessarily assigning uplink grants to idle VoIP connections. For instance, Hong et al. [37] proposed two alternative strategies. The first approach consists of dynamically adapting the grant interval, depending on the bandwidth that is actually consumed by the connection. The second is inspired to the UGS with Activity Detection (UGS/AD) scheduling service of the DOCSIS standard [25], whose MAC-layer design choices have been broadly reused by the IEEE working group. This strategy relies on the SS notifying the BS when it is entering/leaving an OFF period, respectively. In this way, during the OFF periods, the BS will assign small uplink grants instead of full-sized ones, which are used by the SS to notify the BS of the start of the next ON period as soon as the application becomes busy again. This solution has become part of the specifications of the IEEE e amendment [4] as the Enhanced Real-time Polling Service (ertps). Both these approaches have been shown to perform better than the original UGS, in terms of the MAC overhead. Finally, Lee et al. [44] 15

23 Frame number CID Table 2.3: Example of a static timetable to poll rtps connections (see Fig. 2.10). proposed a modification to the UGS to efficiently support VoIP applications with variable rate, i.e. when packet size changes during the ON periods. More recently they compared all the above mechanisms through simulation and showed that their proposal achieves the least MAC overhead with variable rate VoIP applications [45]. In the following we ignore service of UGS connections, since the latter is based on periodic scheduling only. The only effect of having UGS connections is that the amount of capacity available in each sub-frame varies depending on the allocation of downlink/uplink grants reserved for them [19]. Real-Time Polling Service The rtps is designed to support real-time applications with less stringent delay requirements than UGS, that generate variable-size data packets at periodic intervals, such as Moving Pictures Expert Group (MPEG) video and VoIP with silence suppression. The key QoS parameters with such connections are the Minimum Reserved Traffic Rate, the Maximum Latency, and the Unsolicited Polling Interval (uplink only). Since the size of packets with rtps is not fixed as with UGS-tailored applications, SSs are required to notify the BS of their current bandwidth requirements. However, in order to grant deterministic access to the medium, the BS periodically sends unicast polls to rtps connections. For this reason, the latter are refrained from using bandwidth request mechanisms on a contention basis. The polling period is equal to the Unsolicited Polling Interval (UPI), if specified. With regard to uplink connections, the BS can issue periodic polls by means of a static timetable like that of UGS grants. The only difference is that the grant size is not equal to the expected SDU size, which is not known in advance, but to the number of bytes needed by an SS to transmit a bandwidth request PDU for the polled connection. An example of static timetable of unicast polls is reported in Table 2.3 with reference to Fig In general, the bandwidth request mechanism of rtps connections thus incurs an additional delay with respect to UGS connections of at least one frame duration. In fact, by responding to a unicast poll an SS notifies the BS of the backlog of one of its connections, but it cannot actually transfer data until the BS reserves an uplink grant for it. However, unlike UGS, rtps connections can piggyback bandwidth requests on outgoing PDUs, provided that new data arrived before the previous backlog has been entirely served. This way an rtps connection can anticipate the backlog notification to the BS with respect to the next scheduled unicast poll, thus reducing the aforementioned delay. Non-real-time Polling Service and Best-Effort Unlike UGS and rtps scheduling services, nrtps and BE are designed for applications that do not have any specific delay requirements. The only difference between them is that nrtps connections are reserved a minimum amount of bandwidth, which can boost performance of bandwidth-intensive applications, such as File Transfer Protocol (FTP) and Video on Demand (VoD). Both nrtps and BE uplink connections typically use contention bandwidth requests; however, the BS should also grant unicast bandwidth request opportunities to nrtps connections 16