Download Wireless Data Tutorial

Wireless Data Tutorial
Phil Karn
Senior Staff Engineer
Qualcomm
[email protected]
http://people.qualcomm.com/karn
Introduction


"Data" really means packet data
Or more specifically, Internet access
–

could be a private net that uses TCP/IP
Everything else is an Internet application
–
e.g., CDMA asynch data & fax
Tutorial Topics



The Internet and its architecture
Generic considerations for IP over wireless
Adapting existing digital voice systems to packet
data
–

Systems designed specifically for packet data
–

IS-95 CDMA, Globalstar, GSM
CDPD, HDR
Ad-hoc packet radio networks
–
IEEE 802.11
Introduction to the Internet



Evolved from DARPA-sponsored packet
networking research begun in the 1960s
ARPANET begun in 1969 as first packet
switched network
What became TCP/IP conceived in 1974 as
means to interconnect ARPANET with ARPA
packet radio networks
The Internet Problem


Given a variety of applications, transmission and
networking technologies, including those not yet
invented, how can we unify them into a single,
seamless network?
Cerf & Kahn, A Protocol for Packet Network
Interconnection, IEEE Transactions on
Communications, May 1974
–
–
–
describes the basic design of what became TCP/IP
TCP/IP was originally one protocol, later split
established Cerf & Kahn as the Internet’s
“grandfathers”
Key Internet Concepts

End-to-end principle
–
–


Simplified, 4-layer reference model
Connectionless network layer
–
–

push complexity and features to upper layers
I.e., out of network to user computers
every packet contains full source & dest addresses
easy to implement on variety of physical networks
Flexible transport protocols
–
TCP and UDP meet virtually all needs
The End-to-End Principle

Saltzer, Reed and Clark, 1981:
–
–

Many traditional low-level network functions are
better done at the endpoints, I.e., at higher protocol
levels
Some functions can sometimes be justified within the
network as a performance enhancement
IMHO, one of the most important CS papers of
all time
–
http://people.qualcomm.com/karn/library.html has
links
End-to-End in the Internet


The end-to-end principle is widely accepted, is
fundamental to the Internet architecture, and
largely explains its success
Nevertheless, some old-guard Bell-heads still
refuse to accept it on ideological grounds
–
–

Sort of like the theory of biological evolution
Telcos don’t like being thought of as dumb bit pipe
providers, even if that is their only real competence
The end-to-end Internet architecture is a
powerful tool in the hands of end users
–
significant political and economic implications
The Internet Reference Model
Application
Host-to-Host
(end-to-end)
Internet
Subnet
The Internet Reference Model

Application Layer
–
–

End-to-End Layer
–
–

OSI transport & session layers
TCP & UDP
Internet Layer
–
–

covers OSI application & presentation layers
HTTP, Telnet, FTP, SMTP, POP, DNS, etc
OSI network (upper part)
IP
Subnet Layer
–
OSI network (lower part), link, physical
How the Internet Model Differs from
OSI

Fewer layers
–
–

Single connectionless Internet layer
–

simple, least-common-denominator service
Subnetwork layer deliberately unspecified
–

Presentation merged into application
Session & transport layers merged into end-to-end
may be a simple point-to-point link, a complete
network with internal routing, or tin cans & string
Strong end-to-end emphasis
–
–
Put functions at endpoints whenever possible
Keep the network itself as simple as possible
The Major Internet Protocols
SMTP
Telnet
FTP
POP
TCP
HTTP
ICMP
DNS
DHCP
UDP
IP
PPP
ARP
Enet
Dial
IS95
Other subnetworks
ISDN
Connectionless Networks

Similar to postal system
–

Full addresses in every packet
–



network handles each packet independently
Any notion of a “connection” is strictly end-toend; the network doesn’t know about them
–

perhaps an unfortunate metaphor
facilitates scaling to very large networks
Service is usually best-effort
Far easier to implement
Standard examples: Ethernet, IP
The Internet Protocol (IP) - RFC791



The protocol that defines “The Internet”
Datagram based (connectionless)
32-bit address space (IPv4)
–



written as 4 bytes in “dotted decimal” format, e.g.,
129.46.101.170
Maximum datagram size: 64KB
Best-effort delivery service, optional QOS
Fragmentation/reassembly for subnets with
smaller packet size limits
Internet Services

IP is best effort. Packets may be:
–
–
–
–

