1 ericsson overview of 0-byte rohc and voice over ip models

1 Ericsson

Overview of 0-byte ROHC and

Voice over IP models

Notice2000 Telefonaktiebolaget LM Ericsson. The information contained in this contribution is provided for the sole purposeof promoting discussion within the Technical Specifcation Groups of 3GPP2 and is not binding on Ericsson, Inc.Ericsson, Inc. reserves the right to add to, amend or withdraw the statements contained herein.

The contributor grants a free, irrevocable license to 3GPP2 and its Organizational Partners to incorporate text or othercopyrightable material contained in the contribution and any modifications thereof in the creation of 3GPP2publications; tocopyright and sell in Organizational Partner's name any Organizational Partner's standards publication even though itmay include portions of the contribution; and at the Organizational Partner's sole discretion to permit others toreproduce in whole or in part such contributions or the resulting Organizational Partner's standards publication. Thecontributor must also be willing to grant licenses under such contributor copyrights to third parties on reasonable, non-discriminatory terms and conditions, as appropriate.

2 Ericsson

3GPP2 Requirements - Overview

Requirements are divided in 3 categories:

Impact on Internet Infrastructure Efficiency/Complexity 3GPP2 Specific Requirements

3 Ericsson

Impact on Internet InfrastructureTransparency - 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 Ericsson

Impact on Internet InfrastructureMobile 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 Ericsson

Efficiency/ComplexitySpectral Efficiency

Minimize Error Propagation

Handling of Handover events

Minimal Processing delay

6 Ericsson

Efficiency/ComplexityMultiple Links

Unidirectional Links

No increase in Residual Errors

Genericness

7 Ericsson

3GPP2 Specific RequirementsMinimal Impact on Air InterfaceMinimal Core Access Network impactImpact on Future Protocol changesCo-existence with other Header Compression schemesMinimal Complexity in the MT

8 Ericsson

MAC0-Byte

MAC

0-Byte

0-Byte within the CDMA 2000 ArchitectureWWW

HTTP

VIDEO CODEC

SIGNALLING

RTP

SPEECH CODEC

UDP TCP

IP

LINK LAYER

LINK LAYER

PL

IP

R-P

PL

R-P

PHYSICAL LAYERPLAIRLINK

LAC

AIRLINK

LAC

IP

PPP

ROHC

PPP

ROHC

0-Byte 0-Byte

MN BSC/PCF PDSN

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:

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 Ericsson

0-Byte Initialization

MN BSC/PCF PDSN

IS 2000 OriginationSERVICE_OPTION = e.g.‘XX Speech over IP’’

Establishment ofR-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 instancesis associated to one R-P instance

PPP

11 Ericsson

BSC/PCF

0-Byte Negotiation

MN PDSN

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | IP-Compression-Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAX_CID | MRRU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAX_HEADER | suboptions... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

•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 Ericsson

0-Byte Negotiation (Continue)

PROFILES suboption 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Profiles... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

MN BSC/PCF PDSN

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 Ericsson

0-Byte Parameter Setting

CompressorDecompressor

• 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

HH H H H

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Add-CID | IR type | CID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0-Byte | CRC | 0-Byte Specific Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

14 Ericsson

0-Byte Context InitializationCompressorDecompressor

• 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)

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Payload / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

PP PPP

0-Byte Packets

15 Ericsson

PP P P P

0-Byte Scheme During Normal OperationCompressorDecompressor

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 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 usedto send compressedheaders

P P P PHP

40

80

170

New Data Rate after Compressed Header

17 Ericsson

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 0 0 0 0 0 1 1 1 0 0 0 0 0 1 1 1 0 0 0 0 0|0 1| Seq Number| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | CRC | Payload / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

PP P PH P

…Sending Non-0-Byte Compressed Headers to Periodically Verify Context (Continue)


• 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 Ericsson

Packet Loss/Packet Delay Handling

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 0 0 0 0 0 1 1 1 0 0 0 0 0 1 1 1 0 0 0 0 0|0 1| Seq Number| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | CRC | Payload / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

P PPH


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 Ericsson

0-Byte and Multimedia

data block

ROHC0-Byte Profile

ROHC Profile 1

ROHC Profile 2

ROHCSignaling Profile

