Download mobicom-old - Computer Science, Columbia University

Wireless IP Multimedia
Henning Schulzrinne
Columbia University
MOBICOM Tutorial, September 2002
7 May 2017
Overview
 Types of wireless multimedia
applications
– streaming
– interactive
– object delivery
 Properties of multimedia
content
– loss resiliency
– delay
– reordering
 3G and WLAN MMrelated channel
properties
– effective bandwidth
– packet loss
– delay
7 May 2017
 Header and signaling
compression
– cRTP
– ROHC
– signaling compression
 Packet FEC
 UMTS multimedia
subsystem (IMS)
– QoS
– Session setup
 Fast handoff
mechanisms
 Multimodal networking
Types of wireless multimedia
applications
 Streaming
– video/audio on demand
– may be cached at various places, including end system
 Interactive
– VoIP
– multimedia conferences
– multiplayer games
 Object retrieval
– peer-to-peer
– user may be waiting for result
 Messaging
– store-and-forward (e.g., MMS)
– can be batched
7 May 2017
IETF (multimedia) protocols
SAP
SDP
MGCP
DHCPP
SIP
RTSP
RSVP
Network
TCP
Physical
PPP
SONET
7 May 2017
RTCP
RTP
DNS
LDAP
CIP
MIP
(H.261. MPEG)
UDP
IDMP
MIP-LR
MIPv6
IPv4, IPv6, IP Multicast ICMP
AAL3/4
ATM
AAL5
IGMP
PPP
802.11b
Heterogeneous
Access
Ethernet CDMA 1XRTT
/GPRS
Kernel
H.323
media encap
Application
Media Transport
Signaling
Common wired & wireless audio
codecs
codec name
standards
org.
sampling
rate
G.711 (µ/A-law)
ITU
8,000
any
64
G.723.1
ITU
8,000
20 ms
5.3, 6.3
G.729 (CS-ACELP)
ITU (1996)
8,000
10 ms
8
AMR
ETSI
(adaptive multi-rate) 26.090
(1999)
8,000
20 ms
4.75 – 12.2 (8)
GSM-HR
GSM 06.20
8,000
20 ms
5.6
GSM-FR
GSM 06.10
8,000
20 ms
13
AMR-WB (wideband) ETSI
7 May 2017
frame size bit rate (kb/s)
(Hz)
6.7: PDC-EFR
7.4: IS 641
12.2: GSM-EFR
16,000 20 ms
6.6 – 23.85 (9)
Audio codecs, cont'd.
codec name
standards
org.
samplin
g rate
EVRC (RCELP)
TIA/EIA
(1996)
G.726 (ADPCM)
G.728 (LD-CELP)
7 May 2017
frame
size
bit rate (kb/s)
8,000
20 ms
8.55, 4, 0.8
ITU
8,000
sample
16, 24, 32, 40
ITU
8,000
20 ms
16
(Hz)
Audio codecs
 MP3 and AAC: delay > 300 ms  unsuitable for
interactive applications
 GSM and AMR are speech (voiceband) codecs  3.4
kHz analog designed for circuit networks with nonzero BER
 Wideband = split into two bands, code separately 
conferencing
 AMR is not variable-rate (dependent on speech
content)
 receiver sends Codec Mode Request (CMR) to request
different codec, piggy-backed on reverse direction
 trade-off codec vs. error correction
7 May 2017
Audio codecs
 Typically, have algorithmic look-ahead of
about 5 ms  additional delay
– G.728 has 0.625 ms look-ahead
 AMR complexity: 15-25 MIPS, 5.3 KB RAM
original
4
6
8
10
12
14
16
18
20
G.723.1
G.729
G.729A
AMR-NB
AMR-WB
7 May 2017
www.voiceage.com
22
24
Audio codecs - silence
 Almost all audio codecs support Voice Activity
Detection (VAD) + comfort noise (CN)
– comfort noise: rough approximation in energy and
spectrum  avoid "dead line" effect
– G.729B
– AMR built-in: CN periodically in Silence Indicator
(SID) frames = discontinuous transmission (DTX)
 saves battery power
– or source controlled rate (SCR)
7 May 2017
Audio codecs - silence
 silence periods depend on
– background noise
– word vs. sentence vs. alternate speaker
 particularly useful for conferences
– small ratio of speakers to participants
– avoid additive background noise
7 May 2017
Video codecs
JPEG
e.g., DCT:
spatial  frequency
Frames of
Digital Video
Motion
Estimation
&
Compensation
predict current
frame from previous
common code words 
shorter symbols
Huffman, arithmetic coding
Transform,
Quantization, ZigZag Scan & RunLength Encoding
Symbol
Encoder
Bit Stream
Quantization changes representation
size for each symbol
adjust rate/quality trade-off
Run-length encoding:
long runs of zeros  run-length symbol
7 May 2017
MPEG, H.26x
courtesy
M. Khansari
History of video codecs
H.261
ITU-T
H.263
H.263++
H.263+
ISO
MPEG 1
MPEG 4
MPEG 2
1990
7 May 2017
1992
H.263L
1994
1996
MPEG 7
1998
2000
2002
courtesy
M. Khansari
H.263L example
64 kb/s, 15 fps
7 May 2017
Delay requirements
 In many cases, channel is delay constrained:
– ARQ mechanisms
– FEC
– low bandwidths
 ITU G.114 Recommendation:
– 0..150 ms one way delay: acceptable to most users
– 150..400 ms: acceptable with impairments
 Other limits:
– telnet/ssh limit ~ 100-200 ms [Shneiderman 1984, Long
1976]?
– reaction time 1-2 s for human in loop [Miller 1968]:
•
•
•
•
7 May 2017
web browser response
VCR control for streaming media
ringback delay for call setup
can often be bridged by application design
802.11 architecture
ESS
Existing
Wired LAN
AP
STA
BSS
AP
STA
STA
BSS
STA
Infrastructure
Network
STA
Ad Hoc
Network
STA
BSS
BSS
STA
Ad Hoc
Network
STA
Mustafa Ergen
7 May 2017
802.11b hand-off
Kanter, Maguire, Escudero-Pascual, 2001
7 May 2017
802.11 delay
channel
is busy
idle
slots
Data
ACK
idle slots
time
DIFS
SIFS
(DCF interframe space)
idle
slots
DIFS
(short IFS)
RTS
CTS
Data
idle
slots
ACK
time
DIFS
SIFS
IFS (µs)
7 May 2017
SIFS
SIFS
FHSS
DSSS
DIFS
OFDM
SIFS
28
10
13
PIFS
78
30
19
DIFS
128
50
25
M. Zukerman
802.11 delay
802.11
1, 2 Mb/s
DSSS
802.11b
11 Mb/s
FHSS, DSSS
802.11a
2, 11, 24, 54 Mb/s OFDM
 802.11b: 192 bit PHY headers  192 µs (sent
at 1 Mb/s)
 802.11a: 60 µs
 three MAC modes:
– DCF
– DCF + RTS
– PCF: AP-mode only
7 May 2017
Mean data frame delay (msec)
802.11 delay

Payload:
512 bits
2430 bits
4348 bits
8184 bits







7 May 2017



Throughput


802.11 delay
Mean message delay (msec)


Hyper-geometric
Geometric
Dual fixed
Fixed






7 May 2017



Throughput


802.11a delay for VoIP
7 May 2017
802.11b channel access delay
Köpsel/Wolisz
• 12 mobile data nodes, 4 mobile with on/off audio
• 6 Mb/s load
7 May 2017
802.11b VoIP delay
 Köpsel/Wolisz WoWMoM 2001: add priority
and PCF enhancement to improve voice delay
DCF
Köpsel/Wolisz
7 May 2017
802.11b – PCF+priority
 poll only stations with
