The Future: Video Mobility and Beyond 361 www.newnespress.com used, for example, to synchronize the one or more audio channels with the one video channel. On the other hand, encoded video itself usually comes with its own frame encapsulation mechanism. The reason for this is that it allows all of the media streams for a video to be kept together. These mechanism allow the embedding of the audio streams into the video stream, even on a real-time basis, and thus provides a higher-layer representation of the order and flow of the video, on top of RTP. Whether the audio streams are combined into the video is as much a function of the device that is sending the video and the signaling application as it is the video encoding. Because all of the media can be kept together in one stream of bytes, TCP-based streaming for video also works. The disadvantage of using TCP, of course, is that the real-time nature of the stream is broken, as TCP will delay the stream if not every byte can make it through at the moment. On the other hand, TCP-based video streaming is the popular method of transporting video over the Internet, especially when having real-time video is not the requirement, and approximately real-time video is acceptable. This is commonly used for news streaming, where the content needs to be almost live, but it is acceptable for different viewers to see versions of the video with different delays, based on whatever the transport required. Nevertheless, it is important to maintain a distinction between serving video clips and streaming live video. Both may use TCP, but the latter will be rate-limited to the speed of the real-time video, and thus special quality-of-service considerations can be applied that might not be appropriate for the former. 9.1.3.2 Video Signaling Video signaling depends on the application being used to send the video. However, the requirements for effective video conferencing share a great deal with that of voice calling, and so the concepts learned in previous chapters can be applied. Video conferencing is often performed with H.323, which was designed to simply having multiple users enter a conference. In much the same way, SIP can be used by some applications for point-to-point video calls, or for where there is a video conferencing server that combines multiple videos and provides one flow for each client. Nevertheless, standardization for video conferencing is not as ubiquitous, as many video conferencing platforms have advanced features and codecs that only work with their own products—again, the fact that video is still an area of active research and development makes putting together a video system more complicated than doing the same for voice. TCP-based video streams usually come from a streaming HTTP-based video server. The signaling protocol, in this case, is the trivial one of the client requesting a URL corresponding to a particular video stream—even a live one—and the server responds with the bits of the video, encoded as if it were a standalone, already-generated video file (such as MPEG-4) that could conceivably even be captured, saved to a file, and played later. 362 Chapter 9 www.newnespress.com 9.1.4 Video Networking Now that you have seen what goes into a video stream, we can look at how video is transported over real networks—especially mobility networks. As with voice, Wi-Fi will play a prominent role in the delivery of video, especially now that users have become more mobile. One of the hardest challenges for video networks is identifying the video stream and applying quality-of-service differentiation or protection to it. Unlike voice, which is often marked on a packet-by-packet basis with the correct DSCP tags to designate it and differentiate it from the best effort traffic on the network, video often lurks in best effort traffic streams. For example, TCP-based video is designed to look like best effort, and detecting whether the stream is video may require actively inspecting the traffic, looking for markers in the flow (such as HTTP MIME types designating video media), and then trying to apply the appropriate tagging. TCP applications are notoriously difficult to apply quality- of-service to. For starters, the networking stack may not have the facility for applying DSCP tags to the packets of the TCP stream. Whereas UDP applications can often write whatever DSCP tag they like, because they deal with writing individual packets or datagrams, TCP packets are produced by the underlying operating system. Applications only see a socket, or a place to write bytes in the order they should go over the network, and the underlying system produces packets based on the requirements of TCP itself. But even more, applying quality-of-service prioritization to one TCP stream can lead that TCP stream to crowd out the other traffic on the network. Most TCP server applications are not bandwidth-limited, and therefore will provide traffic at whatever rate the client can process. Applying prioritization to TCP traffic can then cause that traffic to dominate. When TCP is being prioritized, it is best to apply band shaping or tight throughput bounds, to prevent the TCP connection from racing ahead at a bandwidth too much higher than that the underlying video codec expects. Unfortunately, this is not automatically provided by most routers and network systems—there is no “limit to codec” switch or configuration option—and so setting the bounds may have to be by hand. Some Wi-Fi networks and wireline bandwidth shapers can at least apply the upper limits on a per-flow basis, rather than lumping all flows together into the same bandwidth constraint. Multicast is another area where video stands out. As mentioned before, both video conferencing and video broadcasting can take advantage of IP-level multicast to greatly reduce the amount of packets that are necessary for real-time video streaming. IP multicast works by the video encoder sending traffic to a particular IP multicast group address, which begin with the first octet of 224 to 239. These IP packets are not destined to any one device, so no technology such as ARP is used to determine the next hop Ethernet address. Instead, the multicast traffic is simply sent out on the link. All devices on that layer-2 subnet can The Future: Video Mobility and Beyond 363 www.newnespress.com receive the traffic. Multicast can cross from one subnet to another when a multicast router sits across the two subnets. Multicast routing with IP requires that the clients that wish to receive the multicast traffic advertise their desires using the Internet Group Management Protocol (IGMP), for IP version 4. (The similar Multicast Listener Discovery [MLP] protocol exists for IP version 6.) The client sends an IGMP packet to a specific subnet-local multicast address. The IGMP packet contains the real multicast addresses that the client wants to subscribe to. The router listens in on these IGMP messages and collects the list of multicast group addresses on that subnet, joining or leaving the group from its own upstream router as necessary. When a router receives a multicast packet for a group on the upstream link, it repeats it onto every downstream link that has at least one device that is a member of this group. In that way, a tree is built back to the multicast source, covering all of the links that lead to multicast group members. There are specific routing protocols that manage this between routers as needed. Setting up multicast networks requires a fair amount of work, and it would not be appropriate to enter into a discussion on all of the details here. However, it should be clear that multicast does allow the sender to send only one packet, which is then copied efficiently—one and only one per subnet, no matter how many clients are listening in that subnet—across the entire network of interested devices. Multicast for Wi-Fi, however, has a snag. In wireline Ethernet, a multicast packet takes up the same amount of per-port networking resources as a unicast packet. long as the switches are aware of multicast, and are doing IGMP snooping—listening into the IGMP messages and placing multicast packets only on ports that have listening devices for that multicast group on them—multicast is more efficient that unicast. On the other hand, Wi-Fi multicast may be significantly less efficient than unicast. There are a few reasons for this. The first reason is that multicast on Wi-Fi cannot require the clients to acknowledge the receipt, because there are multiple listeners. The multicast packet is sent only once, and devices that do not receive it cannot benefit from the retransmissions that unicast packets offer when they are not received the first time. Furthermore, the multicast packet must go at a very low Wi-Fi physical data rate. Unicast packets on an 802.11n network can go as fast as 300Mbps, but multicast packets from access points must go at the lowest data rate that all of the clients associated to that access point can hear. This can be as low as 1Mbps. No such restriction exists in wireline. Finally, multicast quality-of-service prioritization may not necessarily be used in Wi-Fi networks. The rule is, unfortunately, that if any one client on the access point uses non-WMM for traffic, then none of the multicast traffic can use WMM. This weakest-link restriction makes multicast over wireless a challenging proposition, compared to wireline. Look to advances in wireless and wireline video technology to occur in the next couple of years, as video takes hold in the enterprise. Many of the issues just mentioned may potentially be solved by then, and video mobility may become a reality. 364 Chapter 9 www.newnespress.com 9.2 Beyond Voice and Video It is always tough to predict what lies ahead. Mobility technology is not embraced by the majority of organizations simply because it is exciting, or can do amazing things, but only because it solves core problems of productivity that were not addressed before and ended up costing, in terms of time or dollars. Video mobility will likely become useful for the enterprise as applications embrace video. This is especially true in industries such as health care and education, which each have obvious needs for moving video media and can immediately benefit from the network supporting video mobility. But no matter what the application, mobility itself will be the main driver. Wi-Fi started the trend, and other technologies may pick up if Wi-Fi fails to remain in the lead, but the removal of wires as an edge networking technology, and their replacement with wireless radios, seems likely to only intensify in pace and degree, as budgets get tight and IT organizations become forced to justify why they should spend a lot of money running copper to each user, when a wireless signal works better for less money. In terms of applications, these too will be driven by mobility. It is clear that the user’s device is shrinking. Mainframes and terminals gave way to desktops, which gave way to portable laptops, and which are themselves giving way to a brand new generation of handhelds. Devices such as the Apple iPhone show that ease of use and a rich feature set—including three-dimensional graphics and a strong audio offering—can entice users to focus their efforts onto just one device. The transition to enterprise-class devices and applications is tough and is still in its infancy, but it would not be unreasonable to expect that the future lies in being able to provide the entire enterprise experience on one device. This is not to say that desktops or laptops are dead, as there are so many things that you cannot do on a small screen: the sheer evidence that televisions started out small and got larger only over time is proof that people do want to see things on a large scale. However, users will demand that their information and services are available, in some familiar, if modified, form, everywhere they go. I hope you have enjoyed this book and have found it to be useful in explaining the concepts behind voice mobility and has helped point the way for those who have decided to implement such a network. Q 365 References Chapter 2 Internet Engineering Task Force. (2002) RFC 3261. SIP: Session Initiation Protocol. http://www.ietf. org/rfc/rfc3261.txt Internet Engineering Task Force. (2003) RFC 3550. RTP: A Transport Protocol for Real-Time Applications. http://www.ietf.org/rfc/rfc3550.txt Internet Engineering Task Force. (2006) RFC 4566. SDP: Session Description Protocol. http://www. ietf.org/rfc/rfc4566.txt Internet Engineering Task Force. (2006) RFC 4733. RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals. http://www.ietf.org/rfc/rfc4733.txt International Telecommunication Union. (2006) Recommendation H.323. Packet-based multimedia communications systems. http://www.itu.int/rec/T-REC-H.323 International Telecommunication Union. (1998) Recommendation Q.931. ISDN user-network interface layer 3 specification for basic call control. http://www.itu.int/rec/T-REC-Q.931 International Telecommunication Union. (1988) Recommendation G.711. Pulse code modulation (PCM) of voice frequencies. http://www.itu.int/rec/T-REC-G.711 International Telecommunication Union. (2007) Recommendation G.729. Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear prediction (CS-ACELP). http://www.itu. int/rec/T-REC-G.729 Chapter 3 International Telecommunication Union. (1996) Recommendation P.800. Methods for subjective determination of transmission quality. http://www.itu.int/rec/T-REC-P.800 International Telecommunication Union. (2001) Recommendation P.862. Perceptual evaluation of speech quality (PESQ): An objective method for end-to-end speech quality assessment of narrow- band telephone networks and speech codecs. http://www.itu.int/rec/T-REC-P.862 International Telecommunication Union. (2008) Recommendation G.107. The E-model: a computational model for use in transmission planning. http://www.itu.int/rec/T-REC-G.107 International Telecommunication Union. (2007) Recommendation G.113. Transmission impairments due to speech processing. http://www.itu.int/rec/T-REC-G.113 International Telecommunication Union. Recommendation G.711 International Telecommunication Union. Recommendation G.729 Q 366 References www.newnespress.com Chapter 4 Internet Engineering Task Force. (1981) RFC 791. Internet Protocol. http://www.ietf.org/rfc/rfc791. txt Internet Engineering Task Force. (1998) RFC 2460. Internet Protocol, Version 6 (IPv6) Specification. http://www.ietf.org/rfc/rfc2460.txt Internet Engineering Task Force. (1980) RFC 768. User Datagram Protocol. http://www.ietf.org/rfc/ rfc768.txt Internet Engineering Task Force. (1997) RFC 2205. Resource ReSerVation [sic] Protocol (RSVP)— Version 1 Functional Specification. http://www.ietf.org/rfc/rfc2205.txt Internet Engineering Task Force. (1999) RFC 2597. Assured Forwarding PHB Group. http://www. ietf.org/rfc/rfc2597.txt Internet Engineering Task Force. (1999) RFC 2598. An Expedited Forwarding PHB. http://www.ietf. org/rfc/rfc2598.txt Chapter 5 Institute of Electrical and Electronics Engineers (IEEE) Computer Society. (2007) IEEE Std 802.11- 2007. IEEE Standard for Information technology—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 Institute of Electrical and Electronics Engineers (IEEE) Computer Society. (2007) IEEE P802.11n/ D2.00. Draft STANDARD for Information technology—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: Enhancements for Higher Throughput Paulraj, Arogyaswami, Rohit Nabar, Dhananjay Gore. Introduction to Space-Time Wireless Communications. Cambridge University Press, 2009 Chapter 6 Institute of Electrical and Electronics Engineers (IEEE) Computer Society. (2008) IEEE Std 802.11k- 2008. IEEE Standard for Information technology—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 1: Radio resource Measurements of Wireless LANs Institute of Electrical and Electronics Engineers (IEEE) Computer Society. (2008) IEEE Std 802.11r- 2008. IEEE Standard for Information technology—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 2: Radio Fast Basic Service Set (BSS) Transition Voice over Wireless LAN 4.1 Design Guide, Cisco Systems, 2009. http://www.cisco.com/en/US/ docs/solutions/Enterprise/Mobility/vowlan/41dg/vowlan41dg-book.html Q References 367 www.newnespress.com Chapter 7 Institute of Electrical and Electronics Engineers (IEEE) Computer Society. (2006) IEEE Std 802.16e- 2005. IEEE Standard for Local and metropolitan area networks Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems Amendment 2: Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands Chapter 8 Internet Engineering Task Force. (2000) RFC 2865. Remote Authentication Dial In User Service (RADIUS). http://www.ietf.org/rfc/rfc2865.txt Internet Engineering Task Force. (2004) RFC 3748. Extensible Authentication Protocol (EAP). http:// www.ietf.org/rfc/rfc3748.txt Internet Engineering Task Force. (2008) RFC 5246. The Transport Layer Security (TLS) Protocol Version 1.2. http://www.ietf.org/rfc/rfc5246.txt Internet Engineering Task Force. (2006) RFC 4186. Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM). http:// www.ietf.org/rfc/rfc4186.txt Internet Engineering Task Force. (2005) RFC 4301. Security Architecture for the Internet Protocol. http://www.ietf.org/rfc/rfc4301.txt Internet Engineering Task Force. (1998) RFC 2408. Internet Security Association and Key Management Protocol (ISAKMP). http://www.ietf.org/rfc/rfc2408.txt International Telecommunication Union. (2005) Recommendation X.509. Information technology— Open Sytems Interconnection—The Directory: Public-key and attribute certificate frameworks. http://www.itu.int/rec/T-REC-X.509 Chapter 9 International Telecommunication Union. (2000) Recommendation H.262. Information technology— Generic coding of moving pictures and associated audio information - Video. http://www.itu.int/ rec/T-REC-H.262 International Telecommunication Union. (2007) Recommendation H.264. Advanced video coding for generic audiovisual services. http://www.itu.int/rec/T-REC-H.264 Q 369 Index A A-law, 47–48 AAA (Authentication, Authorization, and Accounting), 180, 325 administrator determining EAP methods, 182–183 server, 183, 186 AC (access category) for each packet, 204 parameters, 206–207 in WMM, 204 accept message, 328 accepted resources, 258 access control, 125 access points (APs) adding additional, 288 adjusting transmit power levels, 225–226 approximation and position of, 136–137 connections to, 115 controller-based, 121 controllerless, 122 controlling over-the-air resource utilization, 275 coverage patterns for, 226 decision to leave, 240–249 definition in 802.11, 127b deploying for voice and data, 284 described, 106–108 existing independently, 233 ignoring client, 221 load reporting performed by, 246–247 locations of, 106–107, 107f, 136 multiple-radio standalone, 120 phone transitioning to a more distant, 245–246 properties belonging directly to, 235–236 repeating information from clients, 118 scanning, 227 setting, 207 specifying neighboring, 266 standalone, 120 in SVP, 38–40 taking over role of tunnel endpoints, 122 testing additional, 281 Access-Accept message, 328t Access-Request message, 326 accounting, 325 acknowledgement (ACK) in TCP, 88, 88t proxy sending in SIP, 23, 24t in 802.11, 114 delayed, in 802.11, 89 Acknowledgement field, in TCP, 88 active call quality tools, 288 active report, 264 active resources, 258 active scanning, 237 as the choice for voice clients, 238 effects of, 237–238 as quicker process, 238 active voice quality monitoring, 229–230 adaptive microcell, 123 adaptive power control, 281–282 Add Traffic Stream (ADDTS) Request message, 215 address fields, in 802.11, 113, 113t in Ethernet, 76–77 Address Resolutio™n Protocol. See ARP addresses binding to the network, 74– 75 ADDTS protocol, 254 ADDTS Request Action frame, 251 ADDTS Response, 215, 218 ADDTS Response Action frame, 251 administrators. See network administrators admission control, 208, 214–220 determining capacity for, 219–220 in H.323, 34 parameters, 285 requests, 275 RSVP as a form of, 91 in Wi-Fi, 215 admission controller, 215 Advanced Video Coding (AVC), 360 advantage factor, 60–61, 60t AES (Advanced Encryption Standard), 52. See also WPA2 as block cipher, 178 used by SRTP, 341–342 in WPA2, 174, 178–179 aggregation, in 802.11n, 167 Aggressive mode, in ISAKMP, 340–341 AH (Authentication Header) protocol, 339 AID (association ID), 117, 209 AIFS (Arbitration Interframe Spacing), 206 air monitors, 227 airtime, 218 airways, 49–50 AKA (Authentication and Key Agreement) protocol, 337 ALERTING message, in Q.931, 41 Algorithm Number, in 802.11r, 255–256, 255t aliasing effects, 43–44, 45f Allow header, in SIP, 18 A-MPDUs, 167 amplitude modulation (AM), 149, 150f analog cellular phones, 297. See also cellular phones analog frequency modulation. See frequency modulation analog phone lines, 73 analog telephones, 7–8 analog-to-digital converter, 43 antenna ID field, 265 antennas in a MIMO system, 198–199 not working well in every direction, 244–245 in a phone, 8 required by MIMO, 163 requiring room for, 164–165 Apple iPhone, 364 APs. See access points Arbitration Interframe Spacing (AIFS), 206 area codes, in a dialing plan, 9 ARP (Address Resolution Protocol) cache, 83–84 message, 84, 84t Q 370 Index arrays, 120 assisted handoff, in cellular technologies, 271 association ID (AID), 117, 209 Association Request, 117 Association Response, 117 assured forwarding (AF), 93, 93t @ (at sign), in a sip: marker, 13 attacks, detecting, 178 attenuation caused by the caller’s head, 244–245 of radio waves, 131 of signals, 196 weakening radio signals, 133f attributes, in RADIUS, 326, 327t–328t audio, separate from communication, 7 audio codecs. See codec(s) audio compression, 46, 354 audio streams, 360–361 authentication in 802.1X, 181–183 defined, 181 described, 325 examples, 185–192 in IPsec, 338 over Wi-Fi, 182 in SIP, 30–31 Authentication, Authorization, and Accounting. See AAA Authentication and Key Agreement (AKA) protocol, 337 authentication challenge header, in SIP, 31, 31t authentication credentials, 180– 181 Authentication frames, 116–117, 171 Authentication Header (AH) protocol, 339 authentication mechanism, 328–329 Authentication message, 249–250 Authentication Request, 255–256, 255t Authentication Response message, 255t Authentication/FT Acknowledgement step, 257–258 Authentication/FT Confirm step, 257–258 authenticator in 802.1X, 252–253 in EAP, 329 in RADIUS, 326 Authenticator field, 328 authenticity by a secure network, 324 by a secure wireless network, 169–170 authorization, 325 Authorization header, 31 autoattendant PBX feature, 10–11 autocorrelation, 154 autonegotiation protocol, 80–81 autonomous or background reporting, 263 AVC (Advanced Video Coding), 360 average access delay, 246–247 average queue delay, 269, 270t average transmit delay, 269, 270t B B channels, 40 background noise, mind compensating for, 46 background reporting, 263 background scanning, 240 background transmissions, 281 backoffs, in 802.11 to avoid contention, 145, 285 leading to unstable behavior, 79 procedure for multiple radios, 147f band load balancing, 223 band steering, 223 bands, for GSM, 299 bandwidth, of 802.11 radio, 128 Barker sequence, 153–155 base station access point serving as, 106 in a cellular network, 290f, 291 holding signal together in CDMA, 301 base station controller, 290f, 291 Base Transceiver Station (BTS), 298 baseband signal, 151, 195 basic service set identifiers. See BSSIDs basic service sets (BSSs), 232–233, 275 battery, in a phone, 8 battery life, 208–213, 225–226 Beacon(s) clients looking for, 116 clients skipping, 210 miniature version of, 269–270 observing loss, 239 sent by access points, 107 setting periodically, 209–210 signal strength of, 274 waits for enabling signal, 237–238 beacon report, 264–266, 265t Beacon Report frame, 265 beacon report request, 264–265, 264t beamforming, in MIMO, 166 bearer channel, 5, 7 in digital phones, 8–9 H.245 setting up, 34 bearer protocols, 43–55 best-effort delivery guarantee, 85 bidirectional traffic stream, 216 Bin 0 Range field, 268–269, 268t bit flips catching, 177 RC4 vulnerable to, 172–173 bit-by-bit extraction, 96–97 Block Acknowledgement, 167 block cipher, AES as, 178 Blu-ray video discs, 360 BPSK (binary phase shift keying), 152–153, 153f, 159 “branch,” setting in SIP, 16–17 break-before-make handoff, 249–252 bridge, 109–110 bridging traffic, in Ethernet, 79–80 broadcast mechanism, video as, 350 broadcasts, to the wireless network, 118 BSC, in GSM, 298 BSS Info field, 266–267, 267t BSSIDs (basic service set identifiers), 110. See also SSIDs Action frames containing, 257 allowing for multiple, 127b in a beacon request, 264–265 in a beacon response, 265 listing of, 234 in the neighbor report element, 266–267, 267t scanning tables of unique, 272 BSSs (basic service sets), 232–233, 275 BTS (Base Transceiver Station), in GSM, 298 buckets. See token buckets burst ratio, 64–65 bursting, in WMM, 207 BYE message in SIP, 27, 28t byte stream, TCP as, 87–88 C CAC (Call Admission Control), 214, 288 call. See voice call(s) call continuity, 318 call forwarding PBX feature, 10–11 call manager, in SCCP, 35, 36t–37t call park PBX feature, 10–11 CALL PROCEEDING message, 41 call quality, 59, 230 call setup phases of in SIP, 19–20, 19f signaling, 214 in SIP, 26, 26f call transferring PBX feature, 10–11 called party, rejecting SIP calls, 26 caller’s head, 243f Call-ID, in SIP, 17 capacity, for admission control, 219–220 capacity limits, setting low, 288 capacity management, 228 capture effect, 141 cardkey authentication, 336–337 carrier for 802.11b signals, 149 disregarding, 195 mathematical description of, 193–194 Q Index 371 carrier sense in Ethernet, 78–79 referring to clear channel assessment as, 140 of transmitters, 114 types, 143–144 Carrier Sense Multiple Access with Collision Detection (CSMA/CA), 113–114, 145 carrier-centric software, 315 CBC (cipher block chaining), in WPA2, 178–179 CBQ (class-based queueing), 95 CCA (clear channel assessment), 140–141 CCK (complementary code keying), 156 CCMP (Counter Mode with Cipher Block Chaining Message Authentication Code), 179 CDMA (code division multiple access) scheme, 300–301 CDMA2000, 302 CDMA-based cellular systems, 273 CE (Congestion Experienced) bit, 99 cell boundaries, irregular, 243f, 244 cellphones. See cellular phones cellular connection, 318–319 cellular networks architecture of, 289, 291 as efficient in terms of spectrum, 299 in enterprise-centric FMC, 308f, 309 cellular phone call, 289–297 cellular phones analog, 297 compared to landline phones, 1 as managed entities, 233 mobile call setup, 294–297 with two speakers, 313 uses of, 2 cellular radio, theft of devices with, 345–346 cellular technologies, 271, 297–306 cellular-based FMC, 317–318 architecture of, 316f demands on the router and Internet link, 317–318 described, 315 features and benefits, 315–318 cellular-centric technology, 320–321 cellular-only technology, 321–322 CELP (Code-Excited Linear Prediction), 49–50 center frequency, of 802.11 radio, 128 centralized authentication, 180 certificate(s). See also Wi-Fi Alliance certificate described, 181–182, 332–334 necessary for network authentication, 182 signing in chains, 334 versions of, 333 certificate authority in public key cryptography, 181–182 Thawte Consulting, 333 Certificate handshake message, 188 certificate of authenticity, 330 certificate-based authentication, 330–335 certifications, for Wi-Fi for high-quality voice, 277 WMM, 278–279, WMM AC, 255–256 CF Polls lost field, 269, 270t challenge-response protocol, 30–31 Change Cipher Spec and Finished message, 189, 189t Change Cipher Spec message, 188, 189t channel(s) alternating assignment of, 124 described, 127–130, 196–197 dividing available into bands, 229 effects of, 196 frequencies formula, 130 in GSM, 299 listing of, 128, 129t naming, 127–128 nonoverlapping, 130 properties, 197, 235–236 removing information, 200 timing of changing, 238 total number of, 130 “channel bonding”. See double-wide channels, in 802.11n channel layer, channel layering creating, 124–125, 229 over-the-air behavior of, 275 described, 272 freeing channels, 229 inherent location-determining behavior, 276 for load balancing, 224 mechanics of handoffs, 275–276 as more proactive, 274 severing static connection to access point, 272 wireless architecture, 320 channel matrix, 199–200 channel noise, 274 checksum, in the preamble, 140 checksum field in TCP, 88 in UDP, 87 chip, in 802.11, 153–154 choke points, 94 chrominances, 353–354 CID (connection ID), in WiMAX, 304 cipher block chaining (CBC), 178–179 circuit switching, 75 circuit-switched networks, 74 Cisco SCCP, 34–35 Unified Communications Manager, 34 802.11 architecture, 119t class-based queueing (CBQ), 95 classes, dividing traffic into, 91–92 classification, of packets, 95 clear channel assessment (CCA), 140–141 client(s) assigning each a unique BSS, 275 associating with a Wi-Fi network, 185–192 choosing access points, 116 connecting to access points, 115, 241 cutting power constraints for, 285 described, 108–109 finding out about access points, 237 information collected by, 235–236, 236t initiating handoff process too early, 245–246 making handoff successful, 252 optimal choice set of access points, 270–271 removing ability to make poor decisions, 272 role in channel layering, 274 searching out available SSIDs, 115–116 skipping Beacons, 210 underestimating radio environment, 244 client control, hidden, 241 client independence, in handoff behavior, 272–273 Client Key Exchange, 188 client nonce, 175 client RSN IE, 175 client tracing and logging activity, 287 client-focused solution, 272–273 client-to-client communication, 118 co-channel interferences, 226 co-channel overlap, 273–274 code division multiple access (CDMA) scheme, 300–301 code selector, in the DSCP field, 93 codebook, in G.279, 49–50 codec(s) defined, 46 described, 5–7, 46–51 recovering from packet loss, 49 selecting, 60 setups mapping RTP packet types, 53–54 for video conferencing and webinar broadcasts, 360 . most routers and network systems—there is no “limit to codec” switch or configuration option and so setting the bounds may have to be by hand. Some Wi-Fi networks and wireline bandwidth shapers. 802.16e- 2005. IEEE Standard for Local and metropolitan area networks Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems Amendment 2: Physical and Medium Access Control. by mobility. It is clear that the user’s device is shrinking. Mainframes and terminals gave way to desktops, which gave way to portable laptops, and which are themselves giving way to a brand