Wireless ip multimedia
This presentation is the property of its rightful owner.
Sponsored Links
1 / 149

Wireless IP Multimedia PowerPoint PPT Presentation


  • 56 Views
  • Uploaded on
  • Presentation posted in: General

Wireless IP Multimedia. Henning Schulzrinne Columbia University MOBICOM Tutorial, September 2002. Types of wireless multimedia applications streaming interactive object delivery Properties of multimedia content loss resiliency delay reordering 3G and WLAN MM-related channel properties

Download Presentation

Wireless IP Multimedia

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Wireless ip multimedia

Wireless IP Multimedia

Henning Schulzrinne

Columbia University

MOBICOM Tutorial, September 2002


Overview

Types of wireless multimedia applications

streaming

interactive

object delivery

Properties of multimedia content

loss resiliency

delay

reordering

3G and WLAN MM-related channel properties

effective bandwidth

packet loss

delay

Header and signaling compression

cRTP

ROHC

signaling compression

Packet FEC

UMTS multimedia subsystem (IMS)

QoS

Session setup

Fast handoff mechanisms

Multimodal networking

Overview


Types of wireless multimedia applications

Types of wireless multimedia applications

  • Interactive

    • VoIP

    • multimedia conferences

    • multiplayer games

  • Streaming

    • video/audio on demand

    • broadcast TV/radio

    • may be cached at various places, including end system

  • Object retrieval

    • peer-to-peer

    • user may be waiting for result

  • Messaging

    • store-and-forward (e.g., MMS)

    • can be batched


Ietf multimedia protocols

IETF (multimedia) protocols

media encap

(H.261. MPEG)

Media Transport

Signaling

SAP

SDP

MGCP

DHCPP

SIP

H.323

RTSP

RSVP

RTCP

RTP

DNS

Application

LDAP

TCP

UDP

CIP

MIPv6

IDMP

Network

MIP

ICMP

IGMP

MIP-LR

IPv4, IPv6, IP Multicast

Kernel

PPP

AAL3/4

AAL5

PPP

Physical

CDMA 1XRTT

/GPRS

SONET

ATM

802.11b

Ethernet

Heterogeneous

Access


Common wired wireless audio codecs

Common wired & wireless audio codecs


Audio codecs cont d

Audio codecs, cont'd.


Audio codecs

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 non-zero 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


Audio codecs1

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

18

20

22

24

16

G.723.1

G.729

G.729A

AMR-NB

AMR-WB

www.voiceage.com


Audio codecs silence

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)


Audio codecs silence1

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


Video codecs

Video codecs

JPEG

common code words 

shorter symbols

Huffman, arithmetic coding

e.g., DCT:

spatial  frequency

Transform,

Quantization, Zig-

Zag Scan & Run-

Length Encoding

Motion

Estimation

&

Compensation

Symbol

Encoder

Frames of

Digital Video

Bit Stream

predict current

frame from previous

Quantization changes representation

size for each symbol

adjust rate/quality trade-off

Run-length encoding:

long runs of zeros  run-length symbol

courtesy

M. Khansari

MPEG, H.26x


History of video codecs

History of video codecs

H.261

H.263++

H.263

H.263+

H.263L

ITU-T

MPEG 1

MPEG 4

ISO

MPEG 2

MPEG 7

1990

1992

1994

1996

1998

2000

2002

courtesy

M. Khansari


H 263l example

H.263L example

64 kb/s, 15 fps

courtesy of Siemens CT


Delay requirements

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]:

      • web browser response

      • VCR control for streaming media

      • ringback delay for call setup

      • can often be bridged by application design


802 11 architecture

802.11 architecture

ESS

Existing Wired LAN

AP

AP

STA

STA

STA

STA

BSS

BSS

Infrastructure Network

STA

STA

Ad Hoc Network

Ad Hoc Network

BSS

BSS

STA

STA

Mustafa Ergen


802 11b hand off

802.11b hand-off

Kanter, Maguire, Escudero-Pascual, 2001


802 11 delay

802.11 delay

channel

idle

is busy

Data

ACK

idle slots

slots

