分享
 
 
 

RFC3322 - Signaling Compression (SigComp) Requirements & Assumptions

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

Network Working Group H. Hannu

Request for Comments: 3322 EriCsson

Category: Informational January 2003

Signaling Compression (SigComp) Requirements & Assumptions

Status of this Memo

This memo provides information for the Internet community. It does

not specify an Internet standard of any kind. Distribution of this

memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

The purpose of this document is to outline requirements and

motivations for the development of a scheme for compression and

decompression of messages from signaling protocols. In wireless

environments and especially in cellular systems, e.g., GSM (Global

System for Mobile communications) and UMTS (Universal Mobile

Telecommunications System), there is a need to maximize the transport

efficiency for data over the radio interface. With the introdUCtion

of SIP/SDP (Session Initiation Protocol/Session Description Protocol)

to cellular devices, compression of the signaling messages should be

considered in order to improve both service availability and quality,

mainly by reducing the user idle time, e.g., at call setup.

Table of Contents

1. Introduction....................................................2

1.1. Protocol Characteristics......................................2

1.2. Cellular System Radio Characteristics.........................3

2. Motivation for Signaling Reduction..............................4

2.1. Estimation of Call Setup Delay Using SIP/SDP..................4

3. Alternatives for Signaling Reduction............................6

4. Assumptions.....................................................7

5. Requirements....................................................8

5.1. General Requirements..........................................8

5.2. Performance Requirements......................................9

6. Security Considerations.........................................11

7. IANA Considerations.............................................11

8. References......................................................11

9. Author's Address................................................12

10. Full Copyright Statement.......................................13

1. Introduction

In wireless environments, and especially in cellular systems, such as

GSM/GPRS, there is a need to maximize the transport efficiency of

data over the radio interface. The radio spectrum is rather

eXPensive and must be carefully used. Therefore, the cellular

systems must support a sufficient number of users to make them

economically feasible. Thus, there is a limitation in the per user

bandwidth.

Compressing the headers of the network and transport protocols used

for carrying user data is one way to make more efficient use of the

scarce radio resources [ROHC]. However, compression of the messages

from signaling protocols, such as SIP/SDP, should also be considered

to increase the radio resource usage even further. Compression will

also improve the service quality by reducing the user idle time at

e.g., call setup. When IP is used end-to-end, new applications, such

as streaming, will be brought to tiny end-hosts, such as cellular

devices. This will introduce additional traffic in cellular systems.

Compression of signaling messages, such as RTSP [RTSP], should also

be considered to improve both the service availability and quality.

New services with their corresponding signaling protocols make it

reasonable to consider a scheme that is generic. The scheme should

be generic in the meaning that the scheme can efficiently be applied

to arbitrary protocols with certain characteristics, such as the

ASCII based protocols SIP and RTSP.

1.1. Protocol Characteristics

The following application signaling protocols are examples of

protocols that are expected to be commonly used in the future. Some

of their characteristics are described below.

1.1.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.

1.1.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.

1.1.3 RTSP

The Real Time Streaming Protocol [RTSP] is an application level

protocol for controlling the delivery of data with real-time

properties, such as audio and video. RTSP may use UDP or TCP (or

other) as a transport protocol. RTSP is text based using the ISO

10646 character set in UTF-8 encoding.

1.1.4 Protocol Similarities

The above protocols have many similarities. These similarities will

have implications on solutions to the problems they create in

conjunction with e.g., 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.

- They are geNerous in size in order to provide the necessary

information to the session participants.

- 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.

1.2. 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 %. 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; however, this 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 it might be as high as

200 ms.

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.

2. 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 channel.

2.1 Estimation of Call Setup Delay Using SIP/SDP

Figure 2.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. E.g., a WCDMA system can provide maximum bit rates up to 2

Mbits/s in ideal conditions, but that means one single user would

consume all radio resources in the cell. For a mass market service

such as voice, it is always crucial to reduce the bandwidth

requirements for each user.

Client Network-Proxy Size [bytes] Time [ms]

---------- INVITE ---------> 620 517+70=587

<-- 183 Session progress --- 500 417+70=487

---------- PRACK ----------> 250 208+70=278