audio data
 move audio flows from
PCF to DCF and back
after talkspurts
Köpsel/Wolisz
• IEEE 802.11 TGe working on enhancements for MAC (PCF and DCF)
• multiple priority queues
7 May 2017
802.11e = enhanced DCF
HC
hybrid controller
TC
traffic categories
AIFS
arbitration IFS
TXOP
transmission opportunity
Mustafa Ergen
7 May 2017
802.11e back-off
7 May 2017
Metric of VoIP quality
 Mean Opinion Score (MOS) [ITU P.830]
– Obtained via human-based listening tests
– Listening (MOS) vs. conversational (MOSc)
4
Quality
5
Excellent
4
Good
3
Fair
2
Poor
1
Bad
7 May 2017
3.5
MOS
Grade
iLBC 14kb/s
G.729 8kb/s
G.723.1 6.3kb/s
3
2.5
2
1.5
0
0.03 0.06 0.09 0.12 0.15
average loss probability
FEC and IP header overhead
 An (n,k) FEC code has (n-k)/k overhead
 Typical IP/UDP/RTP header is 40 bytes
codec
iLBC
(4,2) FEC
media pkt size
(T=30ms)
rmedia
rIP
54 bytes 14.4 kb/s
25.1 kb/s
108 bytes 28.8 kb/s
39.5 kb/s
G.729
(4,2) FEC
30 bytes
8 kb/s
18.7 kb/s
60 bytes
16 kb/s
26.7 kb/s
G.723.1
(4,2) FEC
24 bytes
6.4 kb/s
17.1 kb/s
48 bytes 12.8 kb/s
23.5 kb/s
7 May 2017
Predicting MOS in VoIP
 The E-model: an alternative to humanbased MOS estimation
– Do need a first-time calibration from an
existing human MOS-loss curve
 In VoIP, the E-model simplifies to two
main factors: loss (Ie) and delay (Id)
 A gross score R is computed and
translated to MOS.
 Loss-to-Ie mapping is codec-dependent
and calibrated
7 May 2017
Predicting MOS in VoIP, contd
– From loss and
delay to their
impairment scores
and to MOS
35
E-model Id
45
Ie (loss impairment)
 Example mappings
50
40
35
30
25
20
15
10
0
25
3.5
Id (delay impairment)
4
MOS
3
2
10
1.5
5
1
7 May 20170
R to MOS mapping
2.5
15
0
0.18
4.5
30
20
G.729 T=20ms random loss
0.03 0.06 0.09 0.12 0.15
average loss probability
50 100 150 200 250 300 350 400
delay (ms)
0.5
20
40
60
R value
80
100
Predicting MOS under FEC
 Compute final loss probability pf after
FEC [Frossard 2001]
– Bursty loss reduces FEC performance
– Increasing the packet interval T makes FEC
more efficient under bursty loss [Jiang
2002]
 Plug pf into the calibrated loss-to-Ie
mapping
 FEC delay is n*T for an (n,k) code
 Compute R value and translate to MOS
7 May 2017
Quality Evaluation of FEC vs.
Codec Robustness
 Codecs under evaluation
– iLBC: a recent loss-robust codec proposed in
IETF; frame-independent coding
– G.729: a near toll quality ITU codec
– G.723.1: an ITU codec with even lower bit-rate,
but also slightly lower quality.
 Utilize MOS curves from IETF presentations
for FEC MOS estimation
 Assume some loss burstiness (conditional
loss probability of 30%)
 Default packet interval T = 30ms
7 May 2017
G.729+(5,3) FEC vs. iLBC
 Ignoring delay effect, a larger T improves FEC
efficiency and its quality
 When considering delay, however, using a
60ms interval is overkill, due to higher FEC
delay (5*60 = 300ms)
4
3.8
3.8
3.6
3.6
3.4
3.4
MOS
MOS_c
4
3.2
3.2
3
2.8
G.729+(5,3)
2.6 G.729+(5,3),T=60ms
iLBC,no FEC
2.4
0
0.03
0.06
0.09
0.12
average loss probability
7 May 2017
G.729+(5,3)
G.729+(5,3),T=60ms
iLBC, no FEC
3
2.8
2.6
0.15
2.4
0
0.03
0.06
0.09
0.12
average loss probability
0.15
G.729+(5,2) vs. iLBC+(3,2)
 When iLBC also uses FEC, and still keeping
similar gross bit-rate
– G.729 still better, except for low loss conditions
when considering delay
4
3.8
3.8
3.6
3.6
3.4
3.4
MOS
MOS_c
4
3.2
3.2
3
2.8
2.4
2.8
G.729+(5,2)
G.729+(5,2),T=60ms
iLBC+(3,2)
2.6
0
7 May 2017
0.03
0.06
0.09
0.12
average loss probability
3
G.729+(5,2)
G.729+(5,2),T=60ms
iLBC+(3,2) FEC
2.6
0.15
2.4
0
0.03
0.06
0.09
0.12
average loss probability
0.15
G.729+(7,2) vs. iLBC+(4,2)
 Too much FEC redundancy (e.g., for G.729)
 very long FEC block and delay
 not always a good idea
 iLBC wins in this case, when considering delay
4
3.8
3.8
3.6
3.6
3.4
3.4
MOS
MOS_c
4
3.2
3.2
3
2.8
2.4
2.8
G.729+(7,2)
iLBC+(4,2)
2.6
0
7 May 2017
0.03
0.06
0.09
0.12
average loss probability
3
G.729+(7,2)
iLBC+(4,2)
2.6
0.15
2.4
0
0.03
0.06
0.09
0.12
average loss probability
0.15
G.729+(3,1) vs. iLBC+(4,2)
 Using less FEC redundancy may actually
help, if the FEC block is shorter
 Now G.729 performs similar to iLBC
4
3.8
3.8
3.6
3.6
3.4
3.4
MOS
MOS_c
4
3.2
3.2
3
2.8
2.4
2.8
G.729+(3,1)
iLBC+(4,2)
2.6
0
0.03
0.06
0.09
0.12
average loss probability
7 May 2017
3
G.729+(3,1)
iLBC+(4,2)
2.6
0.15
2.4
0
0.03
0.06
0.09
0.12
average loss probability
0.15
Comparison with G.723.1
 MOS(G.723.1) < MOS(iLBC) at zero loss
 iLBC dominates more low loss areas compared
with G.729, whether delay is considered or not
4
4
G.723.1+(2,1)
G.723.1+(2,1),T=60ms
iLBC, no FEC
3.8
3.6
3.8
3.6
3.4
MOS
MOS_c
3.4
3.2
3.2
3
2.8
2.8
2.6
2.4
3
0
0.03
0.06
0.09
0.12
average loss probability
7 May 2017
0.15
G.723.1+(2,1)
2.6 G.723.1+(2,1),T=60ms
iLBC,no FEC
2.4
0
0.03
0.06
0.09
0.12
average loss probability
0.15
G.723.1+(3,1) vs. iLBC+(3,2)
 iLBC is still better for low loss
 G.723.1 wins for higher loss
4
3.8
3.8
3.6
3.6
3.4
3.4
MOS
MOS_c
4
3.2
3.2
3
2.8
G.723.1+(3,1)
G.723.1+(3,1),T=60ms
2.6
iLBC+(3,2)
2.4
0
0.03
0.06
0.09
0.12
average loss probability
7 May 2017
3
2.8
0.15
G.723.1+(3,1)
G.723.1+(3,1),T=60ms
2.6
iLBC+(3,2)
2.4
0
0.03
0.06
0.09
0.12
average loss probability
0.15
G.723.1+(4,1) vs. iLBC+(4,2)
 iLBC dominates in this case whether delay is
