Part 8: Mobile transport layer

❒ Mobile transport layer

❍ “how to support mobility in Transport-layer”
❍ apps relies on transport-layer protocols (TCP, UDP,…)
• apps-addresses (ports)
• reliable end-to-end trans. (error detection, retransmission,…)
• flow-,seq.-, congestion control,…
❍ (Mobile network-layer only provides address/routing
mechanisms: “how to find/route packets to mobile node”)
❒ Subjects End-to-end

❍ Standard TCP
❍ TCP enhancements
Internet
• Indirect TCP
• Snooping TCP
• Mobile TCP Apps multiplex./ demultiplex

❍ Additional enhancements appl. appl. appl.

• Fast retransmission/recovery (ports)
Transport layer
• Transmission freezing, Transaction TCP,…
❍ TCP in 2.5/3G Network layer (IP)

Mobile Communications, ETB018, BTH 1

TCP-protocol: Basic mechanisms
TCP: Internet’s
❒ TCP (Transmission control protocol) connection-oriented
transport service,
❍ used by several common apps/protocols offering reliable, in-
• Web/HTTP, file transfer/FTP, mail/SMTP,… order, byte-stream
data-transfer to apps
❍ state-full protocol
• com.-parties exchange info prior to data-transfer
• negotiation/set-up procedure (“handshaking”)
– resource reservation, window parameters, seq.-numbers,…
❍ stream-oriented
• byte-streams (from apps) divided into distinct TCP-segments
❍ “network friendly”
• mechanisms to slow down senders transfer-rate
if network congested
❍ reliable, in-order delivery
• CRC, ACKs, retransmission,…(errors, loss,…)
• seq.-numbers (duplication control, in-order segments)
❍ TCP in mobile environments (= problems ?!)
• most mechanisms assumes fixed/wired networks, stations,…

Mobile Communications, ETB018, BTH 2

TCP-protocol: Congestion control
❒ Congestion
❍ main cause for packet-losses in fixed/wired networks
• (rather than trans.-errors, bugs in switch-soft/hardware,..)
❍ network exposed for more traffic/packets than it can manage
• routers may handle short periods of overload (buffering)
• long periods often result in buffer-overflow (= packet loss)
❍ upon congestion, sending stations must reduce their transfer-rates
• allowing network to recover (routers)
❒ TCP congestion control
❍ sender-TCP detects congestion via missing ACKs (…timeout)
• earlier sent TCP-segment lost (no ACK delivered), ACK lost,
or both segment/ACK lost
• (interpreted as congestion by TCP)
❍ TCP initiates slow-start
• stations reduce their transfer-rates (drastically)
• co-operation imperative to prevent Internet from collapse
– (several millions of end-stations attached !?)

Mobile Communications, ETB018, BTH 3

TCP-protocol: Congestion control
❒ Slow start algorithm
❍ sender calculates Congestion-window for receiver
• # unAcked segments a sender may have outstanding before
receiving ACK (initial size: 1 segment)
❍ on receiving ACKs, sender increase Cong.-window (exponentially)
• Ex: 1 -> 2 -> 4 -> 8 -> 16 ->…
❍ …up to Congestion-threshold (increase turns linear)
• Ex: 32 -> 33 -> 34 -> 35 ->…
❍ linear increase continues until: congestion
(congestion detected)

• TCP timeouts (missing ACK) window size

linear-
• or receive multiple ACKs increase

for same segment congestion

threshold
• (following segment(s) missing) congestion
exp.- threshold
❍ TCP responds by setting: increase
t
• Cong.-window = 1 segment
• Cong.-threshold = ½ * current value
– (half duration of exp.-increase)

Mobile Communications, ETB018, BTH 4

TCP-protocol: Early enhancements
❒ Fast retransmit/fast recovery
❍ enhancements to improve TCP efficiency
• avoid repeated slow-start and reduction of Cong.-threshold
❍ on reception of multiple ACKs for same segment, sender concludes:
• receiver got all segments up to ACKed segment
• receiver stills receives further segments
– (transmission of multiple ACKs for same segment is triggered
by other segments arriving out-of-sequence)
❍ sender assumes segment lost due to trans.-errors (not congestion)
• no slow-start or reduce of Cong.-threshold
❍ sender retransmit missing segment before timeout, avoiding slow-start
• “Fast retransmit”
❍ sender continues with same cong.-window/threshold as earlier
• “Fast recovery”
❍ (TCP implementing fast retransmit/fast recovery, only performs
slow-start if retransmission-timer timeouts)

