Network Working Group Ghyslain Pelletier, Ericsson
INTERNET-DRAFT Sweden
Expires: November, 2001 May 6, 2001
Link-Layer Assisted ROHC Over CDMA2000
<draft-pelletier-rohc-rtp-llarohc-cdma2000-00.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 May 6, 2001
Table of contents
1. Introduction....................................................2
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. Context IDentifiers (CID) ............................
4.3.3. Packet sizes..........................................
4.3.4. Padding...............................................
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 the CCP 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 ..............
6. Security considerations.........................................
7. Acknowledgements................................................
8. References......................................................
9. Author's addresses..............................................
Pelletier [Page 2]
INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 May 6, 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.
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
Pelletier [Page 3]
INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 May 6, 2001
ECCP Extended CCP 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].
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.
As shown in figure 1, within a CDMA2000 system it cannot be assumed
that the ROHC RTP implementation will be physically co-located with
Pelletier [Page 4]
INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 May 6, 2001
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
+-------------+ +-----+
| 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
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
Pelletier [Page 5]
INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 May 6, 2001
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.
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.4]. 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
Pelletier [Page 6]
INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 May 6, 2001
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
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.
Pelletier [Page 7]
INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 May 6, 2001
4.2. Architecture overview
In [LLAROCH section 4.3], 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 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 |
+---------------------+ +---------------------+
[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
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].
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
Pelletier [Page 8]
INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 May 6, 2001
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]. Once the LLAROHC profile has been identified by the
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
header compression traffic is outside the scope of this document.
4.3.2. 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.3. 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
[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
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.
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.4. 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].
Pelletier [Page 9]
INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 May 6, 2001
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.3]. 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 at the LLA MAC, all
parameters corresponding to the same packet to be transmitted MUST be
ignored at the LLA MAC until they are all received reliably, as
described in [section 4.6].
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.
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.3].
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].
Pelletier [Page 10]
INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 May 6, 2001
b. Reset the Context Check Counter
4.4.4. Sending the CCP 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
which will maintain proper context at the decompressor, as
described in [LLAROHC].
b. Assemble the packet
This is done according to section 4.4.5. As the CCP and its
extended format is an RHP packet, 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
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].
c. 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 [section 4.3.3], 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 [section 4.3.3], 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.
Pelletier [Page 11]
INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 May 6, 2001
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 extended CCP (ECCP)
The packet for which the calculation of the size was made is
discarded and the ECCP is sent according to [section 4.4.4].
Note that this will readily repair the context at the decompressor
according to [LLAROHC] after detection of the packet loss signaled
by the reception of the ECCP 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].
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.
Pelletier [Page 12]
INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 May 6, 2001
The CCP, and its extended ECCP format, 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.4]: the packet received with an indication of the presence of a
header or an indication of packet loss together with explicit
sequence number [section 4.7].
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 ECCP, 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.4]
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.
Pelletier [Page 13]
INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 May 6, 2001
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.
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.
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", February 2001, <draft-jonsson-
rohc-ll-assisted-rtp-00.txt>
[ROHC] C. Bormann, "Robust Header Compression (ROHC)", Internet
draft (work in progress), January 2001, <draft-ietf-
rohc-rtp-07.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,
Pelletier [Page 14]
INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 May 6, 2001
"Evaluation of CRTP Performance over Cellular Radio
Networks", IEEE Personal Communications Magazine, Volume
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.
[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.
[TCP] J. Postel, "Transmission Control Protocol", RFC 793,
September 1981.
[RTP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications",
RFC 1889, January 1996.
[ROHC PPP] C. Bormann, "ROHC over PPP", March 2001, <draft-ietf-
rohc-over-ppp-01.txt>.
[EVRC RTP] A. Li, "An RTP Payload Format for EVRC Speech",(work in
progress), April 2001 <draft-ietf-avt-evrc-02.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 November 4, 2001
Pelletier [Page 15]