Internet DRAFT - draft-hannu-rohc-signaling-cellular
draft-hannu-rohc-signaling-cellular
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
<draft-hannu-rohc-signaling-cellular-02.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 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.
<draft-westberg-realtime-cellular-04.txt>
[GUIDE] J. Rosenberg, H. Schulzrinne, Guidelines for Authors of
SIP Extensions, Internet Draft (work in progress), March
2001. <draft-ietf-sip-guidelines-02.txt>
[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]
