Medium Access Protocol for Wireless Multimedia Networks

Medium Access Protocol for Wireless Multimedia Networks Bruno Ascenso, Bruno Santos, Rui Rocha, José B. Gerald Instituto Superior Técnico, Av. Rovisco...
Author: Cory Barber
3 downloads 0 Views 61KB Size
Medium Access Protocol for Wireless Multimedia Networks Bruno Ascenso, Bruno Santos, Rui Rocha, José B. Gerald Instituto Superior Técnico, Av. Rovisco Pais, 1046-001 LISBOA, Portugal Abstract The role of mobile communications in the society is becoming more important every day. The increasing need of a mobile broadband network has driven the intensification of the research efforts in this area. In the wireless LAN field, the 802.11 standard has been a commercial success, making it easy to find products conforming to this standard. But, whenever quality of service is required, the 802.11 fails in supporting flexibly and efficiently real-time requirements. This article describes a wireless MAC algorithm to use with PCNet-Mobile 802.11 cards. Its purpose is to provide access to wireless networks while handling with the quality of service required by the different multimedia applications. Performance results obtained through simulation are presented and discussed.

I. Introduction The tremendous commercial success of mobile systems in the last few years along with the recent developments in signal processing and computer performance has boosted the efforts in this area. The need for the development of a wireless mobile broadband network is becoming more important every day. The IEEE 802.11 standard allows the support of both besteffort and continuous media type of services [1], but fails in efficiently providing quality of service (QoS) for different traffic classes in a multi-cell scenario. The need for a suitable MAC protocol is therefore clear. However, the development of a new MAC protocol often requires new functions at the hardware level. This usually implies the development of new interface cards, which is a rather expensive solution. Since some of the existing 802.11 cards are very flexible in what concerns to the medium access controller, one can think in removing the existing firmware and develop a new one capable of flexible QoS provisioning. The data rates supported by these cards are too slow for the most demanding multimedia applications, but are enough to carry voice and compressed low-quality video signals. Guaranteeing QoS at the air interface is not an easy task. The environment is a lot more error prone than other media and it is sensitive to multi-path propagation interference and fading, thus demanding the existence of more complex error control mechanisms [4]. The packet size should be kept small to increase the error immunity. In the fixed network domain, the ATM protocol possesses this characteristic. So it becomes natural to try to use it in the wireless networks [5, 6]. The use of an ATM compatible protocol also brings the advantage of allowing a seamless integration between wireless and ATM wired networks. This paper describes a new MAC protocol, based on ATM transport mechanisms [2, 3], to be used in PCNet-Mobile 802.11 cards. Its purpose is to allow the implementation of wireless multimedia networks, handling different QoS

requirements. It tries to fulfill the requirements formulated by IEEE when recommending a standard for wireless LAN’s. The network structure is similar to that of 802.11, with a point coordinator managing the available bandwidth. It uses a TDMA access scheme, scheduled by the access point. The contention has been reduced to what is strictly necessary. Hence, a small contention period exists at the end of the frame, used only to transmit control information. The MAC has been simulated and is now in the implementation stage. This consists in removing the firmware from the cards and downloading the new code. The corresponding device driver has also been developed for Linux.

II. Network Architecture In order to guarantee fairness in the wireless access, a structured network topology was chosen, with the access point (BS) being responsible for the control of the bandwidth allocation among the mobile stations (MS). Thus, all traffic between two mobile stations must be transferred through the BS. The BS distinguishes the traffic based on its real-time requirements, implementing four queues with different scheduling priorities, which can be used by four different traffic flows. One possible mapping of these flows are the ATM traffic classes: CBR, VBR, ABR and UBR [7]. This is also the order used to define priorities between the queues in the scheduling. The traffic priority and its QoS requirements are negotiated every time a MS requires a new connection. The QoS parameters are: the minimum required data rate, the peak data rate and the maximum delay. These parameters are used in a different manner according to the priority of the corresponding traffic flow. This usage is summarized in Table I. Table I Usage of QoS parameters CBR




Minimum Data Rate

Reserved Reserved Reserved Ignored

Peak Data Rate

Reserved Reserved Ignored


Maximum Delay





Each mobile station must register itself with the BS before it can communicate through the network. This registration is performed by sending a contention packet with the respective MAC address. If the registration limit has not been reached, the BS chooses the next available identifier and assigns it to the MS. The MS will use this unique identifier to identify

