Network Working Group Hans Hannu, Ericsson INTERNET-DRAFT Jan Christoffersson, Ericsson Expires: January 2002 Krister Svanbro, Ericsson Sweden July 19, 2001 Application signaling over cellular links 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 draft discusses problems arising when ASCII based application signaling protocols are used over cellular access channels. The protocols discussed are SIP, RTSP and SDP. The problems are call setup delays and decreased system capacity due to inefficient signaling by these protocols. An outline of an algorithm for compression of these protocols is given. Hannu, Christoffersson, Svanbro [Page 1] INTERNET-DRAFT Application signaling over cellular links July 19, 2001 0. Document history - November 17, 2000, version 00. First draft introducing the problem with current ASCII-based signaling protocols. The draft also included a proposed direction of a solution. - March 2, 2001, version 01. The draft was updated with some requirements on the compression scheme. - July 19, 2001, version 02. Updated with some system capacity issues in relation with SIP- signaling. TABLE OF CONTENTS 1. Introduction..................................................4 2. Protocol characteristics......................................5 2.1. SIP.....................................................5 2.2. SDP.....................................................5 2.3. RTSP....................................................5 2.4. Protocol similarities...................................5 3. Cellular system radio characteristics.........................6 4. Motivation for signaling reduction............................6 4.1. Estimation of Call Setup Delay using SIP/SDP............7 4.1.1. Delay result..........................................8 4.2 Estimation of system capacity...........................8 5. Possible solutions............................................9 6. Requirements on the compression scheme.......................10 6.1 General requirements...................................10 6.2 Performance requirements...............................11 7. General description of proposed compression method...........12 7.1 Existing compression methods...........................12 Hannu, Christoffersson, Svanbro [Page 2] INTERNET-DRAFT Application signaling over cellular links July 19, 2001 7.1.1 Field compression....................................12 7.1.2 Binary compression...................................12 7.1.3 IPComp...............................................12 7.2 Drawbacks with existing compression methods............13 7.3 Description of proposed solution.......................13 7.4. Compression efficiency.................................15 7.5. Performance after compression..........................16 8. Relation to header compression...............................16 9. Conclusion...................................................17 10. Security considerations......................................17 11. Intellectual property rights considerations..................17 12. Authors addresses............................................17 13. References...................................................18 Hannu, Christoffersson, Svanbro [Page 3] INTERNET-DRAFT Application signaling over cellular links July 19, 2001 1. Introduction Two communication technologies have become commonly used by the general public in the recent years: cellular telephony and the Internet. Cellular telephony has provided its users with the freedom of mobility - the possibility of always being reachable with reasonable service quality no matter where they are. However, until now the main service provided has been speech. With the Internet, the conditions have been almost the opposite. While flexibility for all kinds of usage has been its strength, its focus has been on fixed connections and large terminals, and the experienced quality of some services (such as Internet telephony) has generally been low. Due to new enhanced technologies this is about to change. Internet and cellular technologies are beginning to merge. Future cellular "phones" will contain an IP-stack and support voice over IP in addition to web-browsing, e-mail, etc. One could say that the Internet is going mobile, or that cellular systems are becoming much more than telephony depending on one's point of view. Commonly used terms in this technical area are "all-IP" and "IP all the way". These terms all relate to the case where IP is used end to end, even if the path involves cellular links, and IP is also run over the radio hop(s). This is done for all types of traffic, both the user data (e.g. voice or streaming) and control signaling data (e.g. SIP or RTSP). A great benefit of this is the service flexibility introduce by IP combined with the freedom provided by continuos mobility. A high cost, on the other hand, is the relative large overhead the IP protocol suite typically introduce, e.g. due to large headers and text-based signaling protocols. It is very important in cellular systems to use the scarce radio resources in an efficient way. It must be possible to support a sufficient number of users per cell, otherwise costs will be prohibitive [CELL]. Frequency spectrum and thus bandwidth are the most costly resources in cellular links and must be used carefully. The ROHC (RObust Header Compression) working group has successfully solved the problem of reducing bandwidth requirements for the header parts of e.g. RTP/UDP/IP packets. With this obstacle removed, new possibilities of enhancing mobile internet performance arise. One of these relates to application signaling protocols. Protocols such as SIP [SIP], SDP [SDP] and RTSP [RTSP] will typically be used to setup and control applications also in a mobile Internet. However, the protocol messages are generous in size and create delays due to their request/response nature. Compression of these messages should be considered in order to increase spectrum efficiency and reduce transmission delay. Hannu, Christoffersson, Svanbro [Page 4] INTERNET-DRAFT Application signaling over cellular links July 19, 2001 2. Protocol characteristics The following application signaling protocols are the subject of study in this draft. 2.1 SIP The Session Initiation Protocol [SIP] is an application layer protocol for establishing, modifying and terminating multimedia sessions or calls. These sessions include Internet multimedia conferences, Internet telephony and similar applications. SIP can be used over either TCP [TCP] or UDP [UDP]. SIP is a text based protocol, using ISO 10646 in UTF-8 encoding. 2.2 SDP The Session Description Protocol [SDP] is used to advertise multimedia conferences and communicate conference addresses and conference tool specific information. It is also used for general real-time multimedia session description purposes. SDP is carried in the message body of SIP and RTSP messages. SDP is text based using the ISO 10646 character set in UTF-8 encoding. 2.3 RTSP The Real Time Streaming Protocol [RTSP] is an application level protocol for controlling delivery of data with real-time properties, such as audio and video. RTSP may use UDP or TCP (or other) as transport protocol. RTSP is text based using the ISO 10646 character set in UTF-8 encoding. 2.4 Protocol similarities The above protocols have many similarities. These similarities will have implications on solutions to the problems they create in conjunction with the cellular radio access. The similarities include: -Requests and reply characteristics. When a sender sends a request, it stays idle until it has received a response. Hence, it typically takes a number of round trip times to conclude e.g. a SIP session. -They are ASCII based. Thus to represent e.g. the value 230, 3 * 8 = 24 bits are used. A binary representation of the same value, by comparison, would require only 8 bits. -They are generous in size in order to provide the necessary information to the session participants. Hannu, Christoffersson, Svanbro [Page 5] INTERNET-DRAFT Application signaling over cellular links July 19, 2001 -SIP and RTSP share many common header field names, methods and status codes. The traffic patterns are also similar. The signaling is carried out primarily under the set up phase. For SIP this means that the majority of the signaling is carried out to set up a phone call or multimedia session. For RTSP the majority of the signaling is done before the transmission of application data. 3. Cellular system radio characteristics Partly to enable high utilization of cellular systems and partly due to the unreliable nature of the radio media, cellular links have characteristics that differ somewhat from a typical fixed link, e.g. copper or fiber. The most important characteristics are the lossy behavior of cellular links and the large round trip times. The quality in a radio system typically changes from one radio frame to another due to fading in the radio channel. Due to the nature of the radio media and interference from other radio users, the average bit error rate (BER) can be 10e-3 with a variation roughly between 10e-2 to 10e-4. To be able to use the radio media with its error characteristics, methods such as forward error correction (FEC) and interleaving are used. If these methods were not used, the BER of a cellular radio channel would be around 10 % [CELL]. Thus, radio links are by nature error prone. The final packet loss rate may be further reduced by applying low level retransmissions (ARQ) over the radio channel; this, however, trades decreased packet loss rate for a larger delay. By applying methods to decrease BER, the system delay is increased. In some cellular systems, the algorithmic channel round trip delay is in the order of 80 ms. Other sources of delays are DSP-processing, node-internal delay and transmission. A general value for the RTT is difficult to state, but, to give one example, 200 ms is mentioned in [CELL]. For cellular systems it is of vital importance to have a sufficient number of users per cell; otherwise the system cost would prohibit deployment. It is crucial to use the existing bandwidth carefully; hence the average user bit rate is typically relatively low compared to the average user bit rate in wired line systems. This is especially important for mass market services like voice. 4. Motivation for signaling reduction The need for solving the problems caused by the signaling protocol messages is exemplified in this chapter by looking at a typical SIP/SDP Call Setup sequence over a narrow band cellular channel. Results from a simple system capacity example are also presented. These results indicate that there also would be a gain to the system Hannu, Christoffersson, Svanbro [Page 6] INTERNET-DRAFT Application signaling over cellular links July 19, 2001 capacity by reducing the size of the messages. The corresponding figures obtained when the SIP/SDP messages are compressed can be found in Section 7.5. 4.1 Estimation of Call Setup Delay using SIP/SDP Figure 4.1 shows an example of SIP signaling between two termination points with a wireless link between, and the resulting delay under certain system assumptions. It should be noted that the used figures represent a very narrow band link even if e.g. a WCDMA system can provide maximum bit rates up to 2 Mbits/s in ideal conditions. However, this requires that one user consumes all radio resources in a cell. For a mass market service such as voice, it is always crucial to reduce the bandwidth requirements for each user. The one way delay is calculated according to the following equation: OneWayDelay = MessageSize[bits]/LinkSpeed[bits/sec] + RTT[sec] / 2 (eq. 1) The following values have been used: RTT/2: 70 ms LinkSpeed 9.6 kbps The delay formula is based on an approximation of a WCDMA radio access method for speech services. The approximation is rather crude. For instance, delays caused by possible retransmissions due to errors are ignored. Further, these calculations also assume that there is only one cellular link in the path and also take delays in an eventual intermediate IP-network into account. Even if this approximation is crude, it is still sufficient to provide representative numbers and enable comparisons. The message size given in Figure 4.1, is typical for a SIP/SDP call setup sequence. Client Network-Proxy Size [bytes] Time [ms] | | |---------- INVITE --------->| 620 517+70 | | |<-- 183 Session progress ---| 500 417+70 | | |---------- PRACK ---------->| 250 208+70 | | |<----- 200 OK (PRACK) ------| 300 250+70 : : |<...... RSVP and SM .......>| : : Hannu, Christoffersson, Svanbro [Page 7] INTERNET-DRAFT Application signaling over cellular links July 19, 2001 |---------- COMET ---------->| 620 517+70 | | |<----- 200 OK (COMET) ------| 450 | | + |<------ 180 Ringing --------| 230 567+70 | | |---------- PRACK ---------->| 250 208+70 | | |<----- 200 OK (PRACK) ------| 300 | | + |<--------- 200 OK ----------| 450 625+70 | | |----------- ACK ----------->| 230 192+70 Figure 4.1. SIP signaling delays assuming a link speed of 9600 bits/sec and a RTT of 140 ms. 4.1.1 Delay results Applying equation 1 to each SIP/SDP message shown in the example of Figure 4.1 gives a total delay of 4130 ms from the first SIP/SDP message to the last. The RSVP and Session Management (Radio Bearer setup), displayed in Figure 4.1 will add approximately 1.5 seconds to the total delay, using equation 1. However, there will also be RSVP and SM signaling prior to the SIP INVITE message to establish the radio bearer, which would add approximately another 1.5 seconds. In [TSG] there is a comparison between GERAN call setup using SIP and ordinary GSM call setup. For a typical GSM call setup the time is about 3.6 seconds, and for the case when using SIP, the call setup is approximately 7.9 seconds. Thus, solutions are needed to reduce signaling delay and required bandwidth when considering both system bandwidth requirements and service setup delays. 4.2 Estimation of system capacity Estimation of the increase in system capacity due to the use of compression can be done using similar assumptions as in the previous section, i.e. a link speed of 9600 bits/sec and a total size of the uncompressed SIP/SDP messages of 4200 bytes. The mean length of call duration will have a large impact on the system capacity and is assumed to be 90 seconds. The radio transmitter is also assumed capable of transmitting with variable bit rate using e.g. DTX (Discontinuous Transmission) mode, allowing the transmitter to use roughly half of the bit rate otherwise needed to transmit the calls. These assumptions lead to the following number of bits used for call set up and call: Hannu, Christoffersson, Svanbro [Page 8] INTERNET-DRAFT Application signaling over cellular links July 19, 2001 Bits = 90x9600/2+4200*8 = 465600 An analysis of the number of bits needed when the SIP/SDP messages are compressed and the approximate corresponding capacity gain can be found in Section 7.5. 5. Possible solutions More or less attractive solutions to the previously mentioned problems can be outlined: * Increase the user bit rate. An increase of the bit rate per user will decrease the number of users per cell. There exist systems (for example WCDMA) which can provide high bit rates and even variable rates for instance at setup of new sessions. However, there are also systems, e.g. GSM/EDGE, where it is not possible to reach these high bit rates in all situations. At the cell borders, for example, the signal strength to noise ratio will be lower and result in a lower bit rate. In general, an unnecessary increase of the bit rate should be avoided due to the higher system cost introduced and the possibility of denial of service. The latter could for example be caused by lack of enough bandwidth to support sending of the large setup message within a required time period, which is set for QoS reasons. * Decrease the RTT of the cellular link Decreasing the RTT would require substantial system changes and is thus not feasible. Further, the RTT-delay due to interleaving and FEC will always have to be present regardless of which system is used. Otherwise the BER will be too high for the received data to be useful, or alternatively trigger retransmissions giving an average total delay of the same or higher magnitude. * Optimize message sequence for the protocols. If the request/response pattern could be eased up, then "keeping the pipe full" could be a way forward. Thus, instead of following the message sequence described in figure 4.2, more than one message would be sent in row, even though no response has been received. However, this would entail protocol changes and may be difficult at current date. * Protocol stripping. Removing fields from a message would decrease the size of the messages to some extent. However, this would cause loss of transparency and thus violate the End-to-End principle and is thus not desirable. Hannu, Christoffersson, Svanbro [Page 9] INTERNET-DRAFT Application signaling over cellular links July 19, 2001 * Compression. By compressing messages, the impact of the mentioned problems could be decreased. Compared to the other possible solutions compression can be made, and must be, transparent to the end-user application. Thus, compression seems to be the most attractive way forward. Following chapter sets some requirements on the compression scheme. 6. Requirements on the compression scheme This section contains requirements for compression of ASCII based application signaling protocols. The requirements treat issues such as impact on the rest of the Internet infrastructure, what kind of messages and streams that must be compressed efficiently and what kind of performance the compression scheme should be able to deliver. The requirements have been divided into two broad categories: general and performance related requirements. 6.1 General requirements The compression must be transparent: when a message is compressed and then decompressed the result must be bitwise identical to the original message. The transparency must be maintained independently of the payload. Justification: This is to ensure that the compression scheme will not cause problems for any current or future part of the Internet infrastructure. The compression scheme must be able to coexist with the ROHC framework. Compression of IP/UDP and IP/TCP should be inherited from existing profiles, like the existing ROHC profile for IP/UDP compression. Justification: Signaling compression is used because there is a need to conserve bandwidth usage. In that case, header compression will likely be needed too. Modifications to the protocols, which generate the messages that are to be compressed, must not be required for the compression scheme to work. Justification: This will simplify deployment of the compression scheme. Compression of arbitrary message streams must be supported. The compression scheme must not be limited to certain protocols, traffic patterns or sessions. Hannu, Christoffersson, Svanbro [Page 10] INTERNET-DRAFT Application signaling over cellular links July 19, 2001 Justification: Needed for generality of the compression scheme. Note: This does not preclude optimization for certain streams. The compression scheme must be able to operate on unidirectional links, i.e. without explicit feedback messages from the decompressor. Note: Implementations on unidirectional links might possibly show a degraded performance compared to implementations on bi-directional links. 6.2 Performance requirements The compression scheme must be able to operate under all expected link delay conditions. The compression scheme must be able to operate under all expected packet loss conditions. The compression scheme must be able to operate under all expected residual bit error rate conditions. The compression scheme should aim at minimizing transmission delay and maximizing the bitwise efficiency. Note: Since there are no previously defined solutions for compression of application signaling protocols it is difficult to find a suitable benchmark. The total delay, including processing time of the compression scheme, must decrease when compression is applied compared to sending the packets uncompressed on the same channel bandwidth. Justification: This is one of the primary goals for signaling compression. Error propagation must be minimized. Loss or damage to a single or several messages, on the link between the compressor and the decompressor, should not prevent compression and decompression of later messages. Justification: Error propagation reduces resource utilization and quality. The compression scheme should be able to compress and decompress when there are reordered messages reaching the compressor. Reordering is frequent on the Internet, which implies that the compressor must be able to handle reordering. Hannu, Christoffersson, Svanbro [Page 11] INTERNET-DRAFT Application signaling over cellular links July 19, 2001 7. General description of proposed compression method 7.1 Existing compression methods Different approaches for compression of the protocol messages are possible. 7.1.1 Field compression Compression of the messages could be done using field compression methods such as ROHC. Field compression methods are based on knowledge of the syntax of a specific protocol. Field compression is successful when applied to protocols where many header fields are either static, are dependent on other header fields in the same packet or change in a predictable way between consecutive packets. 7.1.2 Binary compression Several binary compression algorithms are in use for general data file compression. These could possibly be used for the protocol compression discussed here. Huffman compression [HUFF] is a general method intended primarily for compression of ASCII files. Characters occurring frequently in the file are replaced by shorter codes, i.e. codes with less than the 8 bits used by the ASCII code. Huffman compression can be successful in files where relatively few characters are used. The first step when applying Huffman compression is to determine the new codes for the particular file being compressed. This code must also be used when decompressing the file. It is possible to use a fixed code for a sequence of messages; however, this would not give an optimal code for the specific message being compressed. Another widely used compression algorithm is the Lempel-Ziv [LZ77] algorithm. This algorithm operates by replacing character strings which have previously occurred in the file by references to the previous occurrence. This method is successful in files where repeated strings are common. This algorithm does not require any code to be sent to the decompressor. The well known compression programs Gzip and WinZip both use Lempel- Ziv compression followed by Huffman compression. 7.1.3 IPComp IPComp [IPComp] is a compression protocol for compression of IP [IP] payload and could hence be used for compression of SIP, SDP and RTSP. Hannu, Christoffersson, Svanbro [Page 12] INTERNET-DRAFT Application signaling over cellular links July 19, 2001 The protocol can use different compression methods, e.g. Lempel-Ziv, for the actual compression. The IPComp protocol specifies that each datagram is compressed independently of other datagrams. This is to ensure that received packets can be decompressed even if some previous packets are lost. 7.2 Drawbacks with existing compression methods Using field compression would be difficult or impossible since the studied protocols are similar to payload of IP/UDP and do not have any fixed header fields in a strict sense. That is, different protocol messages will have different fields with varying length. A general prerequisite for successful compression using the above mentioned binary compression algorithms is that the file to be compressed is reasonably large, i.e. several kilobytes. This is a consequence of the compression algorithms. The codes for Huffman compression must not be too large compared to the file which is being compressed and the file must be large enough to have many repeated strings so that Lempel-Ziv compression becomes efficient. The messages produced by the protocols considered here are mostly a couple of hundred bytes and definitely not large enough to allow efficient compression with the mentioned algorithms on a message-by- message basis. IPComp compresses each datagram by itself without any relation to any other datagrams. This implies that efficient compression of these protocol messages using IPComp is not feasible. 7.3 Description of proposed solution The proposed solution is a scheme which is robust to packet loss and will give efficient compression of messages. The approach taken here, is to compress the messages sequentially using previous messages from the same session. The compression algorithm used for compression is some, perhaps modified, version of the Lempel-Ziv algorithm. By appending a message to a previous message (dictionary), it becomes possible to replace strings in the message by references to occurrences in the previous messages. Updating of the dictionary can be done in different ways: *Append all new messages to the dictionary. This will increase the size of the dictionary throughout the session. In long sessions with large messages, the dictionary size might cause problems. *Append only new strings to the dictionary. This will also make the dictionary increase in size throughout the session, but at a slower rate. Hannu, Christoffersson, Svanbro [Page 13] INTERNET-DRAFT Application signaling over cellular links July 19, 2001 *Limit the size of the dictionary by keeping only the n most recently transmitted messages. This means that when the n+1 message of the session is appended to the dictionary, the first is removed. *Limit the size by using a sliding window of some predefined size. When a message appended to the dictionary makes the dictionary size exceed the window size by, say, x bytes, x bytes are removed from the beginning of the dictionary. Of course, a combination of these techniques is possible. The first message of the session does not have any previous message to use as dictionary. To compress this message efficiently a static dictionary can be used containing strings that can be expected to occur, such as protocol field names, protocol token method, header field names, etc. This part of the dictionary should be kept during the entire session A potential difficulty with binary compression based on previous messages is how to obtain robustness to packet loss. It is essential that the message is decompressed using the same dictionary as the message was compressed with, otherwise the decompression will fail. Thus, a sent message can not be used to compress further messages until it is known that the message has been received at the other entity. This can be solved in different ways: *Entity 2 can send an acknowledgement to entity 1 that it has received a message and entity 1 can then use this message to compress new messages, see Figure 7.1. However, this is not necessary considering that the protocols (mostly) have a strict request/response pattern. Entity 1 Entity 2 | | |-------------m1,C(S)-------------->| |<.....................ACK,m1.......| | | |<------------m2,C(S)---------------| |.......ACK,m2.....................>| | | |-------------m3,C(S,m1)----------->| |<.....................ACK,m3.......| | | |<------------m4,C(S,m2)------------| |.......ACK,m4.....................>| Figure 7.1. Compression using special ACK messages. "m3,C(S,m1)" means message 3 (m3) compressed (C) using Static dictionary (S) and m1 as dictionaries. Hannu, Christoffersson, Svanbro [Page 14] INTERNET-DRAFT Application signaling over cellular links July 19, 2001 *If the compressor and the decompressor at one entity can communicate, then a header is appended to the compressed message. The header holds an identification number for the compressed message and an indication of which previous messages that have been received. Thus, no extra Acknowledgement message is needed. When this message is received by the decompressor the information in the header is passed to the compressor at the same entity, which then can use the indicated previous messages to improve the compression efficiency, see Figure 7.2. Entity 1 Entity 2 | | |--------------m1,C(S)------------->| | | |<-------------m2,C(S),I(m1)--------| | | |--------------m3,C(S,m1),I(m2)---->| | | |<-------------m4,C(S,m2),I(m3)-----| Figure 7.2. Compression, with header indication. "I(m1)" means that entity 2 indicates in its message header that it has received m1. The scheme can be made even more efficient. If the compressor and decompressor at one entity can communicate and also share the dictionary (shared context), received messages, too, can be used to compress new messages. The received message can always be used as dictionary since it is certain that the message is known at the other entity. This is shown in Figure 7.3. Entity 1 Entity 2 | | |----------------m1,C(S)----------->| | | |<-----------m2,C(S,m1),I(m1)-------| | | |----------m3,C(S,m1,m2),I(m2)----->| | | |<-------m4,C(S,m1,m2,m3),I(m3)-----| Figure 7.3. Compression, with header indication and shared context. 7.4 Compression efficiency Compression efficiency of the proposed method depends among other things on the protocol type and the number of messages the session consists of. The first message will not be compressed very much, but the following messages will be compressed considerably. Some initial tests using the LZSS [LZSS] algorithm in the described compression scheme with shared context have indicated compression factors (original message size / compressed message size) of around 1.6 for Hannu, Christoffersson, Svanbro [Page 15] INTERNET-DRAFT Application signaling over cellular links July 19, 2001 the first message and 5-7 for messages at the end of the sessions. The over all compression factors of all the messages in the sessions taken together have been around 3-4. 7.5 Performance after compression If the messages in the session of Figure 4.1. are compressed using the proposed compression algorithm (Figure 7.2) a reduction of the call setup time with almost 2/3 was achieved. Assuming that the SIP/SDP messages can be compressed by a factor of 3.5 (size uncompressed / size compressed), the bits needed for call set up and call are given by Bits = 90x9600/2+4200x8/3.5 = 441600 This leads to a 5% saving in system capacity. Note that the result depend on the assumed mean call length. An increase of the call duration by 25% leads to an increase of system capacity of only 4% while a decrease of the mean call duration by 25% leads to an increase of system capacity of 9%. 8. Relation to header compression A packet consists not only of application headers and application data, but also transport and network headers. Thus, attention should be paid to UDP/IP or TCP/IP as well. One suggestion could be to note that the first part of the packet is UDP/IP or TCP/IP and the second part is e.g. SIP/SDP. Thus, the first part is handled by e.g. ROHC and the second part is compressed by some method similar to the one described in this draft. Figure 8.1. shows a packet before and after compression. CMP is compressed information e.g. SIP, B is the header of the method handling the compression of the second part of the packet, and R is the ROHC header handling the first part of the packet. +--------+---------+ +---+---+----+ | IP/UDP | SIP/SDP |---- compression ---->| R | B | CMP| +--------+---------+ +---+---+----+ Figure 8.1. Packet before and after compression. To identify that a message has been compressed with a method, such as the one described in this draft, there are some alternatives depending on the environment. For example, a link layer identification method could be used, or some negotiation mechanism, or in conjunction with ROHC, a profile number. Hannu, Christoffersson, Svanbro [Page 16] INTERNET-DRAFT Application signaling over cellular links July 19, 2001 9. Conclusion This draft has identified an important problem which needs to be addressed. Using ASCII based signaling and control protocols over cellular access channels will result in long call setup times and long control times. Various possible solutions have been considered, such as increasing the user bit rate, shortening of the round trip time, optimizing message sequences or stripping the protocols. These methods, even if implementable, would lead to increased costs, changes of either systems or protocols or not be transparent. However, the proposed method seems to offer a tractable solution. A method for sequential binary compression of SIP and RTSP sessions has been described which is promising in terms of compression efficiency and hence gives a substantial reduction in delay or needed bandwidth. Even though only SIP, SDP and RTSP are studied in this draft, the proposed compression method could be extended to other ASCII based protocols with similar characteristics, such as HTTP [HTTP]. 10. Security considerations This draft has discussed problems of some signaling protocols in the context of cellular system characteristics and requires no detailed security considerations at the present time. It should, however, be noted that encryption of e.g. SIP-data does not make the compression scheme outlined in this draft impossible in the same manner as encryption makes e.g. header compression impossible. However, encryption does make the outlined compression scheme much less efficient, since the encrypted data will be more or less random without repeated strings. 11. Intellectual property rights considerations Ericsson has filed patent applications that might possibly have technical relations to this contribution. See further: http://www.ietf.org/ietf/IPR/ERICSSON-General 12. Author's Addresses Hans Hannu Tel: +46 920 20 21 84 Ericsson Erisoft AB Lulea, Sweden EMail: Hans.Hannu@epl.ericsson.se Hannu, Christoffersson, Svanbro [Page 17] INTERNET-DRAFT Application signaling over cellular links July 19, 2001 Jan Christoffersson Tel: +46 920 20 28 40 Ericsson Erisoft AB Lulea, Sweden EMail: Jan.Christoffersson@epl.ericsson.se Krister Svanbro Tel: +46 920 20 20 77 Ericsson Erisoft AB Lulea, Sweden EMail: Krister.Svanbro@epl.ericsson.se 13. References [CELL] L. Westberg and M. Lindqvist, Realtime traffic over cellular access networks, Internet Draft (work in progress), June 2001. [GUIDE] J. Rosenberg, H. Schulzrinne, Guidelines for Authors of SIP Extensions, Internet Draft (work in progress), March 2001. [HTTP] R. Fielding, et. al. Hypertext Transfer Protocol û HTTP/1.1. RFC 2616, June 1999. [HUFF] D. A. Huffman, A method for the construction of minimum- redundancy codes. Proc. Institute of Electrical and Radio Engineers. (9) 1952. [IP] J. Postel, Internet Protocol, RFC 791, September 1981. [IPComp] A. Shacham, Et. al. IP Payload Compression Protocol (IPComp) RFC 2393, December 1998. [LZSS] J.A. Storer and T.G. Szimanski, Data Compression via Textual Substitutions. Journal of the ACM 29, 1982. [LZ77] J. Ziv, and A. Lempel, A universal algorithm for sequential data compression. IEEE_Trans. Information Theory, IT-23, 1977. [RTSP] H. Schulzrinne, A. Rao and R. Lanphier, Real Time Streaming Protocol (RTSP). RFC 2326, April 1998. [SDP] M. Handley and V. Jacobson, SDP: Session Description Protocol. RFC 2327, April 1998. [SIP] M. Handley, H. Schulzrinne, E. Schooler and J. Rosenberg, SIP: Session Initiation Protocol. RFC 2543, August 2000. [TCP] J. Postel, Transmission Control Protocol, RFC 793, September 1981. Hannu, Christoffersson, Svanbro [Page 18] INTERNET-DRAFT Application signaling over cellular links July 19, 2001 [TSG] Nortel Networks, A Comparison Between GERAN Packet- Switched Call Setup Using SIP and GSM Circuit-Switched Call Setup Using RIL3-CC, RIL3-MM, RIL3-RR, and DTAP, 3GPP TSG GERAN #2, GP-000508, 6-10 November 2000. [UDP] J. Postel, User Datagram Protocol, RFC 761, August 1980. This Internet-Draft expires in January 2002. Hannu, Christoffersson, Svanbro [Page 19]