 |
 |
 |
 |
Understanding 802.11n
This is my own attempt to understand and explain the many changes that occured in wireless 802.11 networks to get from 802.11a/g to 802.11n. This has been a controversial standard and thus, in addition to explaining the technical side, I will also try to cover the politics that have shaped the standard or lengthened the time line. The first meeting of the TGn working group was in 2003 and currently, the standard is scheduled to be finalised in late 2009.
One final word of warning is that I do not have a background in electromagnetism and I do not understand maxwells equations. As a result my knowledge of MIMO antennas and how spatial multiplexing actually works is limited. As a result, the information for the 802.11n MAC layer is much more in-depth than the physical layer. For those wanting further details on these topics I would recommend that they read [1] as well as Matthew Gast's fantastic book [5].
TGn Sync and WWiSE
The early stages of IEEE standardisation often start with multiple competing proposals. At the preliminary stages of the IEEE 802.11n standardization effort, two competing proposals gained backing. These groups were TGn Sync and WWiSE (World-Wide Spectrum Efficiency). Of the chip manufacturers Atheros, Agere, Marvell and Intel were backers of TGn Sync. Broadcom, Connextant, Airgo and Motorolla were supporters of the WWiSE proposal. Many of the big buyers of 802.11n chips such as Cisco, Nokia, Sony and Samsung were also backers of the TGn Sync.
Both proposals were more or less similar. They both featured MIMO antenna configurations and spatial multiplexing at the physical layer. At the MAC layer both groups thought that BlockAcks and frame aggregations were necessary to complement the increased data rates. The points of contention between the two groups were largely based on spectrum use and implementation complexity.
The WWiSE group felt that using channel bonding in the 2.4 GHz spectrum was wasteful of the resources. They believed that 40 MHz operation should only be allowed in the 5 GHz spectrum. Furthermore they suggested that the use of 40 MHz channels should be optional as it would increase the cost of producing chips. The backers of TGn Sync felt that the next 802.11 PHY was not around the corner. They also felt that the market was beginning to become interested in home media systems which would require high throughputs between they TV and home network. They thought that if they got 802.11n right it would be the technology of choice for that link. As a result they were aggressively pursuing how to create the fastest possible wireless link over 10-20m. They wanted support for 40 MHz channels to be mandatory. As spectrum regulations differ from country to country WWiSE were worried that 40MHz channels might not be allowed in such countries and therefore the product may not be marketable on a world wide scale.
Physical Layer Improvments
Channel Bonding
The controversial channel bonding feature can double the bandwidth by combining two 20 MHz channels. There are a number of rules pertaining to this. Because of the low number of channels available in the 2.4 GHz spectrum devices are required to check if there are any other 802.11 devices active on the channels being proposed for use. If there are, channel bonding may not be used.
Interestingly, this revives interest in the sometimes forgotten 5 GHz band. Many companies such as Cisco and Linksys are now producing high end 802.11n AP which have two radios. One for use in the 2.4 GHz band and another for use in the 5 GHz band. By taking advantage of the 5 GHz band, many people will be able to use channel bonding to get the highest possible 802.11n performance. Most reports seem to suggest that channel bonding can double, and sometimes more than double, the data rate at short rage [1]. However, these gains dwindle as the distance increases. Furthermore, also be mindful that data rate is not the same as actual throughput.
The TGn Sync proposal and the WWiSE proposal also disagreed in the manner that they would use 40 MHz channels. Under 802.11a/g operation, the side-bands of the transmissions are filtered. If two, 20 MHz channels are added together, there is channel bandwidth in the middle of the two 20 MHz channels that is wasted because of these spectral bands (See Fig 1). The TGn Sync group wanted to reclaim this lost space under 40 MHz operation (See Fig 2). A final difference between the two proposals was that the TGn Sync wanted the ability to use short guard bands to increase performance. Guard bands are explained in further detail below.
Short Guard Interval
Another way that bandwidth improvements are being made is by using shorter guard interval. Wireless transmissions represent data by transmitting symbols. In the highest modulation of 802.11a/g each symbol represents 216 bits. In 802.11a/g each symbol takes 4 us to transmit.
As a side note if you ever wondered where the 54 Mb/s comes from for 802.11a/g (1,000,000 us / 4 us) * 216 = 54,000,000 b/s or 54 Mb/s. So by reducing the guard interval between symbols, you will be able to increase the number of symbols you can transmit per second. I personally believe that this will only work at short ranges. At longer ranges I would expect that ISI[3] will cause multi-path interference. Longer guard periods allow more distant echoes to be tolerated [4].
MIMO and spatial multiplexing
MIMO is a smart antenna system under active research. It is currently being deployed in a range of different wireless systems. MIM) (Multiple Input Multiple Output) is a system of sending and receiving radio signals over a number of antennas. There are a number of different ways that you can use MIMO to increase range/signal. We are going to concentrate on spatial multiplexing. You will hear different APs being referred to as a 3x2 or 4x4 systems. The first number is the number of transmit antennas. The second number is the number of receive antennas. Having more antennas enables an AP to concurrently transmit greater numbers of spatial streams. The greater number of streams the greater potential data rates may be achieved. In MIMO systems, each antenna can transmit its own independent stream. The receiving stream should be able to receive this one multiplexed wireless signal and extrapolate each individual stream out again.
CSIRO Patent Issues
The CSIRO, the Australian Commonwealth Scientific and Industrial Research Organisation claimed to have patents over the Spatial multiplexing of multiple signals using MIMO antennas. They claimed that a number of organisations were infringing on their patents. The 802.11n working group became worried that the companies manufacturing this equipment would be sued. While I do not pretend to understand the technical details of the CSIROs work, their were a number of companies that were forced to withdraw their products from the market. These moves make me think that the CSIROs claims over this technology was very real. In early 2009 a settlement was reached between the manufacturers and the CISRO. You can find the patent here [2].
MAC Layer Improvements
This section discusses the 802.11n MAC layer efficiency enhancements. To complement the increased data rates being offered in 802.11n, it was recognised [9, 8, 10, 14, 13, 15] that MAC layer changes were also necessary. With higher data rates, efficiency will worsen because, the fixed overheads such as preambles and IFS will become an increasingly large component of transmission time. Also, because the frames will be serialised faster, these fixed delays will have to be performed more frequently. To reduce these overheads, the 802.11e BlockAck function and the 802.11n frame aggregation function was introduced.
802.11e BlockAck
The IEEE 802.11e BlockAck function enables senders to transmit multiple packets before requiring an acknowledgement. When packets are acknowledged, a single BlockAck is sent rather than an individual acknowledgement for each packet. The 802.11e block ack function can significantly reduce the ack overhead in 802.11.
While there are two types of block acknowledgements, immediate BlockAck and delayed BlockAck, for brevity we only consider the more efficient immediate BlockAck. Using this block acknowledgements has a number of benefits. The reduction in the number of acknowledgements transmitted is the most obvious. Figure [fig:Standard-802.11-DCF] demonstrates the difference between standard 802.11 and BlockAck 802.11. Note that the IFS between the data frames in block ack in figure 3 is SIFS rather than DIFS. Subsequently, the use of BlockAck saves on IFS as well as the number of transmitted acks.
The protocol operation is relatively simple, the number of frames that can be sent in a block is defined by the AP during the BlockAck transmission setup. Two new 802.11 frames are required for setup and tear-down, ADDBA (Add BlockAck) and DELBA (Delete BlockAck). In the case of immediate BlockAck, when the sender has finished transmitting a block of packets, it will send a BlockAck request to the receiver. The receiver will then respond with a BlockAck to acknowledge the successfully received frames. Any frames sent, but not acknowledged will be resent as part of the next block of transmissions. If a frame is lost, the receiver will buffer the packets received until the lost frame has been recovered. Buffering of packets is done so that packets can be passed to the upper layers in order. A more thorough treatment is given in the IEEE 802.11 standard [12] and the IEEE 802.11e [11] amendment.
A reduction in acks and IFS delays can significantly reduce overheads, however, the reduction in efficiency is difficult to precisely identify as it will vary with a number of factors. Some studies suggest that for bulk transfers with large packet sizes, the performance benefit of block ack is approximately 10% [8, 9].
Most academic work suggests that BlockAcks increase the throughput but also express concern over the number of packets transmitted in a block because of the affect on time sensitive traffic [9, 8, 10, 14, 13, 15] . Obviously it is more efficient to transmit a larger number of packets in a block because larger blocks mean that fewer layer 2 acks must be transmitted. However, the problem with transmitting larger blocks is delay. For these reasons block size is a trade-off between efficiency and delay [9, 8, 10, 14, 13, 15] . Cabral et al [9] believes that the delays added by block acks means that the ideal size is between 12 and 16 packets which makes transmissions 10% more efficient [8, 9]
.802.11n frame aggregation
By concatenating multiple frames together time can be saved on IFS and preambles. This is not a new idea, Tourilhes [17] published a similar design in 1998 and since then, frame aggregation has been used to increase performance in proprietary implementations.
A-MSDU
There are two forms of frame aggregation in 802.11n, these are known as A-MSDU (Aggregated MAC Service Data Unit) and A-MPDU (Aggregated MAC Protocol Data Unit). A-MSDU can be thought of as micro aggregation because it will be used to join multiple small frames into one large frame. Efficiency savings can be made by using one MAC header, preamble, IFS and FCS (Frame Check Sum). The manner in which A-MSDU aggregates frames is shown in figure [fig:A-MSDU] . As only one checksum is generated, if a single part of the transmission is corrupted, all of the aggregated frames must be retransmitted. In 802.11, the chance of errors increase as the frame grows so A-MSDU is limited to 7935 bytes [1]. The other limitation is that the frames being aggregated must have the same source address, destination address and QoS class.
A-MPDU
If A-MSDU is micro aggregation, A-MPDU is macro aggregation as it is designed to merge fully sized frames or A-MSDU's together to further save on preambles and IFS times. Figure [fig:A-MPDU] shows that in A-MPDU both MAC headers and the FCS are retained. In addition, a 4 byte MPDU delimiter is added to each frame. The reason for this is because A-MPDU is designed to aggregate up to 64k and thus the individual frames within the aggregated packet must be reliable. Put simply, the loss of one frame within the A-MSDU should not result in the loss of the entire block.
The mechanism used to provide reliability within the A-MPDU is worthy of detailed discussion. Note that in figure [fig:A-MPDU] a frame delimiter and padding is added to the segment. The MPDU delimiter and specifically the length field within this delimiter is key to A-MPDU's because it allows the receiver to count the number of bytes in each frame. This is used to determine where aggregated frames begin and end. If the FCS of one frame fails, the receiver can skip to the following frame. However, it is likely that if the frame FCS is corrupt, the length field in the delimiter may also be corrupt. If the delimiters own CRC fails the receiver will search forward on every 32-bit (4 byte) boundary looking for data that looks like a delimiter. There is supposedly a good chance of the receiver predicting the next delimiter[1]. Variable lengths of padding are added to the tail of frames to ensure that every delimiter starts on a 4 byte boundary. These mechanisms ensure reliability within A-MPDUs, or simply, that the loss of one packet within a A-MPDU does not result in the loss of others.
Criticisms of BlockAck and A-MPDU
Efficiency can be gained by transmitting blocks of packets because fewer layer 2 acks must be transmitted. However, the problem with transmitting larger blocks of data, whether through block acks and/or A-MPDU is delay. There are two types of delays that may be problematic.
The first type of delay is simply the media sharing/contention delay. A old argument for limiting the size of packets transmitted over any medium is that large packets take a longer time to serialise. If a time sensitive packet, such as a voice packet with limited jitter tolerance, gets queued behind a large data packet, transmission delays may vary. BlockAcks/A-MPDU has been designed to allow up to 64k to be sent before acknowledgement; reviving the old media sharing/contention argument. With this amount of data being transmitted, our calculations suggest that 64k of data, not including MAC back-off, preambles or acks, just data, at 54 Mb/s will take 9.5 ms to serialise. A voice packet that loses contention to other stations transmitting 64k blocks may cause an intolerable amount of jitter. Admittedly, definitions of tolerable delay will differ with different networks and applications, our argument is that the larger block sizes, which are most efficient, may not facilitate fair and jitter free networks.
The second disadvantage is the delay imposed when waiting for the recovery of frames from a block buffered at the receiver. Frames that are lost within a block will temporarily prevent subsequent frames from being delivered to the upper layers. This buffering function is performed to maintain the transmission order of data. Due to the way the medium is shared, any lost packet(s) may not be retransmitted until the station has re-won contention for the medium. If other stations win contention and transmit large blocks of data, there may be a considerable delay before contention is re-won and the lost packet(s) can be retransmitted. Lengthy delays may be imposed before the block can be passed to the upper layers. Thus, by allowing block transmissions, the time required to recover lost packets and pass them to the higher layers can considerably increase. It also means that when missing packets are successfully resent, an entire block of packets will be simultaneously passed to the upper layers causing potential TCP compression problems. For these reasons block size is a trade-off between efficiency and delay [9, 8, 10, 14, 13, 15] . Cabral et al [9] believes that the delays added by block acks means that the ideal size is between 12 and 16 packets.
It is also interesting to predict the affect that these block transmissions of data may have on TCP. TCP is the end-to-end protocol that carries the majority of Internet traffic is responsible for flow control and mediates the transmission of data using a window scheme. MAC layer interaction with TCP is very important as TCP determines the end-to-end transfer rate. TCP has a self clocking mechanism whereby returning TCP acknowledgements prompt the release of new data segments onto the medium. The goal of TCP is to recover errors and facilitate the fastest and most fair transport of data. To do this, the release of TCP data packets onto the medium should be smooth and paced. Excessive traffic bursts are problematic for TCP as they may suddenly increase queue sizes causing packet drops. A lot of work has gone into reducing the natural traffic bursts caused by TCP [19, 7, 18, 6] . This symptom is often referred to as ack compression [7] . Sundaresan [16] made specific reference to this problem with TCP and expects it to worsen in ad hoc networks where media contention is greater.
I question the extent to which transmitting blocks of packets may further degrade this natural effect by compressing data packets arriving in blocks. When TCP receivers experience large numbers of back-to-back TCP segments in blocks, the subsequent TCP acks will also be generated and transmitted in blocks. Rather than the natural multiplexing that occurs in current DCF where after every two TCP data segments received a TCP ack is transmitted, with large block sizes, many data packets will be received which may be replied to by blocks of back-to-back acks. This will increase ack compression and the loss of multiplexed TCP data frames with TCP acks may degrade end-to-end performance in high bandwidth high RTT environments. TCP senders receiving compressed TCP acks can either dump large numbers of packets onto the network, suddenly increasing router buffers and the likely-hood of queuing losses, or, pace the transmission of data packets more evenly and smoothly, but at the price of additional delay. We believe that this issue is worthy of further study. To conclude, transmitting packets in blocks may make transmission more efficient [8, 9], however, these efficiency gains may come at the cost of other network goals.
References
[1] Eldad Perahia and Robert Stacey. Next Generation Wireless LANs : Throughput, Robustness, and Reliability in 802.11n. Cambridge University Press, 2008.
[2] United States Patent No. 5,487,069, Wireless LAN Inventor(s): O'Sullivan; John D. (Ermington, AU), Daniels; Graham R. (Willoughby, AU), Percival; Terence M. P. (Lane Cove, AU), Ostry; Diethelm I. (Petersham, AU), Deane; John F. (Eastwood, AU) Issued on: January 23, 1996 Filed on: November 23, 1993 Application No.: 08/157,375 http://www.patentfizz.com/fizzdisplay.php?patno=5487069
[3] http://en.wikipedia.org/wiki/Intersymbol_interference
[4] http://en.wikipedia.org/wiki/Guard_interval
[5] M.S. Gast, 802.11 Wireless Networks: The Definitive Guide O'Reilly, 2005
[6] Amit Aggarwal, Stefan Savage, and Thomas Anderson. Understanding the performance of tcp pacing. In Mar 2000.
[7] H Balakrishnan, V N Padmanabhan, G Fairhurst, and M Sooriyabandara. Tcp performance implications of network path asymmetry. IETF RFC 3449, December 2002.
[8] Orlando Cabral, Alberto Segarra, and Fernando J Velez. Implementation of ieee 802.11e block acknowledgement policies based on the buffer size. In Infocom, volume 3, pages 1157-1165 vol.3, 14th European Wireless Conference, pages 1-7, June 2008.
[9] Orlando Cabral, Alberto Segarra, and Fernando J Velez. Implementation of multi-service ieee 802.11e block acknowledgement policies. IAENG International Journal of Computer Science, 36:1:1, June 2009.
[10] Guido R Hiertz, Lothar Stibor, Jarg Habetha, Erik Weiss, and Stefan Mangold. Throughput and delay performance of ieee 802.11e wireless lan with block acknowledgments. In 11th IEEE. 802.11e-ieee European Wireless Conference, 2005.
[11] IEEE. 802.11 - ieee standards for information technology-standard telecommunications and information exchange between systems local and metropolitan area networks specific requirements part 11: Wireless lan medium access control (mac) and physical layer (phy) specifications amendment 8: Medium access control (mac) quality of service enhancements. IEEE Standards, 2005.
[12] IEEE. 802.11 - ieee standards for information technology - telecommunications and information exchange between systems - local and metropolitan 8 area network - specific requirements - part 11: Wireless lan medium ac- cess control (mac) and physical layer (phy) specifications. IEEE standards, 2007.
[13] Tianji Li, Qiang Ni, Theirry Turletti, and Yang Xiao. Performance analysis of the ieee 802.11e block ack scheme in a noisy channel. In IEEE BroadNets, pages 551-557, 2005.
[14] Tianji Li, Qiang Ni, and Yang Xiao. Investigation of the block ack scheme in wireless ad hoc networks: Research articles. Wireless Communications & Mobile Computing, 6(6):877-888, 2006.
[15] Arun Ranjitkar and Young-Bae Ko. Performance enhancement of ieee 802.11s mesh networks using aggressive block ack scheme. In The International Conference on Information Networking, 2008.
[16] Karthikeyan Sundaresan, Vaidyanathan Anantharaman, Hung-Yun Hsieh, and Raghupathy Sivakumar. Atp: A reliable transport protocol for ad hoc networks. IEEE Transactions on Mobile Computing, 4(6):588-603, 2005. IEEE International Conference on Universal
[17] Jean Tourrilhes. Packet frame grouping: improving ip multimedia performance over csma/ca. In Personal Communications, volume 2, pages 1345-1349 vol.2, Oct 1998.
[18] David X Wei, Pei Cao, and Stevens H Low. Tcp pacing revisted. In Infocom, 2006.
[19] Lixia Zhang, Scott Shenker, and David D. Clark. Observations on the dynamics of a congestion control algorithm: The effects of two-way traffic. In ACM Computer Communication Review, pages 133-147, 1991.