Network Working Group Mikael Degermark (editor) /Lulea University INTERNET-DRAFT Sweden Expires: May 2000 October 22, 1999 3GPP requirements for header compression 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]