Mobile Communications, ETB018, BTH 5

TCP-protocol: Packet-loss
❒ Packet-loss in fixed/wired networks (causes)
❍ network congestion (main cause)
• temp. overload in one/several node(s) in network path
❍ transmission errors: relative low BER (< 10-9, fiber optics)
• (switch hardware/software, links, …pretty reliable)

❒ Packet-loss in mobile/wireless network (causes)

❍ transmission errors (relative high)
• (BER might be > 10-3, channel impairments)
❍ handovers (unsuccessful, delayed)
• Ex: during FA-switch (Mobile IP: FAold -> FAnew)
• FAold lacks buffer-space or forwarding-capabilities during switch
• (soft handover -> major improvement)
❍ blocking/shadowing
temp. disconnection of radio-channel (movement: user/obstacle)
❍ congestion
• overcrowded cells, overloaded HAs, FAs, routers,…
• (nodes in both radio-access + fixed infrastructure network)
Mobile Communications, ETB018, BTH 6
TCP-protocol: Mobility
❒ Standard TCP in mobile/wireless environments
❍ TCP always concludes congestion on missing ACKs
• justified in fixed/wired network
• …devastating for mobile/wireless networks ?!
❍ slow-start (+ reduction of Cong.-threshold) under wrong assumptions
• increased delay and decreasing performance in
already “slow” (radio) connection
❍ main problem (standard TCP)
• can’t distinguish between packet losses causes
• “narrow-minded” ?!
❍ TCP designed for fixed/wired networks
• doing a great job keeping Internet up-and-running
• (never “familiarized” with mobile/wireless properties)

❒ TCP mobility enhancements (requirements)

❍ compatible with standard TCP (huge installation base)
❍ not jeopardize TCP’s congestion-control (fixed/wired networks)

Mobile Communications, ETB018, BTH 7

TCP enhancements: Indirect TCP
❒ Indirect TCP (I-TCP)
❍ TCP-connection (end-to-end) is segmented into 2 parts
• fixed part: fixed host <-> access point (standard TCP)
• wireless part: mobile host <-> access point (stand./enhanced TCP)
❍ access point (FA) terminates both TCP-connections
• “com.-partner” to both fixed/mobile host
• (FA = MN from CN’s perspective,…vice versa)
❍ FA receives, acknowledges, buffers, forwards incoming packets
• (on be half of MN, CN)
❍

❍ FA and MN performs “local retransmission” on wireless link

• increases overall performance
• prevents MN/CN to timeout

fixed host
mobile host access point (CN)
(MN) (FA) Internet

TCP (wireless) TCP (standard)

Mobile Communications, ETB018, BTH 8

TCP enhancements: Indirect TCP
❒ I-TCP: Packet-delivery

TCP TCP

MN FA CN
packet

ACK
packet

ACK

packet

packet ACK

ACK

t
Mobile Communications, ETB018, BTH 9
TCP enhancements: Indirect TCP
❒ Pros
❍ no modifications to standard-TCP (fixed part)
• minor modifications to TCP (wireless part)
• (no influence on TCP behavior in fixed network)
❍ isolate wireless link
• segmentation into 2 distinct connections prevents packet-losses
in wireless network to propagate into fixed network
• ACKs, retransmissions,… (handled locally)
❍ short delay (MN <-> FA) easily determined for optimizing timeout
• (speed up local retransmissions)
❍ optimization in wireless part (header compression, security,…)