Lost (frequently, alas)
Corrupted (very rarely, thanks to link CRCs)
Delivered out of order (when routes change)
Duplicated (rarely)
Upper layer entities must anticipate and recover
on an end-to-end basis
The IP Header
0
4
8
Ver
IHL
TOS
Identification
TTL
Protocol
Total Length
D M
0
F F
Frag offset
Header Checksum
12
Source Address
16
Destination Address
End-to-End Protocols

User Datagram Protocol (UDP)
–

Transmission Control Protocol (TCP)
–

defined in RFC793
Internet Control Message Protocol (ICMP)
–
–

defined in RFC 768
defined in RFC792
error reporting, diagnostic testing
Others exist, but are rare
–
because TCP and UDP cover nearly all needs
The UDP Header
0
4
Source Port
Length
Destination Port
Checksum
UDP Applications

Short transactions
–
–

Real-time applications
–

Domain Name System (DNS)
Network File System (NFS)
Voice over IP
Multicasting
–
Conferencing, broadcasting
TCP


Connection-oriented
Reliable
–

Bi-directional
–

sequence numbering, retransmission
though many applications are unidirectional
Featureless byte stream
–
records, messages, etc, imposed by application
TCP vs UDP



Many applications could use TCP or UDP
TCP tends to be easier to use
UDP tends to be more efficient and robust
–
especially if application protocol is idempotent
Connections



A socket is an {IP address, port} pair
A connection is defined by a pair of sockets, I.e,
the 4-tuple:
{{IP source address, source port},{IP destination
address, destination port}}
Note that many different connections can share
the same socket on one end
–
–
I.e., the analogy to a hardware outlet isn’t exact
This permits “well known ports” for servers
TCP Connection Management



3-way handshake opens bi-directional point-topoint connection
Either side can issue a close and continue to
receive data indefinitely
Designed to handle simultaneous opens
–


though rarely used in practice
Great care taken to detect and recover from lost,
duplicated or reordered packets
When both sides close, the connection terminates
The TCP Header
0
Source Port
Destination Port
4
Sequence Number
8
Acknowledgement Number
12
16
offs
flags
Checksum
Window
Urgent Pointer
Wireless IP Considerations


Performance
Reliability/availability
–




usually much lower than wired links
Cost
Routing/mobility
Addressing
Security
Wireless Performance Issues


Lower speeds and higher packet loss rates than
wired networks
Connectivity usually not continuous
–
–
–

incomplete wireless coverage
cost
limited battery energy
Transport protocols (e.g., TCP), applications and
users must all adapt to these properties
Transport Performance

TCP adapts to variable throughput and delay
–


already deals with many wireless performance issues
High loss rates, intermittent connectivity more
problematic
Research ongoing
–
IETF Performance Implications of Link
Characteristics (PILC) working group
Transmission Control



TCP - not the application - packetizes user byte
stream, deciding how much to send and when
TCP’s name (“Transmission Control Protocol”)
emphasizes the importance of this function
TCP’s rules:
–
–
A few big packets are better than many tinygrams
Assume most timeouts are congestion-related
Nagle Algorithm


Early TCPs sent every application write in a
separate packet
This was death for character-at-a-time logins
over slow links
–

link header + 40 bytes TCP/IP header + 1 byte data
Nagle algorithm (RFC896, Jan 1984) applies
simple heuristic:
–
–
–
If data avail for a max packet, send it
Else, send only if no unacked data in flight
I.e., stop-and-wait until requested throughput > 1
packet/round trip time
TCP Retransmissions




The Internet can drop packets
As a “reliable” protocol, TCP detects lost packets
with timers and retransmits them
Congestion is the main cause of packet loss
Ergo, overly aggressive TCP retransmission
strategies can cause congestion collapse!
–
links are busy, but little useful work being done
because few packets reach their destinations
Round Trip Time Estimation




TCP must adapt to changing Internet propagation
delays due to queuing delays, changing routes,
speed-of-light delays, etc
Packets are also lost occasionally
It is hard to tell whether an overdue packet has
been lost or is simply delayed longer than usual
TCP doesn’t have enough info in the header to
reliably distinguish ACKs for successive
retransmissions of the same data
TCP Network Delay Modeling



TCP models Internet delay as a gaussian RV with
a slowly varying mean and standard deviation
Retransmission Timeout (RTO) set to
mean delay + 4 standard deviations
This is a tradeoff between:
–
–

maximizing throughput with packet loss
minimizing unnecessary retransmissions
Round trip time (RTT) measurements made by
timer started when certain sequence number sent,
stopped when it is acked
Estimating Round Trip Times

