Slide title In CAPITALS 50 pt Slide subtitle 32 pt Performance of Signalling Compression in the...
-
Upload
cuthbert-montgomery -
Category
Documents
-
view
212 -
download
0
Transcript of Slide title In CAPITALS 50 pt Slide subtitle 32 pt Performance of Signalling Compression in the...
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
Slide subtitle 24 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
Top right corner for field-mark, customer or partner logotypes. See Best practice for example.
Slide title 40 pt
Slide subtitle 24 pt
Text 24 pt
Bullets level 2-520 pt
© Ericsson AB 2005 2005-05-263
Outline
Background Research problem and goals SigComp protocol SigComp prototype Performance evaluation Results Conclusions
Top right corner for field-mark, customer or partner logotypes. See Best practice for example.
Slide title 40 pt
Slide subtitle 24 pt
Text 24 pt
Bullets level 2-520 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
Top right corner for field-mark, customer or partner logotypes. See Best practice for example.
Slide title 40 pt
Slide subtitle 24 pt
Text 24 pt
Bullets level 2-520 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
Top right corner for field-mark, customer or partner logotypes. See Best practice for example.
Slide title 40 pt
Slide subtitle 24 pt
Text 24 pt
Bullets level 2-520 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
Top right corner for field-mark, customer or partner logotypes. See Best practice for example.
Slide title 40 pt
Slide subtitle 24 pt
Text 24 pt
Bullets level 2-520 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
Top right corner for field-mark, customer or partner logotypes. See Best practice for example.
Slide title 40 pt
Slide subtitle 24 pt
Text 24 pt
Bullets level 2-520 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
Top right corner for field-mark, customer or partner logotypes. See Best practice for example.
Slide title 40 pt
Slide subtitle 24 pt
Text 24 pt
Bullets level 2-520 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
Top right corner for field-mark, customer or partner logotypes. See Best practice for example.
Slide title 40 pt
Slide subtitle 24 pt
Text 24 pt
Bullets level 2-520 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
Top right corner for field-mark, customer or partner logotypes. See Best practice for example.
Slide title 40 pt
Slide subtitle 24 pt
Text 24 pt
Bullets level 2-520 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
Top right corner for field-mark, customer or partner logotypes. See Best practice for example.
Slide title 40 pt
Slide subtitle 24 pt
Text 24 pt
Bullets level 2-520 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
Top right corner for field-mark, customer or partner logotypes. See Best practice for example.
Slide title 40 pt
Slide subtitle 24 pt
Text 24 pt
Bullets level 2-520 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
Top right corner for field-mark, customer or partner logotypes. See Best practice for example.
Slide title 40 pt
Slide subtitle 24 pt
Text 24 pt
Bullets level 2-520 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
Top right corner for field-mark, customer or partner logotypes. See Best practice for example.
Slide title 40 pt
Slide subtitle 24 pt
Text 24 pt
Bullets level 2-520 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
Top right corner for field-mark, customer or partner logotypes. See Best practice for example.
Slide title 40 pt
Slide subtitle 24 pt
Text 24 pt
Bullets level 2-520 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
Top right corner for field-mark, customer or partner logotypes. See Best practice for example.
Slide title 40 pt
Slide subtitle 24 pt
Text 24 pt
Bullets level 2-520 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
]
--
Top right corner for field-mark, customer or partner logotypes. See Best practice for example.
Slide title 40 pt
Slide subtitle 24 pt
Text 24 pt
Bullets level 2-520 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
Top right corner for field-mark, customer or partner logotypes. See Best practice for example.
Slide title 40 pt
Slide subtitle 24 pt
Text 24 pt
Bullets level 2-520 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
Top right corner for field-mark, customer or partner logotypes. See Best practice for example.
Slide title 40 pt
Slide subtitle 24 pt
Text 24 pt
Bullets level 2-520 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
Top right corner for field-mark, customer or partner logotypes. See Best practice for example.
Slide title 40 pt
Slide subtitle 24 pt
Text 24 pt
Bullets level 2-520 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
Top right corner for field-mark, customer or partner logotypes. See Best practice for example.
Slide title 40 pt
Slide subtitle 24 pt
Text 24 pt
Bullets level 2-520 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
Top right corner for field-mark, customer or partner logotypes. See Best practice for example.
Slide title 40 pt
Slide subtitle 24 pt
Text 24 pt
Bullets level 2-520 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
Top right corner for field-mark, customer or partner logotypes. See Best practice for example.
Slide title 40 pt
Slide subtitle 24 pt
Text 24 pt
Bullets level 2-520 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