Internet DRAFT - draft-degermark-hc-requirements
draft-degermark-hc-requirements
Network Working Group Mikael Degermark (editor) /Lulea University
INTERNET-DRAFT Sweden
Expires: May 2000 October 22, 1999
3GPP requirements for header compression
<draft-degermark-hc-requirements-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 to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-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 its editor.
Abstract
This document gives the requirements for a header compression scheme
to be used over cellular links for interactive voice. It is an exerpt
(page 36) of the 3GPP document "3GPP TR 23.922", version 1.0.0 of
october 1999 [TR].
Degermark (Ed) [Page 1]
INTERNET-DRAFT 3GPP requirements for header compression Oct 22, 1999
1. Introduction
When sending speech over a celluar link, the headers must be
compressed for spectral efficiency reasons. This document lists the
requirements for such a header compression scheme according to 3GPP
(www.3gpp.org). As no current header compression scheme in the IETF
fulfills these requirements a new header compression scheme may have
to be developed.
2. Header compression requirements
This section is table 8-1, page 36-37 of [TR].
# Focus Area Requirement Justification
------------------------------------------------------------------------
1. Performance/ Must provide low relative In general, a primary goal is
Spectral overhead (as defined in high spectrum efficiency.
Efficiency [TS]) under expected Reduction of overhead has
operating conditions. direct impact.
2. IPv6 or IPv4 Must include support for IPv4 and IPv6 terminals are
IPv6 and IPv4. expected to coexist for some
time
3. Ubiquity Must NOT require modi- Enables use of current devices/
fications to existing IP services which employ generic
(v4 or v6), UDP, or RTP IP/UDP/RTP stacks.
protocol stack implemen-
tations.
4. Cellular HO Must support the cellular Target application is for
handoff operation, in an adaption of the user plane on
efficient manner; All cellular air interfaces;
fields must be transparent therefore this operation *must*
to the HO process, i.e., be supported. Efficiency
are exactly regenerated requirement is due to potential
subsequent to handoff. impacts on spectral efficiency
and voice quality if HO is not
properly handled.
5. Integrity The header compression Would like to maintain the
process must be lossless. end-to-end integrity of IP.
Degermark (Ed) [Page 2]
INTERNET-DRAFT 3GPP requirements for header compression Oct 22, 1999
6. Error Error propagation due to Error propagation results in
Propagation header compression should lower spectral efficiency and
be kept to an absolute lower voice quality; this is a
minimum or avoided if at serious problem for existing
all possible. Error propa- schemes such as [CRTP].
gation is defined as the
loss of packets subsequent
to the one where the error
actually occured, even when
those subsequent packets
contain no errors.
7. Delay Must operate under all The user may be in different
expected delay conditions; types of environments with
header compression process different characteristics;
must not contribute additional delays will have
significantly to system adverse effects on conver-
delay budget. sational voice
8. Packet Loss Must operate under all The user may be in different
expected packet loss cond- types of environments with
itions; prefer that header different characteristics.
compression efficiency is
as independent of packet
loss rate as possible.
9. Media Must function regardless The algorithm should be
Supported of media type in RTP pay- applicable to any type of
load (in general, there RTP/UDP/IP data flow; note that
is NO *required* knowledge this does not preclude optional
of payload). optimizations for certain
media types.
10. Independence Must fuction for mobile- Both types of calls will occur
with respect mobile and mobile-landline in All-IP cellular systems;
to call type calls; performance in each each is equally important.
case should be comparable
to exisiting cellular (in
terms of both quality and
spectral efficiency).
3. Editor's address
Mikael Degermark Tel: +46 920 91188
CDT/Dept of Computer Communication Fax: +46 920 72801
Lulea University Mobile: +46 70 833 8933
S-971 87 Lulea, Sweden EMail: micke@sm.luth.se
Degermark (Ed) [Page 3]
INTERNET-DRAFT 3GPP requirements for header compression Oct 22, 1999
4. References
[TR] 3GPP TR 23.922 version 1.0.0, 3rd Generation partnership
Project; Technical Specification Group Services and
Systems Aspects; Architecture for an All IP network.
[TS] TS 22.101 version 3.6.0: Service Principles
[RFC-768] J. Postel, User Datagram Protocol, RFC 761, August 1980.
[RFC-791] J. Postel, Internet Protocol, RFC 791, September 1981.
[RFC-1144] V. Jacobson, Compressing TCP/IP Headers for Low-Speed
Serial Links, RFC 1144, February 1990.
[CRTP] S. Casner, V. Jacobson, Compressing IP/UDP/RTP Headers
for Low-Speed Serial Links, RFC 2508.
This draft expires in May 2000.
Degermark (Ed) [Page 4]
