2. 22 June 2015 Wireless IP Multimedia Henning Schulzrinne Columbia University MOBICOM Tutorial, September 2002

3. 22 June 2015 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

4. 22 June 2015 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

5. 22 June 2015 IETF (multimedia) protocols Media Transport Application Kernel Physical Network H.323 SIP RTSP RSVPRTCP RTP TCPUDP IPv4, IPv6, IP Multicast PPPAAL3/4AAL5PPP SONETATM Ethernet CDMA 1XRTT /GPRS Signaling media encap (H.261. MPEG) ICMPIGMP SAP 802.11b DNS LDAP MIP MIP-LR CIP SDP MIPv6 MGCP IDMP DHCPP Heterogeneous Access

6. 22 June 2015 Common wired & wireless audio codecs codec namestandards org. sampling rate (Hz) frame sizebit rate (kb/s) G.711 (µ/A-law)ITU8,000any64 G.723.1ITU8,00020 ms5.3, 6.3 G.729 (CS-ACELP)ITU (1996)8,00010 ms8 AMR (adaptive multi-rate) ETSI 26.090 (1999) 8,00020 ms4.75 – 12.2 (8) 6.7: PDC-EFR 7.4: IS 641 12.2: GSM-EFR GSM-HRGSM 06.208,00020 ms5.6 GSM-FRGSM 06.108,00020 ms13 AMR-WB (wideband)ETSI16,00020 ms6.6 – 23.85 (9)

7. 22 June 2015 Audio codecs, cont'd. codec namestandards org. samplin g rate (Hz) frame size bit rate (kb/s) EVRC (RCELP)TIA/EIA (1996) 8,00020 ms8.55, 4, 0.8 G.726 (ADPCM)ITU8,000sample16, 24, 32, 40 G.728 (LD-CELP)ITU8,00020 ms16

8. 22 June 2015 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

9. 22 June 2015 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 468101214 16 18202224 G.723.1 G.729 G.729A AMR-NB AMR-WB original www.voiceage.com

10. 22 June 2015 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)

11. 22 June 2015 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

12. 22 June 2015 Video codecs Motion Estimation & Compensation Motion Estimation & Compensation Transform, Quantization, Zig- Zag Scan & Run- Length Encoding Transform, Quantization, Zig- Zag Scan & Run- Length Encoding Symbol Encoder Symbol Encoder Frames of Digital Video Bit Stream common code words  shorter symbols Huffman, arithmetic coding e.g., DCT: spatial  frequency Quantization changes representation size for each symbol  adjust rate/quality trade-off Run-length encoding: long runs of zeros  run-length symbol predict current frame from previous JPEG MPEG, H.26x courtesy M. Khansari

13. 22 June 2015 History of video codecs 1990199620021992199419982000 H.263L H.263++ H.263+ H.263 H.261 MPEG 7 MPEG 4 MPEG 2 MPEG 1 ISO ITU-T courtesy M. Khansari

14. 22 June 2015 H.263L example 64 kb/s, 15 fps

15. 22 June 2015 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

16. 22 June 2015 802.11 architecture STA AP ESS BSS Existing Wired LAN Infrastructure Network Ad Hoc Network Mustafa Ergen

17. 22 June 2015 802.11b hand-off Kanter, Maguire, Escudero-Pascual, 2001

18. 22 June 2015 802.11 delay Data ACK (short IFS) DIFS SIFS DIFS idle slots channel is busy idle slots time DIFS SIFS DIFS idle slots idle slots RTS CTS Data ACK time M. Zukerman IFS (µs)FHSSDSSSOFDM SIFS281013 PIFS783019 DIFS1285025 (DCF interframe space)

19. 22 June 2015 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.111, 2 Mb/sDSSS 802.11b11 Mb/sFHSS, DSSS 802.11a2, 11, 24, 54 Mb/sOFDM

20. 22 June 2015 802.11 delay

21. 22 June 2015 802.11 delay

22. 22 June 2015 802.11a delay for VoIP

23. 22 June 2015 802.11b channel access delay Köpsel/Wolisz 12 mobile data nodes, 4 mobile with on/off audio 6 Mb/s load

24. 22 June 2015 802.11b VoIP delay  Köpsel/Wolisz WoWMoM 2001: add priority and PCF enhancement to improve voice delay DCF Köpsel/Wolisz