❒ Cons
❍ loss of end-to-end semantics (foundation of TCP)
• CN, MN receiving ACKs, only means FA received packets
• FA crashes -> 2 loose-ends TCP-connections
❍ FA-handovers (socket/state-switch, buffering, latency, …)
❍ security (end-to-end encryption, FA must be a trusted part)
Mobile Communications, ETB018, BTH 10
TCP enhancements: Snooping TCP
❒ Snooping TCP
❍ buffer packets close to MN to enable fast local retransmission
• with no impact on TCP’s “end-to-end” semantics
❍ FA monitors, snoops, buffers packets going in both direction
• performs local retransmission upon packet-loss (missing ACKs)
❍ CN -> MN: FA snoops (and buffers) all packets in packet-flow
• (packets buffered until snooping of associated ACKs from MN)
• packet-loss detected via timeout or duplicated ACKs (from MN)
• FA performs local retransmission (prevent CN-timeout)
❍ MN -> CN: FA snoops/scans packets (seq.-number gaps = packet-loss)
• if gap detected: FA sends NACK to MN, triggering fast local
retransmission of packet (reordering by TCP in CN)

local retrans. Access point

mobile
(FA) fixed host
host (MN)
Internet (CN)

snooping of ACKs buffering of data

end-to-end TCP-connection

Mobile Communications, ETB018, BTH 11

TCP enhancements: Snooping TCP
❒ Snooping TCP: Packet-delivery

(packet flow: MN -> CN)

(packet flow: CN -> MN)
end-to-end TCP-connection end-to-end TCP-connection

CN FA MN MN FA CN
packet
packet packet
packet packet
packet
ACK
ACK ACK
ACK
packet packet
packet packet
timeout (FA) or
packet
duplicated ACKs (MN) packet
fast local packet (gap detected)
ACK retrans. packet
ACK NACK
fast local packet
packet retrans. packet
packet
ACK
ACK

(OBS!: slow-start with

cumulative ACKs)
t t

Mobile Communications, ETB018, BTH 12

TCP enhancements: Snooping TCP
❒ Pros
❍ TCP’s end-to-end connection/semantics intact (no segmentation)
• if FA crashes, standard TCP-connection still exist (CN <-> MN)
• (only lacks benefits of snoop + local retrans.)
❍ CN don’t need to be modified (TCP compatible !)
• enhancement implemented in FA (some modific. in MN,…NACKs)
❍ no “state-handover” required between FAs (roaming)
• packets buffered in FAold are not forwarded to FAnew
• relies on CN timeout/retransmission (standard-TCP)
❍ HO between snoop-TCP supported FA and non-supported FA
• (…falls back on standard-TCP)
❒ Cons
❍ don’t isolate wireless link (trans.-errors may propagate to CN)
• if to long until FA retransmits successfully, CN timeouts
• (FA’s timeout-value to big, long period of “bad” link,…)
❍ enhancements of MN required (…NACKs)
❍ security (end-to-end encrypt. -> snoop seq.-number impossible)
Mobile Communications, ETB018, BTH 13
TCP: Disconnections
❒ Disconnections
❍ common in mobile/wireless networks
• Ex: MN temp. loose radio-connection to base
• (shadowing/blocking, interference, bad coverage,…)
❍ TCP’s reaction on temp. disconnections: timeout -> retransmission
• (implied that disconnect. cause packet-loss)
❍ Standard-TCP
• retransmission timer (retrans.-interval) doubled for
each unsuccessful retrans.-attempt (up to max. 1 min)
• if connection returns, receiver may have to wait up to 1 min
before receiving retransmission (+ slow-start triggered)
❍ I-TCP
• FA must buffer more and more packets depending on
duration of disconnection (-> buffer overflow)
❍ Snooping TCP
• MN unable to return ACKs (CN reacts according to standard-TCP)
• if CN’s Cong.-window is large at time of disconnect (many
outstanding unACKed-packets), FA’s buffers may overflow,

Mobile Communications, ETB018, BTH 14

TCP enhancements: Mobile TCP
❒ Mobile TCP (M-TCP)
❍ focus on lengthy/frequent disconnections
❍ goals: prevent triggering of slow-start + reduction of Cong.-threshold
• (on packet-loss due to temp. disconnections)
• (+ preserve “end-to-end” semantics and support FA-handovers)
❍ M-TCP segments TCP-connection into 2 parts
❍ standard-TCP: CN <-> SH (Supervisory host…~FA)
• SH only forwards packets (no buffering or local retrans.)
❍ optimized TCP: SH <-> MN (TCP without slow-start)
• (Bandwidth manager: prevent congestion, “hogging” in wireless)
❍ SH monitors all packets to MN + ACKs returning from MN
❍ if no ACK for some time: SH assumes MN disconnected
• SH chokes sender (CN) by setting sender-window = 0
• CN set in “persistent-mode” (performs no timeout/retrans.)
❍ …later, SH (old or new) detects MN-connection again
• SH re-opens sender-window to old value
• (CN continues to send at same rate as earlier)