time

DIFS

SIFS

DIFS

(DCF interframe space)

(short IFS)

idle

idle

RTS CTS Data ACK

slots

slots

time

DIFS

SIFS

SIFS

SIFS

DIFS

M. Zukerman


802 11 delay1

802.11 delay

  • 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


802 11 delay2

802.11 delay


802 11 delay3

802.11 delay


802 11a delay for voip

802.11a delay for VoIP


802 11b channel access delay

802.11b channel access delay

Köpsel/Wolisz

  • 12 mobile data nodes, 4 mobile with on/off audio

  • 6 Mb/s load


802 11b voip delay

802.11b VoIP delay

  • Köpsel/Wolisz WoWMoM 2001: add priority and PCF enhancement to improve voice delay

DCF

Köpsel/Wolisz


802 11b pcf priority

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


802 11e enhanced dcf

802.11e = enhanced DCF

Mustafa Ergen


802 11e back off

802.11e back-off


Metric of voip quality

Metric of VoIP quality

  • Mean Opinion Score (MOS) [ITU P.830]

    • Obtained via human-based listening tests

    • Listening (MOS) vs. conversational (MOSc)


Fec and ip header overhead

FEC and IP header overhead

  • An (n,k) FEC code has (n-k)/k overhead

  • Typical IP/UDP/RTP header is 40 bytes


Predicting mos in voip

Predicting MOS in VoIP

  • The E-model: an alternative to human-based 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


Predicting mos in voip contd

Predicting MOS in VoIP, contd

  • Example mappings

    • From loss and delay to their impairment scores and to MOS


Predicting mos under fec

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


Quality evaluation of fec vs codec robustness

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


G 729 5 3 fec vs ilbc

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)


G 729 5 2 vs ilbc 3 2

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


G 729 7 2 vs ilbc 4 2

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


G 729 3 1 vs ilbc 4 2

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


Comparison with g 723 1

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


G 723 1 3 1 vs ilbc 3 2

G.723.1+(3,1) vs. iLBC+(3,2)

  • iLBC is still better for low loss

  • G.723.1 wins for higher loss


G 723 1 4 1 vs ilbc 4 2

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”


The best of both worlds

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)


Max bandwidth 21 28 kb s

Max Bandwidth: 21-28 kb/s


Effect of max bandwidth on achievable quality

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


Umts and 3g wireless

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


Wireless ip multimedia

UMTS

  • 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


1g 3g air interface

cdma2000 1X (1.25 MHz)

cdma2000 3X (5 MHz)

1G-3G air interface

1G

2G

“2.5G”

3G/ IMT-2000 Capable

Existing Spectrum New Spectrum

Analog

AMPS

IS-95-A/

cdmaOne

IS-95-B/

cdmaOne

1XEV DO: HDR (1.25 MHz)

IS-136

TDMA

136 HS

EDGE

TACS

GSM GPRS

EDGE

GSM

WCDMA

HSCSD

Ramjee


The mysterious 4g

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


Umts 3gpp and 3ggp2

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


Wireless ip multimedia

UMTS

W. Granzow


3gpp network architecture

3GPP network architecture

AS

Jalava


3gpp network architecture gateways

3GPP network architecture - gateways

Legacy Mobile

Signaling Networks

Multimedia

IP Networks

Roaming Signaling Gateway (R-SGW)

Mm

Mh

Ms

HSS

CSCF

Gi

Cx

Mg

Mr

Gi

MRF

Media Gateway Control Function (MGCF)

Transport Switching Gateway (T-SGW)

SGSN

GGSN

Gi

Mc (= H.248)

PSTN/Legacy/External

Media Gateway (MGW)

Media Gateway (MGW)

Gi

Alves


3gpp networks call control

VHE / OSA

Application I/F

3GPP networks – call control

-View on CALL CONTROL -

Applications & Services

CAP

Call State Control Function (CSCF)

Home Subscriber Server (HSS)

(=HLR + +)

Cx

Mr

Multimedia Resource Function (MRF)

Gc

Gi

Gr

Gi

SGSN

GGSN

access

Gn

to other networks