data blockdata block

VOIP Stream

dtch, sr_id=1

Null RLPInstance

0-ByteComponent

Regular RLPInstance

data block

dtch, sr_id=2

CID=0 CID=0 CID=0 ..15

...

CID=0 ..15

...

dtch, sr_id=3

Regular RLPInstance

dtch, sr_id=4

Regular RLPInstance

Data Stream Video Stream Signaling Stream

dsch, sr_id=0

data block

CID=0..15

data block data block data block CRC

data block

CRC data block CRC

MultiplexSublayer

20 Ericsson

Capacity Calculation Assumption

eP fPqP hP

1 1w Pe

2 2w Pe

1 1w Pq

3 3w Pe

2 2w Pq

1 1w Ph

21 Ericsson

Capacity RequirementsEVRC

(Mode 0) 0-Byte HC

EVRC (Mode 0)

no HC

SMV (Mode 1) 0-

Byte HC

SMV (Mode 1)

no HC

SMV (Mode2) 0-

Byte HC

SMV (Mode 2)

no HCFull(9.6) 0.69029092 0.6894 0.3422588 0.3391 0.12162745 0.1163Haff(4.8) 0.06310822 0.0635 0.2606413 0.2621 0.47226814 0.47591/4(2.4) 0.00199657 0 0.1128593 0.1117 0.1092334 0.10791/8(1.2) 0.24460429 0.2471 0.2802407 0.2831 0.29687101 0.2999

Average Data Rate 7.22802921 7.21956 5.1645717 5.141807 4.05291594 4.01964

% of Required Extra

Capacitywith after HC 0.11730928 0.442732 0.82783396

Context Update Rate (%) (Periodic

verification load + Header

Update load) 1.01

EVRC (Mode 0) 0-

Byte HC

EVRC (Mode 0)

no HC

SMV (Mode 1) 0-

Byte HC

SMV (Mode 1)

no HC

SMV (Mode2) 0-

Byte HC

SMV (Mode 2)

no HCFull(9.6) 0.69117302 0.6894 0.3453863 0.3391 0.12690215 0.1163Haff(4.8) 0.06272032 0.0635 0.259197 0.2621 0.46867224 0.47591/4(2.4) 0.00397337 0 0.1140071 0.1117 0.1105536 0.10791/8(1.2) 0.24213329 0.2471 0.2774097 0.2831 0.29387201 0.2999


% of Required Extra




Update load) 2.01

22 Ericsson

Capacity Requirements

EVRC (Mode 0) 0-

Byte HC

EVRC (Mode 0)

no HC

SMV (Mode 1) 0-

Byte HC

SMV (Mode 1)

no HC

SMV (Mode2) 0-

Byte HC

SMV (Mode 2)

no HCFull(9.6) 0.69029092 0.6894 0.3422588 0.3391 0.12162745 0.1163Haff(4.8) 0.06310822 0.0635 0.2606413 0.2621 0.47226814 0.47591/4(2.4) 0.00199657 0 0.1128593 0.1117 0.1092334 0.10791/8(1.2) 0.24460429 0.2471 0.2802407 0.2831 0.29687101 0.2999


% of Required Extra




Update load) 1.01

EVRC (Mode 0) 0-

Byte HC

EVRC (Mode 0)

no HC

SMV (Mode 1) 0-

Byte HC

SMV (Mode 1)

no HC

SMV (Mode2) 0-

Byte HC

SMV (Mode 2)

no HCFull(9.6) 0.6902821 0.6894 0.3422275 0.3391 0.1215747 0.1163Haff(4.8) 0.0631121 0.0635 0.2606557 0.2621 0.4723041 0.47591/4(2.4) 0.0019768 0 0.1128478 0.1117 0.1092202 0.10791/8(1.2) 0.244629 0.2471 0.280269 0.2831 0.296901 0.2999


% of Required Extra




Update load) 1

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

BSC

SIP server

MGW

SIP clientA1

A2

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)

SIPServer

MGW

MSC

BSC

PPP (SIP)PPP/RLP

SIP/IP

EVRC EVRC

EVRC/IP

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 NullRLP

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 layersNull RLP

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

1 ericsson overview of 0-byte rohc and voice over ip models

Documents