Scalable voip mobility intedration and deployment- P27 pdf

260 Chapter 6 www.newnespress.com RADIUS Server WLAN Controller Access Points Mobility Domain Master Key (MSK) Master Key (MSK) PMK-R0 PMK-R1 PTK PMK-R1 PMK-R0 is derived here, but not transmitted PTK R0 Key Holder R1 Key Holder PTK Holder a) With a wireless controller architecture, locating where the 802.11r key holders can be rather simple. The mapping is, in fact, almost the same as for WPA2, with the PTK (connection key) holder being the access point, and the PMK holders all being in the controller. On a handoff to a new access point, that access point only needs to request a new PTK from the controller, which will produce a new PMK-R1 along the way, using the original PMK-R0. The main thing to remember is that there is only one PMK-R0 for the entire mobility domain. RADIUS Server Access Points Mobility Domain Master Key (MSK) Master Key (MSK) PMK-R0 PMK-R1 PTK PMK-R1 PMK-R0 is derived here, but not transmitted PTK R0 Key Holder R1 Key Holder PTK Holder a) With a standalone access point architecture, the mapping is quite different. There is no centralized PMK-R0 holder. Instead, the first access point that the client performs 802.1X becomes the R0 Key Holder. When the client moves to another access point, the new access point needs to discover which original access point is the R0 Key Holder, and then request a PMK-R1 from it. The new access point will then generate the PTKs as needed, from its local store. In this way, each access point still has a PMK and a PTK, just as with WPA2, but there may be a higher-order PMK holder elsewhere in the network if the cliient has handed off. Figure 6.8: Ways of Embedding 802.11r in Wi-Fi Voice Mobility over Wi-Fi 261 www.newnespress.com 802.11k has many potential uses beyond voice, but because voice network depend on the efficient functioning of the underlying technology, it is worth looking into 802.11k here. The reader is warned, however, that the material here can become a little dense, and you may wish to skip around to get a better sense of how all of these new capabilities fit together. 6.2.6.1 The Capabilities of 802.11k 802.11k contains a long list of features, as it is more a framework and a collection of independent uses of that framework than it is a solution to one specific problem. Many of these features come with variants, based on the willingness of vendors to implement the features. The way that the access point and client can determine which subset of 802.11k the devices may support is through the exchange of an RRM Extended Capability information element. Table 6.11 gives the complete list of capabilities that can be expressed. This extensive list is overwhelming, belying the fact that 802.11k is made of multiple methods of performing roughly the same thing. That does not meant that there is no usefulness within the standard, but rather that interoperability among vendors is more important than ever. The following sections will expand on the features more likely to apply to a voice mobility network with Wi-Fi as one of the legs. 6.2.6.2 Requests and Reports Not every capability within 802.11k is a request and report, but most of it is. The idea of the request and report structure came originally from 802.11h, which is the amendment concerning performing radar detection for DFS bands, first in Europe and now applicable to the United States and Canada as well. In the context of DFS, the goal is to request or require stations to scan in order to determine the presence of radar. 802.11k has broadened out the purpose of the mechanism, allowing for a broad number of properties to be measured and reported. A request for measurement is generally requested for in a Radio Measurement Action frame, generically described in Table 6.12. The dialog token specifies which of the possibly multiple outstanding requests a response matches up to, and is specified by the requester and copied by the responder. The number of repetitions specifies how many times the report is to be produced from new information and sent to the responder, with a value of 65,535 (all bits set) specifying to continue forever, until explicitly cancelled. The contents of each Measurement Report element are given in Table 6.13. The measurement token is a unique number of this specific measurement, to identify it if multiple measurements are processing in the background. (They serve a different purpose from the dialog tokens, and the two numbers are not related.) The measurement request 262 Chapter 6 www.newnespress.com Table 6.11: The 802.11k RRM extended capability information element Link Measurement Neighbor Report Parallel Measurements Repeated Measurements Beacon Passive Beacon Active Beacon Table Beacon Reporting Conditions … Bit: 0 1 2 3 4 5 6 7 … Frame Measurement Channel Load Noise Histogram Statistics Measurement LCI Measurement LCI Azimuth Transmit Stream Triggered Transmit Stream … Bit: 8 9 10 11 12 13 14 15 … AP Channel RRM MIB Operating Channel Max Measurement Duration Non-operating Channel Max Measurement Duration Measurement Pilot Measurement Pilot Information Neighbor Report TSF Offset RCPI … Bit: 16 17 18–20 21–23 24–26 27 28 29 … RSNI BSS Average Access Delay BSS Available Admission Capacity Antenna Information Reserved Bit: 30 31 32 33 34–39 Voice Mobility over Wi-Fi 263 www.newnespress.com Table 6.12: 802.11k Radio measurement request action frame Category Action Dialog Token Number of Repetitions Measurement Request Element 1 byte 1 byte 1 byte 2 bytes n different copies Table 6.13: Measurement request element format Element ID Length Measurement Token Measurement Request Mode Measurement Type Measurement Request 1 byte 1 byte 1 byte 1 byte 1 byte variable Table 6.14: 802.11k Radio measurement report action frame Category Action Dialog Token Measurement Report Element 1 byte 1 byte 1 byte n different copies mode specifies how the measurement is to be made. The Parallel bit (bit 0) states that this measurement is to run in parallel with the next measurement request within the same frame. The Enable bit (bit 1), Request bit (bit 2), and Report bit (bit 3) are used in concert to determine whether the sender is requesting a new background (or autonomous) report series to begin or end with this request, or whether the request is to run right away. The Duration Mandatory bit (bit 4) specifies that the measurement is to run for exactly a certain amount of time, specified later in the Measurement Request itself. The notion of autonomous or background reporting exists to allow the requester to have the other device send reports as needed. A further refinement allows the requester to specify specific triggers, which the receiver uses to determine just when to send the autonomous reports. In this way, the request protocol can be used to set up some sort of background reporting agreement. How each report works is specified with the reports. The response to a request comes in the format shown in Table 6.14, with the contained Measurement Report shown in Table 6.15. The measurement report mode specifies the type of report, and can be value 2 to indicate that the reporter is incapable of generating this sort of report, or the value 4 to indicate that the reporter refuses to generate this sort of report, probably given an unspecified decision that the reporting work is too burdensome for the client at the time. One can see that there is a large number of moving parts to this apparatus. The use for this complexity will hopefully become clearer as we progress. 264 Chapter 6 www.newnespress.com 6.2.6.3 Beacon Reports The first useful mechanism for 802.11k, especially as it applies to voice, is the beacon report. The beacon report is a report from the client, to the access point, about the entries within its scanning table. From the discussion on scanning in Section 6.2.2, one can imagine that learning about the contents of the scanning table can have some positive specific uses. The beacon report request comes in three variants: active reporting, passive reporting, and beacon table reporting. These map directly to the scanning types: an active report is one in which the client was demanded to perform an active scan first; a passive report is one in which the client was demanded to perform a passive scan first; and a beacon table report is where the client is only required to give what it currently has in its scanning table, no matter how stale. Table 6.16: Beacon request format Regulatory Class Channel Randomization Interval Measurement Duration Measurement Mode BSSID SSID Reporting Detail AP Channel Report 1 byte 1 byte 2 bytes 2 bytes 1 byte 6 bytes (optional) (optional) (optional) Table 6.15: Measurement report element format Element ID Length Measurement Token Measurement Report Mode Measurement Type Measurement Report 1 byte 1 byte 1 byte 1 byte 1 byte variable Table 6.16 specifies the contents of the beacon request. The regulatory class and channel together specify which channel the client is to scan or report on. (Regulatory class is needed with the channel, because some channel numbers are reused in different bands.) The value of zero for the channel means to report on all channels in the band; the value of 255 means to report on all channels listed in the AP Channel Report. The randomization interval and measurement duration are used to specify whether the report should start now or after a delay, and how long the scan should take. The measurement mode specifies whether the request is for a passive scan (0), active scan (1), or beacon table (2). The BSSID is used to limit the request to produce the entry for just the given BSSID; this restriction is ignored if the BSSID given is all zeros. Furthermore, the optional SSID limits the scanning for SSIDs that match only, thus allowing the requesting access point to ignore other SSIDs. Finally, the requester can specify just what it gets back about each entry. The entry is not returned as arbitrary information; rather, a subset of the fields in each access point’s beacon or probe response frame is returned, based on the contents of the reporting detail. The reporting Voice Mobility over Wi-Fi 265 www.newnespress.com detail can be for nothing extra (0), or for requested parts of the beacon, using an added IE that appears at the end of the request and would be inappropriate to go into that level of detail here. (A good wireless protocol analyzer will be able to satisfy any curiosity you may have, if a device is using this protocol.) The client that receives a request may choose to perform the request, or reject it for being too busy. If the client accepts the request, it must perform the actions and report on them. Now, there is no requirement that the client modify its real scanning table, the one it uses to make handoff decisions on, or that it report back the contents of that table to the access point. It is allowed to keep a separate table just for the purposes of 802.11k. However, the hope behind the amendment is that the scanning and beacon table processes are related. Table 6.17: Beacon response format Regulatory Class Channel Measurement Start Time Measurement Duration Reported Frame Information RCPI RSNI … 1 byte 1 byte 8 bytes 2 bytes 1 byte 1 byte 1 byte … BSSID Antenna ID Parent TSF Frame Body 6 bytes 1 byte 4 byes variable Table 6.17 shows the structure of the report. Each report provides information on exactly one BSSID. A Beacon Report fr-ame, a type of Management Report frame, will have multiple Management Report information elements, with one element containing one beacon report, to allow for reports to be sent back on multiple access points. The channel specifies what channel the access point was on. The measurement start time specifies when this measurement began, and the duration reports how long the measurement took. The reported frame information is set to zero. The RCPI provides a measure of the signal strength of the access point; the RSNI provides the signal-to-noise ratio for the same frame. The BSSID field contains the BSSID of the access point. The antenna ID field specifies which antenna the receiver heard the access point on, and is not terribly useful. The parent TSF field specifies the lowest four bytes of the timestamp clock on the client when it precisely heard the beginning of the beacon. Finally, the frame body contains all of the requested and fixed field bits of the access point. Considering the tremendous size of the requests and responses, especially when there is a high amount of density in the environment, one might wonder what the purpose of such a beacon report really is. The goal is to allow the access point to assign idle clients 266 Chapter 6 www.newnespress.com with the task of informing it what its neighboring access points are, for use in the neighbor report. 6.2.6.4 Neighbor Reports The neighbor report is requested for by a client from the access point, and specifies a list of neighboring access points. A client would request a neighbor report in order to supplement its scanning list, most likely to avoid having to stay off channel for a potentially long period of time. The information in the neighbor report comes from no particular source, however, and clients are not expected to replace their scanning table with the limited information returned in the neighbor report, or even to augment it in any significant way. Together with the beacon report mechanism, however, one can picture an architecture where clients do request neighbor reports to learn about off-channel access points, and where access points do assign idle clients with the task of keeping them up to date. Table 6.18 specifies the Neighbor Report Request Action frame. This frame is substantially simpler than the one used for beacon requests, because the client is not allowed to change the access point’s behavior or to require it to do work. Instead, the client can simply ask for a neighbor report list, and can specify an optional SSID to limit the results down to the given SSID, rather than see results for every SSID. Table 6.19: 802.11k Neighbor report response action frame Category Action Dialog Token Neighbor Report Elements 1 byte 1 byte 1 byte multiple Table 6.18: 802.11k Neighbor report request action frame Category Action Dialog Token SSID 1 byte 1 byte 1 byte (optional) The format of the neighbor report element is shown in Table 6.20. The BSSID is that of the access point. The BSS Info field provides information as to whether the neighbor supports the same security as the current access point, can participate in opportunistic key caching (Section 6.2.4) with this access point, or supports a subset of 802.11 capabilities. The channel and radio type of the neighbor is reported. Additionally, if the access point knows the timestamp clock of the neighbor, the country of the neighbor, the RRM capabilities of The access point will respond right away with a Neighbor Report Response Action frame, as shown in Table 6.19. This response includes a number of Neighbor Report elements, each element corresponding to one neighbor. Voice Mobility over Wi-Fi 267 www.newnespress.com the neighbor, or how many other BSSIDs the neighbor supports, these can be communicated in the last four optional information subelements. Table 6.20: Neighbor report element Element ID Length BSSID BSS Info Regulatory Class Channel PHY Type TSF Country RRM Capabi- lities Multiple BSSID 1 byte 1 byte 6 bytes 4 bytes 1 byte 1 byte 1 byte (opt.) (opt.) (opt.) (optional) Table 6.21: Link measurement request frame Category Action Dialog Token Transmit Power Used Maximum Power 1 byte 1 byte 1 byte 1 byte 1 byte Again, this is a somewhat involved protocol, and the meaning of most of what you see here will not necessarily become required knowledge, as a good protocol analyzer will shed light on what the protocol is communicating. But the intent is clear: the neighbor report is designed to provide a way for the client to find a neighbor that it could very well hand off to, without itself having to scan. In a perfect world, this can reduce scanning times, and it still remains to be seen whether 802.11k will be successful in reducing times. Unfortunately, some part of the process cannot be eliminated—DFS bands, for example, always require a passive scan of the channel, whether the client is told about the access point’s presence on that channel or not. However, more information can be better than less, and the neighbor report mechanism aims to provide it. Now, we can see that the neighbor report can be filled in from information gotten by a beacon report. 6.2.6.5 Link Measurement and Power Reporting It is not possible for a client or access point to guess what power the other is using. Especially for systems that engage in dynamic transmit power control (see Section 6.1.3), if the client or access point wants to make a decision on the basis of the power level at which the other device is transmitting, it needs to find this information out explicitly. To accomplish this, 802.11k provides for a method for requesting a link measurement. A link measurement is an exchange where the requester tells the power level it is sending at, and the reporter returns with what power level and SNR it saw that frame received at, thus letting the requester know its link margin to the other device. Table 6.21 shows the contents of the Link Measurement Request frame. 268 Chapter 6 www.newnespress.com The responder puts together an immediate response formatted as specified in Table 6.22. The TCP Report element, given in Table 6.23, specifies the power that the responder is sending at. Its transmit power field is that of the link measurement response, and the link margin field is the expected link margin as measured in a possibly proprietary way by the responder. The receive and transmit antenna IDs are to help determine which antenna is being used in complex, sectorized solutions. The RCPI reports the signal strength of the originalLinkMeasurementrequestattheresponder,andtheRSNIreportsthesignal-to- noise ratio. Table 6.24: Traffic stream request Randomization Interval Measurement Duration Peer Address Traffic ID Bin 0 Range Triggered Reporting 2 bytes 2 bytes 6 bytes 1 byte 1 byte (optional) Table 6.22: Link measurement response frame Category Action Dialog Token TPC Report Element Receive Antenna ID Transmit Antenna ID RCPI RSNI 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte Table 6.23: TPC report element Element ID Length Transmit Power Link Margin 1 byte 1 byte 1 byte 1 byte With this much information available, no device lack knowledge of the transmit power or link margin of the other. 6.2.6.6 Traffic Stream Metrics 802.11k also allows for one device to ask the other about the quality of the admission control flows that it has. This is useful for inferring the voice quality of the link, and thus allowing either side to take action to improve performance if something is going wrong. Table 6.24 shows the information that is placed in the measurement request for these metrics. The peer address is the address of the device whose performance wishes to be measured. The traffic ID is the TID of the admitted stream that the requester would like to find out about. The Bin 0 Range field is used to specify the properties of the histogram that is returned. Finally, if a triggered reporting element is given, the requester can specify that Voice Mobility over Wi-Fi 269 www.newnespress.com the reporter send a report whenever conditions cross certain thresholds. The sorts of thresholds which can be used include reporting because of excessive average errors (lost packets), and consecutive errors. … Discarded Frame Count Failed Frame Count Multiple Retry Count CF Polls Lost Count Average Queue Delay Average Transmit Delay … 4 bytes 4 bytes 4 bytes 4 bytes 4 bytes 4 bytes … Bin 0 Range Bin 0 Bin 1 Bin 2 Bin 3 Bin 4 Bin 5 1 byte 4 bytes 4 bytes 4 bytes 4 bytes 4 bytes 4 bytes The report format is given in Table 6.25. This report includes both exact counts and a histogram of the nature of the errors. The transmitted frame count specifies the number of frames sent successfully for the flow. The discarded frame count specifies the number of frames that could not be delivered and were thrown away without any retransmissions having been knowingly delivered. The failed frame count specifies how many frames were lost, just like the discarded count, but excluding frames that timed out because they were in a buffer for too long. The multiple retry count specifies the number of frames that took more than one try to be successfully delivered. The CF Polls lost field can be ignored, as CF Polling belongs to a part of the standard not used in WMM. The average queue delay is the amount of time packets tend to be delayed until they start transmitting on the air. The average transmit delay is the amount of time packets tend to be delayed until they are successfully completed, including retransmissions. The histogram measures delay, and is divided up into five bins, where each bin measures a range of values double that of the previous bin, starting at Bin 1. The Bin 0 Range specifies the amount of time the delay value for Bin 0 covers. For example, if Bin 0 Range is equal to 10, then Bin 0 covers delays from 0 to 10.24ms. That would make Bin 1 cover the range from 10.24ms to 20.48ms, and Bin 2 would cover the range from 20.48ms to 40.96ms, and so on. With this information, each side can measure the loss rates of the other, as well as the delay profile. 6.2.6.7 Other Features of 802.11k 802.11k includes a plethora of other features, many of which are not likely to be as useful for voice mobility deployments. 802.11k includes a provision for reporting on the noise levels that a client sees. It also includes a provision for reporting on the activity of each device in the air, based on frame counts. A peculiar mechanism known as measurement pilot frames exist, which serve as frequent, miniature versions of beacons. This could have been useful for aiding in the . within the standard, but rather that interoperability among vendors is more important than ever. The following sections will expand on the features more likely to apply to a voice mobility network. as one of the legs. 6.2.6.2 Requests and Reports Not every capability within 802.11k is a request and report, but most of it is. The idea of the request and report structure came originally. is the amendment concerning performing radar detection for DFS bands, first in Europe and now applicable to the United States and Canada as well. In the context of DFS, the goal is to request