Multicast Polling and Efficient VoIP Connections in IEEE Networks

Transcription

1 Multicast Polling and Efficient VoIP Connections in IEEE Networks Olli Alanen Telecommunication Laboratory Department of Mathematical Information Technology University of Jyv-askyl-a, FINLAND ABSTRACT IEEE standard defines the wireless broadband access network technology called WiMAX which introduces several interesting advantages including its the support for quality of service (QoS) at the MAC layer. Its several features, such as multicast polling support the base station (BS) topro- vide the QoS guarantees for subscriber stations (SSs). The specification, however, does not define very exactly how this optional multicast polling technique should be used. We propose a way to use this feature on the base stations and also suggest an addition to the specification, to serve several different delay requirements. To test the proposed solution and the performance of the multicast polling in general, we have run several simulation scenarios in the NS-2 simulator. Voice over IP (VoIP ) is considered as a specific application, since its tight delay requirements benefit most from the positive effect of multicast polling. Categories and Subject Descriptors C.2.1 [Computer-Communication Networks]: Network Architecture and Design Wireless communication; I.6. [Computing Methodologies]: Simulation and Modeling General General Terms Performance Keywords Multicast Polling, WiMAX, 82.16, Contention Resolution, QoS, NS-2 1. INTRODUCTION WiMAX is an IEEE standard for the wireless broadband access network [1]. The main advantages of WiMAX when compared to other access network technologies like are the longer range and more sophisticated QoS support at Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. MSWiM 7, October 22 26, 27, Chania, Crete Island, Greece. Copyright 27 ACM /7/1...$5.. Figure 1: Frame Structure of WiMAX the MAC level. Several different types of applications and services can be used in the WiMAX networks and the MAC layer is designed to support this convergence. The standard defines two basic operational modes: point-to-multipoint (PMP) and mesh. In the mesh mode, subscriber stations (SS) can communicate with each other and with the base stations (BS). In the PMP mode, the SSs are only allowed to communicate through the BS. It is anticipated that the network providers will use the PMP mode to connect customers to the Internet. In this case, the SSs do not send data one to each other, and the provider can control the environment to ensure the customers QoS requirements. In this article, only the PMP mode is considered. An important principle of WiMAX is that it is connection oriented. This means that an SS must register to the base station before it can start to send or receive data. During the registration process, an SS negotiates the initial QoS requirements with the BS. These requirements can be changed later, and new connections may also be established on demand. A simplified frame structure of WiMAX in time division duplexing (TDD) mode is presented in Figure 1. The time domain is divided into the frames, which are then further divided into the uplink (UL) and the downlink (DL) parts. Furthermore, both the UL and DL sub-frames are divided into SSs and to some special purpose areas. These special purposes include broadcast, multicast and initial ranging contention slots. The basic approach for providing the QoS guarantees in the WiMAX network is that the BS does the scheduling for both the uplink and the downlink directions. In other words, an algorithm at the BS has to translate the QoS re- 289

