Date post: | 03-Jan-2016 |
Category: |
Documents |
Upload: | derrick-lang |
View: | 222 times |
Download: | 1 times |
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)
CompressorDecompressor
• 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
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 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
Average Data Rate 7.23641457 7.21956 5.1871107 5.141807 4.08586242 4.01964
% of Required Extra
Capacitywith after HC 0.23345707 0.8810805 1.64747153
Context Update Rate (%) (Periodic
verification load + Header
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
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.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
Average Data Rate 7.22794536 7.21956 5.1643463 5.141807 4.05258648 4.01964
% of Required Extra
Capacitywith after HC 0.1161478 0.4383485 0.81963758
Context Update Rate (%) (Periodic
verification load + Header
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