Wireless Data Tutorial Phil Karn Senior Staff Engineer Qualcomm

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 – IS-95 CDMA, Globalstar, GSM Systems designed specifically for packet data – CDPD, HDR Ad-hoc packet radio networks – IEEE

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 Internets grandfathers

Key Internet Concepts End-to-end principle – push complexity and features to upper layers – I.e., out of network to user computers Simplified, 4-layer reference model Connectionless network layer – 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 – 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 dont 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 – covers OSI application & presentation layers – HTTP, Telnet, FTP, SMTP, POP, DNS, etc End-to-End Layer – OSI transport & session layers – TCP & UDP Internet Layer – OSI network (upper part) – IP Subnet Layer – OSI network (lower part), link, physical

How the Internet Model Differs from OSI Fewer layers – Presentation merged into application – Session & transport layers merged into end-to-end Single connectionless Internet layer – simple, least-common-denominator service Subnetwork layer deliberately unspecified – 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 IP ARP Enet PPP TCP UDP Telnet FTP SMTP POP ICMP DNS DHCP HTTP DialIS95ISDN Other subnetworks

Connectionless Networks Similar to postal system – perhaps an unfortunate metaphor Full addresses in every packet – network handles each packet independently Any notion of a connection is strictly end-to- end; the network doesnt know about them – 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., 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 Total Length TOSVerIHL Identification Source Address Destination Address Header Checksum TTLProtocol 0 DFDF MFMF Frag offset

End-to-End Protocols User Datagram Protocol (UDP) – defined in RFC 768 Transmission Control Protocol (TCP) – defined in RFC793 Internet Control Message Protocol (ICMP) – 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 Destination Port Checksum Length

UDP Applications Short transactions – Domain Name System (DNS) – Network File System (NFS) Real-time applications – Voice over IP Multicasting – Conferencing, broadcasting

TCP Connection-oriented Reliable – sequence numbering, retransmission Bi-directional – 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 isnt exact – This permits well known ports for servers

TCP Connection Management 3-way handshake opens bi-directional point-to- point 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 Source Port Destination Port Sequence Number Acknowledgement Number Window Checksum Urgent Pointer offs flags

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 TCPs name (Transmission Control Protocol) emphasizes the importance of this function TCPs 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 doesnt 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, theres no way to know if its 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 1 packet, expands 1 packet for every packet acked – called slow start - a misnomer since its 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 – TCP ACK snooping/spoofing Protocol translation (e.g., WAP) All violate end-to-end principle – less robust – complicates security Just say no!

Intermittent Connectivity Already common on wired networks – dialups – roving laptops Generally handled at the application layer – e.g., Post Office Protocol (POP) for 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 – stationary systems that own mobile users address and accept traffic on behalf of mobile user – analogous to cellular HLRs Foreign agents – 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 Internet HA FA Rest of Internet Mobile user net User owns home net IP address block ISP-assigned IP address FA and HA can be Linux, BSD, NOS, etc Tunnel

Tunneled Packet Format Outer IP Header Src=HA Dst=FA Prot=IP Inner IP Header 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: 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: – HTTP, SSH/Telnet, FTP – SMTP (for sending mail) – POP (for fetching mail) Most couldnt run servers anyway – intermittent operation on battery power – connectivity limits (e.g., air travel) Most transactions are very short-lived – but not all… Dynamic addressing has served the dialup ISP market well

Addressing IP addresses are an increasingly scarce resource – 2 32 used to seem like such a large number IP does use space more efficiently than PSTN Long term solution: IPv6 – 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 – but is not magic bullet Can authenticate or provide confidentiality Governments dont like confidentiality – export controls used to thwart widespread use Carriers not motivated to protect users privacy – 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 – Dialup modems – ISDN – Leased lines – IS-95 CDMA traffic channels (above RLP) Type field for non-IP protocols Configuration negotiation – addresses, max sizes, etc Authentication at link setup No retransmission

PPP Frame Format Flag PPP Hdr Data Flag CRC Flag: 0x7e Header: 1-4 bytes (negotiable) CRC: 16 bits

PPP Framing Bit-synchronous channels – Synchronous modems, most leased lines Octet-synchronous channels – 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 - major advantage given widespread IS-95 deployment Globalstar – very similar to IS-95 wrt data GSM – circuit switched – General Packet Radio Service (GPRS)

The IS-95 Channel Semi-connection-oriented – hardware allocated to call, but air resource is dynamically shared Designed for variable-data-rate vocoder – Frames sent at constant 50 Hz (20ms) rate Four fixed-size frames with raw sizes: – 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 = (pretty bad) – For FER=.02, probability of packet success is (1-.02) 68 = (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 IS-95 Physical RLP PPP IP TCP/ UDP Appl

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 kb/s – 8 timeslots/channel – 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 – similar to CDMA MDR 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 – 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 – connectionless (simpler than IS-95) Requires dedicated equipment in each cell – only shares spectrum, antennas & power – limited coverage, high costs & prices RF channel compatible with AMPS (30 KHz) GMSK 19.2 ks/s – 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

traceroute to storyprod.qualcomm.com ( ), 30 hops max, 40 byte packets 1 san-diego-114.wireless.gte.net ( ) ms ms ms ( ) ms ms ms 3 s houston1-cr1.bbnplanet.net ( ) ms ms ms 4 h3-0.dallas1-br2.bbnplanet.net ( ) ms ms ms 5 a4-0-1.atlanta1-br1.bbnplanet.net ( ) ms ms ms ( ) ms ms ms ATM2-0.XR1.ATL1.ALTER.NET ( ) ms ms ms ATM3-0.TR1.ATL1.ALTER.NET ( ) ms ms ms ATM6-0.TR1.LAX2.ALTER.NET ( ) ms ms ms ATM7-0.XR1.LAX2.ALTER.NET ( ) ms ms ms ATM GW1.SDG1.ALTER.NET ( ) ms ms ms 12 qualcomm-gw.customer.ALTER.NET ( ) ms ms ms 13 storyprod.qualcomm.com ( ) ms ms ms CDPD Traceroute

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) 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 cellular- based – 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 – Pioneering work in 1970s-1980s Amateur (ham) packet radio – early 1980s-present Part devices – Many proprietary designs – IEEE – Metricom

Advantages of Ad-Hoc Networks Lower getting-started costs – no need to install base stations – easier temporary setup Well suited to free unlicensed spectrum – 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 Power control necessarily more coarse than on full-duplex IS-95 or HDR channel

Hidden Terminals ABC A and B can hear each other B and C can hear each other A and C cannot hear each other If C transmits while A is transmitting to B, C will interfere with Bs 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 theyre 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 cellulars market share