considered or not,
– (4,2) code already suffices for iLBC
– (4,1) code’s performance essentially “saturates”
4
3.8
3.8
3.6
3.6
3.4
3.4
MOS
MOS_c
4
3.2
3.2
3
2.8
G.723.1+(4,1)
G.723.1+(4,1),T=60ms
2.6
iLBC+(4,2)
2.4
0
0.03
0.06
0.09
0.12
average loss probability
7 May 2017
3
2.8
0.15
G.723.1+(4,1)
G.723.1+(4,1),T=60ms
2.6
iLBC+(4,2)
2.4
0
0.03
0.06
0.09
0.12
average loss probability
0.15
The best of both worlds
 Observations, when considering delay:
– iLBC is usually preferred in low loss conditions
– G.729 or G.723.1 + FEC better for high loss
 Example: max bandwidth 14 kb/s
– Consider delay impairment (use MOSc)
4
iLBC,no FEC
G.729+(5,3)
G.723.1+(2,1),T=60ms
3.8
3.6
MOS_c
MOS_c
3.4
3.2
3
2.8
2.6
2.4
0
7 May 2017
0.03
0.06
0.09
0.12
average loss probability
0.15
4
iLBC Max BW: 14 kb/s
3.8
G.723.1+(2,1),T=60ms
3.6
3.4
3.2 G.729+(5,3)
3
2.8
2.6
2.4
0 0.03 0.06 0.09 0.12 0.15
average loss probability
Max Bandwidth: 21-28 kb/s
4
iLBC, no FEC
G.729+(5,2)
3.8
3.6
MOS_c
MOS_c
3.4
3.2
3
2.8
2.6
2.4
0
4
0.03
0.06
0.09
0.12
average loss probability
0.15
iLBC, no FEC
G.729+(3,1)
G.729+(5,2)
3.8
3.6
MOS_c
MOS_c
3.4
3.2
3
2.8
2.6
2.4
0
7 May 2017
0.03
0.06
0.09
0.12
average loss probability
0.15
4
iLBC Max BW: 21 kb/s
3.8
3.6
3.4
G.729+(5,2)
3.2
3
2.8
2.6
2.4
0 0.03 0.06 0.09 0.12 0.15
average loss probability
4
iLBC Max BW: 28 kb/s
3.8
3.6
3.4 G.729+(3,1)
G.729+(5,2)
3.2
3
2.8
2.6
2.4
0 0.03 0.06 0.09 0.12 0.15
average loss probability
Effect of max bandwidth on
achievable quality
 14 to 21 kb/s: significant improvement in MOSc
 From 21 to 28 kb/s: marginal change due to
increasing delay impairment by FEC
4
3.8
3.6
MOS_c
3.4
3.2
3
2.8
Max BW: 14 kb/s
Max BW: 21 kb/s
Max BW: 28 kb/s
2.6
2.4
7 May 2017
0
0.03
0.06
0.09
0.12
average loss probability
0.15
UMTS and 3G wireless
 Staged roll-out with "vintages"  releases:
– Release 3 ("1999")  GPRS data services
• Multimedia messaging service (MMS) = SMS successor ~ MIME
email
• RAN via evolved CDMA
– Release 4: March 2001
– Release 5: March-June 2002
– Release 6: June 2003  all-IP network
 Main future new features (affecting packet services):
– All-IP transport in the Radio Access and Core Networks
– Enhancements of services and service management
– High-speed Downlink Packet Access (HSDPA)
• Introduces additional downlink channels:
– High-Speed Downlink Shared Channel (HS-DSCH)
– Shared Control Channels for HS-DSCH
7 May 2017
UMTS
macrocell 2 km 144 kb/s
microcell 1 km 384 kb/s
picocell 60 m 2 Mb/s
 Follow-on to GSM, but WCDMA physical layer
 new ($$$) spectrum around 2 GHz
 radio transmission modes:
– frequency division duplex (FDD): 2 x 60 MHz
– time division duplex (TDD): 15 + 20 MHz
 Chip rate 3.84 Mcps  channel bandwidth
4.4 – 5 MHz
7 May 2017
1G-3G air interface
1G
2G
“2.5G”
3G/ IMT-2000 Capable
Existing Spectrum
Analog
AMPS
IS-95-A/
cdmaOne
IS-95-B/
cdmaOne
New Spectrum
cdma2000 1X (1.25 MHz)
cdma2000 3X (5 MHz)
1XEV DO: HDR (1.25 MHz)
136 HS
EDGE
IS-136
TDMA
TACS
GSM GPRS
EDGE
GSM
WCDMA
HSCSD
7 May 2017
Ramjee
The mysterious 4G
 Fixes everything that's wrong with 3G 
 Convergence to IP model: treat radio access
as link layer that carries IP(v6) packets
– not necessarily new radio channel
• no new spectrum available
 all-IP radio access network (RAN)
 common mobility management
– AAA and roaming
– user identifiers
– roaming across wired networks
7 May 2017
UMTS
UTRAN
Packet switched Core Network
IP
server
UE
Application
Applic.
GGSN
TCP
Radio Access Bearers
IP
IP
TCP
IP
IP
SGSN
RNC
Radio Bearers
PDCP
RLC
Logical channels
MAC
Transport channels
PHY
PDCP
Iu UP
Iu UP
RLC
GTP-U
GTP-U
MAC
UDP
UDP
Node B
PHY
FP
FP
PHY
AAL2/
ATM
AAL2/
ATM
IP
IP
AAL5/
ATM
AAL5/
ATM
GTP-U
GTP-U
GPRS
IP backbone
UDP/
TCP
IP routing
IP
IP
IP
UDP/
TCP
IP
Physical channels
Uu
Iub
Iu
Gn
Gn/Gp
Gi
W. Granzow
7 May 2017
3GPP network architecture
Iu
Uu
End user
terminal
Radio Access Network
Core Network
AS
7 May 2017
Jalava
3GPP network architecture gateways
Legacy Mobile
Signaling Networks
Multimedia
IP Networks
Roaming Signaling
Gateway (R-SGW)
Mh
Mm
Ms
HSS
CSCF
Gi
Cx
Mg
Mr
Gi
MRF
Gi
SGSN
GGSN
Media Gateway
Control Function
(MGCF)
Transport Switching
Gateway (T-SGW)
Mc (= H.248)
Media Gateway
(MGW)
7 May 2017
Gi
Media Gateway
(MGW)
PSTN/Legacy/External
Alves
3GPP networks – call control
-View on CALL CONTROL Applications & Services
VHE / OSA
CAP
Application I/F
Home
Subscriber
Server (HSS)
Call State Control
Function (CSCF)
Cx
Mr
(=HLR + +)
Gr
Gc
Gi
Multimedia Resource
Function (MRF)
Gi
access
SGSN
Gn
to other
networks
GGSN
Iu
Gf
EIR
7 May 2017
Alves
UMTS network architecture
MSC
GSN
RNC
Node B
Mobile Services Switching Center
GPRS Support Node
MSC/GSN
Radio Network controller
Base Node
RNC
RNC
Radio network
System (RNS)
Node B
Node B
Node B
Node B
Node B
7 May 2017
No
Node B
W. Granzow
Aside: some 3G/UMTS
terminology
CS
circuit-switched
GERAN
GSM/EDGE Radio Access Network
GGSN
Gateway GPRS Support Node. A router between the
GPRS network and an external network (i.e., the
Internet).
PDP
Packet Data Protocol
PDP context
A PDP connection between the UE and the GGSN.
PS
packet-switched
SGSN
Serving GPRS Support Node
UTRAN
Universal Terrestrial Radio Access Network
See RFC 3114 for brief introduction.
7 May 2017
UTRA transport channels
categories
 Common channels
