1. Slide title In CAPITALS 50 pt Slide subtitle 32 pt Performance of Signalling Compression in the Third Generation Mobile Network Jouni Mäenpää S-38.310 Thesis seminar on networking technology Helsinki University of Technology 6.6.2005

2. 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-5 20 pt © Ericsson AB 20052005-05-262 About the thesis  Thesis written at Oy LM Ericsson Ab Finland  Supervisor: Professor Raimo Kantola  Instructor: M. Sc. Harri Reiman

3. 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-5 20 pt © Ericsson AB 20052005-05-263 Outline  Background  Research problem and goals  SigComp protocol  SigComp prototype  Performance evaluation  Results  Conclusions

4. 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-5 20 pt © Ericsson AB 20052005-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

5. 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-5 20 pt © Ericsson AB 20052005-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

6. 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-5 20 pt © Ericsson AB 20052005-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

7. 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-5 20 pt © Ericsson AB 20052005-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

8. 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-5 20 pt © Ericsson AB 20052005-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

9. 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-5 20 pt © Ericsson AB 20052005-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

10. 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-5 20 pt © Ericsson AB 20052005-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

11. 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-5 20 pt © Ericsson AB 20052005-05-2611 Results (1/10)  Compression ratio –Basic compression is useless –Only dynamic and shared compressions offer satisfactory compression ratios

12. 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-5 20 pt © Ericsson AB 20052005-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

13. 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-5 20 pt © Ericsson AB 20052005-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

14. 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-5 20 pt © Ericsson AB 20052005-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

15. 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-5 20 pt © Ericsson AB 20052005-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. 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-5 20 pt © Ericsson AB 20052005-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

17. 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-5 20 pt © Ericsson AB 20052005-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

18. 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-5 20 pt © Ericsson AB 20052005-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  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

19. 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-5 20 pt © Ericsson AB 20052005-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

20. 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-5 20 pt © Ericsson AB 20052005-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

21. 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-5 20 pt © Ericsson AB 20052005-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

22. 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-5 20 pt © Ericsson AB 20052005-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

23. 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-5 20 pt © Ericsson AB 20052005-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

24. 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-5 20 pt © Ericsson AB 20052005-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

25. 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-5 20 pt © Ericsson AB 20052005-05-2625