New Distributed QoS Control Scheme for IEEE 802.16 Wireless ...

New Distributed QoS Control Scheme for IEEE 802.16 Wireless Access Networks Xiaofeng Bai1, Abdallah Shami1, Khalim Amjad Meerja1 and Chadi Assi2 1

The University of Western Ontario, Canada, [email protected], [email protected], [email protected] 2 Concordia University, Canada, [email protected] subscriber station. The rest of this paper is organized as follows: Section II presents an overview of the physical (PHY) and MAC layer specifications in the standard. Section III and Section IV introduce the motivation and design of the proposed QoS control scheme. Simulation results are presented in Section V and Section VI concludes this study.

Abstract—The IEEE 802.16 WirelessMAN standard provides a comprehensive quality-of-service (QoS) control structure to enable flow isolation and service differentiation over the common wireless network interface. By specifying a particular set of service parameters, the media access control (MAC) mechanisms defined in the standard are capable of offering service guarantees on the connection basis. However, the design of efficient, flexible and yet bandwidth-saving scheduling algorithms for such QoS provisioning still remains an open topic. This paper proposes a new distributed QoS control scheme that guarantees particular service parameter settings for both uplink and downlink connections. Detailed simulation experiments are presented to study the performance and to validate the effectiveness of the proposed algorithm.

II. OVERVIEW OF THE IEEE 802.16 WIRELESSMAN SYSTEMS The IEEE 802.16 WirelessMAN system contains one central Base Station (BS) and one or more Subscriber Stations (SSs) in one architectural cell. The BS is responsible for communicating with each SS and regulating its behavior. Two operation modes are defined in the standard, i.e., point-to-multipoint (PMP) and mesh modes, along with different physical layer specifications. In this section we briefly overview the basic concepts defined for the physical and MAC layer services in the standard. Specifically, we consider the 10-66 GHz band single carrier (SC) system operating in PMP mode.

Index Terms—Broadband Wireless Access Networks, IEEE 802.16, Quality of Service, Scheduling.

I. INTRODUCTION

B

roadband wireless access (BWA) technology is accepted as a promising solution for the next generation last-mile access systems. With less installation period, lower maintenance cost and higher network scalability, this technology offers more revenue points and better market penetration than its wired counterpart. Supported by the robust link adaptation framework and flexible QoS control structure in the newly developed standard, BWA in particular provides a suitable solution for delivering broadband Internet services to foliage-populated rural areas, where wired infrastructure is economically infeasible, as well as to built-up urban areas, where existing wired access is bottlenecked. The wireless metropolitan area network specifications, known as WirelessMAN, are defined in IEEE 802.16 [1]. The standard provides a set of mechanisms to achieve reliable and link-adaptive high rate transmission. QoS is supported by the standard with a full set of parameters that permits service differentiation up to the connection level. The implementation of such QoS provisioning to maintain the predefined service parameters, however, is left for vendor discretion. Many researchers have made tributary contributions from different perspectives. In this study, we propose a QoS control scheme that guarantees individual service parameter settings of each uplink and downlink connection. This scheme considers the data control plane as a collaborative entity and specifies detailed operations performed at the base station and each

A. PHY specifications for WirelessMAN-SC systems The physical layer operation is frame based and supports both Time Division Duplex (TDD) and Frequency Division Duplex (FDD) configurations. Both setup use burst transmission format where the burst profiling for each SS is adaptive and may change frame-by-frame. In this section we focus on the frame structure of TDD configurations. A transmission frame is defined as a fixed time duration in which both the downlink and uplink transmission complete one round. A frame consists of two subframes, i.e., downlink and uplink, designated for BS-to-SS and SS-to-BS transmissions, respectively. The downlink subframe begins with information for synchronization and a frame control section that defines the transmission burst profile, including modulation and coding schemes as well as relevant timing information, for each SS. Following the frame control section is the downlink data destined to individual SSs. The downlink data is grouped into several transmission bursts using TDM technique. These transmission bursts are differentiated by their applied Downlink Interval Usage Code (DIUC), which represents a certain set of modulation and coding scheme for transmission. Particularly, the burst mapped into QPSK (Quadrature Phase-Shift Keying) constellation appears first, followed by bursts mapped into 16-QAM (Quadrature Amplitude Modulation) and then 64-QAM (optional) constellations. Downlink subframe is broadcast by the BS to all SSs. The