– Multiplexed users (user ID in the MAC header)
• Forward Access Channel (FACH)
• Random Access Channel (RACH)
• Common Packet Channel (CPCH)
 Dedicated channels (DCH)
– Assigned to a single user (identified by the spreading code)
 Shared channels
– „Sharing“ of code resource by several users by fast reassignment scheduling
• Downlink Shared Channel (DSCH)
7 May 2017
Transmission Format UTRA
FDD
1 radio frame (10 ms), 15*2560 chips (3.84 Mcps)
Slot 1
Slot 2
Slot i
Uplink
frequency
Microcell
layer
5 MHz
5 MHz
Duplex distance, e.g. 190 MHz
7 May 2017
time
Downlink
Macrocell layers
5 MHz
Slot 15
5 MHz
UMTS/3G QoS classes
conversational voice, video
conferencing
streaming
video streaming
interactive
low delay, strict
ordering
modest delay,
strict ordering
web browsing, games modest delay
background
email download
7 May 2017
no delay
guarantees
QoS class requirements
 Excerpt from 3GPP TS 23.107:
Traffic class
Conversational
Streaming
Residual BER
5*10-2, 10-2,
5*10-3, 10-3,
10-4, 10-6
5*10-2, 10-2,
5*10-3, 10-3,
10-4, 10-5, 10-6
4*10-3, 10-5,
6*10-8
4*10-3, 10-5,
6*10-8
SDU error rate
10-2, 7*10-3,
10-3, 10-4, 10-5
10-1, 10-2,
7*10-3, 10-3,
10-4, 10-5
10-3, 10-4, 10-
10-3, 10-4,
10-6
Transfer delay
 100 ms
 250 ms
Guaranteed bit rate
2,048 kb/s
2,048 kb/s
Traffic handling
priority
Allocation/retention
priority
7 May 2017
Interactive
6
Background
1,2,3
1,2,3
1,2,3
1,2,3
1,2,3
GPRS delay
Gurtov, PWC 2001
7 May 2017
UMTS transport
External
PLMN
Gp
Iub
RBS
UE
UTRAN
RNC
Host
GGSN
Gn
IP
Network
UMTS/GPRS
Backbone
(IPv4)
SGSN
Appl
Appl
TCP/UDP
TCP/UDP
IP
IP
Relay
GTP-U
GTP-U
Relay
PDCP
GTP-U
PDCP
RLC
MAC
MAC
IP
IP
IP
IP
L1
L1
L2/L1
L2/L1
L2/L1
L2/L1
UE
Uu
UTRAN
User level IP
Transport level IP
7 May 2017
UDP
Iu-PS
UDP
SGSN
IP
L2
L2
L1
L1
GTP-U
RLC
UDP
IP
UDP
Gn/Gp
GGSN
Gi
Host
UMTS Release 4/5
Architecture
Kulkarni
7 May 2017
UMTS IP multimedia
7 May 2017
QoS in UMTS
 Short term: signaling  tell network elements about QoS
requirements
– RSVP (IntServ)
– DiffServ with DSCPs
– PDP context
 Longer term: provisioning  allocate resources to QoS classes
–
–
–
–
low network utilization (overprovisioning)
DiffServ
IntServ (possibly for DiffServ classes, RFC xxxx)
MPLS
 Mechanisms can be heterogeneous
– DSCP translation
– localized RSVP
7 May 2017
QoS signaling in UMTS
 UMTS R5: two end-to-end QoS signaling scenarios
 QoS provisioning left vague
 RSVP currently not in standard
– additional scenario featuring RSVP may be added to a later
release of the standard
 QoS connected to application layer signaling (SIP)
SIP - Session Initiation Protocol
–
–
–
–
necessary for IP telephony, not streaming or data
SIP allows applications to agree on address, port, codec, ...
standardized by IETF
but UMTS-specific SIP dialect
• additional functionality compared to IETF SIP
7 May 2017
UMTS – 3GPP and 3GGP2
 Divided regionally/historically:
– both from ITU IMT-2000 initiative
– GSM  3GPP (ETSI) = WCDMA
– US (CDMA)  3gpp2 (TIA) = CDMA2000
 3GPP2: different PHY, but similar
applications (not completely specified)
– cdma2000
7 May 2017
Session setup: SIP
INVITE
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com
[email protected]:
;branch=z9
128.59.16.1
Max-Forwards: 70
To: Bob <sip:[email protected]>
REGISTER
From: Alice <sip:[email protected]>
;tag=1928301774
Call-ID: [email protected]
CSeq: 314159 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 142
BYE
7 May 2017
Session setup: SIP
 Creates, modifies, terminates
sessions
 sessions = audio, video, text
messages, …
 IETF RFC 3261-3266
 UTF-8 text, similar to HTTP
– request line
– headers
– body (= session description ~
SDP), not touched by proxies
 URLs for addresses
Client 1
Client 2
INVITE
100 Trying
INVITE
180 Ringing
180 Ringing
200 OK
200 OK
ACK
ACK
Media streams
BYE
BYE
200 OK
200 OK
– sip:[email protected]
– tel:+1-212-555-1234
Jalava
7 May 2017
SIP request routing
 SIP proxies route all SIP requests
 don't care about method (INVITE, REGISTER, DESTROY, …)
 use location server based on registrations
– e.g., sip:[email protected]  sip:[email protected]
 route to one or more destinations
– parallel forking
– sequential forking
 use Via header to track proxies visited  loop prevention
 normally, only during first request in dialog
– but proxy can request visits on subsequent requests via RecordRoute
– user agent copies into Route header
– also used for service routing  preloaded routes
7 May 2017
3GGP Internet Multimedia
Subsystem
 services (call filtering, follow-me, …) provided in
home network, via Home Subscriber Server (HSS)
 may use CAMEL for providing services, but also
–
–
–
–
Call Processing Language (CPL)
SIP Common Gateway Interface (sip-cgi, RFC 3050)
SIP Servlets (JAIN)
VoiceXML for voice interaction (IVR)
 use ENUM (DNS) to map E.164 numbers to SIP URIs
– +46-8-9761234 becomes 4.3.2.1.6.7.9.8.6.4.e164.arpa
 mechanisms and roles:
