Performance of Signalling Compression in the Third Generation Mobile Network

1. 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. About the thesis • Thesis written at Oy LM Ericsson Ab Finland • Supervisor: Professor Raimo Kantola • Instructor: M. Sc. Harri Reiman

3. Outline • Background • Research problem and goals • SigComp protocol • SigComp prototype • Performance evaluation • Results • Conclusions

4. 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. 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. 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. 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. 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. 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. 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. Results (1/10) • Compression ratio • Basic compression is useless • Only dynamic and shared compressions offer satisfactory compression ratios

12. 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. 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. Results (4/10) • Compressibility of different signalling sequences • The longest sequences achieve best compression ratios because their last messages can be compressed very efficiently • Compressibility of the registration sequence is very low

15. 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. Results (6/10) • 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 • Delay caused by the system

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