1

periodically by the BS with fixed value. In this study we do not consider this service type for brevity. Excluding UGS connections, the standard does not specify detailed scheduling algorithm for other non-UGS connections and leaves it for vendor specific.

MAC in each SS listens to the downlink channel and looks for the MAC headers indicating data for this SS. The uplink subframe follows downlink subframe. Uplink data transmission is organized in TDMA fashion where the uplink bursts are differentiated by the sending SSs. Each scheduled SS transmits into the uplink during its granted window using burst profile associated with the Uplink Interval Usage Code (UIUC) that was informed in the frame control section. The bandwidth of a frame is allocated to downlink subframe with the granularity of one physical slot (PS), and to uplink subframe with the granularity of one minislot, which is 2 m PSs long (m ranges from 0 through 7). The length of one PS is defined as the duration of four modulated symbols. The symbol rate is a system parameter and is designed such that there should be an integer number of PSs within one frame duration. With the same PHY symbol rate, bursts using different DIUC/UIUC can achieve different bit rate for the MAC layer data stream.

III. MOTIVATION OF THE PROPOSAL From the previous section, we can see that the uplink request/grant scheduling is crucial for providing service guarantees to non-UGS connections. The cost of this mechanism, however, is the extra overhead required for connections to request their real-time bandwidth needs. This cost is a function of the number of connections concurrent in the system and the request interval of each connection. Consider that the 16 bit CID defined in the standard permits up to 64K connections running simultaneously under the BS’s administration, the bandwidth available for data transmission may decrease seriously in peak hours. Though some delay-tolerant connections can be polled with a longer interval, this precludes timely perception of the connection’s bandwidth need by the BS. With the fixed frame duration, the BS’s delayed perception eventually deteriorates the inter-connection statistical bandwidth multiplexing and potentially leads to bandwidth waste. In conclusion, the following principles should be taken into consideration for the design of an efficient QoS control scheme: (1) Guarantee service parameters for each connection; (2) Minimize the per-connection overhead required for bandwidth request; (3) Optimize the freshness of BS’s perception on each connection’s bandwidth need. Bearing these points in mind, we propose a distributed QoS control scheme that guarantees service parameters for both uplink and downlink connections. We refer to this scheme as Sing-Carrier Scheduling Algorithm (SCSA).

B. MAC services and transmission scheduling The operation of MAC services is connection-oriented. A connection is defined as a unidirectional mapping between BS and SS MAC peers for the purpose of transporting a service flow’s traffic [1]. A service flow is a unidirectional flow of MAC service data units with predefined QoS parameters. A connection is identified by its unique Connection Identifier (CID) and is mapped to a service flow. The QoS parameters defined for the service flow is therefore implicitly provided by the connection’s CID. In order to accommodate upper layer applications with different service requirements, the standard defines four types of MAC scheduling service. Each connection is categorized into one of these four service types, according to the property of applications carried by this connection. These scheduling services and related QoS parameters are as follows: (1) Unsolicited Grant Service (UGS)—the key QoS parameters are reserved traffic rate, maximum latency and tolerated jitter. (2) Real-time Polling Service (rtPS)—the key QoS parameters are minimum reserved traffic rate, maximum sustained traffic rate and maximum latency. The maximum latency is only guaranteed for traffic within the minimum reserved traffic rate. (3) Non-real-time Polling Service (nrtPS)—the key QoS parameters are minimum reserved traffic rate and maximum sustained traffic rate. (4) Best Effort (BE)—the key QoS parameter is only maximum sustained traffic rate. Each connection can request desired bandwidth by sending a stand-along MAC header or by inserting a grant management subheader into a MAC Protocol Data Unit (PDU). Though the bandwidth is requested for a connection, the grant is however issued to the corresponding SS. Therefore, the SS has the right to decide the consumption of a particular bandwidth allocation. Since the bandwidth need for a UGS connection is time-invariant, the grants for UGS connections are provisioned