– proxy servers  call routing, forking
– user agents (UA)  voice mail, conferencing, IM
– back-to-back UA (B2BUA)  3rd party call control
7 May 2017
3GPP Internet Multimedia
Subsystem
Call State Control Function (CSCF)
Interrogating-CSCF
• Accesspoint to domain
Subscription
Location Function
HSS
Diameter
Diameter
Cx
Dx
UE
Gm
UA
Mw
P-CSCF
(User Agent)
SIP
AS
ISC
Cx
SIP
Mw
I-CSCF
SIP
Visited
Domain
Application
Server
Sh
SLF
• Hides topology and configuration
Proxy-CSCF
Home
Subscriber
Server
S-CSCF
SIP
Home
Domain
Serving-CSCF
• Session control services
• Registration, AS usage, charging, etc
7 May 2017
Jalava
IMS session overview
UA1
UA1's visited network
UA1’s home network
P-CSCF
S-CSCF
I-CSCF
(optional)
I-CSCF
UA2
I-CSCF
S-CSCF
I-CSCF
P-CSCF
UA2’s home network
UA2’s visited network
7 May 2017
Jalava
Locating the P-CSCF
UE
GGSN
DHCP server
DNS server
1. PDP Context Activation
2. DHCP-Query/Response
2. DHCP-Relay
3. DNS-Query/Response
2 mechanisms:
UE
SGSN
GGSN
1. Activate PDP Context Request
1. Create PDP Context Request
2. Get IP address(es)
of P-CSCF(s)
3. Create PDP Context Response
3. Activate PDP Context Accept
7 May 2017
3GPP SIP registration
Visited Network
UE
Home Network
P-CSCF
I-CSCF
HSS
S-CSCF
1. Register
2. Register
3. Cx-Query
4. Cx-Query Resp
5. Cx-Select-pull
6. Cx-Select-pull Resp
7. Register
8. Cx-put
9. Cx-put Resp
10. Cx-Pull
11. Cx-Pull Resp
12. Service Control
13. 200 OK
15. 200 OK
14. 200 OK
sip:[email protected]
7 May 2017
TS 23.228/5.1
3GPP IMS call setup
UE(A)
GGSN(A) P-CSCF(A)
Other xCSCFs
P-CSCF(A) GGSN(B)
UE(B)
1. Session Initiation
2. Prealerting
3. Pre-alerting indication
4. User
interaction
5. UE(B)
generates
accepted SDP
6. Session Progress / Session Offering
7. Initial UMTS bearer creation
8. Ringing
9. Alerting indication
10. User
interaction
11. UMTS bearer modification
12. Session Acknowle dgement
7 May 2017
IMS call setup with QoS
Home Network
Visited Network
UE#1
P-CSCF
S-CSCF
1. INVITE
2. 100 Trying
3. INVITE
4. 100 Trying
5. Evaluation of Initial
Filter Criterias
6. INVITE
7. 100 Trying
9.183 Session
Progress
8. 183 Session
Progress
10. Authorize QoS resources
11. 183 Session
Progress
12. PRACK
13. Resource
Reservation
14. PRACK
18. 200 OK
19. UPDATE
17. 200 OK
20. UPDATE
23. 200 OK
15. PRACK
16. 200 OK
21. UPDATE
22. 200 OK
24. 200 OK
25. 180 Ringing
27. 180 Ringing
28. PRACK
26. 180 Ringing
33. 200 OK
32. 200 OK
29. PRACK
30. PRACK
31. 200 OK
34. 200 OK
35. 200 OK
36. Approval of QoS commit
37. 200 OK
38. ACK
7 May 2017
39. ACK
40. ACK
SIP for mobility
 Terminal mobility
– same device, different attachment point
• nomadic/roaming user: change between sessions
• mid-session mobility
 Personal mobility
– same person, multiple devices
– identified by SIP address-of-record
 Service mobility
– configuration information
– address book, speed dial, caller preferences, …
 Session mobility
– hand-over active session to different device
• e.g., cell phone to office PC
7 May 2017
SIP for terminal mobility
 For most UDP applications, no need to keep constant
source IP address at CH
– e.g., RTP uses SSRC to identify session
– others typically single request-response (DNS)
 TCP: see Dutta et al. (NATs, proxies) or
Snoeren/Balakrishnan TCP migration
CH
REGISTER IP1
INVITE
re-INVITE
IP2
7 May 2017
registrar
[email protected]:
128.59.16.1
REGISTER IP2
SIP mobility vs. mobile IP
 Mobility at different layers:
– permanent identifier
– rendezvous point identified by that identifier
– forwarding of messages
mobile IP
SIP
permanent identifier IP address
SIP AOR
temporary address
care-of-address
Contact header
rendezvous point
home agent (
permanent address)
registrar ( host part of
AOR)
HA/FA discovery
ICMP
not needed (name)
binding update
UDP message
REGISTER
in visited network
foreign agent (FA)
none/outbound proxy
7 May 2017
SIP personal mobility
7 May 2017
SIP hierarchical registration
1
From: alice@NY
Contact: 193.1.1.1
2
From: alice@NY
Contact: alice@CA
CA
San Francisco
NY
4
3
From: alice@NY
Contact: 192.1.2.3
REGISTER
INVITE
Los Angeles
7 May 2017
registrar
proxy
3GPP – IETF SIP differences
 SIP terminal + authentication = 3GPP
terminal
 signaling as covert channel?  death of SMS?
 CSCFs are not quite proxies, not quite
B2BUAs
–
–
–
–
modify or strip headers
initiate commands (de-registration, BYE)
edit SDP  violate end-to-end encryption
modify To/From headers
7 May 2017
NSIS = Next Steps in Signaling
 IETF WG to explore alternatives (or profiles?) of RSVP
– currently, mostly requirements and frameworks
 RSVP complexity  multicast support
– forwarding state
– killer reservations
– receiver orientation not always helpful
 better support for mobility
– pre-reserve
– tear down old reservations
 layered model (Braden/Lindell, CASP)
– signaling base layer, possibly on reliable transport (CASP)
– applications/clients, e.g., for resources, firewall, active networks
 proposals:
– trim RSVP
– CASP (Cross-Application Signaling Protocol) Columbia/Siemens
7 May 2017
Header compression
 Wireless access networks =
–
–
–
–
high latency: 100-200ms
bit errors: 10-3, sometimes 10-2
non-trivial residual BER
low bandwidth
 IP  high overhead compared with
specialized circuit-switched applications:
– speech frame of 15-20 octets
– IPv4+UDP+RTP = 40 bytes of header, 60 with
IPv6
– SIP session setup ~ 1000 bytes
7 May 2017
Header compression
 3GPP architecture
3GPP Architecture for all IP networks
7 May 2017
Header compression
 Pure use of dictionary-based compression (LZ, gzip)
not sufficient
 Similar to video/audio coding  remove "spatial" and
"temporal" redundancy
 Usually, within some kind of "session"
 Access network (one IP hop) only
 Layering violation: view IP, UDP, RTP as whole
 see also A Unified Header Compression Framework
for Low-Bandwidth Links,
Lilley/Yang/Balakrishnan/Seshan, Mobicom 2000
7 May 2017
Compressed RTP (CRTP)
 VJ header compression for TCP  uses TCP-level
retransmissions to updated decompressor
 RFC 2508: First attempt at RTP header compression
– 2 octets without UDP checksum, 4 with
– explicit signaling messages (CONTEXT_STATE)
– out-of-sync during round trip time  packet loss due to
wrong/unknown headers
 Improvement: TWICE
– if packet loss  decompressor state out of sync
– use counter in CRTP to guess based on last known packet +
verify using UDP checksum
– only works with UDP checksum  at least 4 octets
7 May 2017
Robust header compression
(ROHC)
 Avoid use of UDP checksums
– most speech codecs tolerate bit errors
– not very strong 
• payload errors cause spurious header prediction failures
• may accept wrong header
 Loss before compression point may make
compressed RTP header behavior less regular
 100 ms of loss exceeds loss compensation ability
 ROHC: primarily for RTP streams
– header field = f(RTP seq. no)
– communicate RTP seq. no reliably
– if prediction incorrect, send additional information
7 May 2017
ROHC
 Channel assumptions:
– does not reorder (but may before
compressor)
– does not duplicate packets
 Negotiated via PPP
 ROHC profiles: uncompressed, main
(RTP), UDP only, ESP only
Initialization
and Refresh
7 May 2017
First Order
Second Order
ROHC modes
 Unidirectional (U)
– compressor  decompressor only
– periodic timeouts only
– starting state for all modes
 Bidirectional Optimistic (O)
– feedback channel for error recovery requests
– optional acknowledgements of significant context
updates
 Bidirectional Reliable (R)
– more intensive usage of feedback channel
– feedback for all context updates
7 May 2017
ROHC encoding methods
 Least significant bits (LSB)
– header fields with small changes
– k least significant bits
– interpretation interval
– f(vref,k) = [vref – p, vref + (2k –1) – p]
– p picked depending on bias of header field
 window-based LSB (W-LSB)