2 quirements of SSs into the appropriate number of slots. The algorithm can also account for the bandwidth request size that specifies the size of the SS output buffer. When the BS makes a scheduling decision, it informs all SSs about it by using the UL-MAP and DL-MAP messages in the beginning of each frame. These special messages define explicitly the slots that are allocated to each SS in both the uplink and downlink directions. The scheduling policy, i.e. an algorithm to allocate slots, is not defined in the WiMAX specification, but rather is open for alternative implementations. We have earlier proposed a scheduling solution in [2] and this paper extends the solution by examining a new feature of the 82.16, namely multicast polling. When WiMAX SSs connected to a BS need to send data in the uplink direction there are several methods to use, depending on the service class of the particular connection. If the connection is of the UGS type, it will be allocated a constant number of slots and it does not need to request them separately. In the rtps class, connections are always allocated at least a sufficient number of slots to satisfy the minimum bandwidth requirement and even more if required. The SS can send a bandwidth request by using the capacity allocated to the connection. To the ertps connections defined in [3], the BS can choose to allocate always at least one slot, enabling the SS at least to request for more bandwidth. In this article this method is referred to as the ertps with polling. Another possibility is not to allocate any slots to the ertps connections while they have not yet requested any. In this case, the ertps connections must participate in the contention procedure when moving from an idle to an active phase. Also no slots are allocated to the nrtps and BE connections if not explicitly requested. Therefore they need to participate on the contention whenever they have some data to send and no slots allocated. Participating in the contention is possible during either the broadcast or the multicast polling period. The contention procedure is described in more details in the following section. Since the WiMAX itself is a relatively new technology, and there is not very much research on the area of WiMAX QoS, the other studies on the multicast polling in WiMAX networks are quite rare. In [4] and [5] Chang et al. propose a new service class (QrtPS) and a scheme where polling is dynamically switched between the multicast and the unicast mode. Even though impressive numerical results are presented, the work lacks appropriate simulation results. In [6] the performance of broadcast and multicast polling methods were compared. The analytical model and the simulation results were used to show the efficiency of both methods with different parameters. The efficiency was measured as the utilization of the transmission opportunities, which indeed is an important factor, but not the only one. Currently there are no research articles published about the delay and network utilization efficiency, when using multicast polling. In our early studies [7] we discovered that, for VoIP applications, the use of ertps without polling utilizes the network in the best way. The delay constraints however are not always satisfied in this case. In the follow-up article [8], an adaptive algorithm for setting the contention parameters was presented. This way, the delay could be guaranteed with a certain probability. Nevertheless, it turned problematic to have different delay requirements between the connections. Only one threshold could be achieved with the normal broadcast contention resolution. The multicast polling based method, which can actually guarantee several delay requirements is presented in this paper to overcome some of the problems with these issues. The complete simulation results are also presented and analyzed. The rest of this paper is organized as follows. Section II describes the functionality and usage of the contention resolution algorithm in WiMAX networks. Section III describes the functionality of the multicast polling feature and the model that we propose to be used with it. We also suggest some additions to the specification to support QoS more efficiently. In Section IV the simulation environment and several simulation scenarios are presented. This section also analyzes the results of each simulation. Finally section IV concludes the article and discusses the further research problems of us within this topic. 2. CONTENTION RESOLUTION PROCESS The contention resolution mechanism is in a key role, when applying multicast polling and therefore it is discussed shortly in this section. The and 82.16e specifications define the mechanism that is used by the connections in the BE, nrtps and ertps classes that are not polled individually. Basically this means, that when the connections have some packets in the uplink buffers, and no slots are allocated for them, they must compete with each others to get an allocation. This method is known as the contention resolution mechanism. When an SS wants to enter the contention resolution process, it sets its internal backoff window equal to the backoff start value (2 N,N =[,..., 15]) advertised in the UCD message. Then, the SS chooses randomly a number within the window. The SS must then wait for this number of request opportunities before sending a request. If no data grant has been given within a specified interval, the SS considers the request lost. Then, it increases its internal backoff window by a factor of two and chooses a new random number. This process is continued until the internal window of the SS reaches the backoff end value declared in the UCD message. Then, the SS will drop the PDU and start from the beginning with the next PDU. The calculations of the contention parameters (backoff start, backoff end and number of request opportunities per frame) are presented with more details in [8]. The most interesting part of the calculations is, at least for VoIP applications, how to control the maximum medium access delay that SS can encounter. This it is considered briefly here. The enforcing of maximum delay naturally impacts on the loss experienced by the users. In our previous studies, we have also defined the maximum loss, but it is not calculated here since the delay is a more important measurement for voice applications. The worst case MAC delay is realized in the case depicted in Figure 2. Presume that SS has a packet to be sent on time, that is right after the previous contention period C 1 in frame F 1. In the worst case scenario, this frame has no downlink part at all and therefore the time that the SS has to wait before the next contention period can be up to 2 T f,wheret f is the length of the frame and can be according to the specification set to somewhere between 2 and 2 milliseconds. The first possibility for the SS to send a bandwidth request is on C i+1. If the transmission succeeds, the BS will allocate slot(s) to the SS in the next frame, 29