Iu

Gf

EIR

Alves


Umts network architecture

RNC

RNC

MSC/GSN

RNCRadio Network controller

Node BBase Node

Radio network

System (RNS)

Node B

Node B

Node B

Node B

Node B

Node B

UMTS network architecture

MSCMobile Services Switching Center

GSNGPRS Support Node

Node B

W. Granzow


Aside some 3g umts terminology

Aside: some 3G/UMTS terminology

See RFC 3114 for brief introduction.


Utra transport channels categories

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 re-assignment scheduling

      • Downlink Shared Channel (DSCH)


Transmission format utra fdd

time

frequency

1 radio frame (10 ms), 15*2560 chips (3.84 Mcps)

Uplink

Downlink

Macrocell layers

Microcell

layer

5 MHz

5 MHz

5 MHz

Duplex distance, e.g. 190 MHz

5 MHz

Slot i

Slot 15

Slot 2

Slot 1

Transmission Format UTRA FDD


Umts 3g qos classes

UMTS/3G QoS classes


Qos class requirements

QoS class requirements

  • Excerpt from 3GPP TS 23.107:


Gprs delay

GPRS delay

Gurtov, PWC 2001


Umts transport

UMTS transport


Umts release 4 5 architecture

UMTS Release 4/5 Architecture

Kulkarni


Qos in umts

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


Qos signaling in umts

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


Session setup sip

[email protected]: 128.59.16.1

Session setup: SIP

INVITE

INVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP pc33.atlanta.com

;branch=z9

Max-Forwards: 70

To: Bob <sip:[email protected]>

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

REGISTER

BYE


Session setup sip1

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

    • sip:[email protected]

    • tel:+1-212-555-1234

Client 1

Client 2

INVITE

INVITE

100 Trying

180 Ringing

180 Ringing

200 OK

200 OK

ACK

ACK

Media streams

BYE

BYE

200 OK

200 OK

Jalava


Sip request routing

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 Record-Route

    • user agent copies into Route header

    • also used for service routing  preloaded routes


3ggp internet multimedia subsystem

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


Umts ip multimedia

UMTS IP multimedia


Ims session overview

IMS session overview

Jalava


3gpp internet multimedia subsystem

3GPP Internet Multimedia Subsystem

Call State Control Function (CSCF)

Home

Application

Server

Subscriber

Subscription

Server

Location Function

Interrogating-CSCF

Sh

  • Accesspoint to domain

  • Hides topology and configuration

SLF

HSS

AS

Diameter

Diameter

ISC

SIP

Cx

Cx

UE

Dx

Gm

Mw

Mw

UA

P-CSCF

I-CSCF

S-CSCF

(User Agent)

SIP

SIP

SIP

Visited

Domain

Home

Domain

Serving-CSCF

Proxy-CSCF

  • Session control services

  • Registration, AS usage, charging, etc

Jalava


Locating the p cscf

Locating the P-CSCF

2 mechanisms:


3gpp sip registration

3GPP SIP registration

sip:[email protected]

TS 23.228/5.1


3gpp ims call setup

3GPP IMS call setup


Ims call setup with qos

IMS call setup with QoS


Sip for mobility

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


Sip for terminal mobility

[email protected]: 128.59.16.1

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

registrar

INVITE

re-INVITE

IP2

REGISTER IP2


Sip mobility vs mobile ip

SIP mobility vs. mobile IP

  • Mobility at different layers:

    • permanent identifier

    • rendezvous point identified by that identifier

    • forwarding of messages


Sip hierarchical registration

SIP hierarchical registration

1

From: [email protected]

Contact: 193.1.1.1

2

From: [email protected]

Contact: [email protected]

CA

NY

San Francisco

registrar

proxy

4

From: [email protected]

Contact: 192.1.2.3

3

REGISTER

INVITE

Los Angeles


Sip personal mobility

SIP personal mobility


3gpp ietf sip differences

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


Nsis next steps in signaling

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


Header compression

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


Header compression1

3GPP architecture

Header compression

3GPP Architecture for all IP networks


Header compression2

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


Compressed rtp crtp

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