– compressor maintains candidates for
decompressor reference value
7 May 2017
ROHC encoding methods,
cont'd
 Scaled RTP timestamp encoding
– RTP increases by multiple of TS_STRIDE
– e.g., 20 ms frames  TS_STRIDE=160
– downscale by TS_STRIDE, then W-LSB
 Timer-based compression of RTP timestamp
– local clock can provide estimate of TS
– if jitter is bounded
– works well after talkspurts
 Offset IP-ID encoding
– compress (IP-ID – RTP SN)
 Self-describing variable length encoding
– prefix coding: 0 + 1o, 10 + 2o, 110 + 3o, 1110 + 4o
7 May 2017
ROHC
duplicate,
reorder, lose
packets
ACK
NACK
• typically, multiple streams for each channel
• identified by channel identifier (CID)
• protected by 3-8 bit CRC
7 May 2017
Header classification
inferred
can be deduced from
other values (e.g.,
length of frame)
not transmitted
static
constant through
lifetime of packet
stream
communicate once
static-def
values define packet
stream
like static
static-known
well-known values
not transmitted
changing
randomly or within
range
compress by 1st/2nd
order "differentiation"
7 May 2017
Example: IPv6
Field
Size
(bits)
type
Version
4
static
Traffic Class
8
changing
Flow Label
20
static-def
Payload Length
16
Next Header
8
Hop Limit
8
Src/Dest address
2x128
inferred
static
changing
static-def
inferred
static
7 May 2017
2
1.5
static-def
34.5
changing
2
Example: RTP
Field
Size (bits) type
Version
2
Padding
1
Extension
1
CSRC Counter, Marker, PT
12
Sequence Number
16
Timestamp
32
SSRC
32
CSRC
0(-480)
inferred
static-def
static-known
7 May 2017
changing
static-known
static
static
changing
changing
changing
static-def
changing
2 bits
4
2 bits
7.5 (-67.5)
Behavior of changing fields
static
additional assumptions for multimedia
semi-static
occasionally changes, then reverts
rarely changing (RC)
change, then stay the same
alternating
small number of values
irregular
no pattern
7 May 2017
Classification of changing fields
Field
Value/Delta
Class
Knowledge
IP TOS/Traffic Class
value
RC
unknown
IP TTL / Hop Limit
value
alternating
limited
UDP checksum
value
irregular
unknown
RTP CSRC, no mix
value
static
known
RTP CSRC, mix
value
RC
limited
RTP marker
value
semi-static
known
RTP PT
value
RC
unknown
RTP sequence number
delta
static
known
RTP timestamp
delta
RC
limited
7 May 2017
ROHC CRC
 Qiao: add one-bit correction CRC
 helps with BER of 4-5%
Full
header
Decompre
ssed
header
Compressed
header
Validate
CRC
CRC
CRC
Qiao
7 May 2017
Signaling compression
(SigComp)
 Textual signaling protocols like SIP, RTSP and
maybe HTTP
–
–
–
–
long signaling messages ( kB)
signaling delays  call setup delays
less of an issue: total overhead
long packets  headers not a major issue
 unlike ROHC, assume reliable transport
SigComp
ROHC
7 May 2017
SIP
proxy
Signaling compression
application message
& compartment id
compressor
dispatcher
compressor
1
SigComp
message
compartment
identifier
decompressed
message
decompressor
dispatcher
state 1
state
handler
compressor
2
SigComp
message
state 2
SigComp
layer
transport layer (TCP, UDP, SCTP)
7 May 2017
SigComp
 Messages marked with special invalid UTF-8
bit sequence (11111xxx)
 State saved across messages in compartment
– memory size is limited (> 2 KB)
– CPU expenditure is limited, measured in cycles per
bit
 Universal Decompressor Virtual Machine
(UDVM):
– compressor can choose any algorithm to compress
– upload byte code as state
7 May 2017
SigComp UDVM bytecode
 virtual machine with registers and stack
 single byte opcode + literal, reference, multitype and
address
request compressed data
provide compressed data
output decompressed data
decompressor
dispatcher
indicate end of message
UDVM
provide compartment identifier
request state information
provide state information
make state creation request
forward feedback information
7 May 2017
state
handler
SigComp virtual machine
 arithmetic: and, or, not, left/right shift,
integer add/subtract/multiply/divide,
remainder on 16-bit words
 sort 16-bit words ascending/descending
 SHA-1, CRC
 load, multiload, copy, memset, push, pop
 jump, call, return, switch
 input, output
 state create and free
7 May 2017
Example: SIP compression
 SIP compression most likely will use a static
dictionary
– e.g., "sip:", "INVITE ", "[CRLF]Via: SIP/2.0/UDP "
 referenced as state
 works best with default-formatted messages (e.g.,
single space between : and header field)
 permanently defined
 used with a variety of algorithms, such as DEFLATE,
LZ78, …
 Capability indicated using NAPTR records and
REGISTER parameter
7 May 2017
;; order pref flags
service regexp replacement
IN NAPTR 100 100 "s" "SIP+D2T" "" _sip._tcp.school.edu
IN NAPTR 100 100 "s" "SIP+D2U" "" _sip._udp.example.com
IN NAPTR 100 100 "s" "SIP+D2CU" "" comp-udp.example.com
RTP unequal error protection
 Provide generic protection of RTP headers
and payload against packet loss
– may also handle uncorrected bit errors
 RFC 2733: XOR across packets  FEC packet
 ULP (uneven level protection): higher
protection for bits at beginning of packet
–
–
–
–
–
higher protection = smaller group sizes
common for most codecs: closer to sync marker
H.263: video macroblock header, motion vectors
modern audio codecs
stretching of existing audio codecs
7 May 2017
RTP unequal error protection
RTP seq. number base
E PT recovery
length recovery
bit mask (packets after SN base)
RTP timestamp recovery





separate FEC packets or piggy-backed
multiple FEC in one packet
ULP header adds protection length and mask
recovery bytes are XOR(packet headers)
negotiated via SDP
7 May 2017
Unequal erasure protection
(UXP)
 Alternative to ULP, with different properties
 uses interleaving + Reed-Solomon codes
(GF(28)) to recover from packet loss (erasure)
 allows unequal protection of different parts of
payload
 allows arbitrary packet size  optimize for
channel
 interleaving adds delay
 ULP only incurs delay after packet loss (but
this may introduce gaps)
7 May 2017
UDPLite
 Proposal by Larzon&Degermark
 partial checksum coverage
– at least UDP header bytes
source port
destination port
checksum coverage
UDP checksum
data bytes
7 May 2017
Fast handoff – hand-off
latency
 Allow only a few lost packets  < 100 ms hand-off
delay
 detect new network from AP MAC address
– maybe use other packets listened to?
– scan different frequencies
• may need to scan both 2.4 and 5 GHz regions (802.11a, b, g)
– passive scanning: wait for AP beacon
• 802.11 beacon interval = 100 kµs ~ 100 ms
– active scanning: Probe Request Frame + Probe
Response
 associate with new network
– 802.11i authentication
– IETF PANA WG – L2-independent access control
7 May 2017
Handoff latency
 duplicate address detection (DAD)
– DHCP
• DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK 
multiple RTT, plus possible retransmissions
– IPv6 stateless autoconfiguration (RFC 2461, 2462)
• delay first Neighbor Solicitation in
[0,MAX_RTR_SOLICITATION_DELAY], where
MAX_RTR_SOLICITATION_DELAY = 1s
• wait for RetransTimer (1s) for answer
 AAA (authentication, authorization, accounting)