25. 22 June 2015 802.11b – PCF+priority Köpsel/Wolisz  poll only stations with audio data  move audio flows from PCF to DCF and back after talkspurts IEEE 802.11 TGe working on enhancements for MAC (PCF and DCF) multiple priority queues

26. 22 June 2015 802.11e = enhanced DCF Mustafa Ergen HChybrid controller TCtraffic categories AIFSarbitration IFS TXOPtransmission opportunity

27. 22 June 2015 802.11e back-off

28. 22 June 2015 Metric of VoIP quality  Mean Opinion Score (MOS) [ITU P.830] –Obtained via human-based listening tests –Listening (MOS) vs. conversational (MOS c ) GradeQuality 5Excellent 4Good 3Fair 2Poor 1Bad

29. 22 June 2015 FEC and IP header overhead  An (n,k) FEC code has (n-k)/k overhead  Typical IP/UDP/RTP header is 40 bytes codecmedia pkt size (T=30ms) r media r IP iLBC (4,2) FEC 54 bytes14.4 kb/s25.1 kb/s 108 bytes28.8 kb/s39.5 kb/s G.729 (4,2) FEC 30 bytes8 kb/s18.7 kb/s 60 bytes16 kb/s26.7 kb/s G.723.1 (4,2) FEC 24 bytes6.4 kb/s17.1 kb/s 48 bytes12.8 kb/s23.5 kb/s

30. 22 June 2015 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 (I e ) and delay (I d )  A gross score R is computed and translated to MOS.  Loss-to-I e mapping is codec-dependent and calibrated

31. 22 June 2015 Predicting MOS in VoIP, contd  Example mappings –From loss and delay to their impairment scores and to MOS

32. 22 June 2015 Predicting MOS under FEC  Compute final loss probability p f after FEC [Frossard 2001] –Bursty loss reduces FEC performance –Increasing the packet interval T makes FEC more efficient under bursty loss [Jiang 2002]  Plug p f into the calibrated loss-to-I e mapping  FEC delay is n*T for an (n,k) code  Compute R value and translate to MOS

33. 22 June 2015 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

34. 22 June 2015 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)

35. 22 June 2015 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

36. 22 June 2015 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

37. 22 June 2015 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

38. 22 June 2015 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

39. 22 June 2015 G.723.1+(3,1) vs. iLBC+(3,2)  iLBC is still better for low loss  G.723.1 wins for higher loss

40. 22 June 2015 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”

41. 22 June 2015 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 MOS c )

42. 22 June 2015 Max Bandwidth: 21-28 kb/s

43. 22 June 2015 Effect of max bandwidth on achievable quality  14 to 21 kb/s: significant improvement in MOS c  From 21 to 28 kb/s: marginal change due to increasing delay impairment by FEC

44. 22 June 2015 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

45. 22 June 2015 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 macrocell2 km144 kb/s microcell1 km384 kb/s picocell60 m2 Mb/s

46. 22 June 2015 1G-3G air interface 3G/ IMT-2000 Capable Existing Spectrum New Spectrum IS-95-A/ cdmaOne IS-95-A/ cdmaOne IS-95-B/ cdmaOne IS-95-B/ cdmaOne IS-136 TDMA IS-136 TDMA 136 HS EDGE 136 HS EDGE GSM GSM GPRS EDGE WCDMA cdma2000 1X (1.25 MHz) cdma2000 3X (5 MHz) HSCSD 1XEV DO: HDR (1.25 MHz) 2G“2.5G”1G Analog AMPS Analog AMPS TACS Ramjee

47. 22 June 2015 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

48. 22 June 2015 UMTS W. Granzow

49. 22 June 2015 3GPP network architecture AS Jalava

50. 22 June 2015 3GPP network architecture - gateways Legacy Mobile Signaling Networks Roaming Signaling Gateway (R-SGW) MsMh HSS PSTN/Legacy/External Multimedia IP Networks Gi CSCF MRF Cx Mr Gi Mm Media Gateway (MGW) Media Gateway Control Function (MGCF) Transport Switching Gateway (T-SGW) Mc (= H.248) Gi Mg GGSN Media Gateway (MGW) SGSN Alves

51. 22 June 2015 3GPP networks – call control Gi Call State Control Function (CSCF) Multimedia Resource Function (MRF) Cx Mr Gi VHE / OSA Application I/F Gr Home Subscriber Server (HSS) (=HLR + +) Gc CAP SGSNGGSN access EIR Gn Gf Iu to other networks Applications & Services -View on CALL CONTROL - Alves