Robust header compression rohc

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


Wireless ip multimedia

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

First Order

Second Order


Header classification

Header classification


Example ipv6

Example: IPv6


Example rtp

Example: RTP


Behavior of changing fields

Behavior of changing fields


Classification of changing fields

Classification of changing fields


Rohc modes

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


Rohc encoding methods

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


Rohc encoding methods cont d

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


Wireless ip multimedia

ROHC

duplicate,

reorder, lose

packets

compressor

de-

compressor

ACK

NACK

  • typically, multiple streams for each channel

  • identified by channel identifier (CID)

  • protected by 3-8 bit CRC


Rohc crc

Full header

Decompressed header

Compressed header

Validate

CRC

CRC

CRC

ROHC CRC

  • Qiao: add one-bit correction CRC

  • helps with BER of 4-5%

Qiao


Signaling compression sigcomp

Signaling compression (SigComp)

  • Textual signaling protocols like SIP, RTSP and maybe HTTP

    • long signaling messages ( kB)

    • signaling delays  call setup delays (56 ms/1 kB @ 144 kb/s)

    • less of an issue: total overhead

    • long packets  header overhead not a major issue

  • unlike ROHC, assume reliable transport

SigComp

ROHC

SIP

proxy


Signaling compression

Signaling compression

compartment

identifier

application message

& compartment id

decompressed

message

compressor

dispatcher

decompressor

dispatcher

state

handler

compressor

1

state 1

de-

compressor

(UDVM)

SigComp

message

SigComp

message

compressor

2

state 2

SigComp

layer

transport layer (TCP, UDP, SCTP)


Sigcomp

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


Sigcomp udvm bytecode

SigComp UDVM bytecode

  • virtual machine with registers and stack

  • single byte opcode + literal, reference, multitype and address

request compressed data

UDVM

decompressor

dispatcher

provide compressed data

output decompressed data

indicate end of message

provide compartment identifier

request state information

state

handler

provide state information

make state creation request

forward feedback information


Sigcomp virtual machine

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


Example sip compression

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

;; 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

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


Rtp unequal error protection1

RTP unequal error protection

RTP seq. number base

length 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

E

PT recovery

bit mask (packets after SN base)

RTP timestamp recovery


Unequal erasure protection uxp

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)


Udplite

source port

destination port

checksum coverage

UDP checksum

data bytes

UDPLite

  • Proposal by Larzon&Degermark

  • partial checksum coverage

    • at least UDP header bytes


Fast handoff hand off latency

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


Handoff latency

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


Mipv6 delays

HA

2

2

3

MIPv6 delays

Internet

Internet

CH

BU=

HA, CoA

BU=

HA, CoA

1

1

Site1

Site1

CoA

Castelluccia/Bellier


Micro mobility

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)

ISP1

ISP2

100'


Micro mobility design goals

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

Ramjee


Micro mobility1

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

Hartenstein et al.


Cellular ip

Cellular IP


Cellular ip1

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-by-hop

Cellular IP

Gomez/Campbell


Cellular ip hard handoff

home agent

E

C

R

G

Internet w/ Mobile IP

R

D

R

A

foreign agent

F

B

host

Cellular IP: Hard handoff

Gomez/Campbell


Cellular ip downlink ho loss

Cellular IP: downlink HO loss


Hawaii enhanced mobile ip

Domain

Router

R

R

R

R

R

R

R

R

R

R

R

R

HAWAII: Enhanced Mobile IP

Internet

Domain

Router

MD

Local mobility

Local mobility

Mobile IP

  • Distributedcontrol: Reliability and scalability

    • host-based routing entries in routers on path to mobile

  • Localizedmobility management: Fast handoffs

    • updates only reach routers affected by movement

  • Minimized or Eliminated Tunneling: Efficient routing

    • dynamic, public address assignment to mobile devices

Ramjee


Wireless ip multimedia

Domain

Root

Router 2

Domain

Root

Router 1

Internet

1

1

2

R

R

4

2

4

3

3

1.1.1.100-> port 3,

239.0.0.1

3

4

1.1.1.100->port 4,