IV. DISTRIBUTED QOS CONTROL SCHEME FOR IEEE 802.16 WIRELESSMAN-SC SYSTEMS The basic idea of our SCSA scheme is to move some connection level functionalities performed by the BS to each SS thereby limit the signaling overhead, while keeping the connection level QoS provisioning. Specifically, an Uplink Request Management Agent (URMA) is installed in each SS and collaborates with the local scheduler of the SS. This URMA partially processes each connection’s bandwidth request at the SS and generates up to three per-SS bandwidth requests that will be sent to the BS. These requests are labeled with different priority values and are sent at the end of the uplink burst window assigned to the SS in each transmission frame. In this way, the overhead required for bandwidth request is limited to be only SS-relevant and independent from the number of connections running in the SS. Also the BS is fed with the most recent information on the connections’ bandwidth need in every transmission frame. Therefore, we have complied with the second and third principles mentioned above. In the following discussion we focus on the first 2

The operations performed by the QoS enforcement module include two steps: (1) For each rtPS or nrtPS connection i, segment its bandwidth request ri into bandwidth guaranteed (BG) part and

principle, i.e., providing connection level service parameter guarantees. A. Uplink Request Management Agent A URMA consists of three modules, i.e., service measurement module, QoS enforcement module and SS request generation module. The functionalities performed in each module are described as follows: A.1 Service measurement module This module obtains the instant bandwidth request of each connection according to the connection’s queue length and MAC headers required to transmit the backlogged traffic. This bandwidth request is upper-bounded by the connection’s eligible bandwidth request, which is computed as: ⎧⎪ R max ⎫⎪ rie = max⎨ i × [t − S i (t )] , 0⎬ (1) ⎪⎩ 8 ⎪⎭

non-bandwidth guaranteed (NBG) part, i.e., riBG and riNBG , according to the corresponding value of QoS timer,

denoted as Qi (t ) , i.e.:

ri

BG

⎧ ⎧⎪ ⎪ min ⎨ri , =⎨ ⎪⎩ ⎪ 0 ⎩

⎫⎪ Rimin × [t − Qi (t )]⎬ 8 ⎪⎭

Qi (t ) < t

(3)

Qi (t ) ≥ t

riNBG = ri − riBG (4) The bandwidth request of a BE connection is always NBG, as there is no service guarantee for this connection. (2) For each rtPS connection i, further segment its riBG into

where rie is the eligible bandwidth request of connection i,

imminent part riBG −im and non-imminent part riBG − nim ,

Rimax is the maximum sustained traffic rate (in bits/second) of

according to the contracted maximum latency of this connection. The operation of this step is based on the following facts: if the maximum latency deadline of a PDU will appear in frame n+2, the last opportunity to schedule transmission of this PDU is in frame n+1, in order to guarantee its maximum latency. Therefore, the bandwidth needed to transmit this PDU has to be requested in frame n. The riBG −im part of riBG computed in frame n is thus the

this connection and t is the system time. The service measurement module maintains a service timer for each non-UGS connection running in the SS and S i (t ) in (1) is the value of connection i’s service timer at time t. The service timer applies the concept of Virtual Clock proposed by L. Zhang in [2]. This service timer is synchronized with the system clock when a connection is established and ticks with the following value upon the service of each PDU in the corresponding connection: 8 × Bi Ai = (2)

bandwidth need for transmitting PDUs whose maximum latency deadline appears before the end of frame n+2. The BG −im riBG − nim part of riBG is simply riBG − ri .