Mobile Communications, ETB018, BTH 15

TCP enhancements: Mobile TCP
❒ Pros
❍ TCP “end-to-end” connection/semantics intact
• SH only performs regular packet monitoring/forwarding
during periods of non-disconnection
• SH prevents useless retransmissions, unnecessary slow-starts,…
(during disconnection) by temp. choking sender
❍ simplified handover (between SHs)
• no buffering of packets in SH -> no buffers to forward to new SH
• lost packets is retransmitted to new SH (using standard-TCP)

❒ Cons
❍ don’t fully isolate wireless link
• only handles packet-losses caused by disconnections
• trans.-errors will propagate into network and to CN
• (SH don’t provide buffering-/retrans. features)
❍ optimized TCP in wireless part
• requires modification to MN’s protocol software
• Bandwidth manager (new network entity)

Mobile Communications, ETB018, BTH 16

TCP enhancements: Fast retransmit/recover
❒ Fast retransmission/recovery
❍ early enhancement for preventing slow-start to trigger on losses not
caused by congestion
• receiver sends duplicated ACKs to sender
• sender responds by (fast) retransmit lost packet(s)
• (using current Cong.-window, threshold,…)
❍ focus on handovers (MN moving to new FA)
• HOs introduce delays (…timeouts + slow-start in MN/CN)
❍ after MN registered at new FA, MN sends duplicated ACKs to CN
• (forcing CN to enter fast retransmit/recovery mode)
❍ CN retransmits all unACKed packets
• (preventing itself from trigger slow-start)
❒ Pros
❍ simple solution (only require modifications to MN)

❒ Cons
❍ only focus on problems regarding HO (not trans.-errors, disconnect,…)
❍ efficiency (CN may retransmits packets already delivered)

Mobile Communications, ETB018, BTH 17

TCP enhancements: Transmission freezing
❒ Transmission/timeout freezing
❍ focus on long periods of interruptions/disconnections (radio-channel)
• Ex: delayed HOs, enter overcrowded cell, long period of
interference, blocking/shadowing,…
• (packet-loss + TCP-timeout/disconnect)
❍ uses MAC-protocol’s “early knowledge” about radio-channel problems to
inform TCP about causes for packet-loss
• (prevents TCP from assume congestion -> timeout/disconnect)
❍ if MAC (MN, FA) detects radio-disconnection it informs TCP
• TCP temp. freezes transmission (+ current Cong.-window, timers)
• FA also needs mechanisms to inform CN
– (prevent slow-start, timeout, disconnect)
❍ later, MAC detects connectivity again, it informs TCP to resume
❒ Pros
❍ improves TCP performance (+ support “end-to-end” encryption)

❒ Cons
❍ lots of modification required in software/protocol of MN, FA, CN

Mobile Communications, ETB018, BTH 18

TCP enhancements: Selective retransmission
❒ Standard TCP retransmission schema (Go-back-n)
❍ TCP acknowledge in-order packets, using cumulative ACKs
• single ACK confirms reception of all packets up to certain packet
❍ if packet-loss, TCP retransmits all unACKed packets in buffer
• (lost packet + all outstanding packets)
• inefficient to retransmit of already successfully delivered packets

❒ Selective retransmission (selective-repeat)