239.0.0.1

1

5

1

2

5

1

5

R

4

2

R

R

4

4

3

3

2

3

2

BS1

BS2

BS3

BS4

1.1.1.100->wireless,

239.0.0.1

1

5

MY IP: 1.1.1.100

BS IP:1.1.1.5

Mobile IP

HAWAII

Power-up

Ramjee


Design principle iii soft state

Design Principle III:Soft-state

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

Ramjee


Wireless ip multimedia

Internet

1

1

2

5

5

R

2

R

4

4

3

3

Mobile IP

HAWAII

Failure Recovery

Domain

Root

Router 2

Domain

Root

Router 1

1

1

1.1.1.100-> port 4,

239.0.0.1

2

R

R

4

2

4

3

3

3

1.1.1.100->port 3,

239.0.0.1

5

1

4

R

3

2

2

BS1

BS2

BS3

BS4

1.1.1.100->wireless,

239.0.0.1

1

MY IP: 1.1.1.100

BS IP:1.1.1.5

Ramjee


Wireless ip multimedia

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

Ramjee


Wireless ip multimedia

Domain

Root

Router 2

Domain

Root

Router 1

Internet

1

1

2

R

R

4

2

4

3

3

1.1.1.100-> port 3,

239.0.0.1

1.1.1.100->port 3 (4),

239.0.0.1

5

1

1

1

2

5

5

4

2

R

R

R

4

4

3

2

3

3

4

2

3

BS1

BS2

BS3

BS4

1.1.1.100->wireless,

239.0.0.1

1.1.1.100->port 1(wireless),

239.0.0.1

1

5

MY IP: 1.1.1.100

BS IP:1.1.1.2

Mobile IP

HAWAII

Micro-Mobility

Ramjee


Wireless ip multimedia

Internet

1

1

2

5

5

2

R

R

4

4

3

3

BS1

Mobile IP

HAWAII

Macro-Mobility

Domain

Root

Router 2

Domain

Root

Router 1

Mobile IP Home Agent:

1.1.1.100->

1.1.2.200

1

1

2

R

R

4

2

4

3

3

1.1.2.200-> port 3,

239.0.0.1

3

5

4

1.1.2.200->port 2,

239.0.0.1

6

5

1

4

R

3

2

2

BS2

BS3

BS4

1.1.2.200->wireless,

239.0.0.2

1

7

MY IP: 1.1.1.100

BS IP:1.1.2.1

COA IP:1.1.2.200

Ramjee


Wireless ip multimedia

Simulation Topology

Ramjee


Wireless ip multimedia

Performance: Audio and Video

Ramjee


Wireless ip multimedia

(0,0,0,4,i)

(0,0,0,4,i)

(0,0,0,5,i)

CR

CR

CR

CR

(0,0,0,6,i)

(-2,0,0,4,i)

IR

IR

IR

IR

(0,0,0,3,i)

(0,0,0,3,i)

(0,0,0,5,i)

(0,0,0,6,i)

(-1,0,0,3,i)

(-2,0,0,5,i)

(-2,0,0,3,i)

ER

ER

ER

ER

(0,0,0,2,i)

(0,0,0,4,i)

(0,0,0,7,i)

(0,0,0,4,i)

(-2,0,0,6,i)

(-2,0,0,2,i)

(-1,0,0,4,i)

AR

AR

AR

AR

(0,0,0,5,i)

(0,0,0,1,i)

(0,0,0,5,i)

(0,0,0,8,i)

(-1,0,0,5,i)

(-2,0,0,7,i)

(-2,0,0,1,i)

MH

MH

(-2,0,0,0,i)

TORA

  • O'Neill/Corson/Tsirtsis

  • "make before break"

  • hierarchical

core

interior

edge

access


Hierarchical mobility agents

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

Perkins


Example hierarchical fa dynamics hut

Example: hierarchical FA(Dynamics, HUT)

CN

HA

Location update latencies for some transitions

HFA

FA11

FA1

FA12

FA2

FA29

FA3

FA13

FA14

FA15

FA31

FA13

FA32

Forsberg et al