– usually, RADIUS or (future) DIAMETER
– server may be far away
7 May 2017
MIPv6 delays
Internet
Internet
HA
2
CH
BU=
HA, CoA
BU=
HA, CoA
2
1
3
1
Site1
Site1
CoA
7 May 2017
Castelluccia/Bellier
Micro-mobility
 Separate local (intra-domain, frequent) movement
from inter-domain movement (rare)
–  3 mobility protocol layers: L2 (e.g., 802.11, 3G RAN),
micro, macro
– also offer paging (usefulness with chatty UEs?)
– assumption may not be correct
 Examples:
–
–
–
–
–
–
hierarchical foreign agents (Nokia, 1996)
Cellular IP (Columbia/Ericsson, 1998)
Hierarchical IPv6 (INRIA, 1998)
HAWAII (Lucent, 1999)
THEMA (Lucent/Nokia, 1999)
TeleMIP (Telcordia, IBM, 2001)
7 May 2017
ISP1
ISP2
100'
Micro-mobility design goals
 Scalability
–
process updates locally
 Limit disruption
–
forward packets if necessary
 Efficiency
–
avoid tunneling where possible
 Quality of Service (QoS) support
–
local restoration of reservations
 Reliability
–
leverage fault detection mechanisms in routing protocols
 Transparency
–
minimal impact at the mobile host
7 May 2017
Ramjee
Micro-mobility
 Methods based on re-addressing
–
–
–
–
–
"keep routes, change address"
typically, tunnels within domain
hierarchical FAs
MIP with CoA to world at large
e.g.,
• regional registration, region-aware foreign agents, Dynamics,
hierarchical MIPv6, …
 Routing-based
–
–
–
–
"keep address, change routes"
no tunnels within domain
host-based (mobile-specific) routes
e.g.,
• Cellular IP, HAWAII
7 May 2017
Hartenstein et al.
Cellular IP
7 May 2017
Cellular IP
 base station routes
IP routes  cellular
IP routing
 gateway support
MIP macro mobility
– provides CoA
 inside micro mobility
domain, packets
identified by H@
– no tunneling, no
address conversion
 MH data packets
establish location and
routing "soft state"
 no explicit signaling
– empty IP packets
– discarded at border
 symmetric paths
 uplink establishes
shortest path to MH
 per-host routes, hop-byhop
Gomez/Campbell
7 May 2017
Cellular IP: Hard handoff
home agent
E
C
R
Internet w/ Mobile IP
R
G
R
foreign agent
D
A
B
F
host
Gomez/Campbell
7 May 2017
Cellular IP: downlink HO loss
7 May 2017
HAWAII: Enhanced Mobile IP
Internet
Domain
Router
R
R
Domain
Router
R
R
R
R
R
R
R
R
R
R
MD
Local mobility
Mobile IP
Local mobility
Distributed control: Reliability and scalability
– host-based routing entries in routers on path to mobile
 Localized mobility management: Fast handoffs
– updates only reach routers affected by movement
 Minimized or Eliminated Tunneling: Efficient routing
– dynamic, public address assignment to mobile devices

7 May 2017
Ramjee
Power-up
Domain
Root
Router 2
1
2 R3 4
Internet
1.1.1.100-> port
3,
239.0.0.1
Domain
Root
Router 1
1
2 R
3 4
3
4
5
1 R 4
2 3
1.1.1.100->port 4,
1
239.0.0.1 2 R 5
3 4
1
2 R 5
3 4
2
BS1
BS2
BS3
1
MY IP: 1.1.1.100
BS IP:1.1.1.5
BS4
1.1.1.100->wireless,
5
239.0.0.1
Mobile IP
HAWAII
7 May 2017
Ramjee
Soft-State
 Host-based routing entries maintained
as soft-state
 Base-stations and mobile hosts
periodically refresh the soft-state
 HAWAII leverages routing protocol
failure detection and recovery
mechanisms to recover from failures
 Recovery from link/router failures
7 May 2017
Ramjee
Failure Recovery
Domain
Root
Router 2
1
2 R3 4
Internet
Domain
Root
Router 1
1
1.1.1.100-> port
2 R
4,
3 4
239.0.0.1
3
5
1 R 4
2 3
BS1
2
1
R 5
3 4
2
BS2
BS3
1
MY IP: 1.1.1.100
BS IP:1.1.1.5
7 May 2017
1.1.1.100->port 3,
239.0.0.1
1
2 R 5
3 4
BS4
1.1.1.100->wireless,
239.0.0.1
Mobile IP
HAWAII
Ramjee
Path Setup Schemes
 Host-based routing within the domain
 Path setup schemes selectively update
local routers as users move
 Path setup schemes customized based
on user, application, or wireless network
characteristics
 Micro-mobility handled locally with
limited disruption to user traffic
7 May 2017
Ramjee
Micro-Mobility
Domain
Root
Router 2
1
2 R3 4
5
1 R 4
2 3
Domain
Root
Router 1
1
2 R
3 4
1.1.1.100-> port 3,
239.0.0.1
Internet
1.1.1.100->port 3 (4),
1
239.0.0.1
2 R 5
3 4
4
2
3
BS1
BS2
1.1.1.100->wireless,
1 5
239.0.0.1
MY IP: 1.1.1.100
BS IP:1.1.1.2
BS3
1
2 R 5
3 4
BS4
1.1.1.100->port 1(wireless),
239.0.0.1
Mobile IP
HAWAII
7 May 2017
Ramjee
Macro-Mobility
Domain
Root
Router 2
1
2 R3 4
Domain
Root
Router 1
Mobile IP Home Agent:
1
1.1.1.100->
2 R
4
3
1.1.2.200
Internet
1.1.2.200-> port 3,
239.0.0.1
3
5
4
5
1 R 4
2 3
1.1.2.200->port 2, 6
239.0.0.1
1
2 R 5
3 4
1
2 R 5
3 4
2
BS1
1
BS2
7 1.1.2.200->wireless,
239.0.0.2
MY IP: 1.1.1.100
BS IP:1.1.2.1
COA IP:1.1.2.200
7 May 2017
BS3
BS4
Mobile IP
HAWAII
Ramjee
Simulation
Topology
7 May 2017
Ramjee
Performance:
Audio and Video
7 May 2017
Ramjee
TORA
 O'Neill/Corson/Tsirtsis
 "make before break"
 hierarchical
(0,0,0,4,i)
core
CR
(0,0,0,4,i)
CR
(0,0,0,5,i)
CR
CR(0,0,0,6,i)
(-2,0,0,4,i)
interior
IR(0,0,0,3,i)
edge
IR(0,0,0,3,i)
ER(0,0,0,4,i) ER (0,0,0,2,i)
(-1,0,0,4,i)
access
AR(0,0,0,5,i)
MH
IR(0,0,0,5,i) IR(0,0,0,6,i)
(-1,0,0,3,i)
AR(0,0,0,1,i)
(-1,0,0,5,i)
(-2,0,0,5,i)
(-2,0,0,3,i)
ER (0,0,0,4,i)
ER (0,0,0,7,i)
AR(0,0,0,5,i)
AR(0,0,0,8,i)
(-2,0,0,6,i)
(-2,0,0,2,i)
(-2,0,0,7,i)
(-2,0,0,1,i)
MH
(-2,0,0,0,i)
7 May 2017
Hierarchical Mobility Agents
GMA
RMA
Home Agent
LMA