52. 22 June 2015 UMTS network architecture Node B Radio network System (RNS) MSC/GSN MSCMobile Services Switching Center GSNGPRS Support Node Node B RNC Node B RNC Node B RNCRadio Network controller Node BBase Node W. Granzow

53. 22 June 2015 Aside: some 3G/UMTS terminology CScircuit-switched GERANGSM/EDGE Radio Access Network GGSNGateway GPRS Support Node. A router between the GPRS network and an external network (i.e., the Internet). PDPPacket Data Protocol PDP contextA PDP connection between the UE and the GGSN. PSpacket-switched SGSNServing GPRS Support Node UTRANUniversal Terrestrial Radio Access Network See RFC 3114 for brief introduction.

54. 22 June 2015 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)

55. 22 June 2015 1 radio frame (10 ms), 15*2560 chips (3.84 Mcps) Slot iSlot 1Slot 2Slot 15 time frequency 5 MHz Macrocell layers Microcell layer Duplex distance, e.g. 190 MHz Uplink Downlink Transmission Format UTRA FDD

56. 22 June 2015 UMTS/3G QoS classes conversationalvoice, video conferencing low delay, strict ordering streamingvideo streamingmodest delay, strict ordering interactiveweb browsing, gamesmodest delay backgroundemail downloadno delay guarantees

57. 22 June 2015 QoS class requirements  Excerpt from 3GPP TS 23.107: Traffic classConversationalStreamingInteractiveBackground 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 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 - 6 10 -3, 10 -4, 10 -6 Transfer delay  100 ms  250 ms Guaranteed bit rate 2,048 kb/s Traffic handling priority 1,2,3 Allocation/retention priority 1,2,3

58. 22 June 2015 GPRS delay Gurtov, PWC 2001

59. 22 June 2015 UMTS transport

60. 22 June 2015 UMTS Release 4/5 Architecture Kulkarni

61. 22 June 2015 UMTS IP multimedia

62. 22 June 2015 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

63. 22 June 2015 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

64. 22 June 2015 UMTS – 3GPP and 3GGP2  Divided regionally/historically: –both from ITU IMT-2000 initiative –GSM  3GPP (ETSI) = WCDMA3GPP –US (CDMA)  3gpp2 (TIA) = CDMA2000  3GPP2: different PHY, but similar applications (not completely specified) 3GPP2 –cdma2000

65. 22 June 2015 Session setup: SIP a@foo.com: 128.59.16.1 INVITE REGISTER BYE INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com ;branch=z9 Max-Forwards: 70 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710@pc33.atlanta.com CSeq: 314159 INVITE Contact: Content-Type: application/sdp Content-Length: 142

66. 22 June 2015 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:alice@example.com –tel:+1-212-555-1234 Client 2Client 1 INVITE 100 Trying 180 Ringing 200 OK ACK Media streams BYE 200 OK Jalava

67. 22 June 2015 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:sales@example.com  sip:alice@204.198.76.66  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

68. 22 June 2015 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)  3 rd party call control

69. 22 June 2015 3GPP Internet Multimedia Subsystem UA P-CSCFI-CSCFS-CSCF Gm Mw SLF Dx Cx HSSAS Cx SIP Diameter Sh Visited Domain Home Domain ISC Home Subscriber Server Application Server Subscription Location Function Diameter Call State Control Function (CSCF) Proxy-CSCF Accesspoint to domain Hides topology and configuration Interrogating-CSCF Session control services Registration, AS usage, charging, etc Serving-CSCF (User Agent) Jalava UE

70. 22 June 2015 IMS session overview Jalava

71. 22 June 2015 Locating the P-CSCF 2 mechanisms:

72. 22 June 2015 3GPP SIP registration TS 23.228/5.1 sip:23415098765@15.234.IMSI.3gppnetwork.org

73. 22 June 2015 3GPP IMS call setup

74. 22 June 2015 IMS call setup with QoS

75. 22 June 2015 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

76. 22 June 2015 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 a@foo.com: 128.59.16.1 CH registrar re-INVITE IP 2 INVITE REGISTER IP 1 REGISTER IP 2

77. 22 June 2015 SIP mobility vs. mobile IP  Mobility at different layers: –permanent identifier –rendezvous point identified by that identifier –forwarding of messages mobile IPSIP permanent identifierIP addressSIP AOR temporary addresscare-of-address Contact header rendezvous pointhome agent (  permanent address) registrar (  host part of AOR) HA/FA discoveryICMPnot needed (name) binding updateUDP message REGISTER in visited networkforeign agent (FA)none/outbound proxy