itself in the network in all the future traffic. The identifier is 6 bit long, which considering the value 0 (zero) reserved, allows for 63 registered MSs in each BS. After the registering period, the MS may request the BS to open a new connection whenever it needs to communicate with another terminal. This is also accomplished by means of a contention packet. If the BS is able to open the new connection, it requests the MS to transmit its QoS requirements. This information is transmitted in a slot reserved by the BS, thus avoiding the need for more contention. If the BS is able to reserve the required data rate, it defines a radio identifier (Wireless Virtual Call Identifier – WVCI) for the connection, thus accepting it. In best-effort (UBR) connections, the data rate is ignored, allowing every request to be accepted unless the connection limit has been reached. This limit is only present due to the size of the WVCI, which is also 6 bit. Therefore, considering that the identifier is unique among all the terminals registered in a BS and the value 0 (zero) is also reserved, each BS can handle a maximum of 63 connections. The acceptance of the connection by the BS does not yet indicate that it is open. The BS must first contact the destination MS informing of this connection. Only after a positive acknowledgement by this second MS is the connection effectively open, which is signalled to the first MS by the allocation of the first data packet. Fig. 1 depicts a typical situation that occurs in the network to establish a new connection considering that no errors happen.

The BS never allows the total bandwidth occupied by the connections to exceed a pre-defined limit, which is lower than the maximum available bandwidth. It is done so to guarantee that even in severe error situations the negotiated QoS is present. This limit was adjusted by simulation to be the effective bandwidth available in a situation where BER=10-4 , the worst-case working situation considered. An inactivity timeout has been implemented with the purpose of eliminating from the BS the list of the mobiles that are disconnected, out of range or by any other reason not responding. This is accomplished by a special packet that is sent every pre-determined period of time if the MS doesn’t have any connections. In other words, the BS must hear something from every registered MS at least once in each of those periods of time.

III. Air Interface Frame A. Frame size In order to simplify the data scheduling, the air interface frame used has a fixed size. It is divided into small, equal size packets, each of them containing 6 bytes. This value represents the minimum transfer unit (MTU) of the protocol. The algorithm is greatly simplified by the existence of a single packet size. The rationale for this packet size is twofold: increasing the efficiency when sending control information (small packets) and providing better error immunity. With this chosen value, every transport packet size can be easily accommodated. For instance, the ATM cell payload size (48 bytes) is a multiple of this size, making it easy to pack ATM traffic. The ATM cell size was also used to help determine the best length of the air interface frame. Thus, an hypothetic station transmitting a voice signal with a bit rate of 64kbit/s was considered. Making this value correspond to one ATM cell per frame in a 2Mbit/s radio card, leads to the frame duration of 6ms or 1500 bytes as shown in equation 1.

64kbit / s 8 ≈ 167cel / s ≈ 6ms / cel 48bytes


This frame size is also small which, along with a frame-toframe basis scheduling, allows for a best service for real-time traffic. The uplink and downlink periods are variable according to the best needs determined in each frame by the BS.

B. Frame structure Fig. 1 Establishment of a connection The connection is open until one of the MSs involved explicitly closes it or stops sending packets for a predetermined period of time. When this happens, the BS informs the other MS that the connection can no longer be used.

As Fig. 2 shows, each frame is sub-divided into three periods, corresponding to three different parts of the algorithm: uplink (UL), downlink (DL) and contention.

Fig. 2 Proposed air interface frame structure ! ! !

DL – Frame header, control information to the MSs and DL data; UL – Some control information and UL data; Contention – Period used by the MSs to transmit control information to the BS.

IV. Medium Access Control All the data transfer between two mobile stations must go through the BS, which implements a store-and-forward algorithm, receiving the data packets and transmitting them later.

A. Downlink Frame The DL frame is sent as a single block to minimize the need for physical headers, and thus increasing the efficiency. The first packet sent in each frame is the MAC header containing information about the size of all frame periods. The option of concentrating all this information in the beginning of the frame holds a major disadvantage, since the loss of the header by one MS caused by errors, implies the loss of the whole frame for that MS. Nevertheless, due to the small size of the MAC header (6 bytes) along with the small size of the frame, this situation does not represent too much of a limitation. In the remaining of the DL period, the BS sends some control information, followed by the DL data. The control information can be of the following types: ! ! ! ! !

Reply to contention requests; Request of the QoS parameters before the opening of a connection; Reply to QoS parameters; Allocation of uplink slots; Data acknowledge.

The number of packets of each type may vary from frame to frame. Some of the packets may not even be present in certain frames. The order between them is always the same to facilitate the reading by the terminals. Never a control packet is postponed to the next frame because of bandwidth limitations. Thus, the data can only occupy the room left free by the control information. As the amount of this control information is always very small when compared to the size of the frame, this option does not have a significant impact on the effort to guarantee the QoS.