Hierarchical fa with soft hand off

Hierarchical FA with soft hand-off

Data stream:

100kB/s, 1kB packets (100 packets/s)

OLD

NEW

Lost packets/

FA

FA

update

FA11

FA31

0.00

FA31

FA29

0.00

FA29

FA32

0.00

CN

HA

OLD

NEW

Lost packets/

FA31

FA13

0.00

FA

FA

update

FA11

FA31

0.27

FA12

FA15

0.00

HFA

FA31

FA29

0.27

FA15

FA31

0.03

FA11

FA12

FA29

FA32

0.00

FA32

FA11

0.07

FA31

FA13

0.15

FA13

FA12

0.10

FA12

FA15

0.14

Data stream

CN --> MN

FA3

FA3

FA13

FA3

FA29

FA14

FA15

FA15

FA31

0.00

FA32

FA11

0.00

FA31

FA32

FA13

FA12

0.00

HUT Dynamics

802.11

Data stream

MN --> CN


Inria hmipv6

inter-site (global, macro) vs. intra-site (local, micro)

CH only aware of inter-site 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?

INRIA HMIPv6

Internet

MN

MS

BR

Site1

Castelluccia/Bellier


Inria hmipv61

MH gets 2 CoA:

VCoA in the MN  stays constant within site

PCoA (private CoA)  changes with each micromove

MH registers

(H@,VCoA)  external CH

(H@,PCoA)  local CHs

(VCoA, PCoA)  MS

MH obtains MS address and MN prefix via router advertisements

(H@,VCoA)

(VCoA,PCoA)

(H@,PCoA)

VCoA

PCoA

INRIA HMIPv6

Internet


Inria hmipv6 packet delivery

External CH sends to VCoA

MS in MN intercepts and routes to MH

Local CH sends to PCoA

INRIA HMIPv6 – packet delivery

Internet

MN

MS

Site1


Inria hmipv6 micro mobility registration

MH moves and gets new PCoA (PCoA1)

sends BU (VCoA, PCoA1) to its MS

sends BU (H@, PCoA1) to local CHs

(H@,PCoA1)

INRIA HMIPv6 – micro mobility registration

Internet

(VCoA,PCoA)

MS

(HA,PCoA)

PCoA1


Other approaches to latency reduction

MA

3

1

2

Domain1

Domain2

4

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?

  • UMTS / 802.11 "vertical" hand-off

    • UMTS as "background radiation"

Hartenstein et al.


Comparison of cip hawaii hmip

Comparison of CIP, HAWAII, HMIP

Campbell/Gomez-Castellanos


Network assisted hand off

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


Cost of networking

Cost of networking


Spectrum cost for 3g

Spectrum cost for 3G

Generally, license limited to 10-15 years


Multimodal networking

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


Multimodal networking1

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)


Multimedia data access modalities

Multimedia data access modalities

delay

bandwidth

(peak)


A family of access points

2G/3G

WLAN

hotspot + cache

Infostation

access sharing

7DS

A family of access points


7ds options

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


7ds options1

Power conservation

communication enabled

on

off

time

7DS options

Query Forwarding

FW

query

query

Host C

Host A

Host B

time

Querying

active (periodic)

passive


Dataholders after 25 min

Dataholders (%) after 25 min

high transmission power

P2P

Mobile Info Server

Fixed Info Server

2


Message relaying with 7ds

WLAN

messages

Host A

Message relaying with 7DS

WAN

Gateway

WLAN

Message

relaying

Host B

Host A


Conclusion and outlook

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


Credits

Figures and results (with permission) from

EmmanuelCoelho Alves

Andrew Campbell

Ashutosh Dutta

Mustafa Ergen

Javier Gomez

Wolfgang Granzow

Teemu Jalava

Wenyu Jiang

Andreas Koepsel

Maria Papadopouli

Charles Perkins

Zizhi Qiao

Ramachandran Ramjee

Henning Sanneck

Adam Wolisz

Moshe Zukerman

Kanter, Maguire, Escudero-Pascual

and others

Credits


Umts ip multimedia1

UMTS IP multimedia


  • Login