Because all of the media can be kept together in one stream of bytes, TCP-based streaming for video also works.. On the other hand, TCP-based video streaming is the popular method of tra
Trang 1used, 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
Trang 2362 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
Trang 3receive 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
Trang 4364 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
Trang 5References
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
Trang 6366 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
Trang 7Chapter 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
Trang 8369
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
Trang 9arrays, 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
Trang 10Index 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