Impact and Multiplexing of SIP Signaling in GSM

Transcription

1 LiU-ITN-TEK-A--09/009--SE Impact and Multiplexing of SIP Signaling in GSM Pasha Ayani Petter Gustafsson Department of Science and Technology Linköping University SE Norrköping, Sweden Institutionen för teknik och naturvetenskap Linköpings Universitet Norrköping

2 LiU-ITN-TEK-A--09/009--SE Impact and Multiplexing of SIP Signaling in GSM Examensarbete utfört i datavetenskap vid Tekniska Högskolan vid Linköpings universitet Pasha Ayani Petter Gustafsson Handledare Sofia Svedevall Examinator Di Yuan Norrköping

3 Upphovsrätt Detta dokument hålls tillgängligt på Internet eller dess framtida ersättare under en längre tid från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida Copyright The publishers will keep this document online on the Internet - or its possible replacement - for a considerable time from the date of publication barring exceptional circumstances. The online availability of the document implies a permanent permission for anyone to read, to download, to print out single copies for your own use and to use it unchanged for any non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional on the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its WWW home page: Pasha Ayani, Petter Gustafsson

4 Abstract By the introduction of IMS, future mobile voice traffic will gradually be based on IP. This means that GSM has to undergo further development in order to stay compatible with other mobile networks. Before introducing VoIP into GSM, the impact of the SIP signaling needs to be investigated. Therefore, the objective of this master thesis is to simulate and evaluate how SIP signaling could be multiplexed with VoIP traffic and other MMTel services in the GSM network. In order to multiplex the SIP signaling with other traffic types, new delay sensitive scheduling algorithms have been derived and analyzed along with a dynamic allocation algorithm. The allocation algorithm provide each mobile user with a number of timeslots and frequencies used to transmit its data, while the scheduling algorithms are used to conclude which user that should get the highest priority when several users try to transmit data at the same time and on the same frequency. Unfortunately, it was not possible to receive any reliable data within the given timeframe due to bugs and errors in the simulator software. Therefore, the conclusions in this master thesis are based on our expectations on such simulations. The conclusion is that in order to maximize the number of VoIP users in the GSM system, the presence signaling should be lower prioritized than VoIP and SIP signaling. It is also concluded that the delay sensitive scheduler which is dependent on previous penalties in both the UL and DL scheduling is to be preferred when high multiplexing levels are reached. Furthermore, the throughput of the downprioritized MMTel service should not be expected to be high when the VoIP traffic is intense. 1

5

6 Sammanfattning Framtidens taltrafik i mobila nätverk kommer alltmer vara IP-baserade. Detta betyder att GSM måste kompletteras med nya funktioner för att förbli kompatibelt med andra mobila nätverk. I samband med introduktionen av VoIP i GSM kommer ytterligare signalering tilkomma i form av SIP-signalering. Detta examensarbete syftar till att undersöka hur SIP-signaleringen skall multiplexas i GSM med VoIP trafik och andra MMTel tjänster. För att uppnå en effektiv multiplexing, och kunna maximera antalet VoIPanvändare, har nya fördröjningskänsliga algoritmer för schemaläggning och allokering tagits fram och utvärderats. En dynamisk allokeringsalgoritm har tagits fram för att på ett effektivt sätt kunna tilldela varje användare ett antal tidluckor och frekvenser för att skicka data. Algoritmerna för schemaläggning används för att avgöra prioriteten av varje användare då flera användare vill skicka data i samma tidpunkt och på samma frekvens. Tyvärr har det inte varit möjligt att uppnå några tillförlitliga resultat inom den givna tidramen. Via simuleringar upptäcktes felaktigheter i simulatorn som gjorde att resultaten blev både oberäkneliga och opålitliga. Slutsatserna i detta arbete baseras därför på de förväntningar vi har på de tänkta simuleringarna och inte på verkliga data. Slutsatserna blev då att den fördröjningskänsliga schemaläggaren med minne i både upplänks- och nedlänksschemaläggningen är att föredra då höga multiplexingsnivåer uppnås. Vidare så bör prioriteten av presence-signalering vara lägre än prioriteten av VoIP och SIP-signalering. Datahastigheten av en lågt prioriterad MMTel-tjänst bör ej heller förväntas vara snabb då intensiteten av VoIP-trafik är hög. 3

7

8 Acknowledgments First of all we would like to thank our head supervisor at Ericsson AB, Sofia Svedavall, for all the support and patient listening during this thesis work. Secondly, we would like to send a special thanks to Andreas Bergström, Thommy Jakobsson, Eric Nordström and Mats Wernersson for helping us understand and troubleshoot the simulator software. Lastly, we would like to thank our examiner Di Yuan at Linköpings University for understanding our situation and helping us find an alternative way to finish this thesis work when the simulator software turned out to be faulty. 5

9

10 Contents 1 Introduction Problem description Thesis objective & work description Outline of report Background GSM GSM network architecture Time Division Multiple Access (TDMA) Channels Channel allocation GPRS GPRS network architecture The GPRS protocol stack Quality of Service (QoS) Scheduling concept Session Initiation Protocol (SIP) SIP network architecture SIP request methods SIP responses SIP presence signaling Multiplexing methods General Allocation algorithm MS multislot classes Scheduling Scheduling algorithms Traffic Models General VoIP traffic model SIP traffic model Presence traffic model Web traffic model

11 8 Contents 5 Traffic scenarios Stages Stage 1 - Only VoIP Stage 2 -VoIP & SIP Stage 3 -VoIP, SIP & Presence Stage 4 - VoIP, SIP, Presence & MMTel Simulations Stage 1 - Only VoIP Results - Stage Stage 2 - VoIP & SIP Results - Stage Stage 3 - VoIP, SIP & Presence Results - Stage Stage 4 - VoIP, SIP, Presence & MMTel Results - Stage Discussion Expectations & predictions Conclusions & recommendations Future work Bibliography 57 A Abbreviations 59

12 Chapter 1 Introduction This chapter describes the purpose and the problem description of this master thesis. An introduction to the subject is also provided. 1.1 Problem description Mobile communication systems are one of the fastest growing technologies today. The impact of mobile systems has been colossal; not only in terms of science and research, but also by creating a whole new necessity among ordinary people. To be able to call your friends and co-workers whenever you want is nowadays one of the most natural things in the world. Since more and more people around the world use these mobile networks, new expectations and demands on these networks arise. Mobile network suppliers are forced to adhere to these demands and thereby continuously develop and improve the capacity and quality of their systems. Even though modern mobile network technologies, such as 3G, have been introduced, the most common type of mobile networks today is still the GSM network. This means that a relatively old system, with limited data bit rates, in some way has to be improved in order to keep up the pace and stay compatible with the newer systems. By the introduction of the IP Multimedia Subsystem (IMS), future voice traffic will gradually be based on IP. This means that GSM has to be complemented with new features in order to stay compatible. Many studies have previously been done in GSM concerning user performance, Voice over IP (VoIP) capacity and throughput of multimedia telephony (MMTel) services, but one often neglected aspect is the impact of the Session Initiation Protocol (SIP) signaling. Therefore it is interesting to investigate how SIP signaling will affect system capacity and end-user performance. 9

13 10 Introduction 1.2 Thesis objective & work description The objective of this master thesis is to evaluate how SIP signaling could be multiplexed with VoIP traffic and MMTel services in the GSM network. The multiplexing method should maximize the number of VoIP users in the system while maintaining reasonable levels of packet loss and packet delay. In order to fulfill these objectives the work has been conducted in the following steps: Study literature in order to get insights and knowledge about the GSM radio network. Study reports and other finalized studies in the MMTel & SIP area and learn about multiplexing methods used in GSM today. Derive new methods for scheduling and allocation, taking SIP and QoS into consideration. Implement the derived method for allocation in the simulator software. Through simulations determine how SIP and MMTel services should be multiplexed with VoIP traffic. Analyze simulation results and draw conclusions about the impact of SIP signaling on VoIP capacity. 1.3 Outline of report The structure of this report is laid out so that Chapter 2 gives an overview of the GSM/GPRS radio network and SIP. Chapter 3 describes the multiplexing methods, including scheduling and allocation algorithms. Further on, Chapter 4 specifies the different traffic models used to define the users in the simulations. Chapter 5 presents the different simulation stages while Chapter 6 presents the expected results which are then analyzed in Chapter 7.