3 Figure 2: The worst case MAC delay in contention resolution. since the scheduling decisions on the BS are done per frame. The worst case scenario in this again is that the allocation (A i+2) will be in the end of the frame. Depending on the backoff parameters, the SS may send another request in case of collision. From the figure and the previous equations, it can be seen that the worst case MAC delay for the packet is: t i = t f (i +2)= i +2 (1) FPS where i equals the last possible frame where contention resolution can occur. It can be calculated from the backoff parameters and the number of request opportunities per frame (N). FPS is the Frames per second value and it is statically set at the base station. In a particular case where backoff start and backoff end are set to equal, i = B+1, N where B is the value of the backoff start and end. Then the worst case delay would be: t i = B+1 +2 N (2) FPS This equation can be used to set the contention parameters for broadcast and multicast contention periods. For a delay critical application like VoIP, it is usually a good idea to use the same values for the backoff start and the backoff end parameters, since this speeds up the contention process. 3. MULTICAST POLLING Multicast polling is one of the mechanisms in networks, and achieves better and even guaranteed quality of service with less waste in utilization. When it is used, a group of SSs is added to a multicast polling group and slots are assigned for these SSs to participate on contention resolution process. This way, the probability of collisions on the contention period and the Medium Access Delay (MAC) is decreased. By the term Medium Access Delay, we indicate the latency between the time when an SS starts the contention resolution process and when the SS is allocated some slots. The tradeoff between regular contention resolution and unicast polling is the reason why the multicast polling was introduced in the first place. Each SS can belong to one or zero polling groups and the memberships are managed dynamically. Two management messages (MCA-REQ and MCA-RSP) are used to assign and unassign SSs to and from the polling groups. Base station always decides about membership dynamics by sending MCA-REQs and SSs reply to changes with the latter message. The specification does not clearly define whether the SSs can participate on the broadcast contention while being assigned to a multicast group. We anticipate that the SSs should not, because it significantly simplifies the calculation of the backoff parameters and also provides means to guarantee QoS in a more reliable manner. The specification [1] states that multicast polling can be used to poll SSs when there is insufficient bandwidth for unicast polling. The specification also defines that multicast polling is only allowed to be used with nrtps, ertps and BE connections. Since no guarantees are given to the BE connections, we anticipate that the multicast polling should only be used with the ertps and nrtps connections. Even for the nrtps connections, it is not clear whether the multicast polling can provide a better Quality of Service, since the nrtps connections do not have any delay requirements. The biggest problem in the specification is that there are no separate backoff parameters set to multicast polling and broadcast polling. In practice it means, that the multicast polling group members should use the same backoff parameters as the broadcast ones do, as defined in the UCD management messages. If the polling slots of the broadcast and the multicast groups could be scheduled to separate frames, the problem would not arise, but in practise it is not always possible. We propose that this problem should be solved by adding two new TLV encoded parameters to the MCA-REQ message (backoff start and backoff end). The group members would thus get the correct backoff values for the group when joining to it. This method has some drawbacks, since it does not allow modifications on the parameters during a connection. On the other hand, it might not be necessary to adjust the parameters frequently, and the necessary SSs could at first be unassigned from the group and thereafter reassigned with new parameters. We anticipate that the network operators correct configuration for the usage of multicast polling should be as follows. Each service flow of the ertps type, with its separate delay and loss requirements should have separate multicast polling groups. The backoff parameters and the amount of polling slots should then be done based on the requirements and the number of connections in the group. Probably the only disadvantage on using multicast polling groups instead of broadcast polling, is the increased MAC layer s overhead. The signalling messages do use some of the overhead and it is even more important that each polling group increases the size of the UL-MAP message by 6 bytes (in the OFDM physical layer). Since the UL-MAP is sent with the BPSK-1/2 modulation (12 bytes / slot), adding 3 polling groups increases the overhead by 2 slots. Depending on the used frames per second parameter, three groups would then bring from.3-3 percent of overhead. The decision about the sizes of the polling groups is also important when setting them up. The same delay limits can be guaranteed with different parameters. For example the usage of four request opportunities and the value of 3 as backoff start and end provides the same delay as 2 transmission opportunities and backoff values of 1. So, which one should be preferred? It is quite natural that the latter results in more collisions than the previous one, but it is also possible to make 1 SSs to use those 4 request opportunities or to put two groups of 5 SSs to use the smaller ones. As discussed in [7] the probability p for successful transmission for an SS can be calculated with equation 3, where the sizes of the groups should be set accordingly. In the equation N stands for the number of connections and W is the size of 291