<----- 200 OK (PRACK) ------ 300 250+70=320

: :

<...... RSVP and SM .......>

: :

---------- COMET ----------> 620 517+70=587

<----- 200 OK (COMET) ------ 450

+

<------ 180 Ringing -------- 230 567+70=637

---------- PRACK ----------> 250 208+70=278

<----- 200 OK (PRACK) ------ 300

+

<--------- 200 OK ---------- 450 625+70=695

----------- ACK -----------> 230 192+70=262

Figure 2.1. SIP signaling delays assuming a link speed of 9600

bits/sec and a RTT of 140 ms.

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 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 2.1, is typical for a SIP/SDP call setup sequence.

2.1.1 Delay Results

Applying equation 1 to each SIP/SDP message shown in the example of

Figure 2.1 gives a total delay of 4131 ms from the first SIP/SDP

message to the last. The RSVP and Session Management (Radio Bearer

setup), displayed in Figure 2.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.

Another situation that would benefit from reduced signaling is

carrying signaling messages over narrow bandwidth links in mid-call.

For GERAN, this will result in frame stealing with degraded speech

quality as a result.

Thus, solutions are needed to reduce the signaling delay and the

required bandwidth when considering both system bandwidth

requirements and service setup delays.

3. Alternatives for Signaling Reduction

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, e.g., at the 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 the 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 in the short term. Further, the RTT-delay

caused by 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 a row, even though no response has been

received. However, this would entail protocol changes and may be

difficult at the current date.

- Protocol stripping

Removing fields from a message would decrease the size of the

messages to some extent. However, this would cause the loss of

transparency and thus violate the End-to-End principle and is thus

not desirable.

- 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.

4. Assumptions

- Negotiation

How the usage of compression is negotiated is out of the scope for

this compression solution and must be handled by e.g., the

protocol the messages of which are to be compressed.

- Reliable transport

With reliable transport, it is assumed that a transport recovered

from data that is damaged, lost, duplicated, or delivered out of

order, e.g., [TCP].

- Unreliable transport

With unreliable transport, it is assumed that a transport does not

have the capabilities of a reliable transport, e.g., [UDP].

5. Requirements

This chapter states requirements for a signaling compression scheme

to be developed in the IETF ROHC WG.

The requirements are divided into two parts. Section 5.1 sets

general requirements concerning the Internet infrastructure, while

Section 5.2 sets requirements on the scheme itself.

5.1. General Requirements

1. Transparency: When a message is compressed and then decompressed,

the result must be bitwise identical to the original message.

Justification: This is to ensure that the compression scheme will

not cause problems for any current or future part of the Internet

infrastructure.

Note: See also requirement 9.

2. Header compression coexistence: The compression scheme must be

able to coexist with header compression, especially the ROHC

protocol.

Justification: Signaling compression is used because there is a

need to conserve bandwidth usage. In that case, header

compression will likely be needed too.

3a. Compatibility: The compression scheme must be constructed in such

a way that it allows the above protocols' mechanisms to negotiate

whether the compression scheme is to be applied or not.

Justification: Two entities must be able to communicate

regardless if the signaling compression scheme is implemented at

both entities or not.

3b. Ubiquity: Modifications to the protocols generating 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.

Note: This does not preclude making extensions, which are related

to the signaling compression scheme, to existing protocols, as

long as the extensions are backward compatible.

4. Generality: Compression of arbitrary message streams must be

supported. The signaling compression scheme must not be limited

to certain protocols, traffic patterns or sessions. It must not

assume any message pattern to be able to perform compression.

Justification: There might be a future need for compression of

different ASCII based signaling protocols. This requirement will

minimize future work.

Note: This does not preclude optimization for certain streams.

5. Unidirectional routes: The compression scheme must be able to

operate on unidirectional routes, i.e., without explicit feedback

messages from the decompressor.

Note: Implementations on unidirectional routes might possibly

show a degraded performance compared to implementations on bi-

directional routes.

6. Transport: The solution must work for both unreliable and

reliable underlying transport protocols, e.g., UDP and TCP.

Justification: The protocols, which generate the messages that

are to be compressed, may use either an unreliable or a reliable

underlying transport.

Note: This should not be taken to mean that the same set of

