Wireless IP Multimedia Henning Schulzrinne Columbia University MOBICOM

Скачать презентацию Wireless IP Multimedia Henning Schulzrinne Columbia University MOBICOM Скачать презентацию Wireless IP Multimedia Henning Schulzrinne Columbia University MOBICOM

1fff9ea2332b3ab0c0122f2296adb16c.ppt

  • Количество слайдов: 148

Wireless IP Multimedia Henning Schulzrinne Columbia University MOBICOM Tutorial, September 2002 Wireless IP Multimedia Henning Schulzrinne Columbia University MOBICOM Tutorial, September 2002

Overview § Types of wireless multimedia applications – streaming – interactive – object delivery Overview § Types of wireless multimedia applications – streaming – interactive – object delivery § Properties of multimedia content – loss resiliency – delay – reordering § 3 G and WLAN MMrelated channel properties – effective bandwidth – packet loss – delay § Header and signaling compression – c. RTP – ROHC – signaling compression § Packet FEC § UMTS multimedia subsystem (IMS) – Qo. S – Session setup § Fast handoff mechanisms § Multimodal networking

Types of wireless multimedia applications § Streaming – video/audio on demand – may be Types of wireless multimedia applications § Streaming – video/audio on demand – may be cached at various places, including end system § Interactive – Vo. IP – 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

IETF (multimedia) protocols H. 323 SIP SDP MGCP RTSP RSVP LDAP Network TCP CIP IETF (multimedia) protocols H. 323 SIP SDP MGCP RTSP RSVP LDAP Network TCP CIP MIP Physical PPP SONET DHCPP DNS media encap (H. 261. MPEG) RTCP RTP Application Media Transport SAP UDP IDMP MIP-LR MIPv 6 IPv 4, IPv 6, IP Multicast ICMP AAL 3/4 ATM AAL 5 IGMP PPP 802. 11 b Heterogeneous Access Ethernet CDMA 1 XRTT /GPRS Kernel Signaling

Common wired & wireless audio codecs codec name standards org. sampling rate G. 711 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 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. sampling rate frame size bit rate (kb/s) Audio codecs, cont'd. codec name standards org. sampling rate frame size bit rate (kb/s) EVRC (RCELP) TIA/EIA (1996) 8, 000 20 ms 8. 55, 4, 0. 8 G. 726 (ADPCM) ITU 8, 000 sample 16, 24, 32, 40 G. 728 (LD-CELP) ITU 8, 000 20 ms 16 (Hz)

Audio codecs § MP 3 and AAC: delay > 300 ms unsuitable for interactive Audio codecs § MP 3 and AAC: delay > 300 ms unsuitable for interactive applications § GSM and AMR are speech (voiceband) codecs 3. 4 k. Hz 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

Audio codecs § Typically, have algorithmic look-ahead of about 5 ms additional delay – 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 A AMR-NB AMR-WB www. voiceage. com 22 24

Audio codecs - silence § Almost all audio codecs support Voice Activity Detection (VAD) 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. 729 B – AMR built-in: CN periodically in Silence Indicator (SID) frames = discontinuous transmission (DTX) saves battery power – or source controlled rate (SCR)

Audio codecs - silence § silence periods depend on – background noise – word 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 JPEG e. g. , DCT: spatial frequency Frames of Digital Video Motion 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, Zig. Zag Scan & Run. Length 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 MPEG, H. 26 x courtesy M. Khansari

History of video codecs H. 261 H. 263++ ITU-T H. 263+ ISO MPEG 1 History of video codecs H. 261 H. 263++ ITU-T H. 263+ ISO MPEG 1 1990 MPEG 4 MPEG 2 1992 H. 263 L 1994 1996 MPEG 7 1998 2000 2002 courtesy M. Khansari

H. 263 L example 64 kb/s, 15 fps H. 263 L example 64 kb/s, 15 fps

Delay requirements § In many cases, channel is delay constrained: – ARQ mechanisms – 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 ESS Existing Wired LAN AP STA BSS STA Infrastructure Network STA 802. 11 architecture ESS Existing Wired LAN AP STA BSS STA Infrastructure Network STA Ad Hoc Network STA BSS STA Ad Hoc Network STA Mustafa Ergen

802. 11 b hand-off Kanter, Maguire, Escudero-Pascual, 2001 802. 11 b hand-off Kanter, Maguire, Escudero-Pascual, 2001

