Wireless LANs
Characteristics Infrastructure based
– MAC (MACA)
– Routing (Mobile IP)
– Transport (TCP variants)
Adhoc networks– Routing protocols
– Transport issues
Implementations– 802.11, HIPERLAN, Bluetooth
Other issues– Security
Wireless LANs: Characteristics
Types– Infrastructure based
– Adhoc
Advantages– Flexible deployment
– Minimal wiring difficulties
– More robust against disasters (earthquake etc)
– Historic buildings, conferences, trade shows,…
Disadvantages– Low bandwidth compared to wired networks (1-10 Mbit/s)
– Proprietary solutions
– Need to follow wireless spectrum regulations
Infrastructure vs. Adhoc Networks
infrastructure network
ad-hoc network
APAP
AP
wired network
AP: Access Point
Source: Schiller
Transmission: Infrared vs. Radio Infrared
– uses IR diodes, diffuse light, multiple reflections (walls, furniture etc.)
Advantages– simple, cheap, available in many
mobile devices
– no licenses needed
– simple shielding possible
Disadvantages– interference by sunlight, heat
sources etc.
– many things shield or absorb IR light
– low bandwidth
Example– IrDA (Infrared Data Association)
interface available everywhere
Radio– typically using the license free
ISM band at 2.4 GHz
Advantages– experience from wireless WAN
and mobile phones can be used
– coverage of larger areas possible (radio can penetrate walls, furniture etc.)
Disadvantages– very limited license free frequency
bands
– shielding more difficult, interference with other electrical devices
Example– WaveLAN, HIPERLAN,
Bluetooth
Source: Schiller
Wireless MAC: Motivation
Can we apply media access methods from fixed networks?
Example CSMA/CD– Carrier Sense Multiple Access with Collision Detection– send as soon as the medium is free, listen into the medium if a
collision occurs (original method in IEEE 802.3)
Medium access problems in wireless networks– signal strength decreases proportional to the square of the distance– sender would apply CS and CD, but the collisions happen at the
receiver– sender may not “hear” the collision, i.e., CD does not work– CS might not work, e.g. if a terminal is “hidden”
Difference Between Wired and Wireless
If both A and C sense the channel to be idle at the same time, they send at the same time.
Collision can be detected at sender in Ethernet. Half-duplex radios in wireless cannot detect collision at sender.
A B C
A
B
C
Ethernet LAN Wireless LAN
Hidden terminals– A and C cannot hear each other.
– A sends to B, C cannot receive A.
– C wants to send to B, C senses a “free” medium (CS fails)
– Collision occurs at B.
– A cannot receive the collision (CD fails).
– A is “hidden” for C.
Solution?– Hidden terminal is peculiar to wireless (not found in wired)
– Need to sense carrier at receiver, not sender!
– “virtual carrier sensing”: Sender “asks” receiver whether it can hear something. If so, behave as if channel busy.
Hidden Terminal Problem
BA C
Exposed Terminal Problem
Exposed terminals– A starts sending to B.
– C senses carrier, finds medium in use and has to wait for A->B to end.
– D is outside the range of A, therefore waiting is not necessary.
– A and C are “exposed” terminals.
A->B and C->D transmissions can be parallel; no collisions
A B
CD
MACA: Multiple Access with Collision Avoidance
MACA uses signaling packets for collision avoidance– RTS (request to send)
• sender request the right to send from a receiver with a short RTS packet before it sends a data packet
– CTS (clear to send) • receiver grants the right to send as soon as it is ready to receive
Signaling (RTS/CTS) packets contain– sender address– receiver address– packet size
Variants of this method are used in IEEE 802.11
MACA avoids the problem of hidden terminals– A and C want to send to B
– A sends RTS to B
– B sends CTS to A
– C “overhears” CTS from B
– C waits for duration of A’s transmission
MACA avoids the problem of exposed terminals– B wants to send to A, C to D
– C hears RTS from B->A
– C does not hear CTS from A
– C sends RTS to D
MACA Solutions [Karn90]
A B C
RTS
CTSCTS
A B CRTS
CTS
RTSD
D
MAC: Reliability
Wireless links are prone to errors. High packet loss rate detrimental to transport-layer performance.
Solution: Use of acknowledgements– When B receives DATA from A, B sends an ACK.
– If A fails to receive an ACK, A retransmits the DATA.
– Both C and D remain quiet until ACK (to prevent collision of ACK).
– Expected duration of transmission+ACK is included in RTS/CTS packets.
– This approach adopted in many protocols [802.11].
A B C
RTS
CTS CTS
DATA
D
RTS
ACK
Collision of RTS/CTS packets can happen (hidden terminal). If no CTS, retransmit RTS after backoff.
MAC: Collision Avoidance
With half-duplex radios, collision detection is not possible Collision avoidance: Once channel becomes idle, the node waits for a
randomly chosen duration before attempting to transmit
IEEE 802.11 DCF – When transmitting a packet, choose a backoff interval in the range
[0,cw]; cw is contention window– Count down the backoff interval when medium is idle– Count-down is suspended if medium becomes busy– When backoff interval reaches 0, transmit RTS
Time spent counting down backoff intervals is part of MAC overhead large cw leads to larger backoff intervals small cw leads to larger number of collisions
DCF Example
data
waitB1 = 5
B2 = 15
B1 = 25
B2 = 20
data
wait
B1 and B2 are backoff intervalsat nodes 1 and 2
cw = 31
B2 = 10
MAC: Congestion Control
Number of nodes attempting to transmit simultaneously may change with time; some mechanism to manage congestion is needed.
IEEE 802.11 DCF: Congestion control achieved by dynamically choosing the contention window cw
Binary Exponential Backoff in DCF:– When a node fails to receive CTS in response to its RTS, it increases the
contention window• cw is doubled (up to a bound CWmax)
– Upon successful completion data transfer, restore cw to CWmin
Optimization: MACAW– 802.11: cw reduces much faster than it increases– Backoff: multiply cw by 1.5 (instead of doubling)– Restore: Reduce cw by 1 (instead of CWmin)– cw reduces slower than it increases. Exponential increase linear decrease– Avoids wild oscillations of cw when congestion is high.
MAC: Energy Conservation
Wireless nodes need to conserve power (“resource poor”). Typical solution: Turning the radio off when not needed
Power Saving Mode in IEEE 802.11 (Infrastructure Mode)– An Access Point periodically transmits a beacon indicating which
nodes have packets waiting for them
– Each power saving (PS) node wakes up periodically to receive the beacon
– If a node has a packet waiting, then it sends a PS-Poll
• After waiting for a backoff interval in [0,CWmin]
– Access Point sends the data in response to PS-poll
MAC Protocols: Summary
Wireless medium is prone to hidden and exposed terminal problems
Protocols are typically based on CSMA/CA RTS/CTS based signaling Acks for reliability
Contention window is used for congestion control IEEE 802.11 wireless LAN standard Fairness issues are still unclear
Routing and Mobility
Finding a path from a source to a destination
Issues– Frequent route changes
• amount of data transferred between route changes may be much smaller than traditional networks
– Route changes may be related to host movement– Low bandwidth links
Goal of routing protocols– decrease routing-related overhead– find short routes– find “stable” routes (despite mobility)
Mobile IP (RFC 2002): Motivation
Traditional routing– based on IP destination address– network prefix determines physical subnet– change of physical subnet implies
• change of IP address (conform to new subnet), or• special routing table entries to forward packets to new subnet
Changing of IP address– DNS updates take to long time– TCP connections break– security problems
Changing entries in routing tables– does not scale with the number of mobile hosts and frequent changes in
the location– security problems
Solution requirements– retain same IP address, use same layer 2 protocols– authentication of registration messages, …
Mobile IP: Basic Idea
Router1
Router3
Router2
S MN
Home agent
Source: Vaidya
Mobile IP: Basic Idea
Router1
Router3
Router2
S MN
Home agent
Foreign agent
move
Packets are tunneledusing IP in IP
Source: Vaidya
Mobile IP: Terminology
Mobile Node (MN)– node that moves across networks without changing its IP address
Home Agent (HA)– host in the home network of the MN, typically a router– registers the location of the MN, tunnels IP packets to the COA
Foreign Agent (FA)– host in the current foreign network of the MN, typically a router– forwards tunneled packets to the MN, typically the default router
for MN Care-of Address (COA)
– address of the current tunnel end-point for the MN (at FA or MN)– actual location of the MN from an IP point of view
Correspondent Node (CN)– host with which MN is “corresponding” (TCP connection)
Data transfer to the mobile system
Internet
sender
FA
HA
MN
home network
foreignnetwork
receiver
1
2
3
1. Sender sends to the IP address of MN, HA intercepts packet (proxy ARP)2. HA tunnels packet to COA, here FA, by encapsulation3. FA forwards the packet to the MN
Source: Schiller
CN
Data transfer from the mobile system
Internet
receiver
FA
HA
MN
home network
foreignnetwork
sender
1
1. Sender sends to the IP address of the receiver as usual, FA works as default router
Source: Schiller
CN
Reverse tunneling (RFC 2344)
Source: Schiller
Internet
receiver
FA
HA
MN
home network
foreignnetwork
sender
3
2
1
1. MN sends to FA2. FA tunnels packets to HA by encapsulation3. HA forwards the packet to the receiver (standard case)
CN
Mobile IP: Other Issues
Reverse Tunneling– firewalls permit only “topological correct“ addresses– a packet from the MN encapsulated by the FA is now topological correct
Agent Advertisement– HA/FA periodically send advertisement messages into their physical subnets– MN listens to these messages and detects, if it is in home/foreign network– MN reads a COA from the FA advertisement messages
Registration – MN signals COA to the HA via the FA– HA acknowledges via FA to MN– limited lifetime, need to be secured by authentication
Optimizations– Triangular Routing
• HA informs sender the current location of MN – Change of FA
• new FA informs old FA to avoid packet loss, old FA now forwards remaining packets to new FA
Multi-Hop Wireless Networks
May need to traverse multiple links to reach destination
Mobility causes route changes
Source: Vaidya
Mobile Ad Hoc Networks (MANET)
Host movement frequent Topology change frequent
No cellular infrastructure. Multi-hop wireless links. Data must be routed via intermediate nodes.
A B AB
Source: Vaidya
Routing in MANET
Mobile IP needs infrastructure– Home Agent/Foreign Agent in the fixed network
– DNS, routing etc. are not designed for mobility
MANET– no default router available
– “every” node also needs to be a router
Can we use traditional routing algorithms?– Distance Vector
• periodic exchange of routing tables (destination, distance, next hop)
• selection of the shortest path if several paths available
– Link State
• periodic notification about current state of physical links (flooding)
• router get a complete picture of the network
Traditional Routing
A routing protocol sets up a routing table in routers
A node makes a local choice depending on global topology
Source: Keshav
Distance-vector & Link-state Routing
Both assume router knows– address of each neighbor
– cost of reaching each neighbor
Both allow a router to determine global routing information by talking to its neighbors
Distance vector - router knows cost to each destination
Link state - router knows entire network topology and computes shortest path
Distance Vector Routing: Example
2
Source: Keshav
Link State Routing: Example
Source: Keshav
Extending Traditional Routing to MANET
Traditional routing protocols have been designed for fixed networks with infrequent changes; typically assume symmetric links
MANET– dynamic topology:
• frequent route changes• no “border” routers
– wireless medium: • variable connection quality • limited bandwidth (further reduced due to routing updates)• links may be asymmetric
– resource poor mobile nodes:• routing table updates consume energy without contributing to data Tx• sleep modes difficult to realize
MANET Routing Protocols
Reactive protocols– Determine route if and when needed
– Source initiates route discovery
– Example: DSR (dynamic source routing)
Proactive protocols– Extension of traditional routing protocols
– Maintain routes between every host pair at all times
– Example: DSDV (destination sequenced distance vector)
Hybrid protocols– Adaptive; Combination of proactive and reactive
– Example : ZRP (zone routing protocol)
Multicast routing
Dynamic Source Routing (DSR) [Johnson96]
When source S wants to send a packet to destination D, but does not know a route to D, S initiates a route discovery
S floods Route Request (RREQ) Each node appends its own identifier when forwarding RREQ
D on receiving the first RREQ, sends a Route Reply (RREP) RREP sent on route obtained by reversing the route appended in RREQ RREP includes the route from S to D, on which RREQ was received by D
S on receiving RREP, caches the route included in the RREP When S sends a data packet to D, entire route is included in the header Intermediate nodes use the source route in the packet header to determine
to whom a packet should be forwarded
Route Discovery in DSR
B
A
S E
F
H
J
D
C
G
IK
Z
Y
Represents a node that has received RREQ for D from S
M
N
L
Source: Vaidya
Route Discovery in DSR
B
A
S E
F
H
J
D
C
G
IK
Represents transmission of RREQ
Z
YBroadcast transmission
M
N
L
[S]
[X,Y] Represents list of identifiers appended to RREQ
Route Discovery in DSR
B
A
S E
F
H
J
D
C
G
IK
• Node H receives packet RREQ from two neighbors: potential for collision
Z
Y
M
N
L
[S,E]
[S,C]
Route Discovery in DSR
B
A
S E
F
H
J
D
C
G
IK
• Node C receives RREQ from G and H, but does not forward it again, because node C has already forwarded RREQ once
Z
Y
M
N
L
[S,C,G]
[S,E,F]
Route Discovery in DSR
B
A
S E
F
H
J
D
C
G
IK
Z
Y
M
• Nodes J and K both broadcast RREQ to node D• Since nodes J and K are hidden from each other, their transmissions may collide
N
L
[S,C,G,K]
[S,E,F,J]
Route Discovery in DSR
B
A
S E
F
H
J
D
C
G
IK
Z
Y
• Node D does not forward RREQ, because node D is the intended target of the route discovery
M
N
L
[S,E,F,J,M]
Route Reply in DSR
B
A
S E
F
H
J
D
C
G
IK
Z
Y
M
N
L
RREP [S,E,F,J,D]
Represents RREP control message
Data Delivery in DSR
B
A
S E
F
H
J
D
C
G
IK
Z
Y
M
N
L
DATA [S,E,F,J,D]
Packet header size grows with route length
DSR Issues
Optimizations: cache routes learnt by any means– When S finds route [S,E,F,J,D] to D, S also learns route [S,E,F] to F– When K receives RREQ[S,C,G] for G, K learns route [K,G,C,S] to S– When F forwards RREP [S,E,F,J,D], F learns route [F,J,D] to D– When E forwards Data [S,E,F,J,D], E learns route [E,F,J,D] to D
Advantages– Routes maintained only between nodes who need to communicate– Reduces overhead of route maintenance– Caching (at intermediate nodes) can further reduce route discovery overhead
Disadvantages– Packet header size grows with route length due to source routing– Flood of route requests may potentially reach all nodes in the network– Route Reply Storm problem: Many intermediate nodes reply from local cache– Stale caches will lead to increased overhead
Destination-Sequenced Distance-Vector (DSDV) [Perkins94Sigcomm]
Each node maintains a routing table which stores– next hop, cost metric towards each destination– a sequence number that is created by the destination itself
Each node periodically forwards routing table to neighbors– Each node increments and appends its sequence number when sending its
local routing table Each route is tagged with a sequence number; routes with greater
sequence numbers are preferred
Each node advertises a monotonically increasing even sequence number for itself
When a node decides that a route is broken, it increments the sequence number of the route and advertises it with infinite metric
Destination advertises new sequence number
Destination-Sequenced Distance-Vector (DSDV)
When X receives information from Y about a route to Z– Let destination sequence number for Z at X be S(X), S(Y) is sent
from Y
– If S(X) > S(Y), then X ignores the routing information received from Y
– If S(X) = S(Y), and cost of going through Y is smaller than the route known to X, then X sets Y as the next hop to Z
– If S(X) < S(Y), then X sets Y as the next hop to Z, and S(X) is updated to equal S(Y)
X Y Z
Reactive v/s Proactive Trade-offs
Reactive protocols– Lower overhead since routes are determined on demand– Significant delay in route determination– Employ flooding (global search)– Control traffic may be bursty
Proactive protocols– Always maintain routes– Little or no delay for route determination– Consume bandwidth to keep routes up-to-date– Maintain routes which may never be used
Which approach achieves a better trade-off depends on the traffic and mobility patterns
Zone Routing Protocol (ZRP) [Haas98]
ZRP combines proactive and reactive approaches
All nodes within hop distance at most d from a node X are said to be in the routing zone of node X
All nodes at hop distance exactly d are said to be peripheral nodes of node X’s routing zone
Intra-zone routing: Proactively maintain routes to all nodes within the source node’s own zone.
Inter-zone routing: Use an on-demand protocol (similar to DSR or AODV) to determine routes to outside zone.
ZRP: Example
Radius of routing zone = 2
MANET Routing: Summary
Protocols– Typically divided into proactive, reactive and hybrid– Plenty of other routing protocols: location-aided, power-aware, ….– Several recent proposal in IETF’s MANET Working Group
http://www.ietf.org/ Performance Studies
– Typically studied by simulations using ns, discrete event simulator– Nodes (10-30) remains stationary for pause time seconds (0-900s) and
then move to a random destination (1500m X300m space) at a uniform speed (0-20m/s). CBR traffic sources (4-30 packets/sec, 64-1024 bytes/packet)
– Attempt to estimate latency of route discovery, routing overhead …
Actual trade-off depends a lot on traffic and mobility patterns– Higher traffic diversity (more source-destination pairs) increases overhead
in on-demand protocols– Higher mobility will always increase overhead in all protocols
See Nitin Vaidya’s MobiCom’2000 tutorial
TCP in Wireless Environments
TCP provides– reliable ordered delivery (by means of retransmissions, if necessary)– cumulative ACKs (an ACK acknowledges all contiguously received data)– duplicate ACKs (whenever an out-of-order segment is received) – end-to-end semantics (receiver sends ACK after data has reached)– implements congestion avoidance and control using congestion window
Factors affecting TCP performance in Wireless:– Wireless transmission errors
• may cause fast retransmit, which results in reduction in congestion window size
• reducing congestion window in response to errors is unnecessary– Multi-hop routes on shared wireless medium
• Longer connections are at a disadvantage compared to shorter ones, because they have to contend for wireless access at each hop
– Route failures due to mobility
40 39 3738
3533
TCP basics: Cumulative Acknowledgements
A new cumulative acknowledgement is generated only on receipt of a new in-sequence packet
41 40 3839
35 37
3634
3634
i data ackiSource: Vaidya
TCP: Delayed Acknowledgements
An ack is delayed until– another packet is received, or
– delayed ack timer expires (200 ms typical)
Reduces ack traffic
40 39 3738
3533
41 40 3839
35 37
New ack not producedon receipt of packet 36,
but on receipt of 37
TCP: Duplicate Acknowledgements
A dupack is generated whenever an
out-of-order segment arrives at the receiver
40 39 3738
3634
42 41 3940
36 36
Dupack
(Above example assumes delayed acks)On receipt of 38
TCP: Duplicate Acknowledgements
Duplicate acks are not delayed Duplicate acks may be generated when
– a packet is lost, or
– a packet is delivered out-of-order (OOO)
40 39 3837
3634
41 40 3739
36 36
DupackOn receipt of 38
TCP: Window Based Flow Control
Sliding window protocol Window size minimum of
– receiver’s advertised window - determined by available buffer space at the receiver
– congestion window - determined by the sender, based on feedback from the network
Flow control is “self-clocking”– new data sent only when old data is ACK’d
– congestion window size bounds amount of data that can be sent per RTT
2 3 4 5 6 7 8 9 10 11 131 12
Sender’s window
Acks received Not transmitted
TCP: Detection of packet loss
Retransmission timeout (RTO)– sender sets retransmission timer for only one packet– if ACK not received before timer expiry, the packet is assumed lost– RTO dynamically calculated, doubles on each timeout
Duplicate ACKs– may be generated due to packet loss or out-of-order delivery– sender assumes packet loss if it receives three consecutive dupacks
Fast Retransmit– RTO expiry may take too long– sender assumes packet loss if it receives three consecutive dupacks
On detecting a packet loss, TCP sender assumes that network congestion has occurred and drastically reduces the congestion window
TCP: Slow Start and Congestion Avoidance
Slow Start initially, congestion window size cwnd = 1 MSS (maximum segt size) increment window size by 1 MSS on each new ack phase ends when window size reaches slow-start threshold (ssthresh) cwnd grows exponentially with time during slow start
– factor of 1.5 per RTT if every other packet ack’d
– factor of 2 per RTT if every packet ack’d
Congestion Avoidance On each new ack, increase cwnd by 1/cwnd packets cwnd increases linearly with time during congestion avoidance
– 1/2 MSS per RTT if every other packet ack’d
– 1 MSS per RTT if every packet ack’d
TCP: Congestion Control
On detecting a packet loss, TCP sender– assumes network congestion, drastically reduces the congestion window– Reducing cwnd reduces amount of data that can be sent per RTT
Congestion Control: Timeout timeout occurs when no more packets are getting across
– ssthresh is set to half the window size before packet loss– cwnd is reduced to the initial value of 1 MSS– slow start is initiated
Congestion Control: Fast Retransmit Fast retransmit occurs when multiple (>= 3) dupacks are received Fast recovery follows fast retransmit (different from timeout)
– a packet is lost, but latter packets get through– ack clock is still there; no need to slow start– ssthresh is set to half the window size before packet loss– missing segment is retransmitted (fast retransmit)– cwnd is reduced to ssthresh (by half) when a new ACK is received– enter congestion avoidance phase
Impact of Multi-hop Wireless Paths
TCP throughput degrades with increase in number of hops Packet transmission can occur on at most one hop among
three consecutive hops– Increasing the number of hops from 1 to 2, 3 results in increased
delay, and decreased throughput
Increasing number of hops beyond 3 allows simultaneous transmissions on more than one link, however, degradation continues due to contention between TCP Data and ACKs traveling in opposite directions
When number of hops is large enough (>6), throughput stabilizes [Holland99]
mobility causeslink breakage,resulting in routefailure
TCP data and acksen route discarded
Impact of Node Mobility
TCP sender times out.Starts sending packets again
Route isrepaired
No throughput
No throughputdespite route repair
TCP throughput degrades with increase in mobility but not always
Larger route repairdelays are especially harmful
Improved Throughput with Increased Mobility
Low speed: (Route from A to D is broken for ~1.5 seconds)•When TCP sender times after 1 second, route still broken.•TCP times out after another 2 seconds, and only then resumes
High speed: (Route from A to D is broken for ~0.75 seconds)•When TCP sender times out after 1 second, route is repaired
TCP timeout interval somewhat (not entirely) independent of speedNetwork state at higher speed may sometimes be more favorable than lower speed
C
B
D
A
C
B
D
A
C
B
D
A
Impact of Route Caching
TCP performance typically degrades when caches are used for route repair
When a route is broken, route discovery returns a cached route from local cache or from a nearby node
After a time-out, TCP sender transmits a packet on the new route.
However, typically the cached route has also broken after it was cached
Another route discovery, and TCP time-out interval Process repeats until a good route is found
timeout dueto route failure
timeout, cachedroute is broken
timeout, second cachedroute also broken
Caching and TCP performance
Caching can result in faster route repair– Faster does not necessarily mean correct
– If incorrect repairs occur often enough, caching performs poorly
If cache accuracy is not high enough, gains in routing overhead may be offset by loss of TCP performance due to multiple time-outs
Need mechanisms for determining when cached routes are stale
Impact of Acknowledgements
TCP ACKs (and link layer acks) share the wireless bandwidth with TCP data packets
Data and ACKs travel in opposite directions– In addition to bandwidth usage, ACKs require additional receive-send
turnarounds, which also incur time penalty
Reduction of contention between data and ACKs, and frequency of send-receive turnaround
Mitigation [Balakrishnan97]– Piggybacking link layer acks with data– Sending fewer TCP acks - ack every d-th packet (d may be chosen
dynamically)– Ack filtering - Gateway may drop an older ack in the queue, if a new ack
arrives
TCP Parameters after Route Repair
Window Size after route repair– Same as before route break: may be too optimistic– Same as startup: may be too conservative– Better be conservative than overly optimistic– Reset window to small value; let TCP learn the window size
Retransmission Timeout (RTO) after route repair– Same as before route break: may be too small for long routes– Same as TCP start-up: may be too large and respond slowly to
packet loss– new RTO could be made a function of old RTO and route lengths
Improving TCP Performance in Wireless
Classification 1: – based on nature of actions taken to improve performance– Hide error losses from the sender
• if sender is unaware of the packet losses due to errors, it will not reduce congestion window
– Let sender know, or determine, cause of packet loss• if sender knows that a packet loss is due to errors, it will not
reduce congestion window Classification 2:
– based on where modifications are needed– At the sender node only– At the receiver node only– At intermediate node(s) only– Combinations of the above
Indirect TCP (I-TCP)
I-TCP splits the TCP connection– no changes to the TCP protocol for wired hosts
– TCP connection is split at the wireless interface (foreign agent) into 2 connections, (one from CN to FA and other from FA to MN)
– hosts in wired network do not notice characteristics of wireless part
– no real end-to-end connection any longer
mobile hostaccess point (foreign agent) „wired“ Internet
„wireless“ TCP standard TCP
Source: Schiller
I-TCP socket and state migration
mobile host
access point2
Internet
access point1
socket migrationand state transfer
Source: Schiller
I-TCP: Issues
Advantages– no changes in the fixed network necessary– no changes for the hosts (TCP protocol) necessary– all current optimizations to TCP still work– transmission errors on wireless link do not propagate into the fixed
network– simple to control, “mobile” TCP is used only for one wireless hop
• a very fast retransmission of packets is possible (short delay on the mobile hop is known)
Disadvantages– loss of end-to-end semantics, ACK to sender does not guarantee that
the packet was received (FA may crash)– buffering and forwarding of packets from one FA to another, may
increase latency
Snooping TCP
“Transparent” extension of TCP within the foreign agent– buffer packets sent to the mobile host
– lost packets on the wireless link (both directions) are retransmitted immediately by the mobile host or foreign agent, respectively
– foreign agent “snoops” the packet flow and recognizes ACKs in both directions; it also filters ACKs
Source: Schiller
„wired“ Internet
buffering of data
end-to-end TCP connection
local retransmission correspondenthostforeign
agent
mobilehost
snooping of ACKs
Snooping TCP: Issues
Data transfer to the mobile host– FA buffers data until it receives ACK of the MH
– FA detects packet loss via dupacks or timeout
– fast retransmission possible, transparent for the fixed network
Data transfer from the mobile host– FA detects packet loss on the wireless link via sequence numbers
– FA answers directly with a NACK to the MH
– MH can now retransmit data with only a very short delay
Integration of the MAC layer– MAC layer can detect and discard duplicated packets
Problems– snooping TCP does not isolate the wireless link as good as I-TCP
– snooping might be useless depending on encryption schemes
Mobile TCP (M-TCP)
Special handling of lengthy and/or frequent disconnections M-TCP splits as I-TCP does
– unmodified TCP fixed network to supervisory host (SH)– optimized TCP SH to MH
Supervisory host– no caching, no retransmission– monitors all packets, if disconnection detected
• set sender window size to 0• sender automatically goes into persistent mode
– old or new SH reopens the window Advantages
– maintains semantics, supports disconnection, no buffer forwarding Disadvantages
– loss on wireless link propagated into fixed network– adapted TCP on wireless link
Impact of Handoffs on Schemes to Improve TCP
Split connection (I-TCP) – hard state at base station must be moved to new base station
Snoop protocol– soft state need not be moved
– while the new foreign agent builds new state, packet losses may not be recovered locally
Frequent handoffs a problem for schemes that rely on significant amount of hard/soft state at base stations– hard state should not be lost
– soft state needs to be recreated to benefit performance
Improving TCP Throughput
Network feedback– Network knows best (why packets are lost)– Need to modify transport & network layer to receive/send feedback- Need mechanisms for information exchange between layers
Inform TCP of route failure by explicit message
Let TCP know when route is repaired– Probing– Explicit notification– Better route caching mechanisms
Reduces repeated TCP timeouts and backoff
Impact of Mobility on TCP: Summary
TCP assumes congestion if packets are dropped Random/transmission errors may cause fast retransmit which results in
– retransmission of lost packet– reduction in congestion window
Reducing congestion window in response to errors is unnecessary Reduction in congestion window reduces the throughput
Mobility itself can cause packet loss– e.g. when a node moves from one access point to another while packets
are in transit, and forwarding is not possible
Performance of an unchanged TCP degrades severely– TCP cannot be changed fundamentally, due to widespread deployment– Several adaptation proposals exist
See Nitin Vaidya’s MobiCom’99 tutorial
Wireless LAN Implementations
IEEE 802.11 (WaveLan)
HIPERLAN
Bluetooth
