Network Working Group Lars-Erik Jonsson, Ericsson (editor)
INTERNET-DRAFT
Expires: October 2001 Thinh Nguyenphu, Nokia
Raymond Hsu, Qualcomm
Wayne Bowen, Motorola
Rajesh Bhalla, Cisco
Mark Lipford, Sprint
Tom Hiller, Lucent
April 18, 2001
3GPP2 Requirements for 0-byte ROHC IP/UDP/RTP Header Compression
<draft-jonsson-3gpp2-rohc-rtp-0-byte-requirements-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 contains requirements from 3GPP2 TSG-P on a zero-byte
IP/UDP/RTP header compression scheme and should be seen as an input
to the work of defining an official document with zero-byte
requirements within the ROHC WG.
Jonsson (ed.) [Page 1]
INTERNET-DRAFT 3GPP2 Requirements for 0-byte ROHC RTP April 18, 2001
0. Document history
March 15, 2001 - 00x
Initial and non-official (as an Internet Draft) version of this
document as an input from 3GPP2 TSG-P. Distributed over the ROHC
WG mailing list prior to 50th IETF in Minneapolis.
March 29, 2001 - 00
First official draft. Modified abstract and introduction clearly
stating that this is a 3GPP2 input to the work to be done in ROHC.
A fifth section of chapter 2 has been added addressing 3GPP2
specific concerns.
April 18, 2001 รป 01
Updated version with minor corrections and modifications to
various parts of the draft. This release is expected to be the
final version of this input document from the 3GPP2 community.
1. Introduction
The goal of the ROHC WG is to develop header compression schemes that
perform well over links with high error rates and long link roundtrip
times. The schemes must perform well for cellular links, using
technologies such as WCDMA, EDGE, and CDMA-2000. However, the schemes
should also be applicable to other future link technologies with high
loss and long roundtrip times.
To provide spectrum efficiency for already deployed speech codecs
over existing link technologies, the regular ROHC RTP [ROHC] scheme
do not perform well enough and 0-byte header compression is needed.
Creation of a 0-byte header compression scheme may seem to be an
unsolvable task if the problem is studied from a traditional header
compression point of view. However, it has been shown that if certain
interaction between the header compression entities and the lower
layers is allowed, 0-byte compression is possible to a large extent.
Some header compression functionality is in these cases provided by
the lower layers, reducing the need for compressed header information
and making it possible to completely eliminating the compressed
header for most of the packets.
Jonsson (ed.) [Page 2]
INTERNET-DRAFT 3GPP2 Requirements for 0-byte ROHC RTP April 18, 2001
2. Header compression requirements
The following requirements have, more or less arbitrarily, been
divided into five groups. The first group deals with requirements
concerning the impact of a header compression scheme on the rest of
the Internet infrastructure. The second group concerns what kind of
headers that must be compressed efficiently. The third and forth
groups concern performance requirements and requirements related to
link and system issues. Finally, the fifth group includes some 3GPP2
specific concerns and comments. Requirements marked with (*) are
identical to the corresponding ROHC RTP requirements in [RTP-REQ].
2.1. Impact on Internet infrastructure
1. Transparency(*): When a header is compressed and then
decompressed, the resulting header must be semantically
identical to the original header. If this cannot be achieved, the
packet containing the erroneous header must be discarded.
Justification: The header compression process must not produce
headers that might cause problems for any current or future part
of the Internet infrastructure.
2. Ubiquity(*): Must not require modifications to existing IP (v4 or
v6) UDP or RTP implementations.
Justification: Ease of deployment.
Note: The ROHC WG may recommend changes that would increase the
compression efficiency for the RTP streams emitted by
implementations. However, ROHC cannot rely on such
recommendations being followed.
2.2. Supported headers and kinds of RTP streams
1. IPv4 and IPv6(*): Must support both IPv4 and IPv6.
Justification: IPv4 and IPv6 will both be around during the
foreseeable future.
2. Mobile IP: The kinds of headers used by Mobile IP{v4,v6} must be
supported and should be compressed efficiently. For IPv4 these
include headers of tunneled packets. For IPv6 these include
headers containing the Routing Header, the Binding Update
Destination Option, and the Home Address option.
Justification: It is very likely that Mobile IP will be used by
cellular devices.
Jonsson (ed.) [Page 3]
INTERNET-DRAFT 3GPP2 Requirements for 0-byte ROHC RTP April 18, 2001
2.3. Performance issues
1. Performance/Spectral Efficiency: Must provide low relative
overhead under expected operating conditions. Performance should
be such that 0-byte header packets are used most of the time to
maximize spectral efficiency.
Justification: Spectrum efficiency is a primary goal. Studies has
shown that for certain speech codecs and link technologies, even
a single octet of header may result in a 15-30% decrease in
spectrum efficiency compared to existing circuit switched
solutions.
Note: the relative overhead is the average header overhead
relative to the payload. Any auxiliary (e.g., control or
feedback) channels used by the scheme should be taken into
account when calculating the header overhead.
2. Error propagation(*): Error propagation due to header compression
should be kept at an absolute minimum. Error propagation is
defined as the loss or damage of headers subsequent to headers
lost or damaged by the link, even if those subsequent headers are
not lost or damaged.
Justification: Error propagation reduces spectral efficiency and
reduces quality.
Note: There are at least two kinds of error propagation; loss
propagation, where an error causes subsequent headers to be lost,
and damage propagation, where an error causes subsequent headers
to be damaged.
3a. Moderate Packet Reordering(*): The scheme should efficiently
handle moderate reordering (2-3 packets) in the packet stream
reaching the compressor.
Justification: This kind of reordering is common.
3b. Packet Reordering(*): The scheme should be able to compress when
there are reordered packets in the RTP stream reaching the
compressor.
Justification: Reordering happens regularly in the Internet.
However, since the Internet is engineered to run TCP reasonably
well, excessive reordering will not be common and need not be
handled with optimum efficiency.
4. Processing delay(*): The scheme must not contribute significantly
to system delay budget.
Jonsson (ed.) [Page 4]
INTERNET-DRAFT 3GPP2 Requirements for 0-byte ROHC RTP April 18, 2001
5. Algorithm delay: The scheme should not noticeably add to the end-
to-end delay.
Justification: RTP packets carrying data for interactive voice or
video have a limited end-to-end delay budget.
Note: This requirement is intended to prevent schemes that achieve
robustness at the expense of delay, for example schemes that
require that header i+x, x>0, is received before header i can be
decompressed.
6. Multiple links(*): The scheme must perform well when there are two
or more cellular links in the end-to-end path.
Justification: Such paths will occur.
Note: Loss on previous links will cause irregularities in the RTP
stream reaching the compressor. Such irregularities should only
marginally affect performance.
2.4. Requirements related to link layer and system concerns
1. Configurable frame size fluctuation(*): It should be possible to
restrict the number of different frame sizes used by the scheme.
Justification: Some radio technologies support only a limited
number of frame sizes efficiently.
Note: Somewhat degraded performance is to be expected when such
restrictions are applied.
Note: This implies that a list of "desirable" frame sizes must be
made available and that ROHC may pick a suitable header format to
utilize available space as well as possible.
2. Header compression coexistence: The scheme must fit into the ROHC
framework together with other ROHC profiles
Justification: Implementation simplicity is an important issue
and therefore should the 0-byte compression scheme has as much as
possible in common with the IP/UDP/RTP profile.
Jonsson (ed.) [Page 5]
INTERNET-DRAFT 3GPP2 Requirements for 0-byte ROHC RTP April 18, 2001
3. Handover: Using header compression must not introduce any
additional degradation at handoff, when compared to existing
circuit switched operation. By degradation, it is meant that the
header compression process must not introduce erroneous headers
or packet loss during the handoff process. This must be true
regardless of whether the handoff involves context relocation or
not. Loss of compression efficiency shall be minimized during
handoff.
Justification: Such events can be frequent in cellular systems
where the compressor/decompressor on the network side is close to
the radio base stations.
Soft and Hard handoffs for 0-byte header compression must be
supported the same as current SMV and EVRC circuit calls are
supported for hard and soft handoff. Definitions of hard and soft
handoff can be found in IS2000.2.
Note: In order to aid developers of context recreation schemes
where context is transferred to the new node, the specification
shall outline what parts of the context is to be transferred, as
well as conditions for its use. Procedures for context recreation
(and discard) without such context transfer will also be
provided.
4. Residual errors(*): For a residual bit-error rate of at most 1e-5,
the ROHC scheme must not increase the error rate.
Justification: Some target links have a residual error rate, i.e.,
rate of undetected errors, of this magnitude.
Note: In the presence of residual bit-errors, ROHC will need error
detection mechanisms to prevent damage propagation. These
mechanisms will catch some residual errors, but those not caught
might cause damage propagation. This requirement states that the
reduction of the damage rate due to the error detection
mechanisms must not be less than the increase in error rate due
to damage propagation.
Jonsson (ed.) [Page 6]
INTERNET-DRAFT 3GPP2 Requirements for 0-byte ROHC RTP April 18, 2001
2.5. 3GPP2 specific requirements and notes
1. Speech vocoder support: An implementation of the 0-byte scheme in
CDMA2000 must be able to optimally support the EVRC and SMV
speech vocoders.
Justification: Since these are the two primary forms of vocoders
that are supported in cdma2000, the solution must work well with
these vocoder technologies.
2. Legacy voice over IP: In 3GPP2, a legacy voice over IP model has
been outlined in addition to the true voice over IP model. The
purpose of the legacy model is to make simple voice over IP
terminals available based on legacy hardware. To support this
model, 3GPP2 will standardize transport mechanisms for the speech
data reusing parts of the transparent 0-byte compression scheme
(almost identical network side implementation). The 0-byte scheme
should in no way prevent 3GPP2 from reusing and redefining it for
the legacy model.
Justification: The legacy model will be supported in 3GPP2 and it
would be beneficial from a complexity point of view that the
transparent 0-byte scheme, to be implemented anyway on the
network side, could be mostly reused also for the legacy model.
3. References
[RFC-791] Jon Postel, Internet Protocol, RFC 791, September 1981.
[RFC-768] Jon Postel, User Datagram Protocol, RFC 768, August
1980.
[RTP-REQ] Mikael Degermark, "Requirements for IP/UDP/RTP Header
Compression", RFC 3096, March 2001.
[ROHC] C. Bormann, "Robust Header Compression (ROHC)", RFC
3095, March 2001.
Jonsson (ed.) [Page 7]
INTERNET-DRAFT 3GPP2 Requirements for 0-byte ROHC RTP April 18, 2001
4. Author's addresses
Lars-Erik Jonsson (ed.) Tel: +46 (920) 20 21 07
Ericsson Erisoft AB Fax: +46 (920) 20 20 99
Box 920
SE-971 28 Lulea
Sweden E-mail: lars-erik.jonsson@ericsson.com
Thinh Nguyenphu Tel: +1 (972) 894 5189
Nokia Fax:
6000 Connection Dr.
Irving, TX 75039
USA E-mail: thinh.nguyenphu@nokia.com
Raymond Hsu Tel: +1 (858) 651 3623
Qualcomm Incorporated
5775 Morehouse Dr.
San Diego, CA 92121
USA E-mail: rhsu@qualcomm.com
Wayne Bowen Tel: +1 (847) 435 5912
Motorola
1421 Shure Dr.
Arlington Heights, IL 60004
USA E-mail: fbowen1@enmail.mot.com
Rajesh Bhalla Tel: +1 (408) 853 9265
Cisco Systems Inc. Fax: +1 (408) 853 0406
170 West Tasman Drive
San Jose, CA 95134
USA E-mail: rabhalla@cisco.com
Mark Lipford Tel: +1 (913) 890 4248
Sprint PCS Fax: +1 (913) 890 4100
15405 College Blvd.
Lenexa, KS 66219 E-mail: mlipfo01@sprintspectrum.com
Tom Hiller Tel: +1 (630) 979 7673
Lucent Technologies Fax: +1 (630) 979 7673
263 Shuman Dr.
Naperville, IL 60566
USA E-mail: tom.hiller@lucent.com
This Internet-Draft expires October 18, 2001.
Jonsson (ed.) [Page 8]