802. 11 delay channel is busy idle slots Data ACK idle slots time DIFS 802. 11 delay channel is busy idle slots Data ACK idle slots time DIFS SIFS (DCF interframe space) idle RTS slots DIFS (short IFS) CTS Data ACK idle slots time DIFS SIFS (µs) FHSS SIFS 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. 11 b 11 Mb/s 802. 11 delay 802. 11 1, 2 Mb/s DSSS 802. 11 b 11 Mb/s FHSS, DSSS 802. 11 a 2, 11, 24, 54 Mb/s OFDM § 802. 11 b: 192 bit PHY headers 192 µs (sent at 1 Mb/s) § 802. 11 a: 60 µs § three MAC modes: – DCF + RTS – PCF: AP-mode only

802. 11 delay 802. 11 delay

802. 11 delay 802. 11 delay

802. 11 a delay for Vo. IP 802. 11 a delay for Vo. IP

802. 11 b channel access delay Köpsel/Wolisz • 12 mobile data nodes, 4 mobile 802. 11 b channel access delay Köpsel/Wolisz • 12 mobile data nodes, 4 mobile with on/off audio • 6 Mb/s load

802. 11 b Vo. IP delay § Köpsel/Wolisz Wo. WMo. M 2001: add priority 802. 11 b Vo. IP delay § Köpsel/Wolisz Wo. WMo. M 2001: add priority and PCF enhancement to improve voice delay DCF Köpsel/Wolisz

802. 11 b – PCF+priority § poll only stations with audio data § move 802. 11 b – 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. 11 e = enhanced DCF HC hybrid controller TC traffic categories AIFS arbitration 802. 11 e = enhanced DCF HC hybrid controller TC traffic categories AIFS arbitration IFS TXOP transmission opportunity Mustafa Ergen

802. 11 e back-off 802. 11 e back-off

Metric of Vo. IP quality § Mean Opinion Score (MOS) [ITU P. 830] – Metric of Vo. IP quality § Mean Opinion Score (MOS) [ITU P. 830] – Obtained via human-based listening tests – Listening (MOS) vs. conversational (MOSc) Grade Quality 5 Excellent 4 Good 3 Fair 2 Poor 1 Bad

FEC and IP header overhead § An (n, k) FEC code has (n-k)/k overhead FEC and IP header overhead § An (n, k) FEC code has (n-k)/k overhead § Typical IP/UDP/RTP header is 40 bytes codec i. LBC (4, 2) FEC media pkt size (T=30 ms) rmedia r. IP 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

Predicting MOS in Vo. IP § The E-model: an alternative to humanbased MOS estimation Predicting MOS in Vo. IP § The E-model: an alternative to humanbased MOS estimation – Do need a first-time calibration from an existing human MOS-loss curve § In Vo. IP, 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 Vo. IP, contd § Example mappings – From loss and delay Predicting MOS in Vo. IP, contd § Example mappings – From loss and delay to their impairment scores and to MOS

Predicting MOS under FEC § Compute final loss probability pf after FEC [Frossard 2001] 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 § Codecs under evaluation – i. LBC: Quality Evaluation of FEC vs. Codec Robustness § Codecs under evaluation – i. LBC: 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 = 30 ms

G. 729+(5, 3) FEC vs. i. LBC § Ignoring delay effect, a larger T G. 729+(5, 3) FEC vs. i. LBC § Ignoring delay effect, a larger T improves FEC efficiency and its quality § When considering delay, however, using a 60 ms interval is overkill, due to higher FEC delay (5*60 = 300 ms)

