WMM Admission Control | Voice Mobility with Wi-Fi

Building on even more of the specification in the 802.11e quality-of-service amendment is WMM Admission Control. This specification and interoperability program from the Wi-Fi Alliance, which is required to achieve Voice Enterprise certification, uses an explicit layer-2 reservation scheme. This scheme, in a similar vein as the lightly used RSVP protocol (RFC 2205), requires the mobile device to reach out and request resources explicitly from the access point, using a new protocol built on top of 802.11 management frames.

This protocol is heavily dependant on the concept of a traffic specification (TSPEC). The TSPEC is created by the mobile phone, and specifies how much of the air resources either or both directions of the call (or whatever resource is being requested) will be taken. The access point processes the request as an admission controller (a function often placed literally on the controller, by coincidence), which is in charge of maintaining an account of which clients have requested what resources and whether they are available.

The overall protocol is rather simple. The mobile device, usually when it determines that it has a call incoming our outgoing, will send an Add Traffic Stream (ADDTS)Request message (a special type of Action management frame) to the access point, containing the TSPEC that will be able to carry the phone call. The access point will decide whether it can carry that call, based on whatever scheme it uses (see following discussion), and send an ADDTS Response message stating whether the stream was admitted.

WMM Admission Control can be set to mandatory or optional for each access category. For example, WMM Admission Control can be required for voice and video, but not for best effort and background data. What this would mean is that no client is allowed to transmit voice or video packets without first requesting and being granted admission for flows in those access categories, whereas all clients would be allowed to freely transmit best effort and background data as they see fit. Which access categories require admission control is signaled as a part of the WMM information element, which goes out in beacons and some other frames.

For WMM Admission Control, it is worth looking at the details of the concepts. The main concept is one of a traffic stream itself, and how it is identified and recognized. Traffic streams are represented by Traffic Identifiers (TID), a number from 0-7 (the standard allows up to 15, but WMM limits this to only 7) that represents the stream. Each client gets its own set of eight TIDs to use.

Each traffic stream, represented by its TID, maps onto real traffic by naming which of the eight priority values in WMM will belong to this traffic stream. Thus, if the phone intends to send and knows it is going to receive priority 7—recall that this is the highest of the two voice AC priorities—it can establish a traffic stream that maps priority 7 traffic to it, and get both sides of the call. In order for that to work, the client can specify whether the traffic stream is upstream-only, downstream-only, or bidirectional. It is possible for the client to request both an upstream-only and downstream-only stream mapping to the same priority (different TIDs, though!), if it knows that the airtime used by the downstream side is different than the upstream side—useful for video calls—or it may request both at once in one TID, with the same airtime usage. All of this freedom leads to some complexity, but thankfully there is a rule preventing there from being more than one downstream and one upstream flow (bidirectional counts as one of each) for each access category. Thus, the AC_VO voice access category will only have one admitted bidirectional phone call in it at any given time.^[*]

The client requests the traffic stream using the TSPEC.

Table 1 shows the contents of the TSPEC that is carried in an ADDTS message.

Table 1: WMM admission control TSPEC 

TS Info	Nominal MMSDU Size	Maximum MSDU Size	Minimum Service Interval	Maximum Service Interval	Inactivity Interval	Suspension Interval	Service Start Time
3 bytes	2 bytes	2 bytes	4 bytes	4 bytes	4 bytes	4 bytes	4 bytes

Minimum Data Rate	Mean Data Rate	Peak Data Rate	Maximum Burst Size	Delay Bound	Minimum PHY Rate	Surplus Bandwidth Allowance	Medium Time
4 bytes	4 bytes	4 bytes	4 bytes	4 bytes	4 bytes	2 bytes	2 bytes

There's quite a lot of information in a TSPEC, so let's break it down slowly, using the example of a 20 millisecond G.711 (nearly uncompressed) one-way traffic flow:

• The TS Info field (see Table 2) identifies the TID for the stream, the priority of the data frames that belong to this stream, what direction the stream is going in (00 = up, 01 = down, 10 = reserved, 11 = bidirectional), and whether the AC the stream belongs to is to be WMM Power Save delivery enabled (1) or not (0). The rest of the fields are not used in WMM Admission Control, and have specific values that will never change (Access Policy = 01, the rest are 0).

  Table 2: The TS info field 

  	Traffic Type	TID	Direction	Access Policy	Aggregation	WMM Power Save	Priority	TSInfo Ack Policy	Schedule	Reserved
  Bit:	0	1-4	5-6	7-8	9	10	11-13	14-15	16	17-23