14 Chapter 2 Background This chapter begins by providing an overview of the GSM radio network and its extension GPRS. It continues with a theoretical background of SIP to give the reader the basic understanding of the signaling behavior. For more details regarding the GSM/GPRS radio network see [4], [5]. 2.1 GSM The development of mobile systems is often divided into different generations. The 1G (1st generation of wireless mobile networks) networks are analogue while the 2G (2nd generation of wireless mobile networks) networks are digital. Global Service for Mobile communication (GSM) is an example of a 2G technology. The demand for wireless internet connections and increased capacity of GSM have led to the development of GPRS. This system is based on data packets and is often referred to as a 2,5G technology. GSM on the other hand relies on circuit switched traffic (CS) and therefore doesn t use any packet data. When a CS call is made between two users, the resources needed for the call are occupied for the entire session GSM network architecture The network architecture which provides GSM with radio coverage and enables two end-users to contact each other is composed of several different hardware and software nodes. Figure 2.1 gives an overview of this network architecture. 11

15 12 Background PSTN Air interface MSC VLR MS BSC BTS Figure 2.1. The GSM network architecture. Mobile station (MS) An MS is a piece of equipment used by an end-user to communicate with the mobile network. This equipment is most commonly a mobile phone. The capacity of an MS is defined by its multislot class (see Section 3.3). Base transceiver station (BTS) The radio waves between the mobile station and the radio network are controlled and transmitted by the BTS. It is composed of radio equipment such as antennas and transceivers which are needed in order to provide radio coverage in the particular area. Several BTSs can be controlled by a single BSC, and together, these two nodes compose the Base Station System (BSS). Base station controller (BSC) The BSC is a high capacity switch whose function is to handle all the radio related functions in a GSM network. For example, it controls handovers when an MS is transferred between different cells. Several BSCs can be controlled by one single MSC. Mobile services switching center & visitor location register (MSC/VLR) The MSC provides the mobile system with telephony switching functionality. It controls calls to and from other telephony and data networks, such as the Public

16 2.1 GSM 13 Switched Telephone Network (PSTN) which can be described as the telephony networks equivalence to the Internet. The VLR is a database and is often integrated into the MSC. Its function is to provide information about the subscribers visiting the particular MSC service area. Cells and location areas (LAs) To describe the geographical coverage area of the GSM network structure, one should be familiar with cells and LAs. A cell can be described as the geographical area where radio coverage of a BTS is provided. Usually, three adjacent cells are covered by three BTSs located at joining point between the cells. Furthermore, several BTSs and their cells are defined as an LA as can be seen in Figure 2.2. LA 3 LA 1 MSC VLR LA 2 Figure 2.2. Cells and location areas (LAs) Time Division Multiple Access (TDMA) There are different technologies that utilize the resources in a radio network in different ways; GSM uses a technology called TDMA. The principle of this technology is that one single frequency is divided into several different periods in time. One of these periods in time is called a timeslot (TS). TSs enables several users to transmit and receive data on the same frequency. When a call is made, an MS user is assigned TSs on two different frequencies. One frequency is used to transmit

17 14 Background data; this frequency is called the uplink (UL) frequency. The other frequency is used for receiving data; this frequency is called the downlink (DL) frequency. In GSM, eight timeslots are defined as a TDMA frame. This enables eight different calls to be carried by one single frequency. The data sent on a single timeslot, during a single TDMA frame, is called a burst and is composed of a number of bits. In a normal burst the tail bits (TBs) are placed at the beginning and end of the burst to indicate the start and stop of the TS. The training sequence is a bit pattern that is known by both the MS and the BTS. The receiver uses this pattern to determine and correct any error affected bits that may have occurred during the transmission on the air interface. The data bits are the actual information to be sent while the guard period is an empty period used to separate the information on adjacent timeslots. Figure 2.3 show the structure of a normal burst. Furthermore, it takes four bursts to transmit an entire radio block. Although, when using EDGE (see Section 2.2) this can be modified by using Reduced Transmission Time Interval (RTTI) which means that the bursts are divided between two consecutive TSs. This means that only two TDMA frames (instead of four) are needed to transmit an entire radio block. 0 1 TDMA frame = 8 timeslots (~4,615 ms) timeslot = 156,25 bit durations (~0,577 ms) Normal burst TB 3 Data bits 57 Training seq Data bits 57 TB 3 GP 8,25 Figure 2.3. The relationship between a normal burst and a TDMA frame Channels There are two types of channels; physical channels and logical channels. Each physical channel is a timeslot on a TDMA frame, which means that there are eight physical channels on each TDMA frame. These physical channels are used for transferring different types of data. Depending on what type of data is being sent, different types of logical channels are mapped onto the physical channels. There are two basic groups of logical channels; control channels and traffic channels. The control channels are used for the transfer of control information which can be LA identity information, cell identity information, call setup procedures etc. The traffic channels on the other hand are used for transferring the user traffic data, for instance speech information. When utilizing GPRS and packet switched traffic (see Section 2.2), the traffic channels are called packet data channels (PDCHs).

18 2.2 GPRS Channel allocation Channel allocation is the functionality that provides a certain user with a radio resource to be able to send and receive its data. A radio resource is composed of one, or several, frequencies and timeslots. 2.2 GPRS The General Packet Radio Service (GPRS) is often described as 2,5G, enabling GSM mobile users to send packet data. Traffic sent as packet data is called packet switched traffic (PS) and is different from CS traffic; instead of reserving the full bandwidth of a channel for the entire duration of the call, PS traffic let multiple users share the same channel by only using bandwidth whenever they actually are sending any packets. In order to achieve enhanced data rates in the GSM/GPRS network, new modulation methods and channel coding schemes have been introduced. This feature is called Enhanced Data rates for GSM Evolution (EDGE) and is capable to triple the data rates per user (compared to normal GPRS). The RTTI feature is also a part of the EDGE technology and is a prerequisite for using VoIP and advanced MMTel services such as video streaming, web surfing and multimedia messages in the GSM network. For further information see [6] GPRS network architecture When introducing GPRS to the GSM network a couple of new nodes are introduced in the network, as can be seen in Figure 2.4. Serving GPRS Support Node (SGSN) The SGSN provides packet routing and functions for packet transfer through its geographical service area. It also handles other functions such as authentication and charging. Gateway GPRS Support Node (GGSN) The GGSN acts as the interface between the GPRS network and other external IP-based networks. The GGSN handles routing of incoming external traffic and exchanges routing information with external IP-based networks. The backbone network is the collection of connections that provide the GGSN and SGSN with a communication path.

19 16 Background PSTN External IP-based networks GGSN Air interface MSC VLR Backbone network MS BSC SGSN BTS Figure 2.4. The GPRS network architecture The GPRS protocol stack In order to understand how the user data traverses from the MS, through the air to the BSS it is important to know how the GPRS protocol stack is built up. Figure 2.5 shows the different protocols that are included. At the top is the application layer where the actual information bits come from. These bits include application information as well as information provided by other protocols that are needed in order to define the traffic flow (for instance, UDP/TCP and SIP). Then the IP protocol bits are attached, which provides with address information. These bits are then passed down further in the protocol stack and added to the Subnetwork Dependent Convergence Protocol (SNDCP) bits. This protocol compresses and decompresses user data and protocol control information [2]. The LLC layer is primarily concerned with functions related to multiplexing/demultiplexing, error control and ciphering/deciphering SNDCP packets. After the LLC layer the data bits pass through the RLC/MAC layer. RLC stands for Radio Link Control and provides a reliable radio link between the MS and BTS. MAC stands for Medium Access Control and regulates the access to the radio interface. Thereafter the assembled radio block is sent over the air interface on the given frequency and timeslot to the BSS.

20 2.2 GPRS 17 Application Application IP Application IP SNDCP IP Application SNDCP LLC SNDCP IP Application LLC RLC/MAC LLC SNDCP IP Application RLC MAC RLC MAC Relay BSSGP Network Service GSM RF GSM RF L1bis MS BSS Figure 2.5. The GPRS protocol stack Quality of Service (QoS) QoS is a feature available for PS traffic that enables separate handling and prioritization of different types of traffic. By grouping different types of traffic flows (that for example share the same delay requirements) together, several traffic classes can be defined. In year 2000, the 3rd Generation Partnership Project (3GPP) released a QoS profile in their standard that consists of four unique traffic classes [1]: Conversational - This QoS traffic class is defined to support two-way, realtime services. Since there are people at both ends of the communication when using this class, the tolerance to delay and delay variation (jitter) is very low and directly affects the end-user performance. The most obvious service belonging to the conversational QoS traffic class is speech traffic. As new multimedia services are developed, other types of traffic may belong to this class, such as real-time video conferencing. Streaming - This QoS traffic class is designed to support one-way video and audio streaming. The tolerance for delay is higher than that for the conversational class, but the tolerance for jitter is low. Interactive - The interactive QoS traffic class is applied when the enduser is using services that request data online and therefore is expecting the response quite quickly, such as web-browsing. Background - This QoS traffic class is used when the end-users aren t dependent of the exact arrival time of the packets. Services belonging to this QoS traffic class could be and file transfer.

