230 Chapter 6 www.newnespress.com measure this for the administrator on an ongoing basis, the administrator is able to devote attention to other, more pressing matters. Active voice quality monitoring comes in a few flavors. SIP-based schemes are capable of determining when there is a voice call. This is often used in conjunction with SIP-based admission control. With SIP calls, RTP is generally used as the bearer protocol to carry the actual voice, SIP-based call monitoring schemes can measure the loss and delay rates for the RTP traffic that makes up the call, and report back on whether there are phones with suffering quality. In these monitoring tools, call quality is measured using the standard MOS or R-value metrics, as defined in Chapter 3 on voice quality. SIP-based schemes can be found in a number of different manifestations. Wireline protocol analyzers are capable of listening in on a mirror port, entirely independent of the wireless network, and can report on upstream loss. Downstream loss, however, cannot be detected by these wireline mechanisms. Wireless networks themselves may offer built-in voice monitoring tools. These leverage the SIP-tracking functions already used for firewalling and admission control, and report on the quality both measured by uplink and downlink loss. Purely wireless monitoring tools that monitor voice quality can also be employed. Either located as software on a laptop, or integrated into overlay wireless monitoring systems, these detect the voice quality using over-the-air packet analysis. They infer the uplink and downlink loss rates of the clients, and use this to build out the expected voice quality. Depending on the particular vendor, these tools can be thrown off when presented with WPA- and WPA2-encrypted voice traffic, although that can sometimes be worked around. Voicecallqualitymayalsobemonitoredbymeasurementsreportedbytheclientorother endpoint. RTCP, the RTP Control Protocol, may be transmitted by the endpoints. RTCP is able to encode statistics about the receiver, and these statistics can be used to infer the expected quality of the call. RTCP may or may not be available in a network, based on the SIP implementation used at the endpoints. Where available, RTCP encodes the percentage of packets lost, the cumulative number of packets lost, and interarrival packet jitter, all of which are useful for inferring call quality. At a lower layer, 802.11k, where it is supported, provides for the notion of traffic stream metrics (Section 6.2.6.6). These metrics also provide for loss and delay, and may also be used to determine call quality. However, 802.11k requires upgrades to the client and access point firmware, and so is not as prevalent as RTCP, and nowhere near as simple to set up as overlay or traffic-based quality measurements. 6.2 Inter-Access Point Handoffs In a voice mobility network with Wi-Fi as a major component, we have to look at more than just the voice quality on a particular access point. The end-user of the network, the person with a phone in hand, has no idea where the access points are. He or she just walks Voice Mobility over Wi-Fi 231 www.newnespress.com around the building, going in and out of range of various access points in turn, oblivious to the state of the underlying wireless network. All the while, the user demands the same high degree of voice quality as if he or she had never started moving. So now, we have to turn our focus towards the handoff aspect of Wi-Fi voice networks. LookingbackonhowWi-Finetworksaremadeofmultiplecellsofoverlappingcoverage,we can see that the major sources for problems with voice are going to come from four sources: 1. How well the coverage extends through the building 2. How well the phone can detect when it is exiting the coverage of one access point 3. How well the phone can detect what other options (access points) it has available 4. How quickly the phone can make the transition from the old access point to the new one Let’strytogainsomemoreappreciationofthisproblem.Figure 6.5 shows the wireless environment that a mobile phone is likely to be dwelling within. As the caller and the mobile phone move around the environment, the phone goes into range and out of range of different access points. At any given time, the number of access points that a client can see, and potentially connect to, can be on the order of a dozen or more in environments with substantial Wi-Fi coverage. The client’s task: determine whether it is far enough out of range of one access point that it should start the potentially disruptive process of looking for another access point, and then make the transition to a new access point as quickly as possible. The top part of Figure 6.5 shows the phone zigzagging its way throughaseriesofcells,eachonefromanaccesspointonadifferentchannel.Lookingat the same process from the point of view of the client (who knows only time), you can see how the client sees the ever-varying hills and valleys of the differing access points’ coverage areas. Many are always in range; hopefully, only one is strong at a time. The phone is a multitasker. It must juggle the processes of searching for new access points and handing off while maintaining a good voice connection. In this section, we’ll go into details on the particular processes the phone must go through, and what technologies exist to make the process simpler in the face of Wi-Fi. But first, we will need to get into some general philosophy. 6.2.1 The Difference Between Network Assistance and Network Control If you have read the sections on cellular handoff, you’ll know that there are broadly two different methods for phone handoffs to occur. The first method, network control, is how the network determines when the phone is to hand off and to which base station the phone is to connect. In this method, the mobile phone may participate by assisting in the handoff 232 Chapter 6 www.newnespress.com Access Point Channel 1 Access Point Channel 11 Access Point Channel 48 Access Point Channel 48 Access P oint Channel 44 Access Point Channel 44 Access Point Channel 40 Access Point Channel 40 Access Point Channel 40 Access Point Channel 36 Access Point Channel 36 Access Point Channel 6 Distance Signal Quality Figure 6.5: The Handoff Environment process, usually by providing information about the radio environment. The second method, network assistance, is where the network has the ability to provide that assistance, but the mobile phone is fundamentally the device that decides. For transitions across basic service sets (BSSs) in Wi-Fi, the client is in control, and the network can only assist. Why is this? An early design decision in Wi-Fi was made, and the organization broke away from the comparatively long history of cellular networking. In the early days of Wi-Fi, each cell was unmanaged. An access point, compared to a client, was thought of as the dumber of the two devices. Although the access point was charged with operating the power saving features (because it is always plugged in), the client was charged with making sure the connection to the network stayed up. If anything goes wrong and a connection drops, the client is responsible for searching out for one of any number of networks the client might be configured to connect to, and the network needed to learn only Voice Mobility over Wi-Fi 233 www.newnespress.com about the client at that point. It makes a fair amount of sense. Cellular networks are managed by service providers, and the force of law prevents people from introducing phones or other devices that are not sanctioned and already known about by the service provider. Therefore, a cell phone could be the slave in the master/slave relationship. On the other hand, with Wi-Fi putting the power of the connection directly into the hands of the client, the network never needs to have the client be provisioned beforehand, and any device can connect. In many ways, this fact alone is why Wi-Fi holds its appeal as a networking technology: just connect and go, for guest, employee, or owner. This initial appeal, and tremendous simplicity which comes with it, has its downsides, and quickly is meeting its limitations. Cellular phones, being managed entities, never require the user to understand the nature of the network. There are no SSIDs, no passphrases to enter. The phone knows what it is doing, because it was built and provisioned by the service provider to do only that. It simply connects, and when it doesn’t, the screen shows it and users know to drive around until they find more bars. But in Wi-Fi, as long as the handset owns the process of connecting, these other complexities will always exist. Now, you might have noticed that SSIDs and passwords have to do only with selecting the “serviceprovider”forWi-Fi,andoncetheuserhasthatdown(whichishopefullyonly once, so long as the user is not moving into hotspots or other networks), the real problem is with the BSSID, or the actual, distinct identities of each cell. That way of thinking has a lot to it, but misses the one point. The Wi-Fi client has no way of knowing that two access points—evenwiththesameSSID—belongstothesame“network.”IntheoriginalWi-Fi, thereisnotevenaconceptofa“network,”asthetermisneverused.Accesspointsexist, and each one is absolutely independent. No two need to know about each other. As long as some Ethernet bridge or switch sits behind a group of them, clients can simply pass from one to the other, with no network coordination. This is what I mean, then, by client control. In this view of the world, there really is no such thing as a handoff. Instead, there is just a disconnection. Perhaps, maybe, the client will decide to reconnect with some access point after it disconnects from the first. Perhaps this connection will even be quick. Or perhaps it will require the user to do something to the phone first. The original standards remain silent—as would have phones, had the process not been improved a bit. Network assistance can be added into this wild-west mixture, however. This slight shift in paradigm by the creators of the Wi-Fi and IEEE standards is to give the client more information, providing it with ways of knowing that two access points might belong to the same network, share the same backend resources, and even be able to perform some optimizations to reduce the connection overhead. This shift doesn’t fundamentally change the nature of the client owning the connection, however. Instead, the client is empowered with increasingly detailed information. Each client, then, is still left to itself to determine what to do and when to do it. It is an article of faith, if you will, that how the client 234 Chapter 6 www.newnespress.com determineswhattodois“beyondthescopeofthestandard,”aphraseintheartmeaning that client vendors want to do things their own way. The network is just a vessel—a pipe for packets. You’ll find, as you explore voice mobility deployments with Wi-Fi as a leg, that this way of thinking is as much the problem as it is a way to make things simple. Allowing the client to make the choice is putting the steering wheel of the network—or at least, a large portion of the driving task—in the hands of hundreds of different devices, each made by its own manufacturer in its own year, with its own software, and its own applications. The complexity can become overwhelming, and the more successful voice mobility networks find the right combinations of technologies to make that complexity manageable, or perhaps to make it go away entirely. 6.2.2 The Scanning Process Now it is time to explore the handoff process in detail. The most important, and most involved, part of a client’s decision making for handoffs is not the actual handoff technique itself, but the research, so to speak, that the client must engage in before it attempts to make the transition. This starts with scanning. Scanning, as mentioned in Chapter 5, is the prelude to connecting. The client starts up with no knowledge of the cells that make up the network. It must look around, browsing the channels for access points whose beacons claim to offer the service (based on that SSID) that the client is looking for. As the client looks around, it creates a repository of this information, known colloquially as a scanning table. (Colloquially, because there is no standard out there that dictates the scanning process itself. The act of scanning, and the results that it can produce, are mentioned in 802.11, but the text is intentionally vague and leaves the real intelligence to the implementer.) 6.2.2.1 The Scanning Table Let’slookatthescanningtableinabitmoredetail.Thistableisprimarilyalistofaccess point addresses (BSSIDs), and the parameters that the access point advertises. The 802.11 standard lists at least some parameters that may be useful to hold in the client’s scanning table, as in Table 6.5. This table contains the fields taken from the access point’s beacons and probe responses. Most of the information is necessary for the client to possess before it can associate, because this information contains parameters that the client needs to adopt upon association. By looking at this table, clients can easily see which access points have the right SSID, but will not allow the client to associate. Examples are for access points that require a higher grade of security than the client is configured for, or require a more advanced radio (such as 802.11n) than the client supports. Most of the time, however, a properly configured Voice Mobility over Wi-Fi 235 www.newnespress.com network will not advertise anything that would prevent a properly configured client from entering. In addition to all of this mostly static, configuration information that the access point reports, clients may collect other information that they may themselves find useful when deciding to which access point they should associate. This information is unique to the client, based on environmental factors. Generally, this information (not that in Table 6.5) is far more important in determining how a client chooses where to hand off or associate to. Table 6.6 contains some more frequent examples of information that different clients may choose to collect. Again, there is no standard here; clients may collect whatever information they want. Roughly, the information they collect is divided into two types: information observed about the access point, and information observed about the channel the access point is on. This split is necessary, because clients have to choose which channel to use as a part of choosing which access point to associate to. Properties like noise floor or observed over-the-air activity belong to the channel at the point in place and time that the client is in. On the other hand, some properties belong directly to the access point without regard to channel, such as the power level at which the client sees the access point’s beacon frames. Furthermore, some of the per-access-point information may have been collected from Table 6.5: Scanning table contents from 802.11 Field Meaning BSSID The Ethernet address of the access point’s service for this SSID SSID The SSID text string BSS Type Whether the access point is a real access point, or an ad hoc device Beacon Period Number of microseconds between beacons DTIM Period How many beacons must go by before broadcast/multicast frames are sent Timestamp The time the last beacon or probe response was scanned for this client Local Time The value of the access point’s time counter Physical Parameters What type of radio the access point is using, and how it is configured Channel The channel of the access point Capabilities The capabilities the access point advertises in the Capabilities field Basic Rate/MCS Set The minimum rates (and MCS for 802.11n) that this client must support to gain entry Operational Rate/MCS Set The allowed rates (and MCS for 802.11n) that this client can use once it associates Country The country and regional information for the radio Security Information The required security algorithms Load How loaded the access point reports itself to be WMM Parameters The WMM parameters that the client must use once it associates Other Information Depends on the standards that the client and access point supports 236 Chapter 6 www.newnespress.com previous periods when the client had been associated to that access point, and measured the quality of the connection. Thescanningtableissomethingthattheclientmaintainsovertime,asauid,“living” menu of options. One of the challenges the client has is in determining how old, or stale, the information may be—especially the performance information—and whether it has observed that channel or access point long enough to have some confidence in what it has seen. This is a constant struggle, and different clients (even different software versions from the same client vendor) can have widely different ways of judging how much of the table to trust and whether it needs to get new information. This is one of the sources of the variability present in Wi-Fi. 6.2.2.2 The Scanning Process As mentioned before, the scanning table’s contents come from beacons and probe requests. Scanning is a process that can be requested explicitly the user—often by performing an operationthatislabeled“Reconnect.”“Update,”or“Scan.”Butfarmoreoften,scanningis a process that happens in the background or when the client decides that it is needed. To understand why the client makes those choices, we will need to look at the mechanisms of scanning itself. There are two ways that the scanning table can be updated. When a client is associated to an access point, it has the ability to gather information about other access points on that channel. Especially when the client is not in power save mode, the client will usually ask its hardware to let it receive all beacon frames from any access point. Each beacon frame is then used to update the scanning table entry for that access point. On the other hand, the client may want to survey other channels to find out what other access point options are out there. To do this, the client clearly needs to leave the channel of Table 6.6: Other possible scanning table contents Field Meaning Signal Strength The power level of the beacon or probe response from the access point Channel Noise The measured noise floor value on the channel the access point is on Channel Activity How often the channel the access point is on is busy Number of Observed Clients How many clients are on the channel the access point is on Beacon Loss Rate How often beacons are missed on that channel, even though they are expected Probe Request Loss Rate How many times probe requests had to be sent to get a probe response Previous Data Loss Rate If associated earlier, how much loss was present between the access point and client Probe Request Needed Whether the client needed to send a probe request Voice Mobility over Wi-Fi 237 www.newnespress.com its access point for at least a small amount of time. Therefore, before engaging in this process, the client will usually tell the access point that it is going into power save mode, even though it is doing no such thing. That way, the access point will buffer traffic for the client, who can then look around the network with impunity. When the client changes channels, it has two methods it can use to find out about the access points. The quickest method is to send out the probe request mentioned earlier. This probe request contains the SSID the client desires (with the option of a null SSID, an empty string, if the client wants to learn about all SSIDs), and is picked up by all access points in range that support the SSID and wish to make themselves known to the client. (Remember that access points may hide from the client, as a part of load balancing. See Section 6.1.2.) Each access point that wishes to answer and that supports the SSID in question will respond with the probe response, a frame that is nearly identical to a beacon but is sent, unicast, directly to the client who asked for it. This procedure is called active scanning, though it can also be called probing, given the name of the frames that carry out the procedure. The other option is called passive scanning, and, as the name suggests, involves sending no framesoutbytheclient.Instead,theclientwaitsaroundforabeacon.Keepinmindthat passive scanning clients do not know, ahead of time, how many access points are on a channel or when these access points may transmit the beacons. Therefore, a client may need to wait for at least one beacon period to maximize its chances of seeing beacons from every access point of possible interest. In these two ways, the client goes from channel to channel, collecting as much information as possible about the available networks. Clients may choose between active or passive scanning for a number of reasons. The advantage of active scanning is that the client will get definitive answers about the access points that are on that channel and in range in short order. Sometimes the client needs to send more than one probe request, just to make sure that none of those broadcast frames were lost because of transient RF effects or collisions. But the process itself concludes rather quickly. Furthermore, active scanning with probe requests is the only way to learn about which access points serve SSIDs that are hidden, where hidden SSIDs are not put in beacons and require the user to enter the SSID by hand. On the other hand, active scanning comes with two major penalties. The first one is for sheer network overhead. A probe request can trigger a storm of probe responses to the client, all of which take up valuable airtime. Especially when there is a network fluctuation (access point reboots, power outages, or RF interference), all of the probes pile onto an already fragile network, making traffic significantly worse. The second penalty is that active scanning is simply not allowed on the majority of the 5 GHz channels. Any channel that is in a DFS band cannot be used with active scanning. Instead, the client is always required to wait for a beacon (an enabling signal), to know that the channel is allowed for operation, does not have a radar, and thus 238 Chapter 6 www.newnespress.com can be used. (Note that, once a client has an enabling signal, it is allowed to proceed with a probe request to discover hidden SSIDs. However, the time hit has been taken, and the process is no faster than a normal passive scan.) Therefore, to better understand scanning, we need to look at the timing of scanning. Active scanning, of course, is the quicker process, but it too has a delay. Active scanning is limited by a probe delay, required by the standard to prevent clients from tuning into a channel in the middle of an existing transmission. The potential problem is that a client abruptly tuning into a channel might not be able to detect that a transmission is under way—carrier sense mechanisms that are based on detecting the preamble will miss out, and thus produce a false reading of a clear channel. Thus, if the client were then to send a probe request, the client could very well destroy the ongoing transmission and lose out on the access points’ seeing the probe request, because of a collision. As it turns out, many voice clients set that probe delay to a trivial value, in order to not have to wait. But the common value for that delay is 12ms, which is a long time in the world of voice. Passive scanning is worse. Most access points send their beacons every 102.4ms, or as close as they can get. This means that a client who tunes to a channel has a good chance of having to wait 50ms just to get a beacon, and may have to wait the entire 100ms in the worst case, for just that one access point. The timescale that dominates, for voice mobility, is the voice packet arrival interval. Normally, that value is 20ms (though it can be 30ms in some cases). A client will usually want to get all of the scanning it can get done in those 20ms, so that it can return to its original channel and not miss the next voice packet. Certainly, the client will not want to take 100ms unless it has to, because 100ms is a long enough jitter that it can be quite noticeable (as mentioned in Chapter 3). Again, this tends to make active scanning the choice for voice clients, who are always in a hurry to learn about new access points. If the client is going to scan between the voice packets, then the client’s ability to scan will probably be limited to one channel at a time. When limited this way, the client may take up to a second, easily, to scan every possible channel. Recall from Chapter 5 that there are 11 channels in 2.4GHz, 9 non-DFS channels in 5GHz, and 11 more in the DFS bands, for a total of 31 channels to scan (or 23 channels if clients make the assumption that service is provided only on channels 1, 6, and 11 in the 2.4GHz band). Of course, scanning is also a battery-intensive process, and so a client may choose to spread out the scanning activity over time. Furthermore, the process of changing channels is not always instantaneous. Depending on the radio chip vendor, some clients will have to wait through a multimillisecond radio settling and configuration time, reprogramming the various aspects of the radio in order to ensure proper transmission on the new channel. This adds additional padding time to the individual scanning channel transitions. Voice Mobility over Wi-Fi 239 www.newnespress.com Overall, this scanning delay is a major source of handoff delays, and some methods for reducing the scanning time have been created, which we will examine shortly. 6.2.2.3 When Scanning Happens The client’s handoff is only as good as its scanning table. The more the client scans, the more accurate the information it receives, and the better decision the client can make, thus ensuring a more robust call. However, scanning can cost as much in call quality as it saves, and most certainly diminishes battery life. So how do phones determine when to scan? The most obvious way for a client to decide to scan is for it to be forced to scan. If the phone loses connection with the access point that it is currently attached to, then it will have no choice but to reach out and look for new options. Clients mainly determine that they have lost the connection with their current access point in three different ways. The first method is to observe the beacons for loss. As mentioned earlier, beacon frames are transmitted on specific intervals, by default every 102.4ms. Because the beacons have such a strict transmission pattern, clients—even sleeping clients—know when to wake up to catch a beacon. In fact, they need to do this regularly, as a part of the power saving mechanisms built into the standard. A client can still miss a beacon, for two reasons: either the beacon frame was collided with (and, because beacon frames are sent as broadcast, there are no retransmissions), or because the client is out of the range that the beacons’ data rates allow. Therefore, clients will usually observe the beacon loss rate. If the client finds itself unable to receive enough beacons according to its internal thresholds, it can declare the access point either lost or possibly suffering from heavy congestion, and thus trigger a new scan, as well as deprioritize the access point in the scanning table. The sort of loss thresholds used in real clients often are based on a combination of two or more different types of thresholds, such as triggering a scan if a certain number of beacons are lost consecutively, as well as triggering if a certain percentage is lost over time. These thresholds are likely not to directly specifiable by the user or administrator. The second method is to observe data transmissions for loss. This can be done for received or transmitted frames. However, it is difficult for a client to adequately or accurately determine how many receive frames have been lost, given that the only evidence of a retransmission prior to a lost frame is the setting of the Retry bit in the frame’s header, something that is not even required in the newer 802.11n radios. Therefore, clients tend to monitor transmission retries. The retry process is invoked for a frame (see Section 5.4.8). Retransmissions are performed for both collisions and adapting to out-of-range conditions— because the transmitter does not know which problem caused the loss, both are handled by the transmitter simultaneously reducing the transmit data rate, in hopes of extending range, and increasing backoff, in hopes of avoiding further collisions for this one frame. Should a series of frames back-to-back be retransmitted until they time out, the client may decide that . for loss and delay, and may also be used to determine call quality. However, 802.11k requires upgrades to the client and access point firmware, and so is not as prevalent as RTCP, and nowhere. Process Now it is time to explore the handoff process in detail. The most important, and most involved, part of a client’s decision making for handoffs is not the actual handoff technique itself, but. 5GHz, and 11 more in the DFS bands, for a total of 31 channels to scan (or 23 channels if clients make the assumption that service is provided only on channels 1, 6, and 11 in the 2.4GHz band).