4 the backoff window, which is in our case same as the number of request opportunities. «N 1 W 1 p = (3) W It can be seen from the equation, that an increase in the number of the connections always decreases the probability of successful transmission while the number of request opportunities has the opposite effect. This is an open optimization problem and the topic will be discussed more in our future studies. Still some guidelines, based on the experiments, are provided in the simulation section. 4. SIMULATION This section describes the simulation environment where the simulations were driven. Three separate scenarios, several sub-cases of them and their results are also presented and analyzed. The motivation for the simulations is to show the advantages of the multicast polling feature and to present some guidelines on how it should be used. We have implemented the WiMAX MAC layer to the NS-2 simulator [9]. Our implementation includes the most important features, including packing, fragmentation, most of the management signalling, ARQ, initial ranging, all 5 service classes and their scheduling on the BS, dynamic service flow management, contention resolution process, polling and several others. Also an emulative PHY layer is implemented to support OFDM and OFDMa PHY layers. For this study on multicast polling, also the multicast polling signalling, usage of polling slots on SSs and the scheduling of the multicast polling slots on the BS were implemented. The implementation follows the model and ideas presented in the previous section. The general parameters used in every scenario are presented in Table 1. In each of the scenario, the transferred bytes in uplink and/or downlink directions are calculated on the wired link. This approach is used, since then we do not have to take into consideration the MAC-layer overhead produced by the WiMAX network. Fragmentation and packing produce some non-constant overhead that would make the analysis of the results more complicated. 4.1 Simulation scenario 1 Table 1: Common simulation parameters Parameter Value PHY OFDM Bandwidth 7MHz Cyclic prefix length 1/32 Duplexing mode TDD Frames per second 2 (5 ms per frame) Slots per frame 151 UL/DL ratio Dynamic MCS 64-QAM3/4 (18 B/slot) Ranging transm. opport. 4 Ranging backoff start/end /15 Fragmentation/packing ON PDU size as large as possible CRC ON ARQ OFF Figure 3: Topology of the Simulation Scenario 1 In this simulation scenario, several polling methods are compared to each other, in a fixed set of SSs. There is one BS and 5 SSs connected. For the sake of simplicity, each SS establishes one transport connection and runs one application on top of it. 4 of the SSs use BE service class and Pareto application over TCP. The Pareto application is used to model web traffic with an idle time of 375ms and burst time of 5ms. Due to the nature of the application, there is a need to participate on the contention quite often. The rest 1 of the SSs establish an ertps connection and use simulated VoIP as an application. The VoIP simulates the behavior of the G.711 audio codec, which has the highest mean opinion score [1]. The application sends data on 8. b/s rate and uses a packet size of 3 bytes, which includes the headers of RTP, UDP and IP. Silent suppression is emulated by using active and idle phases of 1.4 and respectively [11]. When the application is in an idle mode, it does not send anything and in an active mode it sends constantly with previously mentioned rate and packet size. The bandwidth guarantee is set to 8 kb/s and the scheduler then allocates appropriate slots for each connection. VoIP applications usually can handle delays of 1-2 ms, and therefore it is important to minimize the delay on the wireless link. In this simulation scenario the parameters are adjusted to see what kinds of delay limits can be achieved with them. The topology of the scenario is presented in Figure 3. There are six sub-cases considered under this simulation scenario and the purpose of them is to compare the efficiency of polling mechanisms. The sub-cases are defined as follows: I Only 1 VoIP connections and no BE connections. This case is just to know how much bandwidth do the VoIP connections take, when they are not disturbed by other connections. Unicast polling is used for the bandwidth requests. II 5 BE connections are added in this scenario and then observed. The VoIP connections still use unicast polling with 1 polling slot in ertps. In this case, the BE connections should not affect the VoIP connections at all, but it shows something about the efficiency of the ertps with polling approach. III The VoIP connections are made to exclude ertps polling and to use regular broadcast contention mechanism. The backoff parameters are adjusted to minimize the packet loss, with the price of lost delay guarantees. IV The case is like the previous one, except that the backoff parameters are changed to serve smaller MAC delays with the cost of decreased utilization. 292