• The Nomimal MSDU Size field mentions the expected packet size, with the highest-order bit set to signify that the packet size never changes. G.711 20ms packets are 160 bytes of audio, plus 12 bytes of RTP header, 8 bytes of UDP header, 20 bytes of IP header, and 8 bytes of SNAP header, creating a data payload (excluding WPA/WPA2 overhead) of 208 = 0×D0. Because the packet size for G.711 never changes, this field would be set to 0×80D0.
• The Maximum MSDU Size field specifies what the largest a data packet in the stream can get. For G.711, that's the same as the nominal size. There is no special bit for fixed sizes, so the value is 208 = 0×00D0. This can also be left as 0, as it is an optional field.
• The Inactivity Interval specifies how long the stream can be idle—no traffic matching it—in microseconds, before the access point can go ahead and delete the flow. 0 means not to delete the flow automatically, and that's the common value.
• The Mean Data Rate specifies, in bits per second, what the expected throughput is for the stream. For G.711, 208 bytes every 20 milliseconds results in a throughput of 83200 bits per second.
• The Minimum Data Rate and Peak Data Rate specify the minimum and maximum throughput the traffic stream can expect. These are optional and can be set to 0. For G.711, these will be the same 83,200 bits per second.
• The Minimum PHY Rate field specifies what the physical layer data rate assumptions are for the stream, in bits per second. If the client is assuming that the data rate could drop as low as 6Mbps for 802. Hag, then it would encode the field at 6Mbps = 6,000,000bps = 0×005B8D80.
• The Surplus Bandwidth Allowance is a fudge factor that the phone can request, to account for that packets might be retransmitted. It's a multiplier, in units of l/8192nds. A value of 1.5 times as an allowance would be encoded as 0×3000 = 001.1000000000000, in binary.
• The other fields are unused by the client, and can be set to 0.

In other words, the client simply requests the direction, priority, packet size, data rate, and surplus allowance.

The access point gets this information, and churns it using whatever algorithms it wants— this is not specified by the standard, but we'll look at what sorts of considerations tend to be used. Normally, we'll assume that the access point knows what percentage of airtime is available. The access point will then decide how much airtime the requested flow will take, as a percentage, and see whether it exceeds its maximum allowance (say, 100% of airtime used). If so, the flow is denied, and a failing ADDTS Response is sent. If not, the access point updates its measure of how much airtime is being used, and then allows the flow. The succeeding ADDTS Response has a TSPEC in it that is a mirror of the one the client requested, except that now the Medium Time field is filled in. This field specifies exactly how much airtime, in 32-microsecond units per second, the client can take for the flow.

The definition of how much airtime a client uses is based on what packets are sent to it or that it sends as a part of a flow. Both traffic sent by the client to the access point and sent by the access point to the client are counted, as well as the times for any RTSs, CTSs, ACKs, and interframe spacings that are between those frames. Another way of thinking about it is that the time from the first bit of the first preamble to the last bit of the last frame of the TXOP counts, including gaps in between. In general, you will never need to try to count this. Just know that WMM Admission Control requires that the clients count their usage. If they exceed their usage in the access category they are using, they have to send all subsequent frames with a lower access category—and one that is not admission control enabled—or drop them.

One advantage of WMM Admission Control is that it works for all traffic types, without requiring the network to have any smarts. Rather, the client is required to know everything about the flows it will both send and receive, and how much airtime those flows will take. The network just plays the role of arbiter, allowing some flows in and rejecting others. Thus, if the client is sufficiently smart, WMM Admission Control will work whether the protocol is SIP, H.323, some proprietary protocol, or even video or streaming data. The disadvantage of that, however, is that the client is required to be smart, and all of its pieces—from wireless to phone software—have to be well integrated. That pretty much eliminates most softphones, and brings the focus squarely on purpose-built phones. Furthermore, the client needs to know what type of traffic the party on the other side of the call will send to it. Some higher-level signaling protocols can convey this, such as with SDP within SIP, but doing so may be optional and may not always be followed. For a phone talking to a media gateway, for example, the phone needs to know exactly how the media gateway will send its traffic, including knowing the codec and packet rate and sizing, before it can request airtime. That can lead to situations in which the call needs to be initiated and agreed to by both parties before the network can be asked for permission to admit the flow, meaning that the call might have to be terminated by the network midway through ringing, if airtime is not available. Because WMM Admission Control is so new—by the time of publication, WMM Admission Control should be launching shortly and large amounts of devices may not yet be available—it remains to be seen how well all of the pieces will fit together. It is notoriously difficult for general-purpose devices to be built that run the gamut of technologies correctly, and so these new programs might be more useful for highly specific purpose-built phones.