Mean and standard deviation estimates made
with exponential smoother:
–
–



mean’ = (7/8)*mean + (1/8)*(rtt)
sdev’ = (3/4)*sdev + (1/4)*abs(rtt-mean)
RTO = mean + 4*sdev
If rtt has low variance, then RTO will be only a
little greater than the mean round trip time
If rtt has high variance, then RTO will be much
greater than the mean round trip time
–
combination of high loss and variable delay is bad for
throughput
Filtering Round Trip Time
Measurements


The TCP header has no way to distinguish a
retransmitted segment from the original
If the sender gets an ACK for a retransmitted
packet, there’s no way to know if it’s for the
original transmission or a retransmission
–


I.e., the RTT measurement is unreliable
Therefore, only RTT measurements on segments
that were ACKed the first time are used
Also, the RTO backoff is “clamped” for the next
packet after a retransmitted one
–
avoids stable collapse state
Van Jacobson Congestion Control
(1988)


Limit effective transmit window to lesser of
advertised receive window or local congestion
window (cwind)
Cwind starts @ 1 packet, expands 1 packet for
every packet acked
–

called “slow start” - a misnomer since it’s
exponential over time!
If a timeout occurs, assume congestion:
–
–
ssthresh = 1/2 cwind
cwind = 1 packet
VJ Congestion Control - 2


After recovery, slow start continues until cwind
= ssthresh
Then cwind increases by 1/cwind on every ack
–
this “tests the waters” to see if the path can support
more traffic
Radio Link ARQ

TCP (and other Internet transport protocols)
designed for relatively low packet loss rates
–



typically <1% or less than one packet/RTT
Most mobile wireless channels have higher loss
rates even with coding and power control
A link-level RLP can lower the loss rate to a range
that can be adequately handled by TCP
The RLP does not have to be perfect
–
just good enough!
Other Approaches

Proxying/spoofing
–


Protocol translation (e.g., WAP)
All violate end-to-end principle
–
–

TCP ACK snooping/spoofing
less robust
complicates security
Just say no!
Intermittent Connectivity

Already common on wired networks
–
–

Generally handled at the application layer
–

dialups
roving laptops
e.g., Post Office Protocol (POP) for email
Experimental proposals for TCP
–
ICMP “reachable” message
Mobility

Allowing a user to keep a fixed address (at some
level) when changing attachment points to a
topologically-routed network
–

both the PSTN and the Internet are topological
Roaming cell phones and Internet users are very
similar in this respect
Mobility - Some Common Concepts

Home agents
–
–

Foreign agents
–
–

stationary systems that “own” mobile user’s address
and accept traffic on behalf of mobile user
analogous to cellular HLRs
provide service to mobile user
analogous to cellular VLRs
Registration
–
mobile users communicate back through serving
system to home agents to indicate current location
Multi-Layer Mobility




Mobility can be provided at several different
layers with different advantages/disadvantages
IP level (Mobile IP)
Domain Name System (DNS)
Application-level
–
–
Post Office Protocol (POP)
various Internet telephony directory servers
Mobility at the IP Layer



Mobile user keeps fixed IP address
IP packets to the mobile user are received by the
home agent and tunneled to his current location
The most transparent form of mobility
–
–
everything works as if the host were fixed
TCP connections stay open when host moves
IP-in-IP Tunneling
Tunnel
FA
User
Mobile user net
HA
Internet
“owns” home net
IP address block
Rest of Internet
ISP-assigned IP address
FA and HA can be Linux, BSD, NOS, etc
Tunneled Packet Format
Outer IP
Header
Inner IP
Header
Src=HA
Dst=FA
Prot=IP
Src=CH
Dst=User
Prot=TCP
(etc)
TCP/
UDP
header
(etc)
User data
(if any)
Problems with Mobile IP



Mobile IP is elegant, but it comes at a price:
Increased per-packet overhead for tunneling
Non-optimum routing
–
–
increased delay, lowered reliability
can be serious over wide areas
Mobility in the DNS





The DNS provides a layer of indirection that can
be used to provide mobility
When a mobile host moves, it obtains a new IP
address and registers it with the server for his
zone
Requires short DNS TTLs if the host moves
frequently
Existing TCP connections break when moving
Advantage of much more efficient routing
–
no need to tunnel every user packet through home
agent
Application Mobility



