Network Working Group Ghyslain Pelletier, Ericsson
INTERNET-DRAFT Sweden
Expires: January, 2002 July 20, 2001
Link-Layer Assisted ROHC Over CDMA2000
<draft-pelletier-rohc-rtp-llarohc-cdma2000-01.txt>
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This document is an individual submission to the IETF. Comments
should be directed to the authors.
Abstract
This document defines implementation specifications and guidelines
for the Link-Layer Assisted ROHC profile [LLAROHC] over CDMA2000
cellular links. The purpose of this document is to apply this profile
for efficient, transparent and robust header compression while using
the CDMA2000 link layer characteristics optimally. Its objective is
to remain flexible with regards to robustness, complexity and
spectral efficiency considerations. In addition to [LLAROHC] it
defines logic, parameters and procedures for the use of header-free
packets over CDMA2000 links.
Pelletier [Page 1]
INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 July 20, 2001
Table of contents
1. Introduction....................................................
2. Terminology.....................................................
3. Overview of the link-layer assisted profile over CDMA2000 links.
3.1. CDMA2000 system overview.....................................
3.1.1. CDMA2000 architecture overview.......................
3.1.2. CDMA2000 link layer characteristics..................
3.1.3. Typical CDMA2000 voice encoder rates.................
3.2. Functionality provided by the link layer to LLAROHC.........
4. Link-Layer Assisted ROHC over CDMA2000 links.....................
4.1. Operating assumptions.......................................
4.2. Architecture overview.......................................
4.3. Initialization..............................................
4.3.1. Header compression setup.. ...........................
4.3.2. Agreement on optimistic approach......................
4.3.3. Context IDentifiers (CID) ............................
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.1. Reception of packets from the LLAROHC RTP compressor..
4.4.2. Sending the NHP packet................................
4.4.3. Sending the RHP packet................................
4.4.4. Sending a CCP or a CSP packet.........................
4.4.5. Assembling the packet for delivery....................
4.4.6. Handling packets larger than MAX_SIZE_ALLOWED.........
4.4.7. Handling of ROHC segmented packets....................
4.4.8. False sequence detection for NHP packets..............
4.4.9. Delayed packet reception..............................
4.4.10.Congestion handling...................................
4.5. LLA MAC logic at the decompressor side......................
5. Implementation Guidelines.......................................
5.1. Periodic context validation and speech bursts ..............
5.2. Handling the non-octet aligned physical frame format........
6. Security considerations.........................................
7. Acknowledgements................................................
8. References......................................................
9. Author's addresses..............................................
Pelletier [Page 2]
INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 July 20, 2001
1. Introduction
Header compression is a technique to compress and transparently
decompress the header information of a packet on a per-hop basis.
Several efforts have been made to improve efficiency over bottleneck
wired links [VJHC, IPHC] as well as over low bandwidth wireless links
with high error rates [ROHC].
Existing air interfaces such as GSM and IS-95 will be used in all-IP
networks, adding new implications to the header compression issue.
These air interfaces are less flexible with radio bearers optimized
for specific payload sizes. This means that not even a single octet
of header can be added without using the next higher fixed packet
size of the link and this is obviously very costly. For the already
deployed speech vocoders, the spectrum efficiency over these links
will thus be low compared to the existing circuit switched solutions.
For deployment reasons, it is important to also achieve efficiency
with these already existing vocoders and air interfaces, such as GSM
and IS-95, with minimal effects on spectral efficiency. To this
purpose was the Link-Layer Assisted ROHC profile (LLAROHC) proposed.
[LLAROHC], extending the ROHC RTP profile, allows the sending of
header-free packets when the link layer can provide in-order
delivery, packet loss detection and packet type identification. It
puts additional requirements on the lower layer to allow the
decompressor to infer some of the information needed to maintain
robust and transparent header compression. This is possible because
of the nature of the synchronized radio bearer.
LLAROHC also specifies interfaces between the ROHC component towards
the lower layer at both ends of the transmission link. Finally, it
describes methods to compress headers so that during most of the
normal operation only header-free packets are transmitted over the
air interface. These header-free packet account for most of the
traffic.
The Link-Layer Assisted ROHC profile does not provide link layer
specifications. The purpose of this document is to specify how to
implement the LLAROHC profile over CDMA2000 links.
Pelletier [Page 3]
INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 July 20, 2001
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
BER Bit Error Rate
BSC Base Station Controller
CCP Context Check Packet as defined in [LLAROHC]
CRC Cyclic Redundancy Check
CSP Context Synchronization Packet, as defined in [LLAROHC]
HC Header Compressor
HD Header Decompressor
LCP PPP Link Control Protocol (defined in RFC 1661)
LLA MAC LLAROHC adaptation to the CDMA2000 MAC layer
LLAROHC Link Layer Assisted ROHC profile
MAC Media Access Control
MSB Most Significant Bit
MN Mobile Node
NHP No Header Packet
NCP PPP Network Control Protocol (defined in RFC 1661)
PDSN Packet Data Serving Node
PDU Protocol Data Unit
PL Physical Link
PPP Point-to-Point Protocol (RFC1661)
RHP ROHC Header Packet (either a CCP or a RRP packet)
ROHC RObust Header Compression
RRP ROHC RTP Packet as defined in [ROHC, profile 1]
VoIP End-to-end Voice over IP
ROHC RTP
ROHC RTP in this document refers to the IP/UDP/RTP profile as
defined in [ROHC].
Pelletier [Page 4]
INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 July 20, 2001
3. Overview of the Link-Layer Assisted profile over CDMA2000 links
The Link-Layer Assisted ROHC profile is a generic scheme applicable
to any link providing the necessary functionality for the use of
header-free packets in an efficient, transparent and robust way as
described in [LLAROHC]. This document specifies how to implement this
scheme over CDMA2000 links according to the LLAROHC profile.
The following sections introduce the relevant architectural and
operational characteristics of the CDMA2000 system before providing
an overview of the general ideas behind implementation specifications
and guidelines for use of LLAROHC in the system.
3.1. CDMA2000 system overview
This section provides a simplified overview of the CDMA2000 system
and its characteristics relevant to header compression.
3.1.1 CDMA2000 architecture overview
Figure 1 shows the protocol stack view of the IP traffic path in the
CDMA2000 system with a LLAROHC header compression implementation.
MN BSC PDSN
+-------------+ +-----+
| RTP | | RTP |
+-------------+ +-----+
| UDP | | UDP |
+-------------+ +---------------------+ +-----+
| IP | | IP | | IP |
+-------------+ +--------------++-----+ +-----+
| ROHC RTP | | ROHC RTP || | | |
+-------------+ +--------------+| | | |
| LLAROHC | | LLAROHC || | | |
+-------------+ +--------------+| | | |
| LLACDMA2K | | LLACDMA2K ||LINK | |LINK |
+-------------+ +---------------+ +--------------+| | | |
| PPP| NO PPP | | RELAY | | PPP| NO PPP ||LAYER| |LAYER|
+-------------+ +----------++---+ +--------------+| | | |
| LLA MAC | | LLA MAC ||GRE| | GRE || | | |
+-------------+ +----------++---+ +--------------+| | | |
| MAC | | MAC ||IP | | IP || | | |
+-------------+ +----------++---+ +--------------++-----+ +-----+
| AIR LINK |==| AIR LINK ||PL |==|PHYSICAL LINK || PL |==| PL |
+-------------+ +----------++---+ +--------------++-----+ +-----+
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
Pelletier [Page 5]
INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 July 20, 2001
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
LLAROHC RTP implementation, while the LLA MAC contains most of the
functionality specific to the LLAROHC implementation for CDMA2000.
3.1.2. CDMA2000 link layer characteristics
The channel used in CDMA2000 for circuit-switched voice traffic is
characterized by:
- No link layer retransmissions
- High priority channel
- BER (1%)
- Fixed frame sizes (16, 40, 80 and 171 bits)
- Synchronized channel, 20ms time intervals
The most relevant characteristics to the design of the LLAROHC
profile over CDMA2000 are the fixed frame sizes together with the
synchronized and non-retransmitting nature of the physical channel.
3.1.3 Typical CDMA2000 voice encoder rates
Typical CDMA2000 voice encoders have been designed to transmit small
payloads during most of the speech connection. The following table
present the typical payload sizes generated:
Rate Activity % Payload size (bits)
Full 20 171
Half 20 80
Quarter 10 40
Eighth 50 16
Table 1: Frame size distribution for a typical vocoder in CDMA2000
From the table, the most frequent transition introduced by the need
to send extra octets will likely happen between the eight rate (from
16 bits payload) and the quarter rate (to 40 bits payload).
Noteworthy for the LLAROHC for CDMA2000 implementation is that the
rate of the encoders matches the frame rate, or PDU sizes, at the
physical level.
Pelletier [Page 6]
INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 July 20, 2001
3.2. Functionality provided by the link layer to LLAROHC
[LLAROHC] states the functionality to be provided by the link layer
to the LLAROHC implementation to allow packet type identification,
replacement of the sequence number and replacement of the CRC.
Packet type identification may be provided through the use of a
leading sequence which consist of already existing ROHC padding.
Although this approach implies some additional overhead, the need for
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
a typical VoIP connection. Furthermore, there is currently no other
identified alternate mechanism within the CDMA2000 system to provide
this functionality.
The sequence number is replaced by packet loss detection at the MAC
layer under the ROHC decompressor through the interface specified in
[LLAROHC section 4.2.2]. This is done by using explicit detection of
damaged packets over the physical medium from the link layer and
through the use of the CCP packet as an indication of packet loss
before the compressor.
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
sent for the case where header-free packets are used. However, to
detect also unexpected errors, periodical context checks should also
be performed.
4. Link-Layer Assisted ROHC over CDMA2000 links
This section describe the implementation specifications to support
the LLAROHC profile in the CDMA2000 system.
4.1. Operating assumptions
CDMA2000 systems have special characteristics from which we derive
the following assumptions, in addition to those described in [ROHC]
and [LLAROHC].
Reordering
If present, it is assumed that the channel between the ROHC
compressor and the LLA MAC may reorder packets (i.e., there is no
assumption that the LLA MAC will receive packets in order). Note
that out-of-order delivery will have an impact on the compression
efficiency of the LLA ROHC profile and should be minimized.
Reliability
If present, the channel between the ROHC compressor and the LLA MAC
Pelletier [Page 7]
INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 July 20, 2001
is not assumed to be reliable. Packet losses may therefore occur on
this channel, but residual bit error rates should be negligible.
On-time delivery is not assumed either although expected (i.e.,
some packets may be delayed so that they are late for transmission
over the air I interface). Note that packet losses will have an
impact on the compression efficiency of the LLAROHC profile and
should obviously be minimized.
Duplication
If present, it is assumed that a channel between the ROHC
compressor and the LLA MAC may duplicate packets (i.e., there
is no assumption that the LLA MAC will receive only one copy of the
same packet), although duplicates are expected to be handled by the
channel itself. The handling of possible duplicates is left to
implementations.
Link layer channel
The channel used to transport header compression traffic is assumed
to not introduce any additional overhead, for example for
reliability or for any link layer framing additional to the one
already present at the physical layer.
4.2. Architecture overview
Figure 2 shows the various components needed for an implementation of
the LLAROHC profile in CDMA2000. It is separated into layers as
defined in [ROHC RTP], [LLAROCH] and this document [this].
+---------------------+ +---------------------+
[ROHC RTP] | ROHC RTP HC | | ROHC RTP HD |
+---------------------+ +---------------------+
[LLAROCH] | LLAROHC Profile | | LLAROHC Profile |
+=====================+ +=====================+
[LLAROCH] | ROHC-LL | | LL-ROHC |
[this] | interface | | interface |
+=====================+ +=====================+
[this] | LLA MAC | | LLA MAC |
| implementation | | implementation |
+---------------------+ +---------------------+
| CDMA2000 MAC Layer | | CDMA2000 MAC Layer |
+=====================+ +=====================+
| |
+------>---- CHANNEL ---->-----+
Fig.2: Overview of the LLAROHC over CDMA2000 implementation
In [LLAROCH section 4.2.1], a generic interface between the LLAROHC
RTP compressor and the lower layer is specified. The CDMA2000 link
layer does not currently provide all the functionality needed to
fulfill this specification. New functionality, represented by the LLA
Pelletier [Page 8]
INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 July 20, 2001
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
This section describes profile specific initialization steps for the
LLAROHC instances. This section also specifies how parameters are
set.
4.3.1 Header compression setup
[PPP] may be used for the negotiation of ROHC parameters over the
connection setup for header compression. Initialization of ROHC per
channel parameters may be done as described in [ROHC section 5.1.1]
and [ROHC PPP].
The physical establishment and release of the connection used for
header compression traffic is outside the scope of this document.
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
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
identification of the NHP packets.
4.3.4. Packet sizes
The PREFERRED PACKET_SIZES parameter MUST be set according to the
CDMA2000 link fixed frame sizes, i.e. the list provided MUST be
Pelletier [Page 9]
INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 July 20, 2001
[16,40,80,168,176] and 176 MUST be for NHP packets only [see section
5.2].
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].
The resulting effect will be that proper context will be maintained
at the decompressor to the expense of dropping the packet.
The LARGE_PACKET_ALLOWED parameter MAY be set to false and packets
larger than the maximum size specified using the PREFERED PACKET
SIZES [LLAROHC section 5.1.1] parameter will be transmitted as
segmented packets according to [section 4.4.7]. These packets will be
delivered as segmented ROHC packets.
4.3.5. Padding
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
octets as the leading sequence to identify RHP packets. Padding does
not introduce new complexity since it is already part of any ROHC RTP
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
This section describes the logic to be used inside the implementation
of the LLA MAC module on the compressor side. This module receives
parameters from the ROHC RTP compressor as stated in [LLAROHC section
4.2.1]. It always receive an RHP with an indication of segmentation,
a CCP, an RTP Sequence Number and possibly an NHP. Because the
presence or absence of the NHP packet is part of the logic of the LLA
MAC module, all parameters corresponding to the same packet to be
transmitted MUST be ignored by the LLA MAC until they are all
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
The following steps MUST be performed by the LLA MAC upon reception
of a packet delivery from the ROHC header compressor:
a. Keep a copy of CCP and RTP SN
The LLA MAC MUST always keep a copy of the received CCP with the
corresponding RTP Sequence Number.
Pelletier [Page 10]
INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 July 20, 2001
b. Decide which packet needs to be sent
If the Context Check Counter is starved, an RHP packet SHOULD be
sent according to [section 4.4.3], otherwise refer to section
[LLAROHC Section 4.2.1].
4.4.2. Sending the NHP packet
If it was determined that the NHP packet should be sent, then the
following MUST be performed:
a. Check for false Leading Sequence according to [section 4.4.8]
b. Assemble the packet according to [section 4.4.5]
c. Decrement the Context Check Counter
Note that if any of these operations determine that an RHP packet
must be sent, then the subsequent operation(s) MUST NOT be performed.
4.4.3. Sending the RHP packet
If it was determined that the RHP packet will be sent, then the
following MUST be performed:
a. Verification of RHP segmentation indicator
If an indication of segmentation for the RHP packet was received,
then the segmented packet is sent as described in [section 4.4.7].
Otherwise, the packet is assembled according to [section 4.4.5].
b. Reset the Context Check Counter
4.4.4. Sending a CCP or a CSP packet
If it was determined that a CCP or a CSP packet will be sent, then
the following MUST be performed:
a. Assemble the packet
This is done according to section 4.4.5. As the CCP and the CSP are
both RHP packets, a leading sequence will be added during assembly
to allow the LLA MAC module at the decompressor side to detect the
presence of the header. Because codecs may generate valid 16 bits
payload sent as NHP and because of the risk of collision with the
leading sequence [section 4.4.8] or the packet type octet, this
unfortunately forces a rate transition when sending a CCP packet.
It is noted that CDMA2000 defines an empty frame when no speech
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
LLAROHC requires that no extra packet be artificially inserted by
Pelletier [Page 11]
INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 July 20, 2001
the lower layers in the header compression flow, the LLA MAC
implementation will make a CCP packet available to prevent the
generation of a filler frame as stated in [section 4.4.9].
b. Reset the Context Check Counter
4.4.5. Assembling the packet for delivery
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
of size 168 bits, the packet must be padded to fit the physical frame
size of 171 bits. In the case where the packet delivered is of size
176 bits, then it must be stripped of the last 5 padding bits to fit
the physical frame of 171 bits. Otherwise the packet already matches
one of the possible 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
In the case where the calculation of the packet size to be
transmitted is larger than the maximum size of a physical frame, the
implementation must decide between the two following options:
a. Segment the packet using ROHC segmentation
This is done according to [section 4.4.7].
b. Discard the packet and send the CSP
The packet for which the calculation of the size was made is
discarded and a CSP is sent according to [section 4.4.4].
Recall that the CSP contains repair information by carrying a ROHC
header which will maintain proper context at the decompressor, as
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
spectral efficiency respectively.
4.4.7. Handling of ROHC segmented packets
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
congestion as defined in [section 4.4.10].
Pelletier [Page 12]
INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 July 20, 2001
4.4.8. False sequence detection for NHP packets
The false sequence problem, defined as the case where the payload to
be sent as an NHP coincidentally begins with the same bit pattern as
the defined leading sequence, MUST be detected since it will impair
efficiency by having the decompressor treat this packet as a packet
with a ROHC header. This is to prevent the payload of such a packet
to be used as with a corrupted reduced version of the RTP payload.
This payload would then be passed to the application.
The first bits of the NHP payload MUST be examined prior to
transmission. If the pattern matches the ROHC padding and therefore
could be interpreted by the receiving end as a false leading sequence
than the NHP MUST not be sent and an RHP MUST be sent instead.
4.4.9. Delayed packet reception
In the event where no packets are received from the ROHC compressor
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.
The CCP is sent according to [section 4.4.4] and will prevent the
artificial insertion of new packets by the link layer.
The CCP MUST be interpreted as a packet loss by the LLA MAC at the
compressor side.
4.4.10. Congestion handling
Packet dropping might be needed to transmit a segmented ROHC packet.
The following MAY be performed:
a. The first segment is assembled and transmitted according to
[section 4.4.5].
b. Remaining segment(s) is transmitted over the same connection in
subsequent time interval(s) according to [section 4.4.5], while the
packet delivered by the ROHC compressor corresponding to this time
slot is be discarded.
4.5. LLA MAC logic at the decompressor side
This section describes the logic inside the implementation of the LLA
MAC module at the decompressor side. This module receives the packet
transmitted over the air interface from the CDMA2000 link layer and
delivers the following information to the ROHC HC [LLAROHC section
4.2.2]: the packet received with an indication of the presence of a
header or an indication of packet loss together with an explicit
sequence number.
Pelletier [Page 13]
INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 July 20, 2001
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
following operations:
a. Determination of the presence of a header
As ROHC padding is used as leading sequence, the first bits of the
packet received are examined to determine if a leading sequence is
present. If present, the indicator for the presence of a header
MUST be set.
b. Determination of packet loss
The indicator of packet loss MUST be set if the packet received
contains a header and the packet type is CCP or CSP, or upon
explicit notification from the physical link layer that the packet
was damaged.
c. Delivery of the packet and other parameters to the ROHC HD
This is done according to the interface specified in [LLAROHC
section 4.2.2]
It is considered optional to remove the padding at the LLA MAC.
Delivery of the packet with or without the padding will be properly
handled by the ROHC decompressor.
Optionally, an implementation SHOULD combine the LLA MAC with the
ROHC implementation to reduce complexity whenever possible.
5. Implementation Guidelines
5.1. Periodic context validation and speech bursts
Implementations MAY delay a periodic context validation during a
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
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.
Pelletier [Page 14]
INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 July 20, 2001
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
Pelletier [Page 15]
INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 July 20, 2001
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
The security considerations of ROHC RTP [ROHC section 7] and of the
Link-Layer Assisted ROHC profile [LLAROHC] also apply to this
document.
Pelletier [Page 16]
INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 July 20, 2001
7. Acknowledgements
The authors would like to thank Ulises Olvera-Hernandez, Francis
Lupien for their input regarding the CDMA2000 standards and Lars-Erik
Jonsson, Krister Svanbro for their input regarding header compression
issues.
8. References
[LLAROHC] L. Jonsson, G. Pelletier, "A Link-Layer Assisted ROHC
Profile for IP/UDP/RTP", July 2001, <draft-jonsson-rohc-
ll-assisted-rtp-01.txt>
[ROHC] C. Bormann, "Robust Header Compression (ROHC)",
RFC 3095, July 2001.
[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
Serial Links", RFC 1144, February 1990.
[IPHC] M. Degermark, B. Nordgren, S. Pink, "IP Header
Compression", RFC 2507, February 1999.
[CRTP] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers
for Low-Speed Serial Links", RFC 2508, February 1999.
[CRTPC] M. Degermark, H. Hannu, L.-E. Jonsson, K. Svanbro,
"Evaluation of CRTP Performance over Cellular Radio
Networks", IEEE Personal Communications Magazine, Volume
7, number 4, pp. 20-25, August 2000.
[IP] J. Postel, "Internet Protocol", RFC 791, September 1981.
[IPv6] S. Deering, R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[UDP] J. Postel, "User Datagram Protocol", RFC 768, August
1980.
[RTP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications",
RFC 1889, January 1996.
Pelletier [Page 17]
INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 July 20, 2001
[TCP] J. Postel, "Transmission Control Protocol", RFC 793,
September 1981.
[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>
9. Author's addresses
Ghyslain Pelletier Tel: +46 920 20 24 32
Ericsson Erisoft AB Fax: +46 920 20 20 99
Box 920
SE-971 28 Lulea
Sweden EMail: ghyslain.pelletier@epl.ericsson.se
This Internet-Draft expires January20, 2002
Pelletier [Page 18]