❍ more efficient retransmission schema
❍ single ACK for each packet (not “bulks” of packets)
❍ if packet-loss, TCP only retransmits that “selected” packet
• (…saving scarce bandwidth)
❒ Pros
❍ improves performance in low-capacity links (≈
≈ wireless links)
❒ Cons
❍ requires modifications in both sender/receiver protocol-software
• additional buffer space, sorting-algorithms,…
• (CPU performance, power consumption,…)
Mobile Communications, ETB018, BTH 19
TCP enhancements: Transaction-TCP
❒ Transaction-oriented TCP
❍ focus on bursty and sparse short-msgs transmissions for apps requiring
TCP’s reliability features
❍ standard TCP’s 3 phases: setup -> data transfer -> release
• connection setup/release, both use “3-way handshake”
• min. 7-8 msgs for sending single data-msg MN TCP SYN CN
• acceptable for long sessions connection TCP SYN/ACK
in fixed networks setup
TCP ACK
• inefficient for short msgs/sessions data-
data msgs
in wireless networks transmission ACK
TCP FIN
❍ T-TCP combines setup-/release msgs
connection TCP FIN/ACK
with actual data-transfer release
TCP ACK
• reduce # msgs to min. 3
❒ Pros
❍ improves performance (overhead-reduction) MN
TCP SYN/data
CN

❒ Cons TCP ACK/FIN

❍ huge modifications in both sender/receiver software
TCP ACK

Mobile Communications, ETB018, BTH 20

TCP enhancements: Comparison
Approach Mechanism
Indirect TCP splits TCP connection
into two connections
Snooping TCP “snoops” data and
acknowledgements, local
retransmission
M-TCP splits TCP connection,
chokes sender via
window size
Fast retransmit/ avoids slow-start after
fast recovery roaming
Transmission/ freezes TCP state at
time-out freezing disconnect, resumes
after reconnection
Selective retransmit only lost data
retransmission
Transaction combine connection
oriented TCP setup/release and data
transmission
Mobile Communications, ETB018, BTH
Advantages Disadvantages
isolation of wireless loss of TCP semantics,
link, simple higher latency at
handover
transparent for end-to- problematic with
end connection, MAC encryption, bad isolation
integration possible of wireless link
Maintains end-to-end Bad isolation of wireless
semantics, handles link, processing
long term and frequent overhead due to
disconnections bandwidth management
simple and efficient mixed layers, not
transparent
independent of content changes in TCP
or encryption, works for required, MAC
longer interrupts dependant
very efficient slightly more complex
receiver software, more
buffer needed
Efficient for certain changes in TCP
applications required, not transparent
21
TCP for 2.5/3G networks
❒ Internet draft (Inamura, 2002)
❍ profile for optimization of TCP in 2.5G/3G networks
• GSM/GPRS, UMTS, cdma 2000,…
• (profile already used in I-mode, WAP 2.0,…)
❒ 2.5G/3G characteristics (TCP-tuning “point-of-view”)
❍ asymmetric (low) bitrates
• 2.5G: 10-20 Kbps (uplink), 20-50 Kbps (downlink)
• 3G (initial): 64 Kbps (uplink), 115-384 Kbps (downlink)
❍ latency/delay (high)
• coding delay (error correct/detect, voice-coding, interleave,
encryption, compression.,…)
• access delay (initial setup, reservation, authentication, HO,…)
❍ jitter/delay variations (high)
• temp. shadow/block, interference, packet-switching,…
❍ packet-loss (high)
• trans.-errors, HO-failures, congested nodes/cells,…
• (link-level retransmission: ARQ improves performance)

Mobile Communications, ETB018, BTH 22

TCP for 2.5/3G mobile networks
❒ TCP adaptation for 2.5/3G (Inamura, 2002)
❍ large windows
• large initial sender-window (2-4 packets) would increase overall
performance (especially for short sessions/few packets)
❍ large MTU (Message transfer unit)
• larger MTUs -> faster increase of cong.-window (byte-counted)
• (segmentation still performed by link-layer, radio-blocks)
❍ selective ACKs
• selective-retransmission of lost packets
❍ Explicit congestion notification (ECN)
• on receiving packet that experience congestion, receiver informs
sender by setting flag in next data/ACK (…similar to ATM)
❍ Timestamp
• included in packets for more accurate calculation/predict of RTT
• RTT (Round-trip-time) used by TCP to set timer/timeout values
❍ no header compression
• results in bad performance in presence of packet-loss
• (strong correlation between consecutive packets)
Mobile Communications, ETB018, BTH 23