21 18 Background By the use of these defined QoS traffic classes the scheduling algorithm can be adapted to, for example, give voice calls higher priority than web surfing traffic. The scheduling concept is discussed further in Section Scheduling concept The scheduling concept refers to the algorithm in the BSC that determines in which order clients should send their data on the radio resources, both in uplink and in downlink. When several users want to send their data on the same frequency at the same time, the scheduler needs to decide in which order the users should transmit their data. By using the QoS traffic classes the scheduler can differentiate between different types of traffic, enabling the scheduler to schedule traffic in the following order: 1. Signaling (GMM/SM) 2. Conversational (VoIP) 3. Streaming (Video streaming etc.) 4. Interactive (Web surfing) 5. Background ( , MMS etc.) The most important traffic type is GPRS signaling called GPRS Mobility Management and Session Management (GMM/SM). Mobility management refers to signaling that informs the network of a user s availability, i.e. the physical location of a user and whether the user is attached or detached to the GPRS network. Session management is used to setup sessions between the user and a service network or an external Internet service provider in order to exchange packet data. Even though the scheduler has the ability to separate different types of traffic, it is common that two traffic flows of the same type want to be scheduled on the same radio resources. In these cases the scheduler needs to consider other parameters than just the QoS traffic class. A common way to separate between two users of the same QoS traffic class is to calculate a weight for each of the users. The weight can be calculated in different ways, but for delay sensitive services the weight is often based on packet delay. When two users wants to send packets at the same time and on the same frequency, the user with the longest packet delay will get the highest weight. Since higher weight often equals higher priority, the user with the highest weight will be scheduled first. For other services that may not be delay sensitive, the weight can be based on other parameters, such as the number of times the user has been scheduled. This results in the most basic scheduling called Round-Robin (or taking turns ). 2.3 Session Initiation Protocol (SIP) SIP is a signaling protocol found in the application layer. The protocol is used for setting up, modifying and terminating sessions and is independent of underlying

22 2.3 Session Initiation Protocol (SIP) 19 transport protocols. A session is a connection between two, or more, users that interact using voice, video, audio or any other type of media. SIP itself is unaware of what type of media that is being managed; it only knows how to manage the session. Furthermore, SIP is text based, making it easy to interpret and understand, similar to its relatives HTTP and SMTP [18] SIP network architecture In order to establish a SIP session, a number of major network components need to be used. In this section however, these will be generalized and put into two categories: SIP user agents (UAs) and SIP proxy servers [11]. UAs are the physical equipment (mobile phones, PDAs, PCs etc.) and software used by the end-users to initiate and manage SIP sessions and SIP proxy servers are the intermediate, physical or logical, nodes. A SIP proxy server ensures that SIP requests are passed to another node closer to the end destination. A SIP proxy server can also interpret, and if necessary, rewrite parts of a request before it gets forwarded SIP request methods SIP request methods are used by UAs and proxy servers to communicate. Each request method usually invokes a series of consecutive SIP messages that end with a response message (see Section 2.3.3). SIP uses a number of different request methods [9], [10], [12], [13] where some of the most common are: INVITE - Received by a client when a caller wants to initiate a session. BYE - Sent to terminate a session. ACK - Acknowledges an INVITE request. PRACK - Sent to acknowledge a provisional response (see Section 2.3.3). PUBLISH - Sent when the user wants to publish an event to the server. NOTIFY - Sent by the server to notify a user of an event. SUBSCRIBE - Tells the server that the subscriber wants to be notified when a certain user publishes an event SIP responses A SIP response can either be a final or a provisional response. A final response is the ultimate result of the processed request, while a provisional response provides additional information concerning the server s current action. There are six categories of responses identified by an integer from 100 to 699: 1xx - Provisional responses giving additional information on a server s actions. For example, 180 Ringing indicates that the recipient s phone is ringing.

23 20 Background 2xx - Positive final responses indicating that the request was successful. For example, 200 OK can indicate that the recipient has accepted the INVITE request. 3xx - Responses used for redirecting a caller. For example, 380 Alternative service indicates that the call was unsuccessful but that alternative services are available. 4xx - Negative final response indicating that there is a problem on the client s side. For example, 401 Unauthorized indicates that the request requires user authentication. 5xx - Negative final response indicating that there is a problem on the server s side. For example, 513 Message too large indicates that the server was unable to process the message due to its size. 6xx - A final response indicating a global failure. For example 603 Decline indicates that the recipient was contacted successfully but explicitly doesn t want to or cannot participate. See Figure 2.6 for an example of how the SIP request methods and responses interact in order to setup and terminate a call between two UAs. User A Proxy Server User B INVITE 100 Trying INVITE 180 Ringing 180 Ringing 200 OK 200 OK Call Setup ACK ACK SESSION BYE 200 OK BYE 200 OK Call Termination Figure 2.6. SIP session call setup and termination.

24 2.3 Session Initiation Protocol (SIP) SIP presence signaling Presence, or presence information, is a service provided in order to get status information about a user without direct contact. This type of service emerged as early as 1996 when the instant messenger ICQ was released. Besides instant messaging, ICQ made it possible for users to get information about their friends availability, where the most basic availability states were online and offline. Since there have never been a set of standards for presence, the Internet Engineering Task Force (IETF) has developed an extension to SIP to provide this functionality. The extension is called Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions (SIMPLE) and is an open standard [12], [13], [14]. A client that wants to receive presence information is called a watcher and the set of users that the watcher wants to receive information from is called presentities. Furthermore, a group of presentities is referred to as a buddy-list. In order to get the updates, the watcher needs to subscribe to the presentities presence information. With the use of a buddy-list a watcher can be informed whenever a presentity in the buddy-list updates its presence information. Figure 2.7 shows an example of a UA that updates his presence information (initiates a PUBLISH request) and subscribes to a presentity (initiates a SUBSCRIBE request). UA Presence Server PUBLISH 200 OK UA sending an update to the presence server SUBSCRIBE 200 OK NOTIFY UA subscribing on some presentity 200 OK NOTIFY 200 OK Figure 2.7. A SIP presence session between a UA and a SIP presence server.

25 22 Background There are two different methods to send buddy-list updates to a watcher from the server. Either, a push-based system or a pull-based system is used. In a pushbased system the server automatically sends updates to the watcher as soon as the server gets a PUBLISH message from a presentity on the watchers buddy-list. This may result in very large amounts of messages sent to the watcher, depending on the number of presentities in the buddy-list. In a pull-based system the watcher polls the server in order to get the desired updates. This method can reduce the amount of presence traffic since the poll interval is independent of the number of updates sent by the presentities to the presence server; i.e. the poll interval determines the trade-off between an updated buddy-list and presence traffic intensity. For example, a short polling interval leads to frequent updates and therefore an up to date buddy-list, but large amount of presence traffic also arise. One of the drawbacks of a pull-based system is that polling occurs even if no presentities in the buddy-list have updated their information, which will lead to unnecessary traffic.

26 Chapter 3 Multiplexing methods In this chapter the methods for multiplexing are discussed; this includes the implemented allocation algorithm, scheduling algorithms and MS multislot classes. 3.1 General Multiplexing is a widely used concept that indicates that multiple data streams share the same transport medium. In this study, multiplexing is referred to when several users share the same radio resource. Multiplexing of SIP signaling with other traffic types have been studied [20], but its impact on VoIP capacity has previously been overlooked in GSM studies. The objective of this thesis is to fill this gap and evaluate how SIP signaling could be multiplexed with other types of traffic in order to minimize the VoIP capacity loss. The simulator software used in this study is a radio system simulation platform, developed internally at Ericsson AB. The software provides detailed models of the physical layers, protocols as well as the traffic. What is not implemented though, is the use of actual control channels. All physical channels in the simulator software are regarded as PDCHs. This software was originally designed for simulating other radio networks and has later on been adapted for simulating the GSM network. In this study, only conversational and background traffic flows are used along with SIP. The streaming traffic class is not considered in this study since its fairly strict QoS requirements would be too hard to maintain when VoIP is included. Also, the interactive traffic class is, at the time of writing, not fully implemented in the simulator software. Background traffic on the other hand, is convenient to use since it is not delay sensitive. Also, since this class will be represented by a simple file transfer, it is fairly easy to evaluate. In order to achieve reliable results, methods for scheduling and allocation have been derived and evaluated. 23