Localize signaling to visited domain
Regional Registration/Regional Binding Update
uses IP tunnels (encapsulation)
only, only one level of hierarchy
7 May 2017
Perkins
Example: hierarchical FA
(Dynamics, HUT)
CN
HA
Location update latencies
for some transitions
OLD
FA
FA11
FA13
FA31
HFA
FA11
FA1
FA13
FA3
FA13
FA31
FA29
FA12
FA2
FA14
NEW Average
FA
in ms
FA12 19,1
FA14 30,4
FA32 41,4
FA15
FA32
Forsberg et al
7 May 2017
Hierarchical FA with soft handoff
Data stream:
100kB/s, 1kB packets
(100 packets/s)
CN
HA
HFA
FA11
FA13
FA3
FA31
FA12
FA29
FA14
OLD
FA
NEW
FA
Lost packets/
update
FA11
FA31
FA29
FA31
FA12
FA15
FA32
FA13
FA31
FA29
FA32
FA13
FA15
FA31
FA11
FA12
0.00
0.00
0.00
0.00
0.00
0.03
0.07
0.10
FA15
FA32
HUT Dynamics
802.11
7 May 2017
Data stream
CN --> MN
OLD
FA
NEW
FA
Lost packets/
update
FA11
FA31
FA29
FA31
FA12
FA15
FA32
FA13
FA31
FA29
FA32
FA13
FA15
FA31
FA11
FA12
0.27
0.27
0.00
0.15
0.14
0.00
0.00
0.00
Data stream
MN --> CN
INRIA HMIPv6
Internet
BR
Site1
7 May 2017
MN
MS
 inter-site (global,
macro) vs. intra-site
(local, micro)
 CH only aware of intersite mobility
 MIPv6 used to manage
macro and micro
mobility
 define MN as LAN
connected to border
router, with >= 1 MS
 use site-local IPv6
addresses?
Castelluccia/Bellier
INRIA HMIPv6
 MH gets 2 CoA:
Internet
(H@,VCoA)
(VCoA,PCoA)
– VCoA in the MN  stays
constant within site
– PCoA (private CoA) 
changes with each
micromove
 MH registers
(H@,PCoA)
PCoA
7 May 2017
VCoA
– (H@,VCoA)  external
CH
– (H@,PCoA)  local CHs
– (VCoA, PCoA)  MS
 MH obtains MS address
and MN prefix via router
advertisements
INRIA HMIPv6 – packet
delivery
 External CH sends to
VCoA
Internet
– MS in MN intercepts
and routes to MH
MN
MS
Site1
7 May 2017
 Local CH sends to
PCoA
INRIA HMIPv6 – micro
mobility registration
Internet
(H@,PCoA1)
(HA,PCoA)
 MH moves and gets
new PCoA (PCoA1)
 sends BU (VCoA,
(VCoA,PCoA) PCoA1) to its MS
 sends BU (H@,
MS
PCoA1) to local CHs
PCoA1
7 May 2017
Other approaches to latency
reduction
 IP-based soft handoff
 buffering of in-flight data in old FA
– forward to new CoA or new BS
 multicast to multiple base stations
– unicast  multicast  unicast
– often, down some hierarchy
– multicast address assignment?
3
7 May 2017
1
2
Domain1
 UMTS / 802.11 "vertical" hand-off
– UMTS as "background radiation"
MA
Domain2
4
Hartenstein et al.
Comparison of CIP, HAWAII,
HMIP
Cellular IP
HAWAII
HMIP
OSI layer
L3
L3
"L3.5"
Nodes
all CIP nodes
all routers
FAs
Mobile host ID
home address
care-of-address
home address
Intermediate nodes
L2 switches
L2 switches
L3 routers
Means of update
data packet
signaling msg.
signaling msg.
Paging
implicit
explicit
explicit
Tunneling
no
no
yes
L2 triggered hand-off
optional
optional
no
MIP messaging
no
yes
yes
Campbell/Gomez-Castellanos
7 May 2017
Network-assisted hand-off
 Network makes hand-off decision, rather than UE
 network sets up resources (QoS) to new FA/BS
 simultaneous bindings kept and destroyed by
network
 allows seamless handoff
 IP nodes may need to report PHY measurements (like
GSM)
 e.g., Hartenstein et al., Calhoun/Kempf (FA-assisted
hand-off)
 may need to be able to predict next access point
7 May 2017
Cost of networking
Modality
mode speed
OC-3
P
155 Mb/s
$0.0013
Australian DSL
P
512/128
kb/s
$0.018
GSM voice
C
8 kb/s
$0.66-$1.70
HSCSD
C
20 kb/s
$2.06
GPRS
P
25 kb/s
$4-$10
Iridium
C
10 kb/s
$20
SMS
P
?
$62.50
P
8 kb/s
$133
videoconferencing or 1/3 MP3)
(512/128 kb/s)
(160 chars/message)
Motient
7 May 2017
(BlackBerry)
$/MB (= 1 minute of 64 kb/s
Spectrum cost for 3G
Location
what
cost
UK
3G
$590/person
Germany
3G
$558/person
Italy
3G
$200/person
New York
Verizon
(20MHz)
$220/customer
Generally, license limited to 10-15 years
7 May 2017
Multimodal networking
 = use multiple types of networks, with
transparent movement of information
 technical integration (IP)  access/business
integration (roaming)
 variables: ubiquity, access speed, cost/bit, …
 2G/3G: rely on value of ubiquity immediacy
– but: demise of Iridium and other satellite efforts
 similar to early wired Internet or some
international locations
– e.g., Australia
7 May 2017
Multimodal networking
 expand reach by leveraging mobility
 locality of data references
– mobile Internet not for general research
– Zipf distribution for multimedia content
• short movies, MP3s, news, …
– newspapers
– local information (maps, schedules, traffic
radio, weather, tourist information)
7 May 2017
Multimedia data access
modalities
bandwidth
(peak)
delay
high
low
high
7DS
802.11
hotspots
low
satellite
SMS?
voice (2G,
2.5G)
7 May 2017
A family of access points
2G/3G
WLAN
hotspot + cache
7 May 2017
7DS
Infostation
access sharing
7DS options
 Many degrees of cooperation
 server to client
– only server shares data
– no cooperation among clients
– fixed and mobile information servers
 peer-to-peer
– data sharing and query forwarding among
peers
7 May 2017
7DS options
Query Forwarding
FW query
query
Host A
Host B
Host C
time
Querying
active
(periodic)
passive
Power conservation
communication enabled
on
off
7 May 2017
time
Dataholders (%) after 25 min
high transmission power
Dataholders (%)
100
P2P
90
80
P2P data sharing
(power cons.)
Mobile Info Server
70
P2P data sharing
60
50
P2P data sharing & FW
(power cons.)
Fixed Info Server
40
Fixed Info Server
30
20
10
Mobile Info Server
0
0
5
10
15
20
25
2
Density of hosts (#hosts/km )
7 May 2017
Message relaying with 7DS
WAN
messages
WLAN
Host A
Gateway
WLAN
Message
relaying
Host A
7 May 2017
Host B
Conclusion and outlook
 First packet-based wireless multimedia networks
going into production
 encumbered by legacy technology and business
model ("minutes")
 what is 4G?
 store-and-forward beats interactive
– SMS, email vs. phone calls
 cost and complexity remain the major challenges
– interworking across generations, from 1876
 role of multimedia in ad-hoc networks?
– ad hoc access (small hop count) + backbone
7 May 2017
Credits
 Figures and results
(with permission) from
–
–
–
–
–
–
–
–
–
–
–
–
Emmanuel Coelho Alves
Andrew Campbell
Ashutosh Dutta
Mustafa Ergen
Javier Gomez
Wolfgang Granzow
Teemu Jalava
Wenyu Jiang
Andreas Koepsel
Maria Papadopouli
Charles Perkins
Zizhi Qiao
7 May 2017
–
–
–
–
–
Ramachandran Ramjee
Henning Sanneck
Adam Wolisz
Moshe Zukerman
Kanter, Maguire,
Escudero-Pascual
– and others