solution mechanisms must be used over both unreliable and

reliable transport.

5.2. Performance Requirements

The performance requirements in this section and the following

subsections are valid for both unreliable and reliable underlying

transport.

7. Scalability: The scheme must be flexible to accommodate a range

of compressors/decompressors with varying memory and processor

capabilities.

Justification: A primary target for the signaling compression

scheme is cellular systems, where the mobile terminals have

varying capabilities.

8. Delay: The signaling compression must not noticeably add to the

delay experienced by the end user.

Justification: Reduction of the user experienced delay is the

main purpose of signaling compression.

Note: This requirement is intended to prevent schemes that

achieve compression efficiency at the expense of delay, i.e.,

queuing of messages to improve the compression efficiency should

be avoided.

The following requirements are grouped into two subsections, a

robustness section and a compression efficiency section.

5.2.1. Robustness

The requirements in this section concern the issue of when compressed

messages should be correctly decompressed. The transparency

requirement (first requirement) covers the issue with faulty

decompressed messages.

9. Residual errors: The compression scheme must be resilient against

errors undetected by lower layers, i.e., the probability of

incorrect decompression caused by such undetected errors must be

low.

Justification: A primary target for the signaling compression

scheme is cellular systems, where undetected errors might be

introduced on the cellular link.

10. Error propagation: Propagation of errors due to signaling

compression should be kept at an absolute minimum. Loss or

damage to a single or several messages, between compressor and

decompressor should not prevent compression and decompression of

later messages.

Justification: Error propagation reduces resource utilization and

quality.

11. Delay: The compression scheme must be able to perform compression

and decompression of messages under all expected delay

conditions.

5.2.2. Compression Efficiency

This section states requirements related to compression efficiency.

12. Message loss: Loss or damage to a single or several messages, on

the link between compressor and decompressor, should not prevent

the usage of later messages in the compression and decompression

process.

13. Moderate message misordering: The scheme should allow for the

correct decompression of messages, that have been moderately

misordered (1-2 messages) between compressor and decompressor.

The scheme should not prevent the usage of later messages in the

compression and decompression process.

Justification: Misordering is frequent on the Internet, and this

kind of misordering is common.

6. Security Considerations

A protocol specified to meet these requirements must be able to cope

with packets that have undergone security measures, such as

encryption, without adding any security risks. This document, by

itself however, does not add any security risks.

7. IANA Considerations

A protocol which meets these requirements may require the IANA to

assign various numbers. This document by itself however, does not

require any IANA involvement.

8. References

[ROHC] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,

Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K.,

Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke,

T., Yoshimura, T. and H. Zheng, "RObust Header Compression

(ROHC): Framework and four profiles: RTP, UDP, ESP, and

uncompressed", RFC3095, July 2001.

[RTSP] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming

Protocol (RTSP)", RFC2326, April 1998.

[SDP] Handley, H. and V. Jacobson, "SDP: Session Description

Protocol", RFC2327, April 1998.

[SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,

Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:

Session Initiation Protocol", RFC3261, June 2002.

[UDP] Postel, J., "User Datagram Protocol", STD 6, RFC768, August

1980.

[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC793,

September 1981.

[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.

9. Author's Address

Hans Hannu

Box 920

Ericsson AB

SE-971 28 Lulea, Sweden

Phone: +46 920 20 21 84

EMail: hans.hannu@epl.ericsson.se

10. Full Copyright Statement

Copyright (C) The Internet Society (2003). All Rights Reserved.

This document and translations of it may be copied and furnished to

others, and derivative works that comment on or otherwise explain it

or assist in its implementation may be prepared, copied, published

and distributed, in whole or in part, without restriction of any

kind, provided that the above copyright notice and this paragraph are

included on all such copies and derivative works. However, this

document itself may not be modified in any way, such as by removing

the copyright notice or references to the Internet Society or other

Internet organizations, except as needed for the purpose of

developing Internet standards in which case the procedures for

copyrights defined in the Internet Standards process must be

followed, or as required to translate it into languages other than

English.

The limited permissions granted above are perpetual and will not be

revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an

"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING

TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING

BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF

MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFCEditor function is currently provided by the

Internet Society.

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有