The data scheduling is always carried out after the control packet scheduling and is based on the connection priority, indicated by its traffic type (CBR > VBR > ABR > UBR). There is no reordering or priority definition among connections with the same traffic type, which leads to the first registered connection in the queue, always being the first to be served. But, as the maximum allocated bandwidth for the real-time connections never approaches the maximum existent bandwidth, this should never lead to a situation where a connection is always left without transferring its data.

B. Uplink Frame In the UL period, the MSs send the data and control packets according to what has been scheduled by the BS in the previous DL period. Together with the data packets, each MS sends a packet tail containing information about the current state of its internal queue for that connection. The BS uses that information to perform the scheduling to the next frame. Whenever the MS reports its queue to be empty no packets are allocated for it, unless it’s a real-time traffic connection. These latter connections are always granted one slot, which is used to transmit the updated queue state, making sure that this kind of traffic is always handled as soon as possible. On the other hand, non real-time traffic connections must send a contention request to update their queue state if at some given time they reported their transmission queue to be empty. For the same connection, each MS can be granted as many data packets as it needs (a packet-train). This packet-train is transmitted as a single block with only one physical header, which increases the efficiency.

C. Contention The contention period is used by the MSs in a slotted-Aloha access scheme. The slot size is also equal to the MTU of the protocol. The number of available slots is variable according to the occurrence or not of collisions in the previous frame. It is always kept in a minimum value when there are no collisions and increased in the opposite case according to the following algorithm: when a collision occurs, the BS doubles the number of contention packets until it reaches a maximum; when there are no collisions the BS brings them back to their minimum value. The MSs transmit their contention requests in a randomly chosen slot in an attempt to minimize the number of collisions. The contention requests may be of three different kinds: ! ! !

MS register request; Connection opening request; Reservation of transmission packets (non real-time connections).

D. Error detection In such an error prone medium as is the air interface a strong error control mechanism must be implemented. Such mechanism on this MAC is based on CRCs sent with each packet.

The control packets are always small (6 bytes) and thus only need a 1-byte CRC. Data packets on the other hand, can be much longer and are protected with 4-byte CRCs for each 6 MTUs they occupy. Also, every data transmission requires an acknowledge packet by the receiver. The UL acknowledge is sent by the BS in the following frame. For the DL data, the BS always reserves one acknowledgement slot for each connection in the same air interface frame. Since there can be multiple data units with different CRCs transmitted in the same frame, there is also present an algorithm of retransmission and reordering of missed packets. Along with each packet is sent a 6-bit sequence number, which is assigned by the upper layer. This upper layer also is responsible for the reordering of the cells received by a MS.

Fig. 3 and Fig. 4 depict the performance results achieved in the simulation. These results were obtained by considering an application producing real-time ATM traffic (CBR). This means that there is one BS and two MS’s with one unidirectional connection between them. Both the maximum throughput and the maximum packet delay were measured under two different conditions: BER = 0 (ideal situation) and BER = 10-4 (with burst errors). This was considered the worst-case scenario with which the algorithm must still provide the negotiated QoS and was used for parameter adjusting. In order to allow the limits to be tested, the real-time traffic was sent to the best-effort queue since, as was said before, with real-time traffic, the coordination point doesn’t allow the maximum bandwidth to be reached.

The retransmission method is implemented differently in the BS and in the mobile terminals. As the BS implements a more complex algorithm, the task of reordering packets cannot be performed. Thus, the MSs must preserve the transmitting sequence. Every time an error occurs in a packet, the transmission sequence goes back to last packet successfully transmitted in previous frames, regardless of other successful packets in the current frame. The BS, on the other hand, does not preserve the sequence of DL packets, but implements a 6-bit sliding window protocol.

E. Power saving The MAC also includes a power saving algorithm. This is accomplished by the existence of a periodic frame in which every terminal must be awake and listening. Between those frames the MS’s that don’t have any connections may enter a power save mode ignoring irrelevant frames. The waking up is synchronized by the BS, which keeps all control information for those MS’s, until the frame when they all are listening.

V. Implementation and results The described MAC has been developed taking into account the objective of implementing it in PCMCIA cards developed by Intersil (PCNet-Mobile cards). Those cards were built to implement the IEEE 802.11 wireless network standard, which uses the 2.4GHz ISM band to communicate. This standard requires the sending of a 18-byte long physical synchronization header at the beginning of each transmission. Two data rates are available in those cards: 1Mbit/s and 2Mbit/s, by the use of DBPSK or DQPSK modulation. The MAC was simulated using a general simulator (PARSEC) in order to test its performance and adjust some parameters. The implementation consists in removing the firmware present in the referred cards and inserting the new one with the developed MAC. Most of the described algorithm is performed by the firmware, leaving only the segmentation and reassembly as well as the reordering of packets to be done by the upper layer. This upper layer consists in a PCMCIA device driver developed for Linux.