27 24 Multiplexing methods 3.2 Allocation algorithm Channel allocation is a method used to provide a certain user with a number of TSs and frequencies on which the user can transmit and receive data. Previously, no dynamic allocation algorithm was implemented in the simulator software. TSs and frequencies were statically given to the clients by editing simple parameters. This meant that if a client was placed on TS 4 and 5, all clients of this type would get allocated to these TSs for the entire simulation. Obviously, this static way of allocating TSs was far from the correct behavior and had to be improved. Since the introduction of VoIP into GSM won t replace the CS traffic all together, PS traffic and CS speech will have to share frequencies (TS sharing is not possible between CS and PS). In order to separate them on the TDMA frames, CS speech is primarily allocated from left to right, while PS traffic is primarily allocated from right to left. In this study however, no CS traffic is included and therefore all TSs are available for PS traffic. Furthermore, since RTTI is used in the simulations, two consecutive TSs can be seen as a bin. This means that only four different positions on the TDMA frame are available for allocation. These are the characteristics by which the implemented allocation algorithm is designed. The algorithm begins by placing the PS clients in the rightmost bin and continues by placing them to the left. Also, since the UL frequency is most likely to act as a bottleneck (further discussion in Section 3.4) it is necessary to utilize as many TSs in the UL as possible. Therefore an evaluation is made so that the client always gets placed in the bin that suffers from the least payload in the UL. If two, or several, bins have the same payload, the rightmost bin will be allocated to the client. 3.3 MS multislot classes An MS multislot class defines the number of TSs an MS can utilize in the UL and DL. In this study, two different MS multislot classes have been implemented. The first multislot class represents an MS capable of transmitting and receiving on two TSs in the DL and UL frequency respectively. The second multislot class represents an MS capable of receiving information on four consecutive TSs in the DL frequency and transmitting on two consecutive timeslots in the UL frequency. These MS multislot classes correspond to multislot class 5 and multislot class 31, as defined in the 3GPP standard [3]. Multislot class 5 was implemented because it is at present time a widely used MS multislot. Multislot class 31 on the other hand, is not used today but might very well be more common in the future. Figure 3.1 presents these MS multislot classes graphically. UL DL UL DL Figure 3.1. MS multislot class 5 to the left and multislot class class 31 to the right.

28 3.3 MS multislot classes 25 When using the allocation algorithm described above, clients of multislot class 31 suffer from an overlap between the bins in the DL frequency. Furthermore, no more than three clients of MS multislot class 31 can fit into the TDMA frame with the implemented allocation algorithm. In order to utilize the UL as much as possible, the leftmost bin will always be allocated by a client of multislot class 5. See Figure 3.2 and 3.3 for an illustration of how the implemented allocation algorithm allocates TSs for clients of the different multislot classes UL DL UL DL 3 7 UL DL UL DL 2 6 UL DL UL DL 1 5 TDMA frame UL DL UL DL Figure 3.2. TS allocation for clients of multislot class UL DL UL DL 3 7 UL DL UL DL 2 6 UL DL UL DL 1 5 TDMA frame UL DL UL DL Figure 3.3. TS allocation for clients of multislot class 31.

29 26 Multiplexing methods 3.4 Scheduling When multiplexing several clients, the scheduler needs to determine in which order they should send their data on the radio resource. Previously, the implemented scheduling algorithm was a simple Round-Robin scheduler (called Scheduler C in this study) that assigned a weight to each user. If two users had the same QoS traffic class the priority would be based on this weight. The weight was calculated by calculating the number of times a user had been scheduled. This way of determining the weight was done indifferently of the traffic flow direction (i.e. UL or DL). The weight was then used as a penalty, making users who had been scheduled many times less important than users who hadn t. Since VoIP utilizes the PS domain, several VoIP users might need to share the same radio resource with other PS service users. In order to maintain the delay requirements for the conversational traffic class, the scheduler needs to be complemented with functionality that determines how long a certain VoIP packet has been in queue for transmission. The reason for this is that the VoIP service by definition is very delay sensitive, which means that packets quickly get out-of-date and thereby dropped. On the other hand, this sensitivity doesn t apply to traffic of the background QoS traffic class. As previously mentioned, the UL is assumed to be the bottleneck since the BSC is unable to know how much information that is to be sent by a certain user [17]. If there only were one user per TS, the users would be scheduled on every TDMA frame. But when several users are multiplexed onto the same resource, it is hard for the BSC to know how often each user should be scheduled in the UL. This issue gets even more prominent when it comes to conversational services (such as VoIP); if the scheduler fails to schedule conversational traffic flows in a fair way, the perceived quality might drop due to packet delay. This is not an issue in the DL since the BSC has full insight of what data is to be sent to each MS Scheduling algorithms Two different schedulers (Scheduler A and Scheduler B) have been derived and analyzed. The schedulers are delay sensitive and their penalties are determined by their weight. Both schedulers take packet age and queue sizes into consideration in the DL weight calculation while the UL weight calculation only is dependent on packet age. However, in the UL penalty, Scheduler A is also dependent on previous penalties while Scheduler B is not. Also, in order to increase the chance for a down-prioritized service to get scheduled, the schedulers assign a zero weight to VoIP users who are trying to transmit data very soon after having a successful transmission. The minimum age threshold plays an important role in the scheduling algorithms for the UL; it regulates the balance between user performance and the level of multiplexing. The threshold defines the time a user gets blocked from scheduling after having a successful transmission. A high threshold thereby let more users get a chance to get scheduled while a low threshold let less users get the same chance. This fairness of giving other users a chance to get scheduled after a suc-

30 3.4 Scheduling 27 cessful transmission is needed in the UL, in order to let down-prioritized services get scheduled more frequently. In the DL on the other hand, it is easier to foresee how much resources that will be needed by each user. Since the BSC knows how much data each user wants to transmit and how long the packets have been waiting, it is reasonable to let these parameters (i.e. queue size and packet age) determine the weight. By doing so, users with a large queue size may get scheduled more frequently to avoid letting packets get out-of-date. In the same fashion, users with old packets may be scheduled more frequently. Since traffic flows of the background traffic class aren t delay sensitive, the weight is simply set to a static value. This is adequate in this study since the purpose of including background traffic flows is to simply determine whether these flows get any throughput at all and not exactly how much.

31

32 Chapter 4 Traffic Models This chapter describes how each traffic flow is represented in the simulator software. It also presents in what way these traffic flows have been configured to behave in an sufficiently realistic way. 4.1 General In the simulator software, each traffic model represents one single traffic type and is used to generate the corresponding traffic flow. In this study there are four different types of traffic models that define the MS clients that will be used in the different traffic scenarios (see Chapter 5). The VoIP traffic model represents the PS speech traffic and this is the traffic flow that will be investigated in terms of capacity loss when introducing SIP signaling. SIP signaling is divided into two separate traffic models; the SIP traffic model and the presence traffic model. The SIP traffic model represents the call setup and termination part of the signaling, while the presence traffic model only represents the presence traffic. The fourth and last traffic model to be used is the web traffic model that will represent a file transfer. From this point on, SIP call setup and termination will be referred to as SIP signaling while SIP presence traffic will be referred to as presence traffic. 4.2 VoIP traffic model The VoIP traffic model generates the traffic flow between two VoIP users. This traffic models is treated as the conversational QoS traffic class, as described in [1]. This means that this traffic flow will have absolute scheduling priority over traffic flows of the background QoS traffic class. Also, the VoIP traffic model utilizes the UDP protocol. UDP is an unreliable transport protocol, meaning that it doesn t do any retransmissions of lost packets. This is desirable because speech traffic is a real time communication where both ends are occupied by real persons. Very delayed packets will therefore be useless, since they contain out-ofdate information. In this case, it is better to drop these packets and move on to 29