5 Table 2: Scenario 1 parameters and results. Broadcast Multicast Case Req. opp. Start Back- Off End Req. opp. Start Back- Off End Sent [KB] VoIP BE Total VoIP Loss I % II % III % IV % V % VI % Table 3: Scenario 2 simulation Parameters SSs per Req. Backoff Case Groups Group Opp. Start End I II III IV Case 3 VoIP MAC Delay [s] Case 5 VoIP MAC Delay [s] Case 4 VoIP MAC Delay [s] Case 6 VoIP MAC Delay [s] Figure 4: MAC Delays in scenario 1. V The VoIP connections are made to use Multicast Polling instead of the broadcast one. The backoff parameters are now adjusted to guarantee 15ms MAC delays. VI This case is exactly like the previous one, except that the MAC delay of 2ms is now guaranteed. The exact delay limits and contention parameters are presented in Table 2. The table also presents some results from the scenario. It can be seen that while the ertps with unicast polling (Cases I and II) gives the best performance for the VoIP connections, it does not utilize the network very well. The solution allows only about 7 % of BE traffic when compared to other cases. The table also shows that the multicast polling based approaches utilize the network more efficiently that the broadcast ones. In Cases IV and V, the same delay limits are being guaranteed, and the latter case utilizes the network more efficiently. Figure 4 presents the MAC delays from subcases III to VI. Cases I and II are not presented since the unicast polling was used and the SSs did not need to participate on the contention, resulting in a small constant MAC delay. It can be seen from the figure that Cases IV and V indeed do result with similar MAC delays. It is worth reminding that the approach with multicast polling (V) resulted with a better utilization. In Case VI a bit larger delay limit (2ms) was set and the limit kept. Figure 5: Topology of the Simulation Scenario 2 It is also worth mentioning, that even though individual QoS guarantees can be satisfied without multicast polling, by adjusting the backoff parameters, not all of them can be. The overall result from this scenario is, that multicast polling provides nice advantages for guaranteeing QoS. 4.2 Simulation scenario 2 In this scenario, a comparison is made whether it is better to use smaller or bigger polling groups. Four sub-cases are run and in each of them, there are 24 VoIP users that use the same application parameters as in the previous scenario and one BE FTP user. The purpose of the FTP background application is to fill the available network utilization, based on the free capacity. FTP is a good application for this purpose due to the greedy nature. In the first case, there is only one multicast polling group with eight request opportunities. In the second one there are two groups with four opportunities on each and in the third one, there are four groups and two opportunities on each. In the fourth and the last case, there are four groups with only one opportunity on each. The backoff parameters are adjusted, so that the SSs can try to send a bandwidth request only once and if it does not succeed, the PDU is discarded. The exact parameters are presented in Table 3 and he topology of the scenario in Figure 5. The effect of the group size should be examined in theory first, but from the experiments we can see, that in this case smaller group equals to lesser collisions and thereafter less packet loss. It must be also taken into account that by increasing the number of groups the size of the UL-MAP is also increased. It can be seen from the bytes sent by the BE class, especially in Case IV. It is also worth mentioning that the groups size does not really have any effect on the MAC delays. This is predictable since the backoff parameters are adjusted to guarantee the delay. The effect of the group size depends on the relation of the request opportunities and the number of connections in the 293