ρi

A.3 SS request generation module This module generates up to three per-SS bandwidth requests, depending on the service type of connections running in the SS. The per-SS bandwidth requests are prioritized, in order to enable service differentiation at the BS. These three bandwidth requests are defined as:

where Ai is the increment of connection i’s service timer, upon the service of a PDU with size of Bi bytes. ρ i is the measurement rate (in bit/second) for connection i. For the service timer, this value should be Rimax . Instead of stamping each arrived packet with its virtual time as introduced in [2], here we use a separate variable to record a connection’s virtual time. The reason, as will be shown later, is that in our case some packets have to be dropped-front due to violation of maximum latency. The service timer thresholds a connection’s service rate within its maximum sustained traffic rate. A.2 QoS enforcement module This module maintains a QoS timer for each rtPS and nrtPS connection running in the SS. The QoS timer is also initialized with the system clock, however ticks with the value decided by different measurement rate defined in (2). For the QoS timer,

P0 rSS =

∑ riBG−im

(5)

∑ riBG−nim + ∑ r jBG

(6)

i⊂ M

P1 rSS =

i⊂ M P2 rSS

=

∑ ri

i⊂ M

j⊂ N

NBG

+

∑ r jNBG + ∑ rk

j⊂ N

(7)

k⊂L

Pi (i=0, 1, 2) denotes the per-SS bandwidth request of where rSS

priority level i, M, N and L are the sets of rtPS, nrtPS and BE connections running in the SS, respectively. Before going further, it is helpful to clarify the background basis whereby these three prioritized requests are defined: (1) From the QoS sense, the r BG part of a rtPS or nrtPS connection is prioritized over its r NBG part and the latter is equivalent to the bandwidth request of a BE connection; (2) From the QoS sense, the r BG−im part of a rtPS connection is prioritized over its r BG−nim part and the latter is equivalent to the r BG part of a nrtPS connection.

the value of ρ i should be Rimin , i.e., the minimum reserved traffic rate (in bits/second) of connection i. The reason for designing two virtual times for a connection requiring minimum service rate is to have the received service rate “guaranteed but not limited” at its minimum reserved traffic rate. This point will be further clarified by the discussion of outbound transmission scheduling. The QoS timer enforces the connection’s service rate to meet a guaranteed value. 3

P1 followed by P2 requests, if there is more bandwidth available. When the scheduler has to select the next packet for transmission among multiple connections, some criterion should be defined. Depending on the type of prioritized request to which the bandwidth is honored, three different criteria are applied: (1) When multiple connections contend for bandwidth honored to the P0 request, the packet with the most imminent maximum latency deadline is selected. However, any packet with expired maximum latency deadline will be dropped at the front of the connection queue. (2) When multiple connections contend for bandwidth honored to the P1 request, the head-of-line packet of connection with the earliest QoS timer is selected. This criterion optimizes fairness among these contending connections. (3) Bandwidth honored to the P2 request is equally shared by each connection in a round-robin fashion, despite of the service type and requested bandwidth of the connections. This criterion continues until the granted burst window expires, i.e., even there may be no request to be honored. However, any connection whose service timer exceeds the system clock will be neglected in the current round. With the service of each PDU in a connection, the service timer ticks accordingly. However, only consuming bandwidth honored to the P0 and P1 requests incurs the advancement of corresponding QoS timer. This enables the received service rate of a rtPS or nrtPS connection to be “guaranteed but not limited” at its minimum reserved traffic rate. The scheduler at the BS performs similarly to the scheduler at each SS, except that the operation scope is a downlink burst window. Namely, connections belonging to the same downlink SG are all considered when the next packet is selected for transmission.