33 30 Traffic Models the next. End user perception will thus be less affected by lost packets than late packets. In this study, the delay threshold has been set to 300 ms which means that packets that arrive at the recipient with a greater delay than this threshold will be dropped and thereby regarded as lost. Table 4.1 shows interesting parameters used to define the behavior of the VoIP traffic in the simulations. These parameters are based on the findings from previous studies in related areas [7], [15]. Parameter Value Description Talk spurt duration 40 s The duration of each speech sequence. Voice activity 0.5 The speech intensity. A value of 0.5 means that at least one of the two end users is talking. Graceful termination True Setting this parameter to true means that the lifetime of each user will be equal to the length of the conversation. Conversation duration 120 s The length of each conversation. Frame size 344 bits The size of the voice frames. Represents AMR 7.95 kbit/s. Max delay 0.3 s Packets that have a delay that exceeds this value are considered as lost. Frame Period 0.04 s This parameter defines the time between each voice frame transmission. Encoding delay s The time it takes to encode the voice frames. Decoding delay s The time it takes to decode the voice frames. Terminal capability (UL and DL) Dual timeslot This corresponds to using RTTI (10 ms). Table 4.1. VoIP traffic model parameters. 4.3 SIP traffic model The SIP traffic model simulates the call setup and call termination. This traffic model doesn t belong to any QoS traffic class and will therefore in the simulations be mapped onto the different QoS traffic classes to find the preferable treatment. In reality, this corresponds to changing the prioritization of SIP signaling in the

34 4.3 SIP traffic model 31 scheduler. The size of each SIP message is in reality not static, but variable depending on the information which might include session and client specific content. Since this information may vary in size due to factors not considered in these simulations, the messages have been assigned a static size based on previous studies [19]. Table 4.2 shows the implemented messages and their corresponding sizes. Message type 183 SESSION IN PROGRESS 1270 INVITE 1113 PRACK OK RINGING 888 BYE 878 ACK 427 PUBLISH 800 NOTIFY 700 SUBSCRIBE 600 Size (byte) Table 4.2. The implemented SIP messages and their corresponding size. INVITE request method The implementation of the INVITE request method in the simulator software allows users to setup media sessions. In Figure 4.1 the message flow of the INVITE method is presented (note that this figure only shows an uninterrupted session). Since there is a possibility for packet loss when simulating the different scenarios, and since SIP relies on UDP, SIP itself has to retransmit these packets. The first retransmission is done after 500 ms, which corresponds to the Round Trip Time (RTT), and the consecutive retransmissions are done at 2*RTT (RTT is an estimate of the transaction time between the client and server). This continues until the retransmission interval hits a 4 s limit. For further details regarding these parameter values and the retransmission timer, see [9].

35 32 Traffic Models User A User B INVITE Establish Radio Bearer 183 Session In Progress PRACK 200 OK Establish Radio Bearer 180 Ringing Pick-up Delay 200 OK ACK Figure 4.1. Messages generated when an INVITE request method is initiated. BYE request method In order to terminate a media session, a client needs to initiate the BYE request method. This method uses the same retransmission timer as the INVITE request method. As seen in Figure 4.2, this method is a lot less complex than the INVITE request method. For more details regarding the implementation of SIP in the simulator software, see [19]. User A User B BYE 200 OK Figure 4.2. SIP call termination session.

36 4.4 Presence traffic model Presence traffic model The presence traffic model simulates a SIP UA and a presence server and generates the presence traffic sent between them. The implementation is based on a pushbased system where the client registers to the server and subscribes to a virtual buddy-list on the server. Whenever an update event is invoked on the server (simulating an update of a presentity on the buddy-list) a notify message is sent to the client. Figure 4.3 show the message flow generated by a user when entering a presence session. Furthermore, Table 4.3 and 4.4 shows the interesting parameter settings for the presence client and the presence server respectively that is used in the simulations. The publish intervals for the client and the server should be the same if it is assumed that they share the same SIP signaling configuration. Parameter Value Description Publish interval 20 min The time between two consecutive PUB- LISH messages sent to the server. Re-registration interval 55 min The time between two consecutive reregistrations sent to the presence server. Offline duration 55 min The mean time a client is offline. Online duration 55 min The mean time a client is online. Table 4.3. Presence client parameters. Parameter Value Description Publish interval 20 min The time between two consecutive PUB- LISH messages sent by the presentities to the server. Re-registration timeout 60 min If no re-registration is received from the client during this period, the client is removed from the registered list. Subscription list length 5 The size of the buddy-list. Table 4.4. Presence server parameters.

37 34 Traffic Models User Server PUBLISH 200 OK SUBSCRIBE 200 OK... NOTIFY 200 OK Figure 4.3. Presence message flow. 4.5 Web traffic model This is the traffic model used to simulate a DL oriented file transfer. The model consists of two different entities; the web client and the web server. The web client always initiates the communication by sending an HTTP request to the web server. In response to this request, a web object is sent from the web server to the client. These objects could represent anything from an HTML web page to an mp3-file. A rather small object size is used to represent simple web pages while a rather large object size could represent some kind of media file. In this study the object size is set to 5 MB in order to avoid the web traffic model from going into an idle state and thereby having zero packets in the queue. Table 4.5 shows interesting parameters used to define the web traffic in the simulations. Parameter Value Description Object size descriptor 5 MB The size of each object requested by the web client. HTTP request size 400 byte The size of the HTTP request. Table 4.5. Web traffic model parameters.

38 Chapter 5 Traffic scenarios This chapter describes how the traffic scenarios in each stage will be designed. Common simulation parameters are also presented along with the purpose of each stage. 5.1 Stages To be able to determine the impact of SIP signaling, different traffic scenarios need to be defined and analyzed. The scenarios are divided into different stages; there s only one type of user per stage, but for each stage the user complexity is increased. All scenarios are simulated with some common parameters as seen in Table 5.1. Note that the clients use frequency hopping among all available frequencies in the system (for further information about frequency hopping, see [5]). This is done in order to reduce vulnerability, secure transmission quality and maximize system performance. In the simulator software, all clients use the same frequency hop pattern at all time. In order to get enough representable data, the number of simulation iterations have been set to 20. Parameter Value Simulation length 120 s Number of base stations 1 Number of cells 1 Number of frequencies per cell 124 Frequency hopping Yes Number of TSs available for VoIP 8 Minimum Age Threshold (minagethd) 30 ms Simulation iterations 20 Table 5.1. Parameter settings used in all scenarios. Furthermore, each stage is composed of scenarios with different radio conditions and scheduling prioritizations. Radio conditions are determined by the Carrier 35

39 36 Traffic scenarios to Interference Ratio (CIR) and are treated by using an appropriate Modulation and Coding Scheme (MCS). A low CIR value indicates that the radio conditions are poor and implies that the BSC should use a low MCS. A low MCS means that a greater part of the sent packet is composed of coding bits that make the transmission less sensitive to packet drops. For example, if a packet is dropped using MCS-8, more data bits will be lost than if using MCS-5. In this study, static CIR values with their corresponding MCS are used, as presented in Table 5.2. In the future it is likely that some kind of Interference Rejection Algorithm (IRA) will be utilized when introducing VoIP into GSM. These algorithms will help reduce interfering signals and thereby the perceived CIR value will be improved. Since no IRA has been implemented in the simulator software, a static addition of 8 db has been added to the CIR values [7]. When accommodating the maximum number of users, at most 5% of the VoIP users are allowed to have an average voice frame loss rate of no more than 4% in each traffic flow direction. This limit is defined as the system s capacity limit. CIR CIR + IRA Coding scheme 14 db 22 db MCS-5 18 db 26 db MCS-7 22 db 30 db MCS-8 Table 5.2. The CIR values and MCSs used in the different scenarios Stage 1 - Only VoIP The purpose of this stage is to determine the maximum possible number of simultaneous VoIP users in the system and obtain a capacity reference for the coming stages. Since the users are modeled only by a VoIP traffic model, no call setup or termination is done in this stage. According to [8], a CIR value of 14 db and MCS-5 can be seen as a border case of when it is possible to run VoIP over EDGE with decent quality. This is why 14 db and MCS-5 has been chosen to act as the worst case scenario. Furthermore, MCS-7 and MCS-8 are believed to provide good enough data rates to accommodate 16 simultaneous users under good radio conditions [17]. By using half rate traffic channels the maximum number of CS users in GSM is 16 (on eight TSs). Since the idea of introducing VoIP is to enable compatibility with future radio networks and maintain current performance and capabilities, the desired maximum number of VoIP users in this study is also Stage 2 -VoIP & SIP In this stage, the users are utilizing the VoIP service along with SIP. Therefore, call setups and terminations are what differ from the previous stage. The purpose of this stage is to investigate how the SIP signaling is supposed to be prioritized compared to the VoIP traffic. As previously mentioned, there are only two options