Certain important applications have protocols
specifically designed to support mobility
Best example: email
SMTP implies ability to listen continuously at a
fairly stable IP address for incoming mail
–

TURN command never implemented
POP allows user to pull mail from a relay server
–
–
mail server plays role of home agent
POP is the registration protocol
Is Mobile IP Really Needed?

Most mobile hosts function only as clients:
–
–
–

Most couldn’t run servers anyway
–
–

intermittent operation on battery power
connectivity limits (e.g., air travel)
Most transactions are very short-lived
–

HTTP, SSH/Telnet, FTP
SMTP (for sending mail)
POP (for fetching mail)
but not all…
Dynamic addressing has served the dialup ISP
market well
Addressing

IP addresses are an increasingly scarce resource
–


IP does use space more efficiently than PSTN
Long term solution: IPv6
–

232 used to seem like such a large number
2128 still less than number of atoms in universe…
Short-term fixes have been effective
–
–
–
dynamic address allocation (PPP, DHCP)
CIDR
NATs, private address blocks (e.g., 10.x.x.x)
Security

General Internet problem, not just wireless
–



security issues only more obvious on wireless
Worthy of an entire tutorial by itself
General principle: place security mechanisms
close to entity being protected
Different mechanisms for different needs
–
–
link resource (e.g., theft of carrier service)
host computers (end-user privacy)
Encryption and Security

Encryption is essential element in security
–


Can authenticate or provide confidentiality
Governments don’t like confidentiality
–

export controls used to thwart widespread use
Carriers not motivated to protect users’ privacy
–

but is not magic bullet
and pressured by CALEA to do opposite
Ergo, user-provided end-to-end encryption
essential
Point-to-Point Protocol (PPP) RFC1661

Carries IP over generic point-to-point link
–
–
–
–


Type field for non-IP protocols
Configuration negotiation
–


Dialup modems
ISDN
Leased lines
IS-95 CDMA traffic channels (above RLP)
addresses, max sizes, etc
Authentication at link setup
No retransmission
PPP Frame Format
PPP
Flag
Hdr
Data
Flag: 0x7e
Header: 1-4 bytes (negotiable)
CRC: 16 bits
CRC Flag
PPP Framing

Bit-synchronous channels
–

Octet-synchronous channels
–

Synchronous modems, most leased lines
ISDN, IS-95
Asynchronous channels
–
Generic dialup modems
PPP on Synchronous Channels

Conventional HDLC framing:
–
–
–
–
–
opening, closing flags
0-bit stuffing of data for transparency
16-bit frame CRC
no link-level retransmission (framing only)
functionality in chips like Z8530 SCC
Octet-Synchronous PPP



Some channels (ISDN, IS-95) provide PPP with
a synchronous octet (byte) stream
No need for bit stuffing (physical layer maintains
byte alignment)
Still need frame delimiters and CRCs
–
byte stuffing to protect special chars:
-
–
0x7e -> 0x7d, 0x5e [flag]
0x7d -> 0x7d, 0x5d [escape character]
other special characters can also be escaped as
needed:
-
0x01 -> 0x7d, 0x21 [ascii control character]
c -> 0x7d, (c ^ 0x20) [general rule]
Asynchronous PPP



Universally used on dialup modems
Like octet-synchronous except arbitrary idle time
between bytes
Still need frame delimiters, CRCs, byte stuffing
–

same escape sequence procedure for special chars
Replaces earlier non-standard SLIP (Serial Line
IP) protocol
–
–
–
IP only
no negotiation facilities
no frame CRC
PPP: Link Configuration Protocol
(LCP)


Runs when link first brought up
Negotiates link-level parameters:
–
–
–
max frame size
special characters to be escaped (besides flag &
escape)
use of abbreviated PPP frame headers
-
-
default has address + control + 2 byte type to look like
standard HDLC UI-frame
most links negotiate to omit address & control and to use
1-byte type field
PPP: IP Configuration Protocol
(IPCP)

Establish IP address of client

PPP server allocates temporary address, or
– client notifies server of fixed address
Negotiate use of VJ TCP/IP header compression
–
Data on Digital Cellular Channels

IS-95 CDMA
–
–
IS-707 data standards
No modifications required to BTS
-

Globalstar
–

major advantage given widespread IS-95 deployment
very similar to IS-95 wrt data
GSM
–
–
circuit switched
General Packet Radio Service (GPRS)
The IS-95 Channel

Semi-connection-oriented
–

Designed for variable-data-rate vocoder
–