78. 22 June 2015 SIP personal mobility

79. 22 June 2015 SIP hierarchical registration Contact: alice@CA From: alice@NY Contact: 193.1.1.1 From: alice@NY NY REGISTER INVITE Los Angeles San Francisco Contact: 192.1.2.3 From: alice@NY CA 1 3 2 4 registrar proxy

80. 22 June 2015 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

81. 22 June 2015 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

82. 22 June 2015 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

83. 22 June 2015 Header compression  3GPP architecture 3GPP Architecture for all IP networks

84. 22 June 2015 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

85. 22 June 2015 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

86. 22 June 2015 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

87. 22 June 2015 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 OrderSecond Order

88. 22 June 2015 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

89. 22 June 2015 ROHC encoding methods  Least significant bits (LSB) –header fields with small changes –k least significant bits –interpretation interval –f(v ref,k) = [v ref – p, v ref + (2 k –1) – p] –p picked depending on bias of header field  window-based LSB (W-LSB) –compressor maintains candidates for decompressor reference value

90. 22 June 2015 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

91. 22 June 2015 ROHC duplicate, reorder, lose packets ACK NACK compressor de- compressor typically, multiple streams for each channel identified by channel identifier (CID) protected by 3-8 bit CRC

92. 22 June 2015 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 valuesnot transmitted changing randomly or within range compress by 1 st /2 nd order "differentiation"

93. 22 June 2015 Example: IPv6 FieldSize (bits) type Version4static Traffic Class8changing Flow Label20static-def Payload Length16inferred Next Header8static Hop Limit8changing Src/Dest address2x128static-def inferred2 static1.5 static-def34.5 changing2

94. 22 June 2015 Example: RTP FieldSize (bits)type Version2static-known Padding1static Extension1static CSRC Counter, Marker, PT12changing Sequence Number16changing Timestamp32changing SSRC32static-def CSRC0(-480)changing inferred2 bits static-def4 static-known2 bits changing7.5 (-67.5)

95. 22 June 2015 Behavior of changing fields staticadditional assumptions for multimedia semi-staticoccasionally changes, then reverts rarely changing (RC)change, then stay the same alternatingsmall number of values irregularno pattern

96. 22 June 2015 Classification of changing fields FieldValue/DeltaClassKnowledge IP TOS/Traffic ClassvalueRCunknown IP TTL / Hop Limitvaluealternatinglimited UDP checksumvalueirregularunknown RTP CSRC, no mixvaluestaticknown RTP CSRC, mixvalueRClimited RTP markervaluesemi-staticknown RTP PTvalueRCunknown RTP sequence numberdeltastaticknown RTP timestampdeltaRClimited

97. 22 June 2015 ROHC CRC  Qiao: add one-bit correction CRC  helps with BER of 4-5% Full header CRC Compressed header CRC Decompre ssed header CRC Validate Qiao

98. 22 June 2015 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 SIP proxy SigComp ROHC

99. 22 June 2015 Signaling compression compressor 1 compressor 2 state handler state 1 state 2 de- compressor (UDVM) compressor dispatcher decompressor dispatcher transport layer (TCP, UDP, SCTP) SigComp message SigComp message application message & compartment id decompressed message SigComp layer compartment identifier

100. 22 June 2015 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

101. 22 June 2015 SigComp UDVM bytecode  virtual machine with registers and stack  single byte opcode + literal, reference, multitype and address UDVM decompressor dispatcher request compressed data provide compressed data output decompressed data indicate end of message provide compartment identifier state handler request state information provide state information make state creation request forward feedback information

102. 22 June 2015 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

103. 22 June 2015 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

104. 22 June 2015 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

105. 22 June 2015 RTP unequal error protection  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 RTP seq. number base RTP timestamp recovery bit mask (packets after SN base) length recovery PT recoveryE

106. 22 June 2015 Unequal erasure protection (UXP)  Alternative to ULP, with different properties  uses interleaving + Reed-Solomon codes (GF(2 8 )) 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)

107. 22 June 2015 UDPLite  Proposal by Larzon&Degermark  partial checksum coverage –at least UDP header bytes source portdestination port checksum coverageUDP checksum data bytes

108. 22 June 2015 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