40 5.1 Stages 37 for SIP prioritization since only the background and conversational QoS traffic classes are used. The best way to prioritize is determined by examining the number of retransmitted SIP messages. By studying the number of SIP retransmissions it is possible to see how the call setup and termination times vary which gives an idea of the SIP performance. Furthermore, the capacity will be the same as in Stage 1, since the SIP signaling only occurs at the beginning and at the end of the simulations and therefore doesn t interfere with the VoIP traffic throughout the whole simulation Stage 3 -VoIP, SIP & Presence In Stage 3 the users also utilize the presence traffic service. The purpose of this stage is to evaluate the impact of presence traffic on VoIP capacity, depending on priority and the presence intensity. As in Stage 2, there are two levels of prioritization: background and conversational. As presence intensity in reality might vary, two different levels of presence intensity will be evaluated in this stage to see how they will affect VoIP packet delays and losses. The presence intensities are varied by changing the client and server publish intervals and the subscription list length (see Tables 6.5 and 6.6) Stage 4 - VoIP, SIP, Presence & MMTel In the last stage, the DL payload is increased by adding another traffic flow representing a file transfer. The purpose of this stage is to evaluate if it is possible to include a multiplexed MMTel service with sustained VoIP capacity. If this is not the case, then it will be investigated how much VoIP capacity that have to be sacrificed in order to achieve decent web traffic quality. The added web traffic model is a so called best-effort-service that does not have any specific delay requirements. Therefore it is suitable to measure the throughput of this traffic flow to determine what data rates that can be achieved. Also, since MS multislot class 31 adds extra DL capabilities, it will be investigated to see if the DL throughput increases by using this MS multislot class.

41

42 Chapter 6 Simulations This chapter was supposed to present the actual simulation results, but due to bugs and issues in the simulator software it was not possible to obtain any reliable data. The simulations turned out to be very unpredictable when some of the results showed that the VoIP capacity in fact was increased when including presence traffic. Also, when using mobile stations of MS multislot class 31 the packet losses skyrocketed to insane levels around 90%. These bugs and issues among other minor errors in the simulator software made it impossible to finish the simulations within the given timeframe. Therefore, the results presented in this chapter are totally fictional but are nonetheless within reasonable limits of what can be expected from such simulations. Since the purpose of the fictional data presented in this chapter is only to give an image of a possible outcome, the fictional data quantity is limited. 6.1 Stage 1 - Only VoIP The radio conditions used in the scenarios of this stage are presented in Table 6.1 while Section shows the expected results of this stage. The expected results are based on an ongoing study at Ericsson AB [17] where the maximum multiplexing limits have been investigated for Scheduler A, B and C with MCS- 5, MCS-7 and MCS-8. The obtained limits correspond well to the expectations presented in Section but since the results of the simulations in [17] also might be affected by some bugs and issues in the simulator software, these results can not yet be fully trusted. Scenario MCS CIR Priority 1.1a b c Table 6.1. Priorities and radio conditions used in each scenario. 39

43 40 Simulations Results - Stage 1 It can be seen that Scheduler A proved to be the better choice throughout the simulations due to it s ability to favor users having transmission difficulties. If Scheduler B is used the maximum number of simultaneous users decreases, as seen in Figure 6.2, since the packets in the queue easier get out of date when a user is having transmission issues. As can be seen in Figure 6.1, at most 16 users can be accommodated when using Scheduler A if at most 5% of the users are allowed to lose no more than 4% of their speech frames. Scheduler C proved to be able to provide the same capacity as Scheduler B, but when looking at Figure 6.2 and 6.3 it can be seen that Scheduler C has an overall lower satisfied user share. 100 Scheduler A Satisfied user share [%] Scenario 1.1a 91 Scenario 1.1b Scenario 1.1c Nr of users Figure 6.1. The amount of satisfied users when using Scheduler A in Stage 1.

44 6.1 Stage 1 - Only VoIP Scheduler B Satisfied user share [%] Scenario 1.1a 91 Scenario 1.1b Scenario 1.1c Nr of users Figure 6.2. The amount of satisfied users when using Scheduler B in Stage Scheduler C Satisfied user share [%] Scenario 1.1a 91 Scenario 1.1b Scenario 1.1c Nr of users Figure 6.3. The amount of satisfied users when using Scheduler C in Stage 1.

45 42 Simulations 6.2 Stage 2 - VoIP & SIP The radio conditions and priorities used in the scenarios of this stage are presented in Table 6.2. According to [8] it is not unrealistic to have setup times spanning from 5 to 8 s. In this study, an uninterrupted session of the implemented SIP INVITE request method would at most take about 5 s. Therefore, it is assumed that about 3,5 SIP retransmissions will be sent in the worst case, resulting in a setup time of 6 to 7 s (given that the retransmissions are not consecutive). Also, some of the predicted retransmissions might be sent during the BYE session, resulting in lower setup times but longer termination times. By lowering the SIP prioritization, it is reasonable to believe that the SIP retransmissions would increase while more favorable radio conditions would decrease the retransmissions. Based on these assumptions, Table 6.3 shows the mean amount of SIP retransmissions in each scenario for each scheduler (at high VoIP intensity). Scenario MCS CIR Priority 2.1a 5 22 VoIP = SIP 2.1b 5 22 VoIP > SIP 2.2a 7 36 VoIP = SIP 2.2b 7 26 VoIP = SIP 2.3a 8 30 VoIP > SIP 2.3b 8 30 VoIP = SIP Table 6.2. Priorities and radio conditions used in each scenario Results - Stage 2 It is easily concluded that the prioritization of SIP should be done equally as VoIP in order to keep setup and termination times fairly low. It can be seen in Table 6.3 that roughly one extra SIP retransmissions is added per session when downprioritizing SIP compared to VoIP. This might not seem as a big deal, but since a SIP retransmission is made at least 500 ms after sending a request, it shows that the delays seem to be quite high. This conclusion is also in line with the findings in [16] where it was found that VoIP and SIP should be equally prioritized in the 3G network. Scenario Scheduler A Scheduler B Scheduler C 2.1a 2,8 3,0 3,7 2.1b 3,7 4,0 4,1 2.2a 2,2 2,4 3,2 2.2b 3,5 3,6 3,6 2.3a 2,2 2,3 3,2 2.3b 3,4 3,6 3,6 Table 6.3. The mean number of SIP retransmissions sent per user and session when reaching maximum capacity.

46 6.3 Stage 3 - VoIP, SIP & Presence Stage 3 - VoIP, SIP & Presence Table 6.5 show the parameter settings used to differentiate the presence intensities while the radio conditions and priorities used in the scenarios of this stage are presented in Table 6.4. The results in Figures 6.4 to 6.6 represents the satisfied user share when applying low presence intensity. When introducing presence signaling that is lower prioritized than VoIP, the total amount of satisfied users are expected to be lowered by about 1%, but when prioritizing presence equal to VoIP the reduction is believed to be bigger. Also, the relative mean packet loss for high presence intensities is expected to be much higher than for low intensities, as seen in Table 6.7. Since the packet loss rate at maximum capacity already is close to the 4% limit, even a small increase might affect the satisfied user share. The relative mean packet losses for the best performing scheduler are presented in Table 6.7 while the UL delay probability functions for the same scheduler is presented in Figures 6.10 and The results in this stage are based on the above assumptions, which in turn are based on predictions and the findings in [15]. In this stage, it is assumed that it s best to prioritize VoIP equally as SIP. Scenario MCS CIR Priority 3.1a 5 22 VoIP & SIP > Presence 3.1b 5 22 VoIP & SIP = Presence 3.2a 7 26 VoIP & SIP > Presence 3.2b 7 26 VoIP & SIP = Presence 3.3a 8 30 VoIP & SIP > Presence 3.3b 8 30 VoIP & SIP = Presence Table 6.4. Priorities and radio conditions used in each scenario. Parameter High Low Description intensity intensity Client publish interval 30 min 60 min The time between two consecutive publish messages sent to the server. Server publish interval 30 min 60 min The time between two consecutive publish messages sent by the presentities to the server. Subscription list length 15 5 The size of the buddy-list. Table 6.5. Parameters representing the presence intensities.