Frames sent at constant 50 Hz (20ms) rate
Four fixed-size frames with raw sizes:
–
–

hardware allocated to call, but air resource is
dynamically shared
Rate set 1 ("9.6"): 24, 48, 96, 192 bits
Rate set 2 ("14.4"): 36, 72, 144, 288 bits
Viterbi decoder tails and CRCs of varying sizes
reduce usable payload
Data on the IS-95 CDMA Channel


The IS-95 physical channel was designed for
voice; data was an afterthought
Voice delay considerations limit frame size
–
–

limited interleaving for slow fading
power control helps
Typical frame loss rates: 1-2%
–
–
acceptable for voice
unacceptable for data
Performance Without RLP

1500 byte IP/PPP packet, IS-95 Rate Set 1:
–
–
–

1500 bytes/22 bytes/frame = 68+ frames
For FER=.01, probability of packet success is
(1-.01)68 = 0.505 (pretty bad)
For FER=.02, probability of packet success is
(1-.02)68 = 0.253 (even worse)
TCP can only recover by resending entire packet
–
selective link-level retransmission clearly needed
Packet Data over IS-95 CDMA





IS-99/657/707 define a Radio Link Protocol for
sending packet data over IS-95 CDMA
RLP breaks variable-length PPP packets into one
of the 4 frame lengths supported by IS-95 Rate
Set 1 or 2 traffic channels
RLP senders add sequence numbers to frames
RLP receivers NAK missing frames and the
senders retransmit them
RLP is “mostly” reliable; it does not try to
provide perfect reliability
IS-95 CDMA Data Protocol Stack
Appl
TCP/
UDP
IP
PPP
RLP
IS-95
Physical
Quick Net Connect

Original concept: IP packet data support with
“dormant mode”
–

similar to demand-dialed ISDN
Political obstacles to CDMA packet data
–
–
–
lackluster carrier interest
vendor resistance (CDPD competition?)
inability to appreciate importance of Internet
-

some telcos still think “data” == “modems”
Asynch data/fax service based on TCP/IP
–
this was the “hook” for QNC
MDR

Multiple IS-95 channels associated with single
user data stream
–

conceptually similar to ISDN B-channel bonding
Variable-rate CDMA channel lessen need to
deallocate unused channels quickly
–
hardware is dedicated to call, but channel resource is
dynamically shared
GSM

Time-division multiple access channel
–
–
–


Burst rate 270.833 kb/s
8 timeslots/channel
182.4 kb/s/channel (including FEC)
Widespread in Europe, less so in US
Circuit-switched data already deployed
–
–
–
9.6 kb/s (sometimes 14.4 kb/s with less FEC)
dedicated air resource during call, wasteful for bursty
packet traffic
no direct ISP connection, must dial modem pool
GPRS

Medium-speed packet mode extension to GSM
–

FEC rates 1/2 to 1
–


9.05 to 21.4 kb/s/timeslot
Likely peak usable throughput ~60 kb/s
Can use up to 8 timeslots at once
–

similar to CDMA MDR
dynamically allocated
Link ARQ with LLC
–
HDLC and LAPD-like
Cellular Data Overlays


Cellular Digital Packet Data (CDPD)
Qualcomm HDR
Cellular Digital Packet Data (CDPD)

Packet data overlay on AMPS
–

Requires dedicated equipment in each cell
–
–


only shares spectrum, antennas & power
limited coverage, high costs & prices
RF channel compatible with AMPS (30 KHz)
GMSK modulation @ 19.2 ks/s
–

connectionless (simpler than IS-95)
usable throughput less due to (63,47) RS FEC
Shared channel
–
busy/idle bits for contention
CDPD Network Architecture

Backbone network based on OSI
–

