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

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

3. 3 Ericsson 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. 4 Ericsson 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. 5 Ericsson Efficiency/Complexity Spectral Efficiency Minimize Error Propagation Handling of Handover events Minimal Processing delay

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

7. 7 Ericsson 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. 8 Ericsson MAC 0-Byte MAC 0-Byte 0-Byte within the CDMA 2000 Architecture WWW HTTP VIDEO CODEC SIGNALLING RTP SPEECH CODEC UDPTCP IP LINK LAYER LINK LAYER PL IP R-P PL R-P PHYSICAL LAYER PLAIRLINK LAC AIRLINK LAC IP PPP ROHC PPP ROHC 0-Byte MNBSC/PCFPDSN

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

10. 10 Ericsson 0-Byte Initialization MNBSC/PCF PDSN IS 2000 Origination SERVICE_OPTION = e.g.‘XX Speech over IP’’ Establishment of R-P towards Transparent RLP TCH Set-Up 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 PPP

11. 11 Ericsson BSC/PCF 0-Byte Negotiation MN PDSN 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) ROHC is negotiate over PPP

12. 12 Ericsson 0-Byte Negotiation (Continue) MNBSC/PCFPDSN 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. 13 Ericsson 0-Byte Parameter Setting Compressor Decompressor 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. IR Packets H HHHH

14. 14 Ericsson 0-Byte Context Initialization CompressorDecompressor 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) P PP PP 0-Byte Packets

15. 15 Ericsson P PPPP 0-Byte Scheme During Normal Operation Compressor Decompressor è 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. Transparency could 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. 16 Ericsson Sending Non-0-Byte Compressed Headers Upon Detection of Non-0-Byte Header Updates 80 40 170 bits 16 Initial Data Rate 16, 40, 80 Max header size is 155, 131, 91 bits 16, 40 Max header size is 64, 40 bits 16 Max header size is 24 bits Three possible frame rates MAY be used to send compressed headers P PP PH P 40 80 170 New Data Rate after Compressed Header

17. 17 Ericsson P PP PH P …Sending Non-0-Byte Compressed Headers to Periodically Verify Context (Continue) Compressor Decompressor 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.. Leading Sequence

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

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

20. 20 Ericsson Capacity Calculation Assumption

21. 21 Ericsson Capacity Requirements

22. 22 Ericsson Capacity Requirements

23. 23 Ericsson 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. 24 Ericsson 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. PDSN MSC IP Tel GW BSCBSC SIP server MGW SIP client A1 A2

25. 25 Ericsson 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. PDSN (IP term) SIP Server MGW MSC BSCBSC PPP (SIP) PPP/RLP SIP/IP EVRC EVRC/IP

26. 26 Ericsson 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 PPP Voice codec (EVRC) ROHC 0-byte control (GEHCO) CDMA2000 specific layers Null RLP

27. 27 Ericsson 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. Video codec (MPEG) SIPRTSP RTP UDP IP ROHC (comp/decomp) Voice codec (EVRC) PPP CDMA2000 specific layers Null RLP

28. 28 Ericsson 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. 29 Ericsson 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. 30 Ericsson 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. 31 Ericsson 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