performance of signalling compression in the third generation mobile network

Slide titleIn CAPITALS

50 pt

Slide subtitle 32 pt

Performance of Signalling Compression in the Third

Generation Mobile NetworkJouni Mäenpää

S-38.310 Thesis seminar on networking technology

Helsinki University of Technology

6.6.2005

Top right corner for field-mark, customer or partner logotypes. See Best practice for example.

Slide title 40 pt


Text 24 pt

Bullets level 2-520 pt

© Ericsson AB 2005 2005-05-262

About the thesis

Thesis written at Oy LM Ericsson Ab Finland Supervisor: Professor Raimo Kantola Instructor: M. Sc. Harri Reiman


Slide title 40 pt


Text 24 pt


© Ericsson AB 2005 2005-05-263

Outline

Background Research problem and goals SigComp protocol SigComp prototype Performance evaluation Results Conclusions


Slide title 40 pt


Text 24 pt


© Ericsson AB 2005 2005-05-264

Background (1/2)

Session Initiation Protocol (SIP) is used for call control in the third generation mobile network starting from the Third Generation Partnership Project (3GPP) release 5 onwards

SIP messages use textual encoding, which is less efficient than binary encoding that e.g. GSM uses, and results in large message sizes

Call setup time of a release 5 network can be multiple times longer than in GSM because a large amount of signalling data needs to be transmitted over the low-bandwidth air interface

A solution is needed to reduce the call setup time


Slide title 40 pt


Text 24 pt


© Ericsson AB 2005 2005-05-265

Background (2/2)

Signalling Compression (SigComp) attempts to reduce the call setup time through the compression of SIP signalling messages

SigComp provides a framework for the compression of application-layer signalling between two network elements

SigComp is a mandatory part of 3GPP release 5 IP Multimedia Subsystem (IMS) – a new core network domain controlling voice and multimedia calls and sessions as well as interconnection to other networks

Compression is applied between a mobile terminal and a Proxy Call Session Control Function (P-CSCF)

– The P-CSCF is the first contact point for the terminal within the IMS


Slide title 40 pt


Text 24 pt


© Ericsson AB 2005 2005-05-266

Research problem and goals Because SigComp is a new feature, there exists a need

to study its performance The main goal was to evaluate SigComp performance

through measurements performed on a SigComp prototype that was implemented

The secondary goals were to– Study the way SigComp functionality can be implemented– Examine the way the load SigComp compression and

decompression places can be reduced


Slide title 40 pt


Text 24 pt


© Ericsson AB 2005 2005-05-267

SigComp protocol (1/2) Most important components of the

SigComp architecture are Universal Decompressor Virtual Machine (UDVM), compressor and state handler

SigComp messages carry bytecodes, which contain instructions needed to decompress the payload of the messages

Decompression algorithms are written in UDVM assembly language and compiled to bytecode using a UDVM interpreter

UDVM is a virtual machine, which decompresses messages by executing bytecodes

Compressor compresses SIP messages and creates SigComp messages

State handler is used to store state information between the messages of a SIP dialog

Compressordispatcher

Compressor 1

Compressor 2

State1

State2

Decompressordispatcher

Decompressor(UDVM)

State handler

Local application(SIP)

Transport layer(e.g. UDP)

Application messageandcompartment identifier

Decompressedmessage

Compartmentidentifier

SigComp message SigComp message

SigComp layer


Slide title 40 pt


Text 24 pt


© Ericsson AB 2005 2005-05-268

SigComp protocol (2/2)

SigComp specifies different compression mechanisms Basic compression uses message-by-message

compression In static compression, messages are compressed

relative to the static SIP and Session Description Protocol (SDP) dictionary specified in RFC 3485

In stateful versions of basic and static compressions, the bytecode is saved between messages

In dynamic compression, previously sent messages are used in the compression process

In shared compression, also received messages are utilised in the compression process


Slide title 40 pt


Text 24 pt


© Ericsson AB 2005 2005-05-269

SigComp prototype

Was implemented as part of the thesis work A multithreaded program using a thread pool whose

size is specified at start time– One active thread per incoming message

Compressor uses a modified version of the Lempel-Ziv-Storer-Szymanski (LZSS) compression algorithm

– Uses a hash table in longest-match string searching

The state handler and database for compressors are implemented as shared resources