47 44 Simulations Results - Stage 3 When presence signaling is introduced it can be seen that the highest VoIP capacity is achieved by down-prioritizing presence compared to VoIP and SIP. Since the UL is not expected to perform as well as the DL, the UL is the traffic flow direction studied when looking at the delays and packet losses. Table 6.7 shows the relative mean packet loss (for the UL) using Scheduler A compared to the same scheduler in Stage 1. A low presence intensity shows that the mean packet loss increases by about % when prioritizing presence lower than the other traffic types. If it on the other hand is prioritized equal to VoIP and SIP the mean packet loss is increased by % depending on radio conditions. For high presence intensities the mean packet loss is further increased, reaching 1.8% in the worst case scenario. Since these measurements are done when the maximum VoIP payload is applied (and the speech frame loss rate therefore already are close to the 4% limit), the seemingly low values can still have some impact on the total VoIP capacity, as seen in Figure 6.4. Furthermore, the UL delays are presented in Figures 6.7 and 6.8. Figure 6.7 shows that about 98% of all packet delays for all users are lower than 300 ms when applying a low presence intensity. If a high presence intensity is applied however, about 97% of all packet delays for all users are lower than 300 ms. This means that for high presence intensities, the packet drop rate has risen with about 1%. 100 Scheduler A Satisfied user share [%] Scenario 3.1a Scenario 3.1b 92 Scenario 3.2a Scenario 3.2b 91 Scenario 3.3a Scenario 3.3b Nr of users Figure 6.4. The amount of satisfied users when using Scheduler A in Stage 3.

48 6.3 Stage 3 - VoIP, SIP & Presence Scheduler B Satisfied user share [%] Scenario 3.1a Scenario 3.1b 92 Scenario 3.2a Scenario 3.2b 91 Scenario 3.3a Scenario 3.3b Nr of users Figure 6.5. The amount of satisfied users when using Scheduler B in Stage Scheduler C Satisfied user share [%] Scenario 3.1a Scenario 3.1b 92 Scenario 3.2a Scenario 3.2b 91 Scenario 3.3a Scenario 3.3b Nr of users Figure 6.6. The amount of satisfied users when using Scheduler C in Stage 3.

49 46 Simulations Scenario High intensity Low intensity Nr of users 1a +1,35 % +0,34 % 8 1b +1,82 % +0,72 % 8 2a +1,27 % +0,31 % 16 2b +1,54 % +0,62 % 16 3a +1,12 % +0,22 % 16 3b +1,36 % +0,41 % 16 Table 6.6. Relative mean packet loss in UL for Scheduler A compared to same scheduler in Stage 1. 1 Uplink - Low presence intensity CDF Delay [s] Figure 6.7. The delay probability function for Scheduler A in Scenario 3.3a with 16 users and low presence intensity.

50 6.4 Stage 4 - VoIP, SIP, Presence & MMTel 47 1 Uplink - High presence intensity CDF Delay [s] Figure 6.8. The delay probability function for Scheduler A in Scenario 3.3a with 16 users and high presence intensity. 6.4 Stage 4 - VoIP, SIP, Presence & MMTel In this stage, the impact of including the web traffic model is investigated. The results in this stage are an estimation based on expectations and the findings in [17]. The throughput of the web traffic is presented in Figures 6.15 to 6.18 while the radio conditions and priorities used in the scenarios of this stage are presented in Table 6.8. Scenario MCS CIR Priority 4.1a 5 22 VoIP & SIP > Presence & MMTel 4.1b 5 22 VoIP, SIP & Presence > MMTel 4.2a 7 26 VoIP & SIP > Presence & MMTel 4.2b 7 26 VoIP, SIP & Presence > MMTel 4.3a 8 30 VoIP & SIP > Presence & MMTel 4.3b 8 30 VoIP, SIP & Presence > MMTel Table 6.7. Priorities and radio conditions used in each scenario Results - Stage 4 In this stage it can be seen that when simulating with very high VoIP payloads the results were just about the same as in Stage 3. Since the web traffic is downprioritized compared to VoIP, the VoIP capacity was not affected by this extra DL payload. In order to get a decent throughput for the web traffic however, the VoIP capacity needed to be reduced. According to Figure 6.9, 12 users can

51 48 Simulations be accommodated with Scheduler A under good radio conditions while the web throughput is fair, as seen in Figures 6.11 to The throughput was shown to vary when changing the presence prioritization and switching between the two implemented MS multislot classes. When prioritizing presence higher than the web traffic the amount of measurements showing zero throughput was increased with about 10% compared to prioritizing presence equal to the web traffic. The difference seen when using MS multislot class 5 and 31 was that when some throughput was registered, it was slightly higher when using MS multislot class 31. This fact shows that the extra DL capability actually makes some difference when enough resources are available to the down-prioritized service. If the VoIP traffic is too intense though, the extra TSs in the DL won t matter because of the VoIP payload and prioritization. 100 Scheduler A Satisfied user share [%] Scenario 4.1a Scenario 4.1b 92 Scenario 4.2a Scenario 4.2b 91 Scenario 4.3a Scenario 4.3b Nr of users Figure 6.9. The amount of satisfied users when using Scheduler A in Stage 4.

52 6.4 Stage 4 - VoIP, SIP, Presence & MMTel Scheduler B Satisfied user share [%] Scenario 4.1a Scenario 4.1b 92 Scenario 4.2a Scenario 4.2b 91 Scenario 4.3a Scenario 4.3b Nr of users Figure The amount of satisfied users when using Scheduler B in Stage Scheduler C Satisfied user share [%] Scenario 4.1a Scenario 4.1b 92 Scenario 4.2a Scenario 4.2b 91 Scenario 4.3a Scenario 4.3b Nr of users Figure The amount of satisfied users when using Scheduler C in Stage 4.

53 50 Simulations 1 MS multislot class 5 - Scenario 4.3a CDF Throughput [kbit/s] Figure Throughput probability function for 12 users using Scheduler A with MS multislot class 5 in Scenario 4.3a. 1 MS multislot class 31 - Scenario 4.3a CDF Throughput [kbit/s] Figure Throughput probability function for 12 users using Scheduler A with MS multislot class 31 in Scenario 4.3a.

54 6.4 Stage 4 - VoIP, SIP, Presence & MMTel 51 1 MS multislot class 5 - Scenario 4.3b CDF Throughput [kbit/s] Figure Throughput probability function for 12 users using Scheduler A with MS multislot class 5 in Scenario 4.3b. 1 MS multislot class 31 - Scenario 4.3b CDF Throughput [kbit/s] Figure Throughput probability function for 12 users using Scheduler A with MS multislot class 31 in Scenario 4.3b.

55

56 Chapter 7 Discussion This chapter discusses the expectations and predictions on the traffic scenarios that are not yet simulated. Conclusions and recommendations are also presented along with future work proposals. 7.1 Expectations & predictions It is expected that using different MCSs will show a significant capacity difference. The scenarios where MCS-5 is used will be the least successful since MCS-5 provides lower data rates compared to MCS-7 and MCS-8. Furthermore, the capacity limits are believed to end up at four, eight, twelve or sixteen users. This is reasonable to assume since, for example, if nine users can be accommodated with satisfactory results, then so could twelve users since all users stay on the same TSs for the entire simulation. So if there only were nine users, there would be three timeslot bins left to accommodate one user each, resulting in a total of twelve users. Scheduler A is believed to give the best performance among the analyzed schedulers which suggests that the dependency of previous penalties in the UL would be significant. The reason for this assumption is that letting the UL scheduling be dependent on previous penalties means that a recently scheduled user doesn t necessarily have to wait for a very long time until being scheduled again. This may happen because the other users might have a larger accumulated penalty than the scheduled user. Therefore, users who have trouble getting successful transmissions will be favored over time, since their penalty accumulates slower than users with no transmission problems. This enables the users to quickly transmit stacked up packets that are about to get out-of-date. In Scheduler B the penalty in the UL does not depend on previous penalties and therefore the UL penalty is only dependent on the weight. This means that the user with the longest time since the last successful transmission will receive the highest priority; in this sense, this UL scheduling could be defined as a delay sensitive Round-Robin. By not having a memory, users with transmission issues that utilize Scheduler B might get less successful transmissions over time. Imagine a user with transmission issues that 53

