1 / 31

Overview of 0-byte ROHC and Voice over IP models

Overview of 0-byte ROHC and Voice over IP models. 3GPP2 Requirements - Overview. Requirements are divided in 3 categories: Impact on Internet Infrastructure Efficiency/Complexity 3GPP2 Specific Requirements. Impact on Internet Infrastructure. Transparency - IP Service flexibility

jagger
Download Presentation

Overview of 0-byte ROHC and Voice over IP models

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Overview of 0-byte ROHC and Voice over IP models

  2. 3GPP2 Requirements - Overview Requirements are divided in 3 categories: • Impact on Internet Infrastructure • Efficiency/Complexity • 3GPP2 Specific Requirements

  3. Impact on Internet Infrastructure • Transparency - IP Service flexibility When a header is compressed and then decompressed, the resulting header must be semantically identical to the original header. Transparency is needed for MobileIP, end-to-end encryption schemes such as SRTP, etc. • Ubiquity - Ease of deployment No modifications to existing IP (v4 or v6), UDP, or RTP implementations shall be required

  4. Impact on Internet Infrastructure • Mobile IP The tunneling headers of Mobile IPv4 must be supported The IPv6 headers for Mobile IP must be supported. These headers contain: - Routing Header - Binding Update Destination Option - Home Address Option

  5. Efficiency/Complexity • Spectral Efficiency • Minimize Error Propagation • Handling of Handover events • Minimal Processing delay

  6. Efficiency/Complexity • Multiple Links • Unidirectional Links • No increase in Residual Errors • Genericness

  7. 3GPP2 Specific Requirements • Minimal Impact on Air Interface • Minimal Core Access Network impact • Impact on Future Protocol changes • Co-existence with other Header Compression schemes • Minimal Complexity in the MT

  8. MAC 0-Byte 0-Byte within the CDMA 2000 Architecture SPEECH CODEC VIDEO CODEC SIGNALLING WWW RTP HTTP MN BSC/PCF PDSN UDP TCP IP IP IP LINK LAYER LINK LAYER ROHC ROHC 0-Byte 0-Byte PPP PPP LAC R-P LAC R-P MAC 0-Byte AIRLINK AIRLINK PL PL PL PHYSICAL LAYER

  9. ROHC 0-Byte within CDMA 2000 • PDSN/MN Support • ROHC framework as described in RFC3095 ‘RObust Header Compression’ • 0-Byte specific functionality including: • 0-Byte specific negotiation over PPP • 0-Byte specific parameter setting • 0-Byte Context Verification Packet Handling • 0-Byte Periodic Context Update Packet Handling • 0-Byte interface towards PCF • Packet-Header synchronization upon initialization or packet loss • PCF/MN Support • 0-Byte Specific functionality including: • Packet Loss/Delay Handling • Interface towards Multiplex Sub-layer • Null RLP establishment • Channeling of Speech/Header information towards relevant dtch

  10. MN BSC/PCF PDSN Establishment of R-P towards Transparent RLP TCH Set-Up 0-Byte Initialization PPP IS 2000 Origination SERVICE_OPTION = e.g.‘XX Speech over IP’’ • A SERVICE_OPTION indicating • ‘Speech over IP’ may trigger the • establishment of a separate • RLP instance • PCF establish R-P session PPP free establishment • Each RLP instances • is associated to one R-P instance

  11. 0-Byte Negotiation BSC/PCF PDSN MN ROHC is negotiate over PPP • Type = 2 • Length = -> 10 • IP Compression Protocol = ROHC (RFC 3096) • MAX_CID = 0 (For 0 Byte Solution) • MRRU = 0 • MAX_HEADER = 168 (Maximum Header Size that can be compressed)

  12. MN BSC/PCF PDSN 0-Byte Negotiation (Continue) 0-Byte is negotiated using PPP suboptions • Type = 1 • Length = 2n+2 • Value: • n octet-pairs in ascending order each • octet pair specifying a ROHC profile supported • Profile = 0 Byte Profile.

  13. 0-Byte Parameter Setting Decompressor Compressor IR Packets H H H H H • Upon completion of PPP IP Compression Negotiation the Compressor • enters the Initialization and Refresh (IR) state. • 0-byte specific parameters, Leading Sequence and Packet Sizes are • are negotiated between compressor and decompressor.

  14. P P P 0-Byte Context Initialization Decompressor Compressor P P 0-Byte Packets • During the Initialization and Refresh (IR) phase context is • established between compressor and decompressor • Compressor initiates sending of 0-Byte Header Packets once • context has been established (e.g. compressor has reached • Second Order State)

  15. 0-Byte Scheme During Normal Operation Decompressor Compressor P P P P P • At the Compressor • 0-Byte Header packet are send during the majority of the 0-Byte • operation. • Period Updates MAY be send in order to guarantee transparency. • Transparencycould be adversely affected due to residual bit errors • contained in compressed headers delivered to the decompressor • Packet Loss/Delay is dealt with by sending Regular compressed ROHC • updates or Context Verification Packets • At the De-Compressor • Headers are decompressed and then passed on to Upper Layers, • based on Sequence Number count assisted by the Link Layer • synchronous nature

  16. H P Sending Non-0-Byte Compressed HeadersUpon Detection of Non-0-Byte Header Updates Initial Data Rate 16 40 P P P P 80 170 bits New Data Rate after Compressed Header 40 Max header size is 24 bits 16 80 Max header size is 64, 40 bits 16, 40 Three possible frame rates MAY be used to send compressed headers 170 Max header size is 155, 131, 91 bits 16, 40, 80

  17. H P …Sending Non-0-Byte Compressed Headers to Periodically Verify Context (Continue) Decompressor Leading Sequence Compressor P P P P • A ROHC defined padding octet (or a sequence of them) is used to • communicate the presence of a Non-0-Byte Header. • Using a 3 byte leading sequence yields a 1 in 16,777,216 probability • of having a matching “false sequence” in the payload..

  18. Packet Loss/Packet Delay Handling Decompressor Leading Sequence Compressor P P H P P P P SN=n SN = n+3 SN = n+1 SN = n+2 SN = n+4 SN = n+5 Packet Delay • The 0-Byte ROHC compressor deals with packet • loss/delay by sending Verification Packets or Update • Packets as required

  19. 0-Byte and Multimedia Signaling Stream VOIP Stream Video Stream Data Stream ROHC Signaling Profile ROHC 0-Byte Profile ROHC Profile 1 ROHC Profile 2 0-Byte Component ... ... CID=0 CID=0..15 CID=0 CID=0 ..15 CID=0 ..15 dsch, sr_id=0 dtch, sr_id=1 dtch, sr_id=2 dtch, sr_id=3 dtch, sr_id=4 Null RLP Instance Regular RLP Instance Regular RLP Instance Regular RLP Instance data block data block data block data block data block Multiplex Sublayer data block data block data block CRC data block CRC data block CRC

  20. Capacity Calculation Assumption

  21. Capacity Requirements

  22. Capacity Requirements

  23. CDMA2000 Voice over IP service models in the Mobile node. Support of Voice over IP service in CDMA2000 could be modeled three ways: - Model 1 (full legacy MS): IP telephony gateway in the network for both voice over IP control and payload. - Model 2 (Hybrid VoIP MS): End-to-End Voice over IP control with VoIP payload termination in the network (GEHCO architecture). - Model 3 (Full VoIP MS): True end-to-end voice over IP (A la ALLIP and a la Internet)

  24. Model 1 (Full legacy MS):IP telephony gateway in the network for both voice over IP control and payload • Support of voice over IP for legacy terminals is provided by the network through an IP telephony gateway (Existing standard solution) • Benefit from using cheaper IP routing, instead of expensive SS7/R1 trunks. • 0 impact in the MS • No IP over the air, use existing CDMA2000 control messages and CS voice over the air. • Use existing IOS standard. • -> No header compression function needed in the PDSN for this service. MSC IP Tel GW SIP server SIP client MGW A1 A2 PDSN B S C

  25. MSC SIP Server SIP/IP PPP (SIP) PPP/RLP PDSN (IP term) B S C EVRC EVRC MGW EVRC/IP Model 2 (Hybrid VoIP MS):End-to-End Voice over IP control with VoIP payload termination in the network (GEHCO architecture). • Service for legacy terminals when reuse of Codecs implementation (on the physical link) is desired. • Not clear what the real benefit is compared to model 1. • EVRC payload is at no time carried as an RTP/UDP/IP stream in the MS. • EVRC is supported as today’s CS voice service, hence “perfect” 0-byte from an air interface point of view. • IP is terminated in the PDSN for the voice payload. • An implementation of ROHC is used to support this model and negotiated within 0-byte profile.

  26. Model 2 (Hybrid VoIP MS):End-to-End Voice over IP control with VoIP payload termination in the network (GEHCO architecture). • No compressor/decompressor is used in the MS. • PDSN supports ROHC compressor/decompressor • Changes to the legacy MS are required: • VoIP control function (eg. SIP). • Some ROHC components are used to control the 0-byte operation. • Specific APIs will be required between VoIP control and the ROHC 0-byte control function (GEHCO style) to transfer the IP/UDP/RTP to the PDSN over PPP. SIP* UDP IP ROHC 0-byte control (GEHCO) PPP Voice codec (EVRC) CDMA2000 specific layers Null RLP

  27. Model 3 (Full VoIP MS):True end-to-end Voice over IP • Codecs are implemented in the IP application layer as well as the voice over IP control (e.g SIP) to provide a voice over IP service in a true AllIP and internet sense. • The ROHC compressor/decompressor is used in the MS and PDSN. • No specific APIs are required between the SIP control application and ROHC. • Compression/decompression is provided equally for video payload by negotiating a new profile. The ROHC C/D components are re-used. • An implementation of ROHC is used to support this model and negotiated within 0-byte profile. • The same 0-byte profile used in model 2 (0-byte lite) is reused. RTSP Video codec (MPEG) Voice codec (EVRC) SIP RTP UDP IP ROHC (comp/decomp) PPP CDMA2000 specific layers Null RLP

  28. Negotiation of ROHC-0 byte for model 2 and 3. • Negotiation of ROHC 0-byte profile would be done via PPP. • Only one 0-byte profile is negotiated to support model 2 (Hybrid VoIP) and model 3 (Full VoIP). • CDMA2000 specific indications could also be used to indicate to the PDSN the MS capabilities. • PDSN would support ROHC and through a single 0-byte profile either or both VoIP models (I.e, model 2 and 3) are supported.

  29. Compliance to requirements of ROHC-0-byte and GEHCO • No need, GEHCO and ROHC-0-byte target two different voice over IP implementation models in the MS (Hybrid model and true end-to-end model). Both models should be supported by the PDSN. • Both models define a 0-byte profile based on ROHC framework. • From a PDSN view point, both VoIP models would be provided through a single 0-byte profile. However, the latest GEHCO draft which defines GEHCO as a 0-byte profile based on ROHC contains some technical inaccuracies with respect to the operations of ROHC.

  30. Conclusion • Voice over IP Model 2 (GEHCO arch or Hybrid MS) and model 3 (true VoIP arch) use 0-byte profile for voice over IP defined within the ROHC framework -> ROHC shall be supported in PDSN. • From a PDSN view point, a single 0-byte profile should be negotiated for either VoIP models (EVRC on the CDMA2000 interface (legacy MS) and EVRC as an IP application (ALLIP MS). • Complexity: Clean and common implementation in the PDSN based on ROHC framework to support simultaneously two possible voice over IP models .

  31. References • [1] ROHC: Carsten Bormann (ed.) et al., "RObust Header Compression (ROHC)", RFC 3095 (last call) • [2] ROHC over PPP: Carsten Bormann, "ROHC over PPP", (draft-ietf-rohc-over-ppp-01.txt) • http://www.dmn.tzi.org/ietf/rohc/draft-ietf-rohc-over-ppp-01.txt • [3] GEHCO: • ALLIP-20000608-012, • P00_20000918_006_GEHCO_clarifications, • draft-mccann-rohc-gehcoarch-00.txt, • draft-hiller-rohc-gehco-00.txt, • P00-20010115-008_LUC_deffered_msgs

More Related