Acts as a simple P-CSCF Decompresses SigComp traffic initiating from the

access network side and compresses SIP traffic terminating to the access network side


Slide title 40 pt


Text 24 pt


© Ericsson AB 2005 2005-05-2610

Performance evaluation Both the performance of the SigComp protocol and the

SigComp prototype were evaluated Different SIP signalling sequences were used

– The results presented here are for video call establishment in a 3GPP release 5 network

A network of three computers was built for the measurements:

– Two nodes generating traffic: one acting as the access network side and one as the core network side

– One node acted as a P-CSCF and was the system under test Either an Intel Pentium 4 Hyper-Threading 3.0 GHz or an

Intel Pentium 4 2.66 GHz The performance of these two processors was compared


Slide title 40 pt


Text 24 pt


© Ericsson AB 2005 2005-05-2611

Results (1/10) Compression ratio

– Basic compression is useless– Only dynamic and shared compressions offer satisfactory

compression ratios

0,00 %10,00 %20,00 %30,00 %40,00 %50,00 %60,00 %70,00 %80,00 %90,00 %

100,00 %

statelessbasic

statefulbasic

statelessstatic

statefulstatic

dynamic shared

Mechanism

Com

pre

ssio

n ratio

--

DMS 4096 DMS 8192 DMS16384


Slide title 40 pt


Text 24 pt


© Ericsson AB 2005 2005-05-2612

Results (2/10) Compression time

– The better compression ratios of dynamic and shared compressions do not come without a cost

– Increased compression time is explained by the calculation of Secure Hash Algorithm 1 (SHA-1) message digest values and by insertion of shared states to the hash table

0,00

5,00

10,00

15,00

20,00

25,00

30,00

35,00

basic static dynamic shared

MechanismC

om

pre

ssio

n tim

e [m

s] --

DMS 4096 bytes DMS 8192 bytes DMS 16384 bytes


Slide title 40 pt


Text 24 pt


© Ericsson AB 2005 2005-05-2613

Results (3/10) Decompression time

– Dynamic and shared compressions are fastest because they produce more and longer matches

– Long matches are fast to decode because the UDVM needs to do less fetch operations to its decompression dictionary

0,00

5,00

10,00

15,00

20,00

25,00

30,00

basic static dynamic shared

Mechanism

Dec

om

pre

ssio

n tim

e [m

s] --

DMS 4096 bytes DMS 8192 bytes DMS 16384 bytes


Slide title 40 pt


Text 24 pt


© Ericsson AB 2005 2005-05-2614

Results (4/10)

– The longest sequences achieve best compression ratios because their last messages can be compressed very efficiently

– Compressibility of the registration sequence is very low

Compressibility of different signalling sequences

0100020003000400050006000700080009000

1000011000

Bas

ic v

oice

call

Bas

ic v

ideo

call PoC

sess

ion

Reg

istrat

ion

3GP

P v

ideo

call

3GP

P w

ithR

E-IN

VIT

E

3GP

P w

ithR

E-IN

VIT

E&

PR

AC

K

Message sequence

Length

[byte

s] -

-

Size uncompressed Size compressed


Slide title 40 pt


Text 24 pt


© Ericsson AB 2005 2005-05-2615

Results (5/10) Impact on Radio Access Network (RAN) delay

– The improvement SigComp offers is greatest when the bandwidth of the signalling link is low

– If the link has a high bandwidth (>64 kbps), the improvement SigComp offers may not be enough to justify the use of the protocol

16 kbps

12,2 kbps

9,6 kbps

256 kbps128 kbps

64 kbps

32 kbps

0,00

1,00

2,00

3,00

4,00

5,00

6,00

7,00

8,00

9,00

10,00

11,00

0 25 50 75 100 125 150 175 200 225 250 275

Signalling link bit rate [kbps]

One-w

ay R

AN

dela

y [s]

---

Uncompressed Compressed


Slide title 40 pt


Text 24 pt


© Ericsson AB 2005 2005-05-2616

Results (6/10) Delay caused by the system

– Time in system starts to grow when the traffic load increases because a higher number of messages are processed concurrently, meaning that each thread gets a smaller share of the available CPU time

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

50 100 250 375 500 750 1000 1250 1500

Number of simultaneous video calls

Tim

e in

sys

tem

[us]

__

_

Processing time Time in buffer


Slide title 40 pt