57 54 Discussion finally gets a successful transmission, the user will then be treated equally as the other users gaining no favor from his problems. Furthermore, when using a delay sensitive service, such as VoIP, Scheduler C will most certainly prove to give the worst results among the schedulers. This because it does not take packet delays and queue sizes into consideration which means that too many packets will get out of date when the amount of multiplexed users increases beyond two users for each timeslot bin. MS multislot class 31 is not believed to give any significant advantages until some kind of heavy DL oriented traffic is added. When the web traffic model is added, it is believed that the usage of MS multislot class 31 won t affect the VoIP capacity but it might improve the throughput of the web traffic. This is not a certain fact though, since the extended DL capacity only offers the possibility of increased throughput. The results of Stage 1 are, as mentioned before, supposed to give a point of reference to the following stages. Since Scheduler B does not have the ability to schedule evenly over time, it is believed that this scheduler won t perform as well as Scheduler A. Furthermore, even though Scheduler B is delay sensitive, it can still be seen as a Round-Robin variant. Therefore it isn t impossible that Scheduler B will perform only slightly better than Scheduler C. In Stage 2 the focus lies on the choice of SIP priority compared to the VoIP traffic. Giving SIP a lower scheduling priority than VoIP is expected to result in longer call setup and termination times. This is expected because SIP messages will then have to wait for a longer time until being transmitted. Furthermore, by letting SIP messages wait for a longer time the SIP protocol is forced to generate more retransmissions since less responses are registered to these messages. Every dropped (or lost) SIP message could be quite costly in terms of call setup and termination time since a retransmission is triggered no sooner than after 500 ms. Therefore it is important to reduce retransmissions by prioritizing SIP equally as VoIP, otherwise the call setup and termination times might get unnecessary long. In Stage 3 it is expected that by letting presence traffic be equally prioritized as SIP and VoIP the voice frame delays will be increased due to tougher competition in the scheduling. Therefore, it is assumed that the mapping of the presence prioritization should be done onto the background QoS traffic class. Also, since presence signaling is simply used to get status updates from users on the buddylist, it is logical to down-prioritize these messages; it is far more important to let a voice frame reach its destination on time than, for example, finding out that your buddy is out for lunch. Also, it should be noted that the SIP message sizes are static in the current implementation in the simulator software which doesn t correspond to real life scenarios where the sizes can vary. Since the VoIP service will be favored in the scheduler compared to the web traffic, the web traffic in Stage 4 is expected to suffer from quite hefty delays. This might not be perceived as a problem if the multiplexed service would be, for example, an transfer. But if the multiplexed service is something that requires a limited amount of interactivity, such as web surfing, the problem might be more prominent. Therefore, when aiming at getting decent delays for the multiplexed web traffic, the capacity limit of this stage are expected to be lower.

58 7.2 Conclusions & recommendations Conclusions & recommendations With the above discussions in mind, it is recommended to prioritize SIP signaling equal to VoIP while letting presence signaling have a lower priority in order to maximize VoIP capacity. It is also concluded that Scheduler A will be the best scheduling algorithm to use under these circumstances. Furthermore, it should not be expected that any great performances will be received out of down-prioritized MMTel services when very high VoIP traffic loads are present. The multiplexed MMTel service performance might however be improved when using MS multislot classes with greater capabilities when the VoIP payload is not too high. 7.3 Future work When using Scheduler A and B in this study, the parameter minagethd is set to a static value of 30 ms. Since the use of RTTI reduces the transmission time of a radio block to 10 ms, setting this parameter to 30 ms makes a scheduled user wait until three other users have been scheduled until being scheduled again. 30 ms is therefore optimized for multiplexing four users on the same timeslot bin which results in a total of sixteen users on eight TSs. In a future study, it would be interesting to let this parameter be set dynamically depending on the level of multiplexing. When no multiplexing is present, the value should be set to zero and then increase by 10 ms for each added level of multiplexing. Obviously, there is a limit where the wait time starts affecting the VoIP performance too much. The simulations in this study were to be run with a static number of users which means that no calls would have been initiated or terminated except at the very beginning and at the end of the simulations. This is obviously far from real life behavior and therefore a dynamic flow of user arrivals and departures would be preferred when running simulations of this kind. This would impact the VoIP capacity even more due to increased SIP signaling payload. It could also be interesting to investigate how different user types could affect the system capacity. For example, it would be interesting to know what impact users only utilizing the presence service would have on the system. Since a session initiation has to be done for each sent presence message (if only utilizing the presence service), the choice of flow release time would probably affect the performance a great deal. Furthermore, the human hearing sense can compensate for occasional packet losses, but when several consecutive packets are lost the perceived speech quality is decreased. Therefore, it might be interesting to evaluate not only the overall packet loss rates, but also the number of consecutively lost packets.

59

60 Bibliography [2] 3GPP. Ts mobile station (ms) - serving gprs support node (sgsn); subnetwork dependent convergence protocol (sndcp) v URL: [ ], [1] 3GPP. Ts quality of service (qos) concept and architecture v URL: [ ], [3] 3GPP. Ts multiplexing and multiple access on the radio path v URL: [ ], [4] Ericsson AB. Gprs system survey. LZU R3A, [5] Ericsson AB. Gsm system survey. EN/LZU R5A, [6] Ericsson AB. The evolution of edge - white paper. URL: _EDGE_A.pdf [ ], [7] Andreas Bergström. Voip over edge evolution - single session performance and service coverage. Ericsson Confidential Report: EAB-07: Uen, [8] Per Synnergren & Jan Christoffersson. Analytical delay calculation of the short ims session setup proposal using wcdma and edge. Ericsson Confidential Report: EAB-05: Uen, [9] IETF. Rfc 3261 sip: Session initiation protocol. URL: [ ], [10] IETF. Rfc 3262 reliability of provisional response sin the session initiation protocol (sip). URL: [ ], [11] IETF. Rfc 3263 session initiation protocol (sip): Locating sip servers. URL: [ ], [12] IETF. Rfc 3265 session initiation protocol (sip)-specific event notification. URL: [ ],

61 58 Bibliography [13] IETF. Rfc 3903 session initiation protocol (sip) extension for event state publication. URL: [ ], [14] IETF. Rfc 3856 a presence event package for the session initiation protocol (sip). URL: [ ], [15] Jan Christoffersson & Tomas Jönsson. Presence traffic impact on gsm/edge capacity. Ericsson Limited Internal: EAB -04: Uen, [16] Fan Rui & Wang Min. Impact of presence traffic on downlink voip system performance. Ericsson Confidential Technical Report: EAB-06: Uen. [17] Daniel Puaca & Sofia Svedevall. Support for multiple qos conversational users in gsm mixed traffic. Ericsson Internal Technical Report: EAB/FJG-08:1915 Uen (Ongoing study), [18] Ubiquity. Understanding sip - white paper. URL: SIP_Overview.pdf [ ], [19] Mats Wernersson. Scheduling of multi-media over 3gpp lte. Ericsson Internal Report: EAB-07: Uen, [20] Mats Wernersson. Effects of sip setup signaling on voip performance in lte. Ericsson Wide Internal Report: EAB-07: Uen, 2008.

62 Appendix A Abbreviations AMR BSC BSS BTS CIR CS GGSN GMM/SM GPRS GSM IMS IRA LA MCS MMTel MS MSC PS PSTN QoS SGSN SIP SMS TDMA TS UA VLR VoIP Adaptive Multi Rate Base Station Controller Base Station System Base Transceiver Station Carrier to Interference Ratio Circuit Switched Gateway GPRS Support Node GPRS Mobility Management and Session Management General Packet Radio Service Global Service for Mobile transmission IP Multimedia Subsystem Interference Rejection Algorithm Location Area Modulation and Coding Scheme MultiMedia Telephony Mobile Station Mobile Services Switching Center Packet Switched Public Switched Telephone Network Quality of Service Serving GPRS Support Node Session Initiation Protocol Short Message Service Time Division Multiplex Access Timeslot SIP User Agent Visitor Location Register Voice over IP 59

63

64 Upphovsrätt Detta dokument hålls tillgängligt på Internet eller dess framtida ersättare under 25 år från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida Copyright The publishers will keep this document online on the Internet or its possible replacement for a period of 25 years from the date of publication barring exceptional circumstances. The online availability of the document implies a permanent permission for anyone to read, to download, to print out single copies for his/her own use and to use it unchanged for any non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional on the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: c Pasha Ayani & Petter Gustafsson