defacto obsoleted by Internet protocols
Static IP addresses
–
–
can carry between serving systems
inefficient wide-area Internet routing
CDPD Traceroute
traceroute to storyprod.qualcomm.com (192.35.156.222), 30 hops max, 40 byte packets
1 san-diego-114.wireless.gte.net (198.226.11.26) 354.057 ms 347.197 ms 369.513 ms
2 198.226.23.161 (198.226.23.161) 389.023 ms 417.724 ms 419.519 ms
3 s11-0-0-18.houston1-cr1.bbnplanet.net (4.0.248.133) 499.053 ms 438.012 ms 439.506 ms
4 h3-0.dallas1-br2.bbnplanet.net (4.0.2.37) 439.056 ms 457.525 ms 429.508 ms
5 a4-0-1.atlanta1-br1.bbnplanet.net (4.0.3.237) 439.066 ms 417.797 ms 459.476 ms
6 4.0.2.142 (4.0.2.142) 479.025 ms 458.099 ms 459.846 ms
7 104.ATM2-0.XR1.ATL1.ALTER.NET (146.188.232.50) 479.854 ms 438.699 ms 429.833 ms
8 195.ATM3-0.TR1.ATL1.ALTER.NET (146.188.232.86) 839.835 ms 458.743 ms 459.819 ms
9 109.ATM6-0.TR1.LAX2.ALTER.NET (146.188.136.50) 499.84 ms 488.663 ms 529.831 ms
10 299.ATM7-0.XR1.LAX2.ALTER.NET (146.188.248.125) 499.837 ms 538.659 ms 499.821 ms
11 195.ATM10-0-0.GW1.SDG1.ALTER.NET (146.188.249.65) 479.846 ms 498.681 ms 499.81 ms
12 qualcomm-gw.customer.ALTER.NET (157.130.225.142) 490.27 ms 517.525 ms 519.817 ms
13 storyprod.qualcomm.com (192.35.156.222) 529.863 ms 668.736 ms 519.828 ms
HDR


High speed wireless packet data system under
development at Qualcomm
Physical layer borrows from IS-95, but
redesigned specifically for packet data
–



will require BTS overlays (like CDPD)
1.2288 MHz spread BW (same as IS-95)
Semi-connection-oriented (like IS-95)
Throughput depends on loading and distance
–
somewhat like ADSL
HDR Forward Link

Single stream of 128-byte frames
–




somewhat like ATM
Fixed symbol rate
Modulation alphabet and FEC code rate
determine user data rate
Constant transmit power
Data rate controlled by mobile request
–
–
38.4kb/s up to 2.4Mb/s
rate depends on SNR
HDR Reverse Link



Fixed-time 53ms frames
Pilot subchannel
Data rate varies from 4.8kb/s - 307kb/s
–

depends again on link margin
Closed loop power control
–
similar to IS-95
Speed Considerations

The higher the data rate, the slower the relative
fading
–
–


larger packets are good
higher data rates are bad (unfortunately)
Ergo, ARQ link protocol still required
HDR RLP similar to IS-707/IS-95
–
byte-numbered vs frame-numbered
Cellular Data Summary

Wireless systems discussed so far are cellularbased
–
–
–

asymmetric fwd & rev links on different frequencies
no direct mobile-to-mobile communication
systems centrally managed
Service model: telephone company or ISP
Ad-Hoc Packet Radio


Original model for DARPA work
Single frequency, symmetric modulation
–




permits direct peer-peer communication
Self-organizing topology
Decentralized control
Well suited to unlicensed bands (Part 15)
Service model: UseNET, Internet backbones
Examples of Ad-Hoc Nets

DARPA SURAN
–

Amateur (ham) packet radio
–

Pioneering work in 1970s-1980s
early 1980s-present
Part 15.247 devices
–
–
–
Many proprietary designs
IEEE 802.11
Metricom
Advantages of Ad-Hoc Networks

Lower getting-started costs
–
–

Well suited to free unlicensed spectrum
–

no need to install base stations
easier temporary setup
significant savings given typical auction prices
Inherent scalability
–
with power control & cooperative relaying, each user
contributes to network capacity
Challenges of Ad-Hoc Networks

Hidden terminal problem
–
–

with every terminal transmitting on the same channel,
stations can interfere with others it cannot hear
addressed with MACA protocol in 802.11
Power control necessarily more coarse than on
full-duplex IS-95 or HDR channel
Hidden Terminals
A and B can hear each other
B and C can hear each other
A and C cannot hear each other
A
B
C
If C transmits while A is transmitting to B,
C will interfere with B’s reception even though
it cannot hear A
MACA





RTS/CTS handshake to reduce chances of hidden
terminal collision
Sender sends brief Request-to-Send (RTS) giving
data length
Receiver returns Clear-to-Send (CTS) echoing
data length
All other transmitters stay off channel long
enough for sender to finish
Collisions can still occur on RTS messages
–
but they’re smaller than data messages
Conclusion

Roles exist for both cellular and ad-hoc data
networks
–
–

cellular provides common-carrier service
ad-hoc provides flexibility
Will be interesting to see if/how ad-hoc networks
take cellular’s market share