6 Table 4: Sent SS Bytes in Scenario 2 Sent [KB] VoIP Max. Case VoIP BE Loss Delay [ms] I % 6.62 II % 6.72 III % 6.88 IV % 7.5 Service Class 1 MAC Delay [s] Service Class 2 MAC Delay [s] Service Class 3 MAC Delay [s] Service Class 4 MAC Delay [s] Figure 7: MAC Delays in scenario 3. Figure 6: Topology of the Simulation Scenario 3 group. Our future studies will investigate this issue more carefully. 4.3 Simulation Scenario 3 In this scenario, it is shown that the network operator can provide different delay limits and drop percentages to different applications / SS-connections. This is shown by using four VoIP classes, with different delay requirements. Each class here has 5 VoIP applications and backoff parameters and the request opportunities are adjusted based on that. The backoff start and end values are informed to the SSs in the MCA-REQ messages as defined in Section III. The network structure of this scenario is presented in Figure 6 The contention parameters and delay requirements for each service class are explained in Table 5. Each class, except the fourth one, is allocated two multicast polling contention slots and the backoff start and end are adjusted based on the delay requirements of the connections, based on Equation 2. The fourth class has more request opportunities per frame, since we want to see how this effects the loss percentage of the connections. The resulting MAC delays from each class of VoIP connections are presented in Figure 7. It can be seen that the delays are always below the desired limit. It is also worth mentioning that following from the contention parameters, for the first class there is only one opportunity in the first frame, where bandwidth request can be sent, and therefore the delay is almost static. With the second class, there are two possible frames and with the third one, four. If a band- Table 5: Scenario 3 Parameters Polling Req. Backoff Delay Packet Group Opp. Start End Req. Loss I ms 1,455% II ms 1,85% III ms,884% IV ms,16% width request results in a collision and there are no more opportunities, the packet is dropped. Since the first class only has one opportunity, the number of dropped packets is naturally bigger than with the others. The losses for each classarepresentedintable5. Byincreasingthenumber of contention slots per frame, the loss percentage can be decreased as seen with the class 4. The decrease between Cases I and IV is actually quite dramatic. 5. ACKNOWLEDGEMENTS I would like to thank Mr. Alexander Sayenko for his valuable comments about the issues concerning this article. 6. CONCLUSIONS In this paper, we have presented a solution on how the multicast polling groups can be used to achieve a better quality of service. Our proposition is to use separate multicast polling groups for service classes with different QoS requirements, and set the backoff parameters based on the delay and loss targets. The simulation scenarios run in NS-2 have confirmed the correctness of the proposed solution. They also show how can the different requirements can be guaranteed with the feature. We have also suggested a change to the specification, by using separate backoff parameters for each polling group and the broadcast contention group. With this addition, different delay requirements can also be guaranteed with multicast polling. Our future studies will focus on the other QoS related features of the WiMAX specification and admission control of the connections. Also we will study the combination of multicast polling and adaptive tuning of the backoff parameters. 7. REFERENCES [1] Air interface for fixed broadband wireless access systems. IEEE Standard 82.16, Jun 24. [2] A. Sayenko, O. Alanen, J. Karhula, and T. Hämäläinen. Ensuring the QoS requirements in scheduling. In The 9th IEEE/ACM International Symposium on Modeling, Analysis and 294

7 Simulation of Wireless and Mobile Systems, pages , Oct 26. [3] Air interface for fixed broadband wireless access systems - amendment for physical and medium access control layers for combined fixed and mobile operation in licensed bands. IEEE Standard 82.16e, Dec 25. [4] Chien-Ming Chou, Ben-Jye Chang, and Yung-Fa Huang. Dynamic polling access control for high density subscribers in wireless wimax networks. In Taiwan Network Conference, Nov 26. [5] Ben-Jye Chang and Chien-Ming Chou. Adaptive polling algorithm for reducing polling delay and increasing utilization for high density subscribers in wimax wireless networks. In The 1th IEEE Singapore International Conference on Communication systems, pages 1 5, Oct 26. [6] Lidong Lin, Weijia Jia, and Wenyan Lu. Performance analysis of ieee multicast and broadcast polling based bandwidth request. In Wireless Communications and Networking Conference, 27.WCNC 27. IEEE, pages , March 27. [7] A. Sayenko, O. Alanen, J. Karhula, and T. Hämäläinen. Supporting VoIP services in the IEEE networks. Technical report, University of Jyväskylä, Telecommunication laboratory, 26. [8] A. Sayenko, O. Alanen, andt. Hämäläinen. Adaptive contention resolution for VoIP services in IEEE networks. In The 8th IEEE International Symposium on a World of Wireless, Mobile and Multimedia Networks, Jun 27. [9] UCB/LBNL/VINT. Network simulator ns-2, [1] Pulse code modulation (PCM) of voice frequencies. ITU-T recommendation G.711, [11] Artificial conversational speech. ITU-T recommendation P.59,