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. f.
org/rfc/rfc3261.txt
Internet Engineering Task Force. (2003) RFC 3550. RTP: A Transport Protocol for Real-Time
Applications. />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. />International Telecommunication Union. (2006) Recommendation H.323. Packet-based multimedia
communications systems. />International Telecommunication Union. (1998) Recommendation Q.931. ISDN user-network
interface layer 3 specification for basic call control. />International Telecommunication Union. (1988) Recommendation G.711. Pulse code modulation
(PCM) of voice frequencies. />International Telecommunication Union. (2007) Recommendation G.729. Coding of speech at 8 kbit/s
using conjugate-structure algebraic-code-excited linear prediction (CS-ACELP). .
int/rec/T-REC-G.729
Chapter 3
International Telecommunication Union. (1996) Recommendation P.800. Methods for subjective
determination of transmission quality. />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. />International Telecommunication Union. (2008) Recommendation G.107. The E-model: a
computational model for use in transmission planning. />International Telecommunication Union. (2007) Recommendation G.113. Transmission impairments
due to speech processing. />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. />txt
Internet Engineering Task Force. (1998) RFC 2460. Internet Protocol, Version 6 (IPv6) Specification.
/>Internet Engineering Task Force. (1980) RFC 768. User Datagram Protocol. />rfc768.txt

Internet Engineering Task Force. (1997) RFC 2205. Resource ReSerVation [sic] Protocol (RSVP)—
Version 1 Functional Specification. />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. f.
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. />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). />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. />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.
/>Internet Engineering Task Force. (1998) RFC 2408. Internet Security Association and Key
Management Protocol (ISAKMP). />International Telecommunication Union. (2005) Recommendation X.509. Information technology—
Open Sytems Interconnection—The Directory: Public-key and attribute certificate frameworks.
/>Chapter 9
International Telecommunication Union. (2000) Recommendation H.262. Information technology—
Generic coding of moving pictures and associated audio information - Video. />rec/T-REC-H.262
International Telecommunication Union. (2007) Recommendation H.264. Advanced video coding for
generic audiovisual services. />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