109. 22 June 2015 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

110. 22 June 2015 MIPv6 delays Site1 Internet CH HA 23 CoA Site1 Internet 1 2 BU= HA, CoA BU= HA, CoA 1 Castelluccia/Bellier

111. 22 June 2015 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) ISP 1 ISP 2 100'

112. 22 June 2015 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

113. 22 June 2015 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.

114. 22 June 2015 Cellular IP

115. 22 June 2015 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- by-hop Gomez/Campbell

116. 22 June 2015 Cellular IP: Hard handoff Internet w/ Mobile IP foreign agent home agent C A B E D F G R R R host Gomez/Campbell

117. 22 June 2015 Cellular IP: downlink HO loss

118. 22 June 2015  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 Domain Router RR RRRR Domain Router RR RRRR Local mobility Mobile IP Internet MD HAWAII: Enhanced Mobile IP Ramjee

119. 22 June 2015 HAWAII Mobile IP Internet 1.1.1.100->port 4, 239.0.0.1 1.1.1.100-> port 3, 239.0.0.1 1.1.1.100->wireless, 239.0.0.1 R 2 3 1 R 1 2 3 4 5 MY IP: 1.1.1.100 BS IP:1.1.1.5 1 R 2 3 4 R 1 2 3 4 5 R 2 3 1 4 4 Domain Root Router 2 Domain Root Router 1 5 BS1 2 3 4 5 BS2BS3BS4 1 Power-up Ramjee

120. 22 June 2015 Design Principle III: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 Soft-State Ramjee

121. 22 June 2015 HAWAII Mobile IP Failure Recovery Internet 1.1.1.100->port 3, 239.0.0.1 1.1.1.100-> port 4, 239.0.0.1 1.1.1.100->wireless, 239.0.0.1 R 2 3 1 R 1 2 3 4 5 MY IP: 1.1.1.100 BS IP:1.1.1.5 1 R 2 3 4 R 1 2 3 4 5 R 2 3 1 4 4 Domain Root Router 2 Domain Root Router 1 5 BS1 2 3 BS2BS3BS4 1 Ramjee

122. 22 June 2015  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 Path Setup Schemes Ramjee

123. 22 June 2015 HAWAII Mobile IP Internet 1.1.1.100->port 3 (4), 239.0.0.1 1.1.1.100-> port 3, 239.0.0.1 R 2 3 1 R 1 2 3 4 5 MY IP: 1.1.1.100 BS IP:1.1.1.2 R 2 3 4 R 1 2 3 4 5 R 2 3 1 4 4 Domain Root Router 2 Domain Root Router 1 5 BS1 23 4 1.1.1.100->wireless, 239.0.0.1 15 BS2BS3BS4 1.1.1.100->port 1(wireless), 239.0.0.1 1 Micro-Mobility Ramjee

124. 22 June 2015 MY IP: 1.1.1.100 BS IP:1.1.2.1 COA IP:1.1.2.200 Internet 1.1.2.200->port 2, 239.0.0.1 1.1.2.200-> port 3, 239.0.0.1 1.1.2.200->wireless, 239.0.0.2 HAWAII Mobile IP R 2 3 1 R 1 2 3 4 5 1 R 2 3 4 R 1 2 3 4 5 R 2 3 1 4 4 Domain Root Router 2 Domain Root Router 1 5 BS1 2 3 4 5 BS2BS3BS4 1 Mobile IP Home Agent: 1.1.1.100-> 1.1.2.200 6 7 Macro-Mobility Ramjee

125. 22 June 2015 Simulation Topology Ramjee

126. 22 June 2015 Performance: Audio and Video Ramjee

127. 22 June 2015 TORA  O'Neill/Corson/Tsirtsis  "make before break"  hierarchical CR IR ER MH ER IR ER MH (0,0,0,3,i) (0,0,0,4,i) (0,0,0,5,i) CR IR ER (0,0,0,4,i) (0,0,0,5,i) (-2,0,0,5,i) (-2,0,0,4,i) (-2,0,0,3,i) (-2,0,0,2,i) (-2,0,0,1,i) (-2,0,0,0,i) (0,0,0,5,i) (0,0,0,6,i) (0,0,0,7,i) (0,0,0,8,i) (-1,0,0,5,i) (-1,0,0,3,i) (-2,0,0,6,i) (-2,0,0,7,i) (0,0,0,1,i) (0,0,0,2,i) (0,0,0,3,i) (0,0,0,4,i) (0,0,0,5,i) AR (-1,0,0,4,i) core interior edge access