G. 729+(5, 2) vs. i. LBC+(3, 2) § When i. LBC also uses FEC, G. 729+(5, 2) vs. i. LBC+(3, 2) § When i. LBC 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. i. LBC+(4, 2) § Too much FEC redundancy (e. g. G. 729+(7, 2) vs. i. LBC+(4, 2) § Too much FEC redundancy (e. g. , for G. 729) very long FEC block and delay not always a good idea § i. LBC wins in this case, when considering delay

G. 729+(3, 1) vs. i. LBC+(4, 2) § Using less FEC redundancy may actually G. 729+(3, 1) vs. i. LBC+(4, 2) § Using less FEC redundancy may actually help, if the FEC block is shorter § Now G. 729 performs similar to i. LBC

Comparison with G. 723. 1 § MOS(G. 723. 1) < MOS(i. LBC) at zero Comparison with G. 723. 1 § MOS(G. 723. 1) < MOS(i. LBC) at zero loss i. LBC dominates more low loss areas compared with G. 729, whether delay is considered or not

G. 723. 1+(3, 1) vs. i. LBC+(3, 2) § i. LBC is still better G. 723. 1+(3, 1) vs. i. LBC+(3, 2) § i. LBC is still better for low loss § G. 723. 1 wins for higher loss

G. 723. 1+(4, 1) vs. i. LBC+(4, 2) § i. LBC dominates in this G. 723. 1+(4, 1) vs. i. LBC+(4, 2) § i. LBC dominates in this case whether delay is considered or not, – (4, 2) code already suffices for i. LBC – (4, 1) code’s performance essentially “saturates”

The best of both worlds § Observations, when considering delay: – i. LBC is The best of both worlds § Observations, when considering delay: – i. LBC 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 § 14 to 21 kb/s: significant improvement 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 3 G wireless § Staged roll-out with UMTS and 3 G 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

UMTS macrocell 2 km 144 kb/s microcell 1 km 384 kb/s picocell 60 m 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

1 G-3 G air interface 1 G 2 G “ 2. 5 G” 3 1 G-3 G air interface 1 G 2 G “ 2. 5 G” 3 G/ IMT-2000 Capable Existing Spectrum Analog AMPS IS-95 -A/ cdma. One IS-95 -B/ cdma. One New Spectrum cdma 2000 1 X (1. 25 MHz) cdma 2000 3 X (5 MHz) 1 XEV DO: HDR (1. 25 MHz) 136 HS EDGE IS-136 TDMA TACS GSM GPRS EDGE GSM WCDMA HSCSD Ramjee

The mysterious 4 G § Fixes everything that's wrong with 3 G § Convergence The mysterious 4 G § Fixes everything that's wrong with 3 G § Convergence to IP model: treat radio access as link layer that carries IP(v 6) 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 W. Granzow UMTS W. Granzow

3 GPP network architecture AS Jalava 3 GPP network architecture AS Jalava

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

3 GPP networks – call control -View on CALL CONTROL Applications & Services VHE 3 GPP 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 Alves

UMTS network architecture MSC GSN RNC Node B Mobile Services Switching Center GPRS Support UMTS network architecture MSC GSN RNC Node B Mobile Services Switching Center GPRS Support Node MSC/GSN Radio Network controller Base Node RNC Node B Radio network System (RNS) Node B No Node B W. Granzow

Aside: some 3 G/UMTS terminology CS circuit-switched GERAN GSM/EDGE Radio Access Network GGSN Gateway Aside: some 3 G/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.

UTRA transport channels categories § Common channels – Multiplexed users (user ID in the 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)

Transmission Format UTRA FDD 1 radio frame (10 ms), 15*2560 chips (3. 84 Mcps) Transmission Format UTRA FDD 1 radio frame (10 ms), 15*2560 chips (3. 84 Mcps) Slot 1 Slot 2 Slot i Uplink time Downlink Macrocell layers 5 MHz Slot 15 frequency Microcell layer 5 MHz Duplex distance, e. g. 190 MHz 5 MHz

UMTS/3 G Qo. S classes conversational voice, video conferencing streaming video streaming low delay, UMTS/3 G Qo. S classes conversational voice, video conferencing streaming video streaming low delay, strict ordering modest delay, strict ordering interactive web browsing, games modest delay background email download no delay guarantees

Qo. S class requirements § Excerpt from 3 GPP TS 23. 107: Traffic class Qo. S class requirements § Excerpt from 3 GPP TS 23. 107: Traffic class Conversational Streaming Residual BER 5*10 -2, 5*10 -3, 10 -4, 10 -6 -4, 10 -5, 10 -6 SDU error rate 10 -2, 7*10 -3, 10 10 -1, 10 -2, 7*10 10 -3, 10 -4, 10 -6 -3, 10 -4, 10 -5 Transfer delay 100 ms 250 ms Guaranteed bit rate 2, 048 kb/s 4*10 -3, 10 -5, 6*10 -8 Background 4*10 -3, 10 -5, 6*10 -8 10 -3, 10 -4, 10 -6 1, 2, 3 Traffic handling priority Allocation/retention priority Interactive 1, 2, 3

GPRS delay Gurtov, PWC 2001 GPRS delay Gurtov, PWC 2001

UMTS transport UMTS transport

UMTS Release 4/5 Architecture Kulkarni UMTS Release 4/5 Architecture Kulkarni

UMTS IP multimedia UMTS IP multimedia

Qo. S in UMTS § Short term: signaling tell network elements about Qo. S Qo. S in UMTS § Short term: signaling tell network elements about Qo. S requirements – RSVP (Int. Serv) – Diff. Serv with DSCPs – PDP context § Longer term: provisioning allocate resources to Qo. S classes – – low network utilization (overprovisioning) Diff. Serv Int. Serv (possibly for Diff. Serv classes, RFC xxxx) MPLS § Mechanisms can be heterogeneous – DSCP translation – localized RSVP

Qo. S signaling in UMTS § UMTS R 5: two end-to-end Qo. S signaling Qo. S signaling in UMTS § UMTS R 5: two end-to-end Qo. S signaling scenarios § Qo. S provisioning left vague § RSVP currently not in standard – additional scenario featuring RSVP may be added to a later release of the standard § Qo. S 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

UMTS – 3 GPP and 3 GGP 2 § Divided regionally/historically: – both from UMTS – 3 GPP and 3 GGP 2 § Divided regionally/historically: – both from ITU IMT-2000 initiative – GSM 3 GPP (ETSI) = WCDMA – US (CDMA) 3 gpp 2 (TIA) = CDMA 2000 § 3 GPP 2: different PHY, but similar applications (not completely specified) – cdma 2000

Session setup: SIP INVITE sip: bob@biloxi. com SIP/2. 0 Via: SIP/2. 0/UDP pc 33. Session setup: SIP INVITE sip: [email protected] com SIP/2. 0 Via: SIP/2. 0/UDP pc 33. atlanta. com [email protected] com: ; branch=z 9 128. 59. 16. 1 Max-Forwards: 70 To: Bob REGISTER From: Alice ; tag=1928301774 Call-ID: a 84 b 4 c 76 e [email protected] 33. atlanta. com CSeq: 314159 INVITE Contact: Content-Type: application/sdp Content-Length: 142 BYE

Session setup: SIP § Creates, modifies, terminates sessions § sessions = audio, video, text 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 200 OK ACK Media streams BYE 200 OK – sip: [email protected] com – tel: +1 -212 -555 -1234 Jalava

SIP request routing § SIP proxies route all SIP requests § don't care about 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] com sip: [email protected] 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

3 GGP Internet Multimedia Subsystem § services (call filtering, follow-me, …) provided in home 3 GGP 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) Voice. XML 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. e 164. arpa § mechanisms and roles: – proxy servers call routing, forking – user agents (UA) voice mail, conferencing, IM – back-to-back UA (B 2 BUA) 3 rd party call control

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