B. Frame generation Upon receiving the prioritized bandwidth requests from SSs, a new frame is generated at the BS. This requires the involvement of three functional modules, i.e., the Downlink Request Management (DRM) module, the resource allocation module and the frame creation module. The operations performed in these modules are described as follows: B.1 Downlink Request Management module The DRM module functions similarly to the URMA at a SS, except that the prioritized bandwidth requests for downlink are associated with each downlink burst. Namely, downlink connections using the same DIUC in the next frame are grouped together by a common set of prioritized bandwidth requests. Note that uplink connections only in the same SS are grouped together by a common set of prioritized bandwidth requests. In the following discussion we refer to connections sharing a common set of prioritized bandwidth requests as a scheduling group (SG). B.2 Resource allocation module This module allocates transmission capacity to each SG, according to their prioritized bandwidth requests. Since different PHY modulation and coding schemes imply different MAC layer transmission capacity, the number of symbols required to transmit one byte in the MAC PDU may vary in every SG. Therefore, the prioritized bandwidth requests of each SG have to be converted into symbol needs and the bandwidth allocation is finally accomplished by symbol assignment. We do not include physical layer details due to limited space. The symbol assignment follows strict priority rule and is defined as: (1) Symbol need of P0 requests is considered first, then P1 followed by P2 requests, according to the number of symbols available for data transmission in the next frame. Here the symbol need of Pi (i=0, 1, 2) requests includes the symbol need of every SG’s Pi request (both downlink and uplink). (2) If at any point the remaining number of symbols cannot accommodate the overall symbol need of Pi requests, every SG submitting a Pi request shares the available symbols in proportion to its symbol need. (3) If the symbol need of every SG has been accommodated, the remaining symbols are assigned to each SG, in proportion to the number of connections included in the SG. (4) The total number of symbols assigned to a SG is the sum of symbols “earned” by its P0, P1, P2 requests and any symbols assigned in step 3, if applicable. B.3 Frame creation module This module converts the above symbol assignment result into timing information in terms of PS or minislot, and then a new frame is created.

V. SIMULATIVE EXPERIMENTS A. Simulation model We set up a simulation environment by ns-2. The network consists of one BS and ten SS nodes (numbered from 1 to 10) locating 2.5 km away from the BS. In the downlink direction there are ten rtPS, ten nrtPS and ten BE connections originated from the BS; while in the uplink direction there are one rtPS, one nrtPS and one BE connection originated from each SS, except SS6 and SS8. As the supervised nodes, SS6 maintains three rtPS and one BE uplink connections; while SS8 serves four nrtPS and one BE uplink connections. We assign the same set of service parameters to connections of the same service type, i.e., 1M bps for the minimum reserved traffic rate of each rtPS and nrtPS connection, 1.5 M bps for the maximum sustained traffic rate of each rtPS, nrtPS and BE connection, 3 ms for the maximum latency of each rtPS connection. In the simulation, each connection running in the network offers averagely 1M bps traffic intensity, except for connection 36, which offers 2M bps traffic intensity. We focus on the service provisioning of three uplink connections: rtPS connection 35 running in SS6, rtPS connection 36 running in SS6 and nrtPS connection 48 running in SS8.

C. Outbound transmission scheduling Within the granted burst window in the uplink subframe, the scheduler at each SS selects packets for transmission, according to each connection’s bandwidth request and the prioritized per-SS bandwidth requests stored in the URMA by the last frame. Specifically, the P0 request is honored first, then 4

The frame duration and system symbol rate in the simulation are set to 1 ms and 20M Baud, respectively. We apply QPSK modulation to the frame control section and 16-QAM to each downlink and uplink burst used for data transmission. In order to illustrate the efficient inter-connection statistical bandwidth multiplexing provided by the BS in the proposed SCSA scheme, we also simulate another scheduling scheme, referred to as passive (PASV) scheme, where the bandwidth allocation is fixed in every frame and equally shared by each SS.