128. 22 June 2015 Hierarchical Mobility Agents Home Agent GMA LMA  Localize signaling to visited domain  Regional Registration/Regional Binding Update  uses IP tunnels (encapsulation)  only, only one level of hierarchy RMA Perkins

129. 22 June 2015 Example: hierarchical FA (Dynamics, HUT) HACN HFA FA2 FA3 FA13 FA29 FA14 FA32 FA15 FA1 Location update latencies for some transitions FA11FA12 FA13 FA31 Forsberg et al

130. 22 June 2015 Hierarchical FA with soft hand- off HACN HFA FA12 FA3 FA31 FA29FA14 FA32 FA15 FA11 FA3 FA13 Data stream CN --> MN OLD FA NEW FA Lost packets/ update FA11FA310.00 FA31FA290.00 FA29FA320.00 FA31FA130.00 FA12FA150.00 FA15FA310.03 FA32FA110.07 FA13FA120.10 OLD FA NEW FA Lost packets/ update FA11FA310.27 FA31FA290.27 FA29FA320.00 FA31FA130.15 FA12FA150.14 FA15FA310.00 FA32FA110.00 FA13FA120.00 Data stream MN --> CN Data stream: 100kB/s, 1kB packets (100 packets/s) HUT Dynamics 802.11

131. 22 June 2015 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? Site1 Internet MN MS BR Castelluccia/Bellier

132. 22 June 2015 INRIA HMIPv6  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 Internet PCoA VCoA (VCoA,PCoA) (H@,PCoA) (H@,VCoA)

133. 22 June 2015 INRIA HMIPv6 – packet delivery  External CH sends to VCoA –MS in MN intercepts and routes to MH  Local CH sends to PCoA MS Site1 Internet MN

134. 22 June 2015 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 MS Internet (VCoA,PCoA) (HA,PCoA) (H@,PCoA1) PCoA1

135. 22 June 2015 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" Domain1 Domain2 MA 1 2 3 4 Hartenstein et al.

136. 22 June 2015 Comparison of CIP, HAWAII, HMIP Cellular IPHAWAIIHMIP OSI layerL3 "L3.5" Nodesall CIP nodesall routersFAs Mobile host IDhome addresscare-of-addresshome address Intermediate nodesL2 switches L3 routers Means of updatedata packetsignaling msg. Pagingimplicitexplicit Tunnelingno yes L2 triggered hand-offoptional no MIP messagingnoyes Campbell/Gomez-Castellanos

137. 22 June 2015 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

138. 22 June 2015 Cost of networking Modality modespeed $/MB (= 1 minute of 64 kb/s videoconferencing or 1/3 MP3) OC-3P 155 Mb/s $0.0013 Australian DSL (512/128 kb/s) P 512/128 kb/s $0.018 GSM voiceC 8 kb/s $0.66-$1.70 HSCSDC 20 kb/s $2.06 GPRSP 25 kb/s $4-$10 IridiumC 10 kb/s $20 SMS (160 chars/message) P ? $62.50 Motient (BlackBerry) P 8 kb/s $133

139. 22 June 2015 Spectrum cost for 3G Location whatcost UK3G$590/person Germany3G$558/person Italy3G$200/person New YorkVerizon (20MHz) $220/customer Generally, license limited to 10-15 years

140. 22 June 2015 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

141. 22 June 2015 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)

142. 22 June 2015 Multimedia data access modalities highlow high7DS802.11 hotspots lowsatellite SMS? voice (2G, 2.5G) bandwidth (peak) delay

143. 22 June 2015 A family of access points Infostation 2G/3G access sharing 7DS hotspot + cache WLAN

144. 22 June 2015 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

145. 22 June 2015 7DS options Query Forwarding Host AHost B query FW query Host C time Querying active (periodic) passive Power conservation on off time communication enabled

146. 22 June 2015 Dataholders (%) after 25 min high transmission power 2 Fixed Info Server Mobile Info Server P2P

147. 22 June 2015 Message relaying with 7DS Host B Message relaying Host A messages Gateway WAN Host A WLAN

148. 22 June 2015 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

149. 22 June 2015 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 –Ramachandran Ramjee –Henning Sanneck –Adam Wolisz –Moshe Zukerman –Kanter, Maguire, Escudero-Pascual –and others