Text 24 pt


© Ericsson AB 2005 2005-05-2617

Results (7/10) Memory consumption

– When all SigComp mechanisms are used, the memory requirement is high because a large amount of state information needs to be stored for each ongoing session

177

297

547

781

0

100

200

300

400

500

600

700

800

900

250 500 1000 1500

Number of video calls in system

Mem

ory

usa

ge

[MB

]

--


Slide title 40 pt


Text 24 pt


© Ericsson AB 2005 2005-05-2618

Results (8/10) Thread switches and

queuing for access to shared resources add overhead

An example: the ratio of the average processing time of a message and the average number of active workers with 5000 voice calls in system

The time one thread uses increases after thread pool size three

700

720

740

760

780

800

820

840

860

880

0 50 100 150 200 250 300 350 400 450 500

Size of thread pool

Pro

cess

ing tim

e / n

um

ber

of ac

tive

work

ers

-

-

With a thread pool of size three, the average number of active threads is close to the value two, meaning that a Hyper-Threading CPU having two logical processors can execute one thread on each of its logical processors with minimum amount of thread switches


Slide title 40 pt


Text 24 pt


© Ericsson AB 2005 2005-05-2619

Results (9/10)

Time in system for different thread pool sizes, 5000 calls– A high number of threads required to keep the time messages

wait for service low– However, with a high number of threads, the time in system

increases because of the overhead

0

2000

4000

6000

8000

10000

12000

1 2 3 5 7 10 11 12 15 25 50 100 250 500

Size of thread pool

Tim

e [u

s] --

Processing time Time in buffer


Slide title 40 pt


Text 24 pt


© Ericsson AB 2005 2005-05-2620

Results (10/10)

Hyper-Threading Pentium 4 vs. a regular Pentium 4, voice calls

– The gains of using a Hyper-Threading processor are the bigger the more simultaneously active threads the system has

0

500

1000

1500

2000

2500

3000

3500

250 500 750 1000 1250 1500

Number of simultaneous voice calls

Tim

e in

sys

tem

[us]

--

-

Intel Pentium 4 Hyper-Threading 3.0 GHz Intel Pentium 4 2.66 GHz


Slide title 40 pt


Text 24 pt


© Ericsson AB 2005 2005-05-2621

Conclusions (1/3) SigComp can only affect the RAN delay; the core

network delay, bearer establishment and the overhead added by lower protocol layers will not be affected

Compression ratios that would reduce the size of SIP signalling messages to the same level as in the case of GSM seem unachievable

The memory requirement of SigComp is large, because a large amount of state information must be stored for each session

SigComp is vulnerable to Denial-of-Service (DoS) attacks: in an attack that was simulated, it was observed that a stream of eight regular SIP messages containing looping code per second was enough to consume all the capacity of the P-CSCF


Slide title 40 pt


Text 24 pt


© Ericsson AB 2005 2005-05-2622

Conclusions (2/3) SigComp requires additional protection against DoS

attacks, e.g. a bytecode verifier Processor load, memory usage and time in system

depend highly on the sizes and number of messages in the SIP signalling sequence

It is beneficial to use a processor supporting simultaneous multithreading

It is not unusual that the decompression of a message takes longer than its compression, suggesting that the use of a fixed decompression algorithm instead of the UDVM would be significantly more efficient

Shared resources have the potential to become the bottlenecks of SigComp unless they are not designed carefully


Slide title 40 pt


Text 24 pt


© Ericsson AB 2005 2005-05-2623

Conclusions (3/3)

To achieve optimum performance, one should– Use an efficient searching technique such as hashing in the

compressor– Restrict the amount of data used from the static dictionary– Restrict the length of shared states or to use only dynamic

compression– Use shared compression only for the first few messages in

each direction– Restrict the length of substitutions to 258 bytes– Use a decompression memory size that is optimal for the

traffic the system serves. A DMS of 4096 bytes provided good results

– Use reliable transport– Redesign inefficient signalling flows


Slide title 40 pt


Text 24 pt


© Ericsson AB 2005 2005-05-2624

Future work

Performance of SigComp in 3G mobile terminals supporting SIP

SigComp security should be improved– e.g. further protection against DoS attacks

Parallel use of header compression and SigComp SigComp shared resources

– scheduling policies– advanced data structures

performance of signalling compression in the third generation mobile network

Documents