< draft-pelletier-rohc-rtp-llarohc-cdma2000-00.txt   draft-pelletier-rohc-rtp-llarohc-cdma2000-01.txt >
Network Working Group Ghyslain Pelletier, Ericsson Network Working Group Ghyslain Pelletier, Ericsson
INTERNET-DRAFT Sweden INTERNET-DRAFT Sweden
Expires: November, 2001 May 6, 2001 Expires: January, 2002 July 20, 2001
Link-Layer Assisted ROHC Over CDMA2000 Link-Layer Assisted ROHC Over CDMA2000
<draft-pelletier-rohc-rtp-llarohc-cdma2000-00.txt> <draft-pelletier-rohc-rtp-llarohc-cdma2000-01.txt>
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line 7 skipping to change at page 2, line 7
cellular links. The purpose of this document is to apply this profile cellular links. The purpose of this document is to apply this profile
for efficient, transparent and robust header compression while using for efficient, transparent and robust header compression while using
the CDMA2000 link layer characteristics optimally. Its objective is the CDMA2000 link layer characteristics optimally. Its objective is
to remain flexible with regards to robustness, complexity and to remain flexible with regards to robustness, complexity and
spectral efficiency considerations. In addition to [LLAROHC] it spectral efficiency considerations. In addition to [LLAROHC] it
defines logic, parameters and procedures for the use of header-free defines logic, parameters and procedures for the use of header-free
packets over CDMA2000 links. packets over CDMA2000 links.
Table of contents Table of contents
1. Introduction....................................................2 1. Introduction....................................................
2. Terminology..................................................... 2. Terminology.....................................................
3. Overview of the link-layer assisted profile over CDMA2000 links. 3. Overview of the link-layer assisted profile over CDMA2000 links.
3.1. CDMA2000 system overview..................................... 3.1. CDMA2000 system overview.....................................
3.1.1. CDMA2000 architecture overview....................... 3.1.1. CDMA2000 architecture overview.......................
3.1.2. CDMA2000 link layer characteristics.................. 3.1.2. CDMA2000 link layer characteristics..................
3.1.3. Typical CDMA2000 voice encoder rates................. 3.1.3. Typical CDMA2000 voice encoder rates.................
3.2. Functionality provided by the link layer to LLAROHC......... 3.2. Functionality provided by the link layer to LLAROHC.........
4. Link-Layer Assisted ROHC over CDMA2000 links..................... 4. Link-Layer Assisted ROHC over CDMA2000 links.....................
4.1. Operating assumptions....................................... 4.1. Operating assumptions.......................................
4.2. Architecture overview....................................... 4.2. Architecture overview.......................................
4.3. Initialization.............................................. 4.3. Initialization..............................................
4.3.1. Header Compression Setup.. ........................... 4.3.1. Header compression setup.. ...........................
4.3.2. Context IDentifiers (CID) ............................ 4.3.2. Agreement on optimistic approach......................
4.3.3. Packet sizes.......................................... 4.3.3. Context IDentifiers (CID) ............................
4.3.4. Padding............................................... 4.3.4. Packet sizes..........................................
4.3.5. Padding...............................................
4.3.6. Fast Context Initialization...........................
4.4. LLA MAC logic at the compressor side........................ 4.4. LLA MAC logic at the compressor side........................
4.4.1. Reception of packets from the LLAROHC RTP compressor.. 4.4.1. Reception of packets from the LLAROHC RTP compressor..
4.4.2. Sending the NHP packet................................ 4.4.2. Sending the NHP packet................................
4.4.3. Sending the RHP packet................................ 4.4.3. Sending the RHP packet................................
4.4.4. Sending the CCP packet................................ 4.4.4. Sending a CCP or a CSP packet.........................
4.4.5. Assembling the packet for delivery.................... 4.4.5. Assembling the packet for delivery....................
4.4.6. Handling packets larger than MAX_SIZE_ALLOWED......... 4.4.6. Handling packets larger than MAX_SIZE_ALLOWED.........
4.4.7. Handling of ROHC segmented packets.................... 4.4.7. Handling of ROHC segmented packets....................
4.4.8. False sequence detection for NHP packets.............. 4.4.8. False sequence detection for NHP packets..............
4.4.9. Delayed packet reception.............................. 4.4.9. Delayed packet reception..............................
4.4.10.Congestion handling................................... 4.4.10.Congestion handling...................................
4.5. LLA MAC logic at the decompressor side...................... 4.5. LLA MAC logic at the decompressor side......................
5. Implementation Guidelines....................................... 5. Implementation Guidelines.......................................
5.1. Periodic context validation and speech bursts .............. 5.1. Periodic context validation and speech bursts ..............
5.2. Handling the non-octet aligned physical frame format........
6. Security considerations......................................... 6. Security considerations.........................................
7. Acknowledgements................................................ 7. Acknowledgements................................................
8. References...................................................... 8. References......................................................
9. Author's addresses.............................................. 9. Author's addresses..............................................
1. Introduction 1. Introduction
skipping to change at page 4, line 4 skipping to change at page 4, line 15
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
BER Bit Error Rate BER Bit Error Rate
BSC Base Station Controller BSC Base Station Controller
CCP Context Check Packet as defined in [LLAROHC] CCP Context Check Packet as defined in [LLAROHC]
CRC Cyclic Redundancy Check CRC Cyclic Redundancy Check
ECCP Extended CCP as defined in [LLAROHC] CSP Context Synchronization Packet, as defined in [LLAROHC]
HC Header Compressor HC Header Compressor
HD Header Decompressor HD Header Decompressor
LCP PPP Link Control Protocol (defined in RFC 1661) LCP PPP Link Control Protocol (defined in RFC 1661)
LLA MAC LLAROHC adaptation to the CDMA2000 MAC layer LLA MAC LLAROHC adaptation to the CDMA2000 MAC layer
LLAROHC Link Layer Assisted ROHC profile LLAROHC Link Layer Assisted ROHC profile
MAC Media Access Control MAC Media Access Control
MSB Most Significant Bit MSB Most Significant Bit
MN Mobile Node MN Mobile Node
NHP No Header Packet NHP No Header Packet
NCP PPP Network Control Protocol (defined in RFC 1661) NCP PPP Network Control Protocol (defined in RFC 1661)
skipping to change at page 4, line 52 skipping to change at page 5, line 28
3.1. CDMA2000 system overview 3.1. CDMA2000 system overview
This section provides a simplified overview of the CDMA2000 system This section provides a simplified overview of the CDMA2000 system
and its characteristics relevant to header compression. and its characteristics relevant to header compression.
3.1.1 CDMA2000 architecture overview 3.1.1 CDMA2000 architecture overview
Figure 1 shows the protocol stack view of the IP traffic path in the Figure 1 shows the protocol stack view of the IP traffic path in the
CDMA2000 system with a LLAROHC header compression implementation. CDMA2000 system with a LLAROHC header compression implementation.
As shown in figure 1, within a CDMA2000 system it cannot be assumed
that the ROHC RTP implementation will be physically co-located with
the synchronous radio bearer implementation, i.e. it must be assumed
that the base station is remote from the ROHC RTP compressor. This
has significant implications on the introduction of a header
compression system that makes specific use of the properties of the
synchronized bearer.
The module implemented close to the synchronous bearer will be
referred to as the LLA MAC, i.e. the LLAROHC to CDMA2000 MAC layer
adaptation module.
MN BSC PDSN MN BSC PDSN
+-------------+ +-----+ +-------------+ +-----+
| RTP | | RTP | | RTP | | RTP |
+-------------+ +-----+ +-------------+ +-----+
| UDP | | UDP | | UDP | | UDP |
+-------------+ +---------------------+ +-----+ +-------------+ +---------------------+ +-----+
| IP | | IP | | IP | | IP | | IP | | IP |
+-------------+ +--------------++-----+ +-----+ +-------------+ +--------------++-----+ +-----+
| ROHC RTP | | ROHC RTP || | | | | ROHC RTP | | ROHC RTP || | | |
+-------------+ +--------------+| | | | +-------------+ +--------------+| | | |
skipping to change at page 5, line 39 skipping to change at page 5, line 53
+-------------+ +----------++---+ +--------------+| | | | +-------------+ +----------++---+ +--------------+| | | |
| LLA MAC | | LLA MAC ||GRE| | GRE || | | | | LLA MAC | | LLA MAC ||GRE| | GRE || | | |
+-------------+ +----------++---+ +--------------+| | | | +-------------+ +----------++---+ +--------------+| | | |
| MAC | | MAC ||IP | | IP || | | | | MAC | | MAC ||IP | | IP || | | |
+-------------+ +----------++---+ +--------------++-----+ +-----+ +-------------+ +----------++---+ +--------------++-----+ +-----+
| AIR LINK |==| AIR LINK ||PL |==|PHYSICAL LINK || PL |==| PL | | AIR LINK |==| AIR LINK ||PL |==|PHYSICAL LINK || PL |==| PL |
+-------------+ +----------++---+ +--------------++-----+ +-----+ +-------------+ +----------++---+ +--------------++-----+ +-----+
Fig.1: Stack view of IP traffic path in CDMA2000 system with LLAROHC Fig.1: Stack view of IP traffic path in CDMA2000 system with LLAROHC
As shown in the figure, within a CDMA2000 system it cannot be assumed
that the ROHC RTP implementation will be physically co-located with
the synchronous radio bearer implementation, i.e. it must be assumed
that the base station is remote from the ROHC RTP compressor. This
has significant implications on the introduction of a header
compression system that makes specific use of the properties of the
synchronized bearer.
The module implemented close to the synchronous bearer will be
referred to as the LLA MAC, i.e. the LLAROHC to CDMA2000 MAC layer
adaptation module.
LLACDMA2K represents the additional functionality required within the LLACDMA2K represents the additional functionality required within the
LLAROHC RTP implementation, while the LLA MAC contains most of the LLAROHC RTP implementation, while the LLA MAC contains most of the
functionality specific to the LLAROHC implementation for CDMA2000. functionality specific to the LLAROHC implementation for CDMA2000.
3.1.2. CDMA2000 link layer characteristics 3.1.2. CDMA2000 link layer characteristics
The channel used in CDMA2000 for circuit-switched voice traffic is The channel used in CDMA2000 for circuit-switched voice traffic is
characterized by: characterized by:
- No link layer retransmissions - No link layer retransmissions
skipping to change at page 6, line 48 skipping to change at page 7, line 22
leading sequence which consist of already existing ROHC padding. leading sequence which consist of already existing ROHC padding.
Although this approach implies some additional overhead, the need for Although this approach implies some additional overhead, the need for
a leading sequence is constrained to the RRP packet type, which is a leading sequence is constrained to the RRP packet type, which is
deemed to be used very seldom in comparison to the NHP traffic during deemed to be used very seldom in comparison to the NHP traffic during
a typical VoIP connection. Furthermore, there is currently no other a typical VoIP connection. Furthermore, there is currently no other
identified alternate mechanism within the CDMA2000 system to provide identified alternate mechanism within the CDMA2000 system to provide
this functionality. this functionality.
The sequence number is replaced by packet loss detection at the MAC The sequence number is replaced by packet loss detection at the MAC
layer under the ROHC decompressor through the interface specified in layer under the ROHC decompressor through the interface specified in
[LLAROHC section 4.4]. This is done by using explicit detection of [LLAROHC section 4.2.2]. This is done by using explicit detection of
damaged packets over the physical medium from the link layer and damaged packets over the physical medium from the link layer and
through the use of the CCP packet as an indication of packet loss through the use of the CCP packet as an indication of packet loss
before the compressor. before the compressor.
The CRC functionality is replaced by this same packet loss detection The CRC functionality is replaced by this same packet loss detection
coupled with the fact that no errors can damage a header which is not coupled with the fact that no errors can damage a header which is not
sent for the case where header-free packets are used. However, to sent for the case where header-free packets are used. However, to
detect also unexpected errors, periodical context checks should also detect also unexpected errors, periodical context checks should also
be performed. be performed.
skipping to change at page 8, line 7 skipping to change at page 8, line 30
Link layer channel Link layer channel
The channel used to transport header compression traffic is assumed The channel used to transport header compression traffic is assumed
to not introduce any additional overhead, for example for to not introduce any additional overhead, for example for
reliability or for any link layer framing additional to the one reliability or for any link layer framing additional to the one
already present at the physical layer. already present at the physical layer.
4.2. Architecture overview 4.2. Architecture overview
In [LLAROCH section 4.3], a generic interface between the LLAROHC RTP Figure 2 shows the various components needed for an implementation of
compressor and the lower layer is specified. The CDMA2000 link layer the LLAROHC profile in CDMA2000. It is separated into layers as
does not currently provide all the functionality needed to fulfill defined in [ROHC RTP], [LLAROCH] and this document [this].
this specification. New functionality, represented by the LLA MAC, is
therefore necessary and is here described in [section 4.4]. It uses
the available functionality from the CDMA2000 MAC layer and may be
implemented together with the LLAROHC compressor as a single entity,
although this is not required and not always possible in all CDMA2000
systems.
Similarly, [LLAROCH section 4.4] describes a generic interface
between the lower layers and the LLAROHC RTP decompressor. The
necessary functionality is also here described in [section 4.5]. It
should be implemented together with the ROHC decompressor as a single
entity to minimize complexity within a mobile terminal.
| |
+ +
+---------------------+ +---------------------+ +---------------------+ +---------------------+
[ROHC RTP] | ROHC RTP HC | | ROHC RTP HC | [ROHC RTP] | ROHC RTP HC | | ROHC RTP HD |
+---------------------+ +---------------------+ +---------------------+ +---------------------+
[LLAROCH] | LLAROHC Profile | | LLAROHC Profile | [LLAROCH] | LLAROHC Profile | | LLAROHC Profile |
+=====================+ +=====================+ +=====================+ +=====================+
[LLAROCH] | ROHC-LL | | LL-ROHC | [LLAROCH] | ROHC-LL | | LL-ROHC |
[this] | interface | | interface | [this] | interface | | interface |
+=====================+ +=====================+ +=====================+ +=====================+
[this] | LLA MAC | | LLA MAC | [this] | LLA MAC | | LLA MAC |
| implementation | | implementation | | implementation | | implementation |
+---------------------+ +---------------------+ +---------------------+ +---------------------+
| CDMA2000 MAC Layer | | CDMA2000 MAC Layer | | CDMA2000 MAC Layer | | CDMA2000 MAC Layer |
+=====================+ +=====================+ +=====================+ +=====================+
| | | |
+------>---- CHANNEL ---->-----+ +------>---- CHANNEL ---->-----+
Fig.2: Overview of the LLAROHC over CDMA2000 implementation Fig.2: Overview of the LLAROHC over CDMA2000 implementation
Figure 2 shows the various components needed for an implementation of In [LLAROCH section 4.2.1], a generic interface between the LLAROHC
the LLAROHC profile in CDMA2000. It is separated into layers as RTP compressor and the lower layer is specified. The CDMA2000 link
defined in [ROHC RTP], [LLAROCH] and this document [this]. layer does not currently provide all the functionality needed to
fulfill this specification. New functionality, represented by the LLA
MAC, is therefore necessary and is here described in [section 4.4].
It uses the available functionality from the CDMA2000 MAC layer and
may be implemented together with the LLAROHC compressor as a single
entity, although this is not required and not always possible in all
CDMA2000 systems.
Similarly, [LLAROCH section 4.2.2] describes a generic interface
between the lower layers and the LLAROHC RTP decompressor. The
necessary functionality is also here described in [section 4.5]. It
should be implemented together with the ROHC decompressor as a single
entity to minimize complexity within a mobile terminal.
4.3. Initialization 4.3. Initialization
This section describes profile specific initialization steps for the This section describes profile specific initialization steps for the
LLAROHC instances. This section also specifies how parameters are LLAROHC instances. This section also specifies how parameters are
set. set.
4.3.1 Header Compression Setup 4.3.1 Header compression setup
[PPP] may be used for the negotiation of ROHC parameters over the [PPP] may be used for the negotiation of ROHC parameters over the
connection setup for header compression. Initialization of ROHC per connection setup for header compression. Initialization of ROHC per
channel parameters may be done as described in [ROHC section 5.1.1] channel parameters may be done as described in [ROHC section 5.1.1]
and [ROHC PPP]. Once the LLAROHC profile has been identified by the and [ROHC PPP].
compressor and the decompressor, profile specific parameters must be
set using ROHC IR packets over the channel which is assumed not to
introduce any overhead.
The physical establishment and release of the connection used for The physical establishment and release of the connection used for
header compression traffic is outside the scope of this document. header compression traffic is outside the scope of this document.
4.3.2. Context Identifiers (CID) 4.3.2. Agreement on optimistic approach
The principle behind the agreement between compressor and
decompressor regarding the usage of the optimistic approach must be
defined and the LLA decompressor MUST use the optimistic approach
knowledge to detect possible context loss events [LLAROHC].
The compressor MUST send a fixed default value of three consecutive
updates when a context change occurs. The decompressor MUST
invalidate the context in the event of consecutive packet losses
equal to or larger than this default value.
4.3.3. Context Identifiers (CID)
The connection for LLAROHC traffic MUST be configured using SMALL The connection for LLAROHC traffic MUST be configured using SMALL
CIDS and CID=0 MUST be reserved for LLAROHC traffic. This is CIDS and CID=0 MUST be reserved for LLAROHC traffic. This is
necessary to omit the CID field in the ROHC header and still allow necessary to omit the CID field in the ROHC header and still allow
identification of the NHP packets. identification of the NHP packets.
4.3.3. Packet sizes 4.3.4. Packet sizes
The PREFERRED PACKET_SIZES parameter MUST be set according to the The PREFERRED PACKET_SIZES parameter MUST be set according to the
CDMA2000 link fixed frame sizes, i.e. the list provided MUST be CDMA2000 link fixed frame sizes, i.e. the list provided MUST be
[16,40,80,168,176] and 176 MUST be for NHP packets only.
The size of 168 may be produced by the LLAROHC compressor from a
typical CDMA2000 codec [EVRC RTP] operating at a speech rate smaller
than the full rate (< 171 bits) and the presence of the IP/UDP/RTP
compressed header.
The size of 176 may be produced for the case of the codec operating [16,40,80,168,176] and 176 MUST be for NHP packets only [see section
at full rate where 5 padding bits are added to obtain octet 5.2].
alignment. This will only be delivered as an NHP packet by the
LLAROHC compressor.
The LARGE_PACKET_ALLOWED parameter MAY be set to true if large The LARGE_PACKET_ALLOWED parameter MAY be set to true if large
packets with headers are to be treated according to [section 4.4.6]. packets with headers are to be treated according to [section 4.4.6].
The resulting effect will be that proper context will be maintained The resulting effect will be that proper context will be maintained
at the decompressor to the expense of dropping the packet. at the decompressor to the expense of dropping the packet.
The LARGE_PACKET_ALLOWED parameter MAY be set to false and packets The LARGE_PACKET_ALLOWED parameter MAY be set to false and packets
larger than the maximum size specified using the PREFERED PACKET larger than the maximum size specified using the PREFERED PACKET
SIZES [LLAROHC, section 5.1.1] parameter will be transmitted as SIZES [LLAROHC section 5.1.1] parameter will be transmitted as
segmented packets according to [section 4.4.7]. These packets will be segmented packets according to [section 4.4.7]. These packets will be
delivered as segmented ROHC packets. delivered as segmented ROHC packets.
4.3.4. Padding 4.3.5. Padding
The ALWAYS_PAD parameter MUST be set in order to request that all RHP The ALWAYS_PAD parameter MUST be set in order to request that all RHP
packets be padded. A CDMA2000 LLA MAC implementation uses one or more packets be padded. A CDMA2000 LLA MAC implementation uses one or more
octets as the leading sequence to identify RHP packets. Padding does octets as the leading sequence to identify RHP packets. Padding does
not introduce new complexity since it is already part of any ROHC RTP not introduce new complexity since it is already part of any ROHC RTP
implementation [ROHC section 5.2]. implementation [ROHC section 5.2].
4.3.6. Fast Context Initialization
Initial establishment of the decompressor context SHOULD be performed
using the CSP, as the initial packets will always be larger than
MAX_SIZE_ALLOWED, according to procedure b) of [section 4.4.6].
4.4. LLA MAC logic at the compressor side 4.4. LLA MAC logic at the compressor side
This section describes the logic to be used inside the implementation This section describes the logic to be used inside the implementation
of the LLA MAC module on the compressor side. This module receives of the LLA MAC module on the compressor side. This module receives
parameters from the ROHC RTP compressor as stated in [LLAROHC section parameters from the ROHC RTP compressor as stated in [LLAROHC section
4.3]. It always receive an RHP with an indication of segmentation, a 4.2.1]. It always receive an RHP with an indication of segmentation,
CCP, an RTP Sequence Number and possibly an NHP. Because the presence a CCP, an RTP Sequence Number and possibly an NHP. Because the
or absence of the NHP packet is part of the logic at the LLA MAC, all presence or absence of the NHP packet is part of the logic of the LLA
parameters corresponding to the same packet to be transmitted MUST be MAC module, all parameters corresponding to the same packet to be
ignored at the LLA MAC until they are all received reliably, as transmitted MUST be ignored by the LLA MAC until they are all
described in [section 4.6]. received reliably. How these parameters are transmitted between the
compressor and the LLA MAC module is an implementation issue and is
therefore outside the scope of this document.
4.4.1. Reception of packets from LLAROHC RTP header compressor 4.4.1. Reception of packets from LLAROHC RTP header compressor
The following steps MUST be performed by the LLA MAC upon reception The following steps MUST be performed by the LLA MAC upon reception
of a packet delivery from the ROHC header compressor: of a packet delivery from the ROHC header compressor:
a. Keep a copy of CCP and RTP SN a. Keep a copy of CCP and RTP SN
The LLA MAC MUST always keep a copy of the received CCP with the The LLA MAC MUST always keep a copy of the received CCP with the
corresponding RTP Sequence Number. corresponding RTP Sequence Number.
b. Decide which packet needs to be sent b. Decide which packet needs to be sent
If the Context Check Counter is starved, an RHP packet SHOULD be If the Context Check Counter is starved, an RHP packet SHOULD be
sent according to [section 4.4.3], otherwise refer to section sent according to [section 4.4.3], otherwise refer to section
[LLAROHC Section 4.3]. [LLAROHC Section 4.2.1].
4.4.2. Sending the NHP packet 4.4.2. Sending the NHP packet
If it was determined that the NHP packet should be sent, then the If it was determined that the NHP packet should be sent, then the
following MUST be performed: following MUST be performed:
a. Check for false Leading Sequence according to [section 4.4.8] a. Check for false Leading Sequence according to [section 4.4.8]
b. Assemble the packet according to [section 4.4.5] b. Assemble the packet according to [section 4.4.5]
c. Decrement the Context Check Counter c. Decrement the Context Check Counter
skipping to change at page 11, line 7 skipping to change at page 11, line 36
following MUST be performed: following MUST be performed:
a. Verification of RHP segmentation indicator a. Verification of RHP segmentation indicator
If an indication of segmentation for the RHP packet was received, If an indication of segmentation for the RHP packet was received,
then the segmented packet is sent as described in [section 4.4.7]. then the segmented packet is sent as described in [section 4.4.7].
Otherwise, the packet is assembled according to [section 4.4.5]. Otherwise, the packet is assembled according to [section 4.4.5].
b. Reset the Context Check Counter b. Reset the Context Check Counter
4.4.4. Sending the CCP packet 4.4.4. Sending a CCP or a CSP packet
If it was determined that the CCP packet will be sent, then the
following MUST be performed:
a. Set the repair (R) bit
The R bit is set to R=0 for the CCP. The R bit is set to R=1 when
using the extended CCP (ECCP) format.
Note that the ECCP contains repair information by carrying fields If it was determined that a CCP or a CSP packet will be sent, then
which will maintain proper context at the decompressor, as the following MUST be performed:
described in [LLAROHC].
b. Assemble the packet a. Assemble the packet
This is done according to section 4.4.5. As the CCP and its This is done according to section 4.4.5. As the CCP and the CSP are
extended format is an RHP packet, a leading sequence will be added both RHP packets, a leading sequence will be added during assembly
during assembly to allow the LLA MAC module at the decompressor to allow the LLA MAC module at the decompressor side to detect the
side to detect the presence of the header. Because codecs may presence of the header. Because codecs may generate valid 16 bits
generate valid 16 bits payload sent as NHP and because of the risk payload sent as NHP and because of the risk of collision with the
of collision with the leading sequence [section 4.4.8] or the leading sequence [section 4.4.8] or the packet type octet, this
packet type octet, this unfortunately forces a rate transition when unfortunately forces a rate transition when sending a CCP packet.
sending a CCP packet.
It is noted that CDMA2000 defines an empty frame when no speech It is noted that CDMA2000 defines an empty frame when no speech
data is available for sending. This frame is referred to as a data is available for sending. This frame is referred to as a
filler frame and has a size of 16 bits, all bits set to 1. As filler frame and has a size of 16 bits, all bits set to 1. As
LLAROHC requires that no extra packet be artificially inserted by LLAROHC requires that no extra packet be artificially inserted by
the lower layers in the header compression flow, the LLA MAC the lower layers in the header compression flow, the LLA MAC
implementation will make a CCP packet available to prevent the implementation will make a CCP packet available to prevent the
generation of a filler frame as stated in [section 4.4.9]. generation of a filler frame as stated in [section 4.4.9].
c. Reset the Context Check Counter b. Reset the Context Check Counter
4.4.5. Assembling the packet for delivery 4.4.5. Assembling the packet for delivery
If the packet cannot fit is larger MAX_SIZE_ALLOWED, packets are If the packet cannot fit is larger MAX_SIZE_ALLOWED, packets are
handled as described in [section 4.4.6]. If the packet delivered is handled as described in [section 4.4.6]. If the packet delivered is
of size 168 bits [section 4.3.3], the packet must be padded to fit of size 168 bits, the packet must be padded to fit the physical frame
the physical frame size of 171 bits. In the case where the packet size of 171 bits. In the case where the packet delivered is of size
delivered is of size 176 bits [section 4.3.3], then it must be 176 bits, then it must be stripped of the last 5 padding bits to fit
stripped of the last 5 padding bits to fit the physical frame of 171 the physical frame of 171 bits. Otherwise the packet already matches
bits. Otherwise the packet already matches one of the possible one of the possible physical frame size and is sent directly.
physical frame size and is sent directly.
Section 5.2 provides additional considerations regarding the non-
octet aligned nature of the CDMA2000 physical frame format.
4.4.6. Handling packets larger than MAX_SIZE_ALLOWED 4.4.6. Handling packets larger than MAX_SIZE_ALLOWED
In the case where the calculation of the packet size to be In the case where the calculation of the packet size to be
transmitted is larger than the maximum size of a physical frame, the transmitted is larger than the maximum size of a physical frame, the
implementation must decide between the two following options: implementation must decide between the two following options:
a. Segment the packet using ROHC segmentation a. Segment the packet using ROHC segmentation
This is done according to [section 4.4.7]. This is done according to [section 4.4.7].
b. Discard the packet and send the extended CCP (ECCP) b. Discard the packet and send the CSP
The packet for which the calculation of the size was made is The packet for which the calculation of the size was made is
discarded and the ECCP is sent according to [section 4.4.4]. discarded and a CSP is sent according to [section 4.4.4].
Note that this will readily repair the context at the decompressor Recall that the CSP contains repair information by carrying a ROHC
according to [LLAROHC] after detection of the packet loss signaled header which will maintain proper context at the decompressor, as
by the reception of the ECCP itself. described in [LLAROHC]. This will readily repair the context at the
decompressor after a detection of packet loss is signaled from the
reception of the CSP itself.
These two alternatives represent a tradeoff between robustness and These two alternatives represent a tradeoff between robustness and
spectral efficiency respectively. spectral efficiency respectively.
4.4.7. Handling of ROHC segmented packets 4.4.7. Handling of ROHC segmented packets
In the case where the RHP packet is to be sent and was delivered as a In the case where the RHP packet is to be sent and was delivered as a
segmented ROHC packet, an implementation MUST handle the resulting segmented ROHC packet, an implementation MUST handle the resulting
congestion as defined in [section 4.4.10]. congestion as defined in [section 4.4.10].
skipping to change at page 13, line 5 skipping to change at page 13, line 28
than the NHP MUST not be sent and an RHP MUST be sent instead. than the NHP MUST not be sent and an RHP MUST be sent instead.
4.4.9. Delayed packet reception 4.4.9. Delayed packet reception
In the event where no packets are received from the ROHC compressor In the event where no packets are received from the ROHC compressor
on time for transmission, this is handled by sending the CCP packet on time for transmission, this is handled by sending the CCP packet
of the previous packet sent which was kept by the LLA MAC instance. of the previous packet sent which was kept by the LLA MAC instance.
The CCP is sent according to [section 4.4.4] and will prevent the The CCP is sent according to [section 4.4.4] and will prevent the
artificial insertion of new packets by the link layer. artificial insertion of new packets by the link layer.
The CCP, and its extended ECCP format, MUST be interpreted as a The CCP MUST be interpreted as a packet loss by the LLA MAC at the
packet loss by the LLA MAC at the compressor side. compressor side.
4.4.10. Congestion handling 4.4.10. Congestion handling
Packet dropping might be needed to transmit a segmented ROHC packet. Packet dropping might be needed to transmit a segmented ROHC packet.
The following MAY be performed: The following MAY be performed:
a. The first segment is assembled and transmitted according to a. The first segment is assembled and transmitted according to
[section 4.4.5]. [section 4.4.5].
b. Remaining segment(s) is transmitted over the same connection in b. Remaining segment(s) is transmitted over the same connection in
subsequent time interval(s) according to [section 4.4.5], while the subsequent time interval(s) according to [section 4.4.5], while the
packet delivered by the ROHC compressor corresponding to this time packet delivered by the ROHC compressor corresponding to this time
slot is be discarded. slot is be discarded.
4.5. LLA MAC logic at the decompressor side 4.5. LLA MAC logic at the decompressor side
This section describes the logic inside the implementation of the LLA This section describes the logic inside the implementation of the LLA
MAC module at the decompressor side. This module receives the packet MAC module at the decompressor side. This module receives the packet
transmitted over the air interface from the CDMA2000 link layer and transmitted over the air interface from the CDMA2000 link layer and
delivers the following information to the ROHC HC [LLAROHC section delivers the following information to the ROHC HC [LLAROHC section
4.4]: the packet received with an indication of the presence of a 4.2.2]: the packet received with an indication of the presence of a
header or an indication of packet loss together with explicit header or an indication of packet loss together with an explicit
sequence number [section 4.7]. sequence number.
This explicit sequencing space corresponds to the received physical
frame sequence and timing. It MUST increment for each frame interval
for which a IP/UDP/RTP packet is expected. The purpose of this
explicit sequencing is to infer the number of packets that were lost,
if any, at the decompressor.
Because the packet type and the packet arrival sequencing are part of
the decompression algorithm, all parameters corresponding to the same
received packet MUST be ignored by the decompressor until they are
all received reliably. How these parameters are transmitted between
the LLA MAC module and the decompressor is an implementation issue
and is therefore outside the scope of this document.
Upon reception of a packet, the LLA MAC module MUST perform the Upon reception of a packet, the LLA MAC module MUST perform the
following operations: following operations:
a. Determination of the presence of a header a. Determination of the presence of a header
As ROHC padding is used as leading sequence, the first bits of the As ROHC padding is used as leading sequence, the first bits of the
packet received are examined to determine if a leading sequence is packet received are examined to determine if a leading sequence is
present. If present, the indicator for the presence of a header present. If present, the indicator for the presence of a header
MUST be set. MUST be set.
b. Determination of packet loss b. Determination of packet loss
The indicator of packet loss MUST be set if the packet received The indicator of packet loss MUST be set if the packet received
contains a header and the packet type is CCP or ECCP, or upon contains a header and the packet type is CCP or CSP, or upon
explicit notification from the physical link layer that the packet explicit notification from the physical link layer that the packet
was damaged. was damaged.
c. Delivery of the packet and other parameters to the ROHC HD c. Delivery of the packet and other parameters to the ROHC HD
This is done according to the interface specified in [LLAROHC This is done according to the interface specified in [LLAROHC
section 4.4] section 4.2.2]
It is considered optional to remove the padding at the LLA MAC. It is considered optional to remove the padding at the LLA MAC.
Delivery of the packet with or without the padding will be properly Delivery of the packet with or without the padding will be properly
handled by the ROHC decompressor. handled by the ROHC decompressor.
Optionally, an implementation SHOULD combine the LLA MAC with the Optionally, an implementation SHOULD combine the LLA MAC with the
ROHC implementation to reduce complexity whenever possible. ROHC implementation to reduce complexity whenever possible.
5. Implementation Guidelines 5. Implementation Guidelines
5.1. Periodic context validation and speech bursts 5.1. Periodic context validation and speech bursts
Implementations MAY delay a periodic context validation during a Implementations MAY delay a periodic context validation during a
speech burst, i.e. during a full-rate NHP train, if it is not speech burst, i.e. during a full-rate NHP train, if it is not
possible to transmit the RHP packet over the connection. There SHOULD possible to transmit the RHP packet over the connection. There SHOULD
be a maximum limit of [to be defined later] for which this validation be a maximum limit of [to be defined later] for which this validation
may be delayed and the RHP SHOULD be sent as soon as possible. may be delayed and the RHP SHOULD be sent as soon as possible.
5.2. Handling the non-octet aligned physical frame format
As seen in table 1 [section 3.1.3], the full rate frame size of the
CDMA2000 link is 171 bits. IP being octet aligned, this frame size
introduces some additional considerations. This section introduces a
solution to handle this characteristic in a generic manner not
constrained to a specific application while being optimal for the
EVRC codec.
Bit 170 is defined as the decision bit. Noting that it corresponds to
the reserved bit of the EVRC payload format [EVRC RTP], it is then
assumed that this reserved bit is set (value=1) as its default
assigned value from the EVRC standard. By considering the default
assignment of the EVRC reserved bit, NHP packets may then be used
even for the EVRC operating at full rate in order to increase the
performance of the most common expected voice application within a
CDMA2000 system.
A size of 168 bits may be produced by the LLAROHC compressor from a
typical CDMA2000 codec [EVRC RTP] operating at a speech rate smaller
than the full rate (< 171 bits) combined with the presence of the
IP/UDP/RTP compressed header.
A size of 176 bits may be produced for the case of the codec
operating at full rate where 5 padding bits are added to obtain octet
alignment. This will only be delivered as an NHP packet by the
LLAROHC compressor.
For the case where the compressed packet size is equal to or larger
than 168 bits, three different cases are identified:
a. RRP or NHP of size 168 bits
0 1 2 3 ... 164 165 166 167
+---+---+---+---+---+---+---+---+---+
| X X X X ... X X X X |
+---+---+---+---+---+---+---+---+---+
Packet Type RRP or NHP, size = 168 bits
If the header compression algorithm outputs a packet of type RRP or
NHP for which the size is equal to 168 bits, then the packet will
be expanded using 3 padding bits to match the physical frame size.
The decision bit is therefore not set. The packet is transmitted as
per [section 4.4.5].
0 1 2 3 ... 164 165 166 167 168 169 170
+---+---+---+---+---+---+---+---+---+---+---+---+
| X X X X ... X X X X | 0 0 | 0 |
+---+---+---+---+---+---+---+---+---+---+---+---+
Packet Type RRP or NHP, padded to size = 171 bits, bit 170 not set
b. NHP of size 176 bits with rear padding and bit 171 is set
0 1 2 3 ... 166 167 168 169 170 171 172 173 174 175
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| X X X X ... X X X X | 1 | 0 0 0 0 0 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Packet Type NHP with rear padding, bit 170 is set, size = 176 bits
If the header compression algorithm outputs a packet of type NHP of
size equal to 176 bits AND bit 170 is set AND bits 171-175 are
padding bits [EVRC RTP] then the NHP may be truncated to fit the
physical frame length with the value of the decision bit remaining
set. This typically corresponds to the case of the EVRC codec
operating at full rate.
0 1 2 3 ... 166 167 168 169 170
+---+---+---+---+---+---+---+---+---+---+
| X X X X ... X X X X | 1 |
+---+---+---+---+---+---+---+---+---+---+
Packet Type NHP, truncated to size = 171 bits, bit 170 is set
c. NHP of size 176 bits, bit 171 is not set OR bits 171-175 are not
rear padding
0 1 2 3 ... 166 167 168 169 170 171 172 173 174 175
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| X X X X ... X X X X | 0 | X X X X X |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Packet Type NHP not rear padded OR bit 170 not set, size = 176 bits
If header compression results in a packet of type NHP of size equal
to 176 bits AND the bit 170 is not set OR bits 171-175 are
not padding bits, then the packet MUST be treated as a packet
larger than MAX_SIZE_ALLOWED, according to [section 4.4.6].
Upon reception of a full rate frame, if the decision bit is set then
it must be interpreted as the case where 5 padding bits were stripped
from an original packet size of 176 bits before transmission.
Otherwise 3 bits of padding were added from an original packet size
of 168 bits before transmission.
6. Security considerations 6. Security considerations
The security considerations of ROHC RTP [ROHC section 7] and of the The security considerations of ROHC RTP [ROHC section 7] and of the
Link-Layer Assisted ROHC profile [LLAROHC] also apply to this Link-Layer Assisted ROHC profile [LLAROHC] also apply to this
document. document.
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Ulises Olvera-Hernandez, Francis The authors would like to thank Ulises Olvera-Hernandez, Francis
Lupien for their input regarding the CDMA2000 standards and Lars-Erik Lupien for their input regarding the CDMA2000 standards and Lars-Erik
Jonsson, Krister Svanbro for their input regarding header compression Jonsson, Krister Svanbro for their input regarding header compression
issues. issues.
8. References 8. References
[LLAROHC] L. Jonsson, G. Pelletier, "A Link-Layer Assisted ROHC [LLAROHC] L. Jonsson, G. Pelletier, "A Link-Layer Assisted ROHC
Profile for IP/UDP/RTP", February 2001, <draft-jonsson- Profile for IP/UDP/RTP", July 2001, <draft-jonsson-rohc-
rohc-ll-assisted-rtp-00.txt> ll-assisted-rtp-01.txt>
[ROHC] C. Bormann, "Robust Header Compression (ROHC)", Internet [ROHC] C. Bormann, "Robust Header Compression (ROHC)",
draft (work in progress), January 2001, <draft-ietf- RFC 3095, July 2001.
rohc-rtp-07.txt>
[ROHC PPP] C. Bormann, "ROHC over PPP", March 2001, <draft-ietf-
rohc-over-ppp-01.txt>.
[RTP-REQ] M. Degermark, "Requirements for IP/UDP/RTP Header
Compression", RFC 3096, July 2001.
[EVRC RTP] A. Li, "An RTP Payload Format for EVRC Speech",(work in
progress), July 2001 <draft-ietf-avt-evrc-05.txt>.
[VJHC] V. Jacobson, "Compressing TCP/IP Headers for Low-Speed [VJHC] V. Jacobson, "Compressing TCP/IP Headers for Low-Speed
Serial Links", RFC 1144, February 1990. Serial Links", RFC 1144, February 1990.
[IPHC] M. Degermark, B. Nordgren, S. Pink, "IP Header [IPHC] M. Degermark, B. Nordgren, S. Pink, "IP Header
Compression", RFC 2507, February 1999. Compression", RFC 2507, February 1999.
[CRTP] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers [CRTP] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers
for Low-Speed Serial Links", RFC 2508, February 1999. for Low-Speed Serial Links", RFC 2508, February 1999.
[CRTPC] M. Degermark, H. Hannu, L.-E. Jonsson, K. Svanbro, [CRTPC] M. Degermark, H. Hannu, L.-E. Jonsson, K. Svanbro,
"Evaluation of CRTP Performance over Cellular Radio "Evaluation of CRTP Performance over Cellular Radio
Networks", IEEE Personal Communications Magazine, Volume Networks", IEEE Personal Communications Magazine, Volume
7, number 4, pp. 20-25, August 2000. 7, number 4, pp. 20-25, August 2000.
[RTP-REQ] M. Degermark, "Requirements for IP/UDP/RTP Header
Compression", Internet draft (work in progress),
November 2000.
<draft-ietf-rohc-rtp-requirements-03.txt>
[ROCCO] L.-E. Jonsson, M. Degermark, H. Hannu, K. Svanbro,
"RObust Checksum-based header COmpression (ROCCO)",
Internet draft (work in progress), June 2000.
<draft-ietf-rohc-rtp-rocco-01.txt>
[IP] J. Postel, "Internet Protocol", RFC 791, September 1981. [IP] J. Postel, "Internet Protocol", RFC 791, September 1981.
[IPv6] S. Deering, R. Hinden, "Internet Protocol, Version 6 [IPv6] S. Deering, R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[UDP] J. Postel, "User Datagram Protocol", RFC 768, August [UDP] J. Postel, "User Datagram Protocol", RFC 768, August
1980. 1980.
[TCP] J. Postel, "Transmission Control Protocol", RFC 793,
September 1981.
[RTP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, [RTP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", "RTP: A Transport Protocol for Real-Time Applications",
RFC 1889, January 1996. RFC 1889, January 1996.
[ROHC PPP] C. Bormann, "ROHC over PPP", March 2001, <draft-ietf- [TCP] J. Postel, "Transmission Control Protocol", RFC 793,
rohc-over-ppp-01.txt>. September 1981.
[EVRC RTP] A. Li, "An RTP Payload Format for EVRC Speech",(work in [ROCCO] L.-E. Jonsson, M. Degermark, H. Hannu, K. Svanbro,
progress), April 2001 <draft-ietf-avt-evrc-02.txt>. "RObust Checksum-based header COmpression (ROCCO)",
Internet draft (work in progress), June 2000. <draft-
ietf-rohc-rtp-rocco-01.txt>
9. Author's addresses 9. Author's addresses
Ghyslain Pelletier Tel: +46 920 20 24 32 Ghyslain Pelletier Tel: +46 920 20 24 32
Ericsson Erisoft AB Fax: +46 920 20 20 99 Ericsson Erisoft AB Fax: +46 920 20 20 99
Box 920 Box 920
SE-971 28 Lulea SE-971 28 Lulea
Sweden EMail: ghyslain.pelletier@epl.ericsson.se Sweden EMail: ghyslain.pelletier@epl.ericsson.se
This Internet-Draft expires November 4, 2001 This Internet-Draft expires January20, 2002
 End of changes. 47 change blocks. 
131 lines changed or deleted 236 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/