Fig. 3 Simulated results of throughput vs. load As can be confirmed by the graphic in Fig. 3 the maximum throughput is achieved for a cell rate of around 1800 ATM cells/s and represents almost 80% of the available bandwidth. In the worst-case situation, due to packet retransmissions, the effective bandwidth usage decreases to around 60% and is achieved for a cell rate of around 1200 ATM cells/s. These values are inferior to those obtained by 802.11 which can be explained by the small packet size used when comparing to 802.11 packets, which being larger allow for a better throughput. Fig. 4 clearly shows the greatest improvement obtained with this solution. The maximum delay is always kept much below the requirements for voice or video transmission. In ideal conditions, the minimum delay corresponds to two air interface frames (12ms). It is already known that augmenting the number of connections causes a proportional increase of the overhead in each frame. With the intention of measuring the impact of this increase in the maximum delay of real-time connections, another simulation was performed.

minimize the number of such packets or the throughput penalty will be very high. Secondly, the hardware is prepared to send the CRC’s defined in 802.11: 1 byte and 4 bytes in the end of the frame. The proposed MAC uses 1 byte and 2 bytes CRC’s, some of them sent in the middle of the frame. These CRC’s must be calculated by the firmware, thus wasting processing time. Nevertheless, the obtained results are quite good considering the above limitations. The MAC is currently still in the implementation stage. Some important difficulties have been experienced when programming the card due mostly to the unavailability of the source code of the radio interface and the corresponding need to develop it in assembly code.

Fig. 4 Simulated results of delay vs. load In this situation, only real-time connections were open, each of them requiring only a minimum bandwidth. A situation of errors (BER = 10-4) was considered. The maximum delay obtained during the time of the simulation, for a packet to reach the destination terminal was measured as a function of the number of connections open. As can be verified in Fig. 5, the algorithm assures a maximum delay of 50ms until the number of connections reaches 20. Above this value the maximum delay increases, but always stayed under 90ms, which can be considered high for voice, but under the extreme circumstances considered, is quite fair.

Also, the frame-to-frame scheduling algorithm imposes demanding requirements to the available hardware. There are no BS-cards and MS-cards. The existing card hardware, which is based on an 80188 processor, though powerful enough to implement the MS algorithm, makes it hard to implement the referred BS algorithm. The availability of better hardware capacity in the BS (using a special Access Point hardware platform) will lead to further improvements in the access scheme implementation. One future important development would be the handoff support, bringing the possibility of moving the MSs between different BSs without loosing the connections. Though it has not been put to work, the protocol developed has embedded mechanisms to ease the support of handoff traffic.

VII. References [1] J. Pagaime, P. Clemente, R. Rocha, "Implementation and Performance Testing of an 802.11 Wireless LAN", ConfTele99, April 1999. [2] J. Sánchez, R. Martinez, M. W. Marcellin, “A Survey of MAC Protocols Proposed for Wireless ATM”, University of Arizona, 1997 [3] D. Søbirk, J.M Karlsson, L.Falk, C.Lind, “An overview of proposed MAC algorithms for wireless ATM”, Telia Research AB, Sweden [4] D. Eckhardt, P. Steenkiste, “Effort-limited Fair (ELF) Scheduling for Wireless Networks”, IEEE INFOCOM 2000.

Fig. 5 Simulated results of delay vs. number of connections for real-time traffic

VI. Conclusions The simulated results show that it is possible to transmit wirelessly different types of traffic using 802.11 hardware, with improved flexibility and fairness than it is expected from an 802.11 system. However, there are some important limitations. Firstly, the need for a synchronization header (which must be transmitted in DBPSK) is an important bottleneck when sending small packets. One must try to

[5] D. Raychaudhury, L. French, “WATMnet: A Prototype Wireless ATM System for Multimedia Personal Communications”, NEC USA, C&C Research Labs. [6] D. Raychaudhuri, “Wireless ATM Networks: Architecture, System Design and Prototyping”, IEEE Personal Communications, 1996. [7] D. Petras, M. Radimirsch, A. Krämling, U. Vornefeld, “Support of ATM Service Classes in Wireless ATM Networks”, Aachen Univ. of Technology, 1997.

Suggest Documents