SCSA. Specifically, we set the Rimin and Rimax parameters of this connection to 1.5M bps and 2M bps respectively, and keep other settings the same as in scenario one. Fig. 1 compares the bandwidth provisioning of connection 36 by SCSA in two scenarios. The curves in the figure present the up-to-date averaged bandwidth provisioned to the connection. Therefore, with the evolvement of time, each curve becomes flatter and more precisely reveals the overall offered/serviced rate of the connection. We can recognize that the serviced rates of this connection are constantly guaranteed above its Rimin parameter

B. Simulation scenarios and results B.1 Scenario one In the first scenario we test the effectiveness of the proposed SCSA scheme in terms of providing connection level service guarantees. In the simulation we have observed that in PASV, both rtPS connection 35 and nrtPS connection 48 were starved by about 30% of their minimum reserved traffic rates. However, in SCSA, the bandwidth provisioned to each of these connections is well confined within the range between the

and constrained below its Rimax parameter, in both scenarios. The service improvement of connection 36 in scenario two, however, is not with the cost of degrading the service parameter compliance of other connections. Fig. 2 illustrates the bandwidth provisioning of connections 35 and 48 by SCSA in scenario two. The figure substantiates that there is no service drop for these two connections in scenario two. Therefore, we can conclude that the service improvement of connection 36 does not affect the contracted service provided to its sibling connections in the same SS, e.g., connection 35, and cousin connections in different SSs, e.g., connection 48. In fact, this service improvement is contributed by other BE connections under the flexible resource manipulation of the MAC.

corresponding Rimax and Rimin parameters. This is because in PASV the compliance of per-connection service parameters is constrained within the local scope of one particular SS, though some bandwidth is wasted by other SSs. Moreover, the dropping probabilities due to latency violation of three rtPS connections in SS6 are 27.04%, 26.61% and 30.4%, respectively for connections 34, 35 and 36 in PASV. While this value is zero for connections 34 and 35, and 25.53% for connection 36 in SCSA. We can see since connection 36 offers traffic intensity twice of its minimum reserved traffic rate, 25.53% packets are dropped. This value, however, is less than the overloaded portion of this connection, i.e., 50%. Hence we can conclude that traffic intensity within the minimum reserved traffic rate of any rtPS connection is serviced within its maximum latency constraint. offered rate serviced rate_scenario1 minimum reserved rate_scenario1 maximum sustained rate_scenario1 serviced rate_scenario2 minimum reserved rate_scenario2 maximum sustained rate_scenario2

2.5

Average bandwidth (bits/second)

Average bandwidth (bits/second)

rtPS connection 36 bandwidth records in two scenarios

3

rtPS connection 35 bandwidth records in scenario2

15

10 offered rate serviced rate minimum reserved rate maximum sustained rate

5

0

0

1 5

Average bandwidth (bits/second)

6

x 10

5

x 10

2

3

4

5

6

nrtPS connection 48 bandwidth records in scenario2

x 10 15

10 offered rate serviced rate minimum reserved rate maximum sustained rate

5

0

0

1

2

3 time (second)

4

5

6

Fig. 2 Bandwidth provisioned to connections 35 and 48 in scenario two 2

VI. CONCLUSION In this study we proposed a distributed QoS control scheme and examined its performance by simulations. This proposed SCSA scheme guarantees service parameters for each uplink and downlink connection and minimizes signaling overhead in the data control plane. Simulation results firmly verified the expected performance of the proposed scheme.

1.5

1

0.5 0

1

2

3 time (second)

4

5

6

REFERENCES

Fig. 1 Bandwidth provisioned to connection 36 in two scenarios

[1]

B.2 Scenario two In the second scenario, we increase the minimum reserved traffic rate parameter of connection 36, i.e., the connection offering 2M bps rate, to test the flexibility of the MAC in

[2]

5

IEEE Std 802.16-2004, “IEEE Standard for Local and Metropolitan Area Networks—Part 16: Air Interface for Fixed Broadband Access Systems,” October 2004. L. Zhang, “Virtual Clock: A New Traffic Control Algorithm for Packet-Switched Networks,” ACM Transaction on Computer Systems, vol. 9, pp. 101-124, 1991.