IMS session overview Jalava IMS session overview Jalava

Locating the P-CSCF 2 mechanisms: Locating the P-CSCF 2 mechanisms:

3 GPP SIP registration sip: 23415098765@15. 234. IMSI. 3 gppnetwork. org TS 23. 228/5. 3 GPP SIP registration sip: [email protected] 234. IMSI. 3 gppnetwork. org TS 23. 228/5. 1

3 GPP IMS call setup 3 GPP IMS call setup

IMS call setup with Qo. S IMS call setup with Qo. S

SIP for mobility § Terminal mobility – same device, different attachment point • nomadic/roaming 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 § For most UDP applications, no need to keep constant 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 IP 1 INVITE re-INVITE IP 2 registrar [email protected] com: 128. 59. 16. 1 REGISTER IP 2

SIP mobility vs. mobile IP § Mobility at different layers: – permanent identifier – 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

SIP personal mobility SIP personal mobility

SIP hierarchical registration 1 From: alice@NY Contact: 193. 1. 1. 1 2 From: alice@NY SIP hierarchical registration 1 From: [email protected] Contact: 193. 1. 1. 1 2 From: [email protected] Contact: [email protected] CA San Francisco NY 4 3 From: [email protected] Contact: 192. 1. 2. 3 REGISTER INVITE Los Angeles registrar proxy

3 GPP – IETF SIP differences § SIP terminal + authentication = 3 GPP 3 GPP – IETF SIP differences § SIP terminal + authentication = 3 GPP terminal § signaling as covert channel? death of SMS? § CSCFs are not quite proxies, not quite B 2 BUAs – – 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 § IETF WG to explore alternatives (or profiles? 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 § Wireless access networks = – – high latency: 100 -200 ms Header compression § Wireless access networks = – – high latency: 100 -200 ms 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 – IPv 4+UDP+RTP = 40 bytes of header, 60 with IPv 6 – SIP session setup ~ 1000 bytes

Header compression § 3 GPP architecture 3 GPP Architecture for all IP networks Header compression § 3 GPP architecture 3 GPP Architecture for all IP networks

Header compression § Pure use of dictionary-based compression (LZ, gzip) not sufficient § Similar 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) § VJ header compression for TCP uses TCP-level retransmissions to updated 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) § Avoid use of UDP checksums – most speech codecs 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

ROHC § Channel assumptions: – does not reorder (but may before compressor) – does 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

ROHC modes § Unidirectional (U) – compressor decompressor only – periodic timeouts only – 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 § Least significant bits (LSB) – header fields with small changes ROHC encoding methods § Least significant bits (LSB) – header fields with small changes – k least significant bits – interpretation interval – f(vref, k) = [vref – p, vref + (2 k – 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 § Scaled RTP timestamp encoding – RTP increases by multiple 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 + 1 o, 10 + 2 o, 110 + 3 o, 1110 + 4 o

ROHC duplicate, reorder, lose packets decompressor ACK NACK • typically, multiple streams for each ROHC duplicate, reorder, lose packets decompressor ACK NACK • typically, multiple streams for each channel • identified by channel identifier (CID) • protected by 3 -8 bit CRC

Header classification inferred can be deduced from other values (e. g. , length of 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-known well-known values not transmitted changing randomly or within range compress by 1 st/2 nd order "differentiation"

Example: IPv 6 Field Size (bits) type Version 4 static Traffic Class 8 changing Example: IPv 6 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 2 x 128 inferred static changing static-def inferred static 2 1. 5 static-def 34. 5 changing 2

Example: RTP Field Size (bits) type Version 2 Padding 1 Extension 1 CSRC Counter, 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 changing static-known static 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 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

Classification of changing fields Field Value/Delta Class Knowledge IP TOS/Traffic Class value RC unknown 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

ROHC CRC § Qiao: add one-bit correction CRC § helps with BER of 4 ROHC CRC § Qiao: add one-bit correction CRC § helps with BER of 4 -5% Full header Decompre ssed header Compressed header Validate CRC CRC Qiao

Signaling compression (Sig. Comp) § Textual signaling protocols like SIP, RTSP and maybe HTTP Signaling compression (Sig. Comp) § Textual signaling protocols like SIP, RTSP and maybe HTTP – – long signaling messages ( k. B) signaling delays call setup delays less of an issue: total overhead long packets headers not a major issue § unlike ROHC, assume reliable transport Sig. Comp ROHC SIP proxy

Signaling compression application message & compartment id compressor dispatcher compressor 1 Sig. Comp message Signaling compression application message & compartment id compressor dispatcher compressor 1 Sig. Comp message decompressor dispatcher state 1 state handler compressor 2 compartment identifier decompressed message decompressor (UDVM) state 2 Sig. Comp layer transport layer (TCP, UDP, SCTP) Sig. Comp message

Sig. Comp § Messages marked with special invalid UTF-8 bit sequence (11111 xxx) § Sig. Comp § Messages marked with special invalid UTF-8 bit sequence (11111 xxx) § 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

Sig. Comp UDVM bytecode § virtual machine with registers and stack § single byte Sig. Comp 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 UDVM decompressor dispatcher indicate end of message provide compartment identifier request state information provide state information make state creation request forward feedback information state handler

Sig. Comp virtual machine § arithmetic: and, or, not, left/right shift, integer add/subtract/multiply/divide, remainder Sig. Comp 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 § SIP compression most likely will use a static dictionary – 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, LZ 78, … § Capability indicated using NAPTR records and REGISTER parameter ; ; order pref flags service regexp replacement IN NAPTR 100 "s" "SIP+D 2 T" "" _sip. _tcp. school. edu IN NAPTR 100 "s" "SIP+D 2 U" "" _sip. _udp. example. com IN NAPTR 100 "s" "SIP+D 2 CU" "" comp-udp. example. com

RTP unequal error protection § Provide generic protection of RTP headers and payload against 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 protection RTP seq. number base E PT recovery length recovery bit 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

Unequal erasure protection (UXP) § Alternative to ULP, with different properties § uses interleaving 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 § Proposal by Larzon&Degermark § partial checksum coverage – at least UDP header UDPLite § Proposal by Larzon&Degermark § partial checksum coverage – at least UDP header bytes source port destination port checksum coverage UDP checksum data bytes

Fast handoff – hand-off latency § Allow only a few lost packets < 100 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. 11 a, 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. 11 i authentication – IETF PANA WG – L 2 -independent access control

Handoff latency § duplicate address detection (DAD) – DHCP • DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK Handoff latency § duplicate address detection (DAD) – DHCP • DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK multiple RTT, plus possible retransmissions – IPv 6 stateless autoconfiguration (RFC 2461, 2462) • delay first Neighbor Solicitation in [0, MAX_RTR_SOLICITATION_DELAY], where MAX_RTR_SOLICITATION_DELAY = 1 s • wait for Retrans. Timer (1 s) for answer § AAA (authentication, authorization, accounting) – usually, RADIUS or (future) DIAMETER – server may be far away

MIPv 6 delays Internet CH Internet HA 2 BU= HA, Co. A 1 3 MIPv 6 delays Internet CH Internet HA 2 BU= HA, Co. A 1 3 1 Site 1 2 Site 1 Co. A Castelluccia/Bellier

Micro-mobility § Separate local (intra-domain, frequent) movement from inter-domain movement (rare) – 3 mobility Micro-mobility § Separate local (intra-domain, frequent) movement from inter-domain movement (rare) – 3 mobility protocol layers: L 2 (e. g. , 802. 11, 3 G 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 IPv 6 (INRIA, 1998) HAWAII (Lucent, 1999) THEMA (Lucent/Nokia, 1999) Tele. MIP (Telcordia, IBM, 2001) ISP 1 ISP 2 100'

Micro-mobility design goals § Scalability – process updates locally § Limit disruption – forward Micro-mobility design goals § Scalability – process updates locally § Limit disruption – forward packets if necessary § Efficiency – avoid tunneling where possible § Quality of Service (Qo. S) support – local restoration of reservations § Reliability – leverage fault detection mechanisms in routing protocols § Transparency – minimal impact at the mobile host Ramjee

Micro-mobility § Methods based on re-addressing – – – Micro-mobility § Methods based on re-addressing – – – "keep routes, change address" typically, tunnels within domain hierarchical FAs MIP with Co. A to world at large e. g. , • regional registration, region-aware foreign agents, Dynamics, hierarchical MIPv 6, … § 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 IP § base station routes IP routes cellular IP routing § gateway support Cellular IP § base station routes IP routes cellular IP routing § gateway support MIP macro mobility – provides Co. A § inside micro mobility domain, packets identified by [email protected] – 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

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

Cellular IP: downlink HO loss Cellular IP: downlink HO loss

HAWAII: Enhanced Mobile IP Internet Domain Router R R R MD Local mobility Mobile HAWAII: Enhanced Mobile IP Internet Domain Router 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 q Localized mobility management: Fast handoffs – updates only reach routers affected by movement q Minimized or Eliminated Tunneling: Efficient routing – dynamic, public address assignment to mobile devices q Ramjee

Power-up Domain Root Router 2 1 2 R 4 3 Internet 1. 100 -> Power-up Domain Root Router 2 1 2 R 4 3 Internet 1. 100 -> port 3, 239. 0. 0. 1 5 1 R 4 2 3 Domain Root Router 1 1 2 R 3 4 3 1. 100 ->port 4, 1 239. 0. 0. 1 2 R 5 3 4 4 1 2 R 5 3 4 2 BS 1 BS 2 BS 3 1 MY IP: 1. 100 BS IP: 1. 1. 1. 5 BS 4 1. 100 ->wireless, 5 239. 0. 0. 1 Mobile IP HAWAII Ramjee

Soft-State § Host-based routing entries maintained as soft-state § Base-stations and mobile hosts periodically 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

Failure Recovery Domain Root Router 2 1 2 R 4 3 Internet Domain Root Failure Recovery Domain Root Router 2 1 2 R 4 3 Internet Domain Root Router 1 1 1. 100 -> port 2 R 4, 3 4 239. 0. 0. 1 3 5 1 R 4 2 3 BS 1 2 BS 2 1 R 5 3 4 2 BS 3 1 MY IP: 1. 100 BS IP: 1. 1. 1. 5 1 2 R 5 3 4 1. 100 ->port 3, 239. 0. 0. 1 BS 4 1. 100 ->wireless, 239. 0. 0. 1 Mobile IP HAWAII Ramjee

Path Setup Schemes § Host-based routing within the domain § Path setup schemes selectively 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

Micro-Mobility Domain Root Router 2 1 R 4 2 3 5 1 R 4 Micro-Mobility Domain Root Router 2 1 R 4 2 3 5 1 R 4 2 3 Internet 1. 100 -> port 3, 239. 0. 0. 1 Domain Root Router 1 1 2 R 3 4 1. 100 ->port 3 (4), 1 239. 0. 0. 1 2 R 5 3 4 4 2 3 BS 1 BS 2 1. 100 ->wireless, 1 5 239. 0. 0. 1 MY IP: 1. 100 BS IP: 1. 1. 1. 2 1 2 R 5 3 4 BS 3 BS 4 1. 100 ->port 1(wireless), 239. 0. 0. 1 Mobile IP HAWAII Ramjee

Macro-Mobility Domain Root Router 2 1 2 R 4 3 3 Domain Root Router Macro-Mobility Domain Root Router 2 1 2 R 4 3 3 Domain Root Router 1 Mobile IP Home Agent: 1 1. 100 -> 2 R 4 3 1. 1. 2. 200 Internet 1. 1. 2. 200 -> port 3, 239. 0. 0. 1 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 2 BS 1 1 BS 2 7 1. 1. 2. 200 ->wireless, 239. 0. 0. 2 MY IP: 1. 100 BS IP: 1. 1. 2. 1 COA IP: 1. 1. 2. 200 BS 3 BS 4 Mobile IP HAWAII Ramjee

Simulation Topology Ramjee Simulation Topology Ramjee

Performance: Audio and Video Ramjee Performance: Audio and Video Ramjee

TORA § O'Neill/Corson/Tsirtsis § TORA § O'Neill/Corson/Tsirtsis § "make before break" § hierarchical (0, 0, 0, 4, i) core CR interior (0, 0, 0, 4, i) CR 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) AR(0, 0, 0, 5, i) MH AR (0, 0, 0, 1, i) (-1, 0, 0, 5, i) CR(0, 0, 0, 6, i) (-2, 0, 0, 4, i) IR(0, 0, 0, 5, i) IR(0, 0, 0, 6, i) (-1, 0, 0, 3, i) (-1, 0, 0, 4, i) access (0, 0, 0, 5, i) CR (-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)

Hierarchical Mobility Agents GMA RMA Home Agent LMA § § Localize signaling to visited 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) CN HA Location update latencies for some transitions HFA Example: hierarchical FA (Dynamics, HUT) CN HA Location update latencies for some transitions HFA FA 11 FA 13 FA 31 FA 13 FA 12 FA 29 FA 14 FA 15 FA 32 Forsberg et al

Hierarchical FA with soft handoff Data stream: 100 k. B/s, 1 k. B packets Hierarchical FA with soft handoff Data stream: 100 k. B/s, 1 k. B packets (100 packets/s) CN HA HFA FA 11 FA 13 FA 31 FA 12 FA 29 FA 14 OLD FA NEW FA Lost packets/ update FA 11 FA 31 FA 29 FA 31 FA 12 FA 15 FA 32 FA 13 FA 31 FA 29 FA 32 FA 13 FA 15 FA 31 FA 12 0. 00 0. 03 0. 07 0. 10 FA 15 FA 32 HUT Dynamics 802. 11 Data stream CN --> MN OLD FA NEW FA Lost packets/ update FA 11 FA 31 FA 29 FA 31 FA 12 FA 15 FA 32 FA 13 FA 31 FA 29 FA 32 FA 13 FA 15 FA 31 FA 12 0. 27 0. 00 0. 15 0. 14 0. 00 Data stream MN --> CN

INRIA HMIPv 6 Internet BR Site 1 MN MS § inter-site (global, macro) vs. INRIA HMIPv 6 Internet BR Site 1 MN MS § inter-site (global, macro) vs. intra-site (local, micro) § CH only aware of intersite mobility § MIPv 6 used to manage macro and micro mobility § define MN as LAN connected to border router, with >= 1 MS § use site-local IPv 6 addresses? Castelluccia/Bellier

INRIA HMIPv 6 § MH gets 2 Co. A: Internet (H@, VCo. A) (VCo. INRIA HMIPv 6 § MH gets 2 Co. A: Internet ([email protected], VCo. A) (VCo. A, PCo. A) – VCo. A in the MN stays constant within site – PCo. A (private Co. A) changes with each micromove § MH registers ([email protected], PCo. A) PCo. A VCo. A – ([email protected], VCo. A) external CH – ([email protected], PCo. A) local CHs – (VCo. A, PCo. A) MS § MH obtains MS address and MN prefix via router advertisements

INRIA HMIPv 6 – packet delivery § External CH sends to VCo. A Internet INRIA HMIPv 6 – packet delivery § External CH sends to VCo. A Internet MN MS Site 1 – MS in MN intercepts and routes to MH § Local CH sends to PCo. A

INRIA HMIPv 6 – micro mobility registration Internet (H@, PCo. A 1) (HA, PCo. INRIA HMIPv 6 – micro mobility registration Internet ([email protected], PCo. A 1) (HA, PCo. A) § MH moves and gets new PCo. A (PCo. A 1) § sends BU (VCo. A, PCo. A) PCo. A 1) to its MS § sends BU ([email protected], MS PCo. A 1) to local CHs PCo. A 1

Other approaches to latency reduction § IP-based soft handoff § buffering of in-flight data Other approaches to latency reduction § IP-based soft handoff § buffering of in-flight data in old FA – forward to new Co. A or new BS MA § multicast to multiple base stations – unicast multicast unicast – often, down some hierarchy – multicast address assignment? 3 2 Domain 1 § UMTS / 802. 11 "vertical" hand-off – UMTS as "background radiation" 1 Domain 2 4 Hartenstein et al.

Comparison of CIP, HAWAII, HMIP Cellular IP HAWAII HMIP OSI layer L 3 Comparison of CIP, HAWAII, HMIP Cellular IP HAWAII HMIP OSI layer L 3 "L 3. 5" Nodes all CIP nodes all routers FAs Mobile host ID home address care-of-address home address Intermediate nodes L 2 switches L 3 routers Means of update data packet signaling msg. Paging implicit explicit Tunneling no no yes L 2 triggered hand-off optional no MIP messaging no yes Campbell/Gomez-Castellanos

Network-assisted hand-off Network makes hand-off decision, rather than UE network sets up resources (Qo. Network-assisted hand-off Network makes hand-off decision, rather than UE network sets up resources (Qo. S) 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 Modality mode speed $/MB OC-3 P 155 Mb/s $0. 0013 Australian Cost of networking Modality mode speed $/MB 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 (512/128 kb/s) (160 chars/message) Motient (Black. Berry) (= 1 minute of 64 kb/s videoconferencing or 1/3 MP 3)

Spectrum cost for 3 G Location what cost UK 3 G $590/person Germany 3 Spectrum cost for 3 G Location what cost UK 3 G $590/person Germany 3 G $558/person Italy 3 G $200/person New York Verizon (20 MHz) $220/customer Generally, license limited to 10 -15 years

Multimodal networking § = use multiple types of networks, with transparent movement of information 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, … § 2 G/3 G: 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 networking § expand reach by leveraging mobility § locality of data references – Multimodal networking § expand reach by leveraging mobility § locality of data references – mobile Internet not for general research – Zipf distribution for multimedia content • short movies, MP 3 s, news, … – newspapers – local information (maps, schedules, traffic radio, weather, tourist information)

Multimedia data access modalities bandwidth (peak) delay high low high 7 DS low 802. Multimedia data access modalities bandwidth (peak) delay high low high 7 DS low 802. 11 hotspots satellite SMS? voice (2 G, 2. 5 G)

A family of access points 2 G/3 G WLAN hotspot + cache 7 DS A family of access points 2 G/3 G WLAN hotspot + cache 7 DS Infostation access sharing

7 DS options § Many degrees of cooperation § server to client – only 7 DS 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 DS options Query Forwarding FW query Host A Host B Host C time 7 DS options Query Forwarding FW query Host A Host B Host C time Querying active (periodic) passive Power conservation communication enabled on off time

Dataholders (%) after 25 min high transmission power P 2 P Mobile Info Server Dataholders (%) after 25 min high transmission power P 2 P Mobile Info Server Fixed Info Server 2

Message relaying with 7 DS WAN messages WLAN Host A Gateway WLAN Message relaying Message relaying with 7 DS WAN messages WLAN Host A Gateway WLAN Message relaying Host A Host B

Conclusion and outlook § First packet-based wireless multimedia networks going into production § encumbered Conclusion and outlook § First packet-based wireless multimedia networks going into production § encumbered by legacy technology and business model ("minutes") § what is 4 G? § 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 – – – Emmanuel Coelho Alves 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




  • Мы удаляем страницу по первому запросу с достаточным набором данных, указывающих на ваше авторство. Мы также можем оставить страницу, явно указав ваше авторство (страницы полезны всем пользователям рунета и не несут цели нарушения авторских прав). Если такой вариант возможен, пожалуйста, укажите об этом.