Impact and Multiplexing of SIP Signaling in GSMliu.diva-portal.org/smash/get/diva2:634053/FULLTEXT01.pdf · Department of Science and Technology Institutionen för teknik och naturvetenskap

Department of Science and Technology Institutionen för teknik och naturvetenskap Linköping University Linköpings Universitet SE-601 74 Norrköping, Sweden 601 74 Norrköping

LiU-ITN-TEK-A--09/009--SE

Impact and Multiplexing of SIPSignaling in GSM

Pasha AyaniPetter Gustafsson

2009-02-20

LiU-ITN-TEK-A--09/009--SE

Impact and Multiplexing of SIPSignaling in GSM

Examensarbete utfört i datavetenskapvid Tekniska Högskolan vid

Linköpings universitet

Pasha AyaniPetter Gustafsson

Handledare Sofia SvedevallExaminator Di Yuan

Norrköping 2009-02-20

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 extra-ordinä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örickekommersiell forskning och för undervisning. Överföring av upphovsrättenvid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning avdokumentet kräver upphovsmannens medgivande. För att garantera äktheten,säkerheten och tillgängligheten finns det lösningar av teknisk och administrativart.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman iden omfattning som god sed kräver vid användning av dokumentet på ovanbeskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådanform eller i sådant sammanhang som är kränkande för upphovsmannens litteräraeller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press seförlagets hemsida http://www.ep.liu.se/

Copyright

The publishers will keep this document online on the Internet - or its possiblereplacement - for a considerable time from the date of publication barringexceptional circumstances.

The online availability of the document implies a permanent permission foranyone to read, to download, to print out single copies for your own use and touse it unchanged for any non-commercial research and educational purpose.Subsequent transfers of copyright cannot revoke this permission. All other usesof the document are conditional on the consent of the copyright owner. Thepublisher has taken technical and administrative measures to assure authenticity,security and accessibility.

According to intellectual property law the author has the right to bementioned when his/her work is accessed as described above and to be protectedagainst infringement.

For additional information about the Linköping University Electronic Pressand its procedures for publication and for assurance of document integrity,please refer to its WWW home page: http://www.ep.liu.se/

© Pasha Ayani, Petter Gustafsson

AbstractBy the introduction of IMS, future mobile voice traffic will gradually be based onIP. This means that GSM has to undergo further development in order to staycompatible with other mobile networks. Before introducing VoIP into GSM, theimpact of the SIP signaling needs to be investigated. Therefore, the objective ofthis master thesis is to simulate and evaluate how SIP signaling could be multi-plexed with VoIP traffic and other MMTel services in the GSM network.

In order to multiplex the SIP signaling with other traffic types, new delaysensitive scheduling algorithms have been derived and analyzed along with a dy-namic allocation algorithm. The allocation algorithm provide each mobile userwith a number of timeslots and frequencies used to transmit its data, while thescheduling algorithms are used to conclude which user that should get the highestpriority when several users try to transmit data at the same time and on the samefrequency.

Unfortunately, it was not possible to receive any reliable data within the giventimeframe due to bugs and errors in the simulator software. Therefore, the con-clusions 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 GSMsystem, the presence signaling should be lower prioritized than VoIP and SIP sig-naling. It is also concluded that the delay sensitive scheduler which is dependenton previous penalties in both the UL and DL scheduling is to be preferred whenhigh multiplexing levels are reached. Furthermore, the throughput of the down-prioritized MMTel service should not be expected to be high when the VoIP trafficis intense.

1

SammanfattningFramtidens taltrafik i mobila nätverk kommer alltmer vara IP-baserade. Dettabetyder att GSM måste kompletteras med nya funktioner för att förbli kompatibeltmed andra mobila nätverk. I samband med introduktionen av VoIP i GSM kommerytterligare signalering tilkomma i form av SIP-signalering. Detta examensarbetesyftar till att undersöka hur SIP-signaleringen skall multiplexas i GSM med VoIPtrafik och andra MMTel tjänster.

För att uppnå en effektiv multiplexing, och kunna maximera antalet VoIP-användare, har nya fördröjningskänsliga algoritmer för schemaläggning och allok-ering tagits fram och utvärderats. En dynamisk allokeringsalgoritm har tagits framför att på ett effektivt sätt kunna tilldela varje användare ett antal tidluckor ochfrekvenser för att skicka data. Algoritmerna för schemaläggning används för attavgöra prioriteten av varje användare då flera användare vill skicka data i sammatidpunkt och på samma frekvens.

Tyvärr har det inte varit möjligt att uppnå några tillförlitliga resultat inom dengivna tidramen. Via simuleringar upptäcktes felaktigheter i simulatorn som gjordeatt resultaten blev både oberäkneliga och opålitliga. Slutsatserna i detta arbetebaseras 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äggarenmed 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-signaleringvara lägre än prioriteten av VoIP och SIP-signalering. Datahastigheten av en lågtprioriterad MMTel-tjänst bör ej heller förväntas vara snabb då intensiteten avVoIP-trafik är hög.

3

Acknowledgments

First of all we would like to thank our head supervisor at Ericsson AB, SofiaSvedavall, for all the support and patient listening during this thesis work.

Secondly, we would like to send a special thanks to Andreas Bergström, ThommyJakobsson, Eric Nordström and Mats Wernersson for helping us understand andtroubleshoot the simulator software.

Lastly, we would like to thank our examiner Di Yuan at Linköpings Universityfor understanding our situation and helping us find an alternative way to finishthis thesis work when the simulator software turned out to be faulty.

5

Contents

1 Introduction 91.1 Problem description . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2 Thesis objective & work description . . . . . . . . . . . . . . . . . 101.3 Outline of report . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 Background 112.1 GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.1 GSM network architecture . . . . . . . . . . . . . . . . . . . 112.1.2 Time Division Multiple Access (TDMA) . . . . . . . . . . . 132.1.3 Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.1.4 Channel allocation . . . . . . . . . . . . . . . . . . . . . . . 15

2.2 GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2.1 GPRS network architecture . . . . . . . . . . . . . . . . . . 152.2.2 The GPRS protocol stack . . . . . . . . . . . . . . . . . . . 162.2.3 Quality of Service (QoS) . . . . . . . . . . . . . . . . . . . . 172.2.4 Scheduling concept . . . . . . . . . . . . . . . . . . . . . . . 18

2.3 Session Initiation Protocol (SIP) . . . . . . . . . . . . . . . . . . . 182.3.1 SIP network architecture . . . . . . . . . . . . . . . . . . . 192.3.2 SIP request methods . . . . . . . . . . . . . . . . . . . . . . 192.3.3 SIP responses . . . . . . . . . . . . . . . . . . . . . . . . . . 192.3.4 SIP presence signaling . . . . . . . . . . . . . . . . . . . . . 21

3 Multiplexing methods 233.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.2 Allocation algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . 243.3 MS multislot classes . . . . . . . . . . . . . . . . . . . . . . . . . . 243.4 Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.4.1 Scheduling algorithms . . . . . . . . . . . . . . . . . . . . . 26

4 Traffic Models 294.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.2 VoIP traffic model . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.3 SIP traffic model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.4 Presence traffic model . . . . . . . . . . . . . . . . . . . . . . . . . 334.5 Web traffic model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

7

8 Contents

5 Traffic scenarios 355.1 Stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.1.1 Stage 1 - Only VoIP . . . . . . . . . . . . . . . . . . . . . . 365.1.2 Stage 2 -VoIP & SIP . . . . . . . . . . . . . . . . . . . . . . 365.1.3 Stage 3 -VoIP, SIP & Presence . . . . . . . . . . . . . . . . 375.1.4 Stage 4 - VoIP, SIP, Presence & MMTel . . . . . . . . . . . 37

6 Simulations 396.1 Stage 1 - Only VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.1.1 Results - Stage 1 . . . . . . . . . . . . . . . . . . . . . . . . 406.2 Stage 2 - VoIP & SIP . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.2.1 Results - Stage 2 . . . . . . . . . . . . . . . . . . . . . . . . 426.3 Stage 3 - VoIP, SIP & Presence . . . . . . . . . . . . . . . . . . . . 43

6.3.1 Results - Stage 3 . . . . . . . . . . . . . . . . . . . . . . . . 446.4 Stage 4 - VoIP, SIP, Presence & MMTel . . . . . . . . . . . . . . . 47

6.4.1 Results - Stage 4 . . . . . . . . . . . . . . . . . . . . . . . . 47

7 Discussion 537.1 Expectations & predictions . . . . . . . . . . . . . . . . . . . . . . 537.2 Conclusions & recommendations . . . . . . . . . . . . . . . . . . . 557.3 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Bibliography 57

A Abbreviations 59

Chapter 1

Introduction

This chapter describes the purpose and the problem description of this masterthesis. 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 andresearch, but also by creating a whole new necessity among ordinary people. Tobe able to call your friends and co-workers whenever you want is nowadays oneof the most natural things in the world. Since more and more people around theworld use these mobile networks, new expectations and demands on these networksarise. Mobile network suppliers are forced to adhere to these demands and therebycontinuously develop and improve the capacity and quality of their systems.

Even though modern mobile network technologies, such as 3G, have been intro-duced, 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 wayhas to be improved in order to keep up the pace and stay compatible with thenewer systems.

By the introduction of the IP Multimedia Subsystem (IMS), future voice trafficwill gradually be based on IP. This means that GSM has to be complemented withnew 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 Pro-tocol (SIP) signaling. Therefore it is interesting to investigate how SIP signalingwill affect system capacity and end-user performance.

9

10 Introduction

1.2 Thesis objective & work descriptionThe objective of this master thesis is to evaluate how SIP signaling could bemultiplexed with VoIP traffic and MMTel services in the GSM network. Themultiplexing method should maximize the number of VoIP users in the systemwhile maintaining reasonable levels of packet loss and packet delay.

In order to fulfill these objectives the work has been conducted in the followingsteps:

• Study literature in order to get insights and knowledge about the GSM radionetwork.

• Study reports and other finalized studies in the MMTel & SIP area and learnabout multiplexing methods used in GSM today.

• Derive new methods for scheduling and allocation, taking SIP and QoS intoconsideration.

• Implement the derived method for allocation in the simulator software.

• Through simulations determine how SIP and MMTel services should be mul-tiplexed with VoIP traffic.

• Analyze simulation results and draw conclusions about the impact of SIPsignaling on VoIP capacity.

1.3 Outline of reportThe structure of this report is laid out so that Chapter 2 gives an overview ofthe GSM/GPRS radio network and SIP. Chapter 3 describes the multiplexingmethods, including scheduling and allocation algorithms. Further on, Chapter 4specifies the different traffic models used to define the users in the simulations.Chapter 5 presents the different simulation stages while Chapter 6 presents theexpected results which are then analyzed in Chapter 7.

Chapter 2

Background

This chapter begins by providing an overview of the GSM radio network andits extension GPRS. It continues with a theoretical background of SIP to givethe reader the basic understanding of the signaling behavior. For more detailsregarding the GSM/GPRS radio network see [4], [5].

2.1 GSMThe development of mobile systems is often divided into different generations.The 1G (1st generation of wireless mobile networks) networks are analogue whilethe 2G (2nd generation of wireless mobile networks) networks are digital. GlobalService for Mobile communication (GSM) is an example of a 2G technology. Thedemand for wireless internet connections and increased capacity of GSM have ledto the development of GPRS. This system is based on data packets and is oftenreferred to as a 2,5G technology. GSM on the other hand relies on circuit switchedtraffic (CS) and therefore doesn’t use any packet data. When a CS call is madebetween two users, the resources needed for the call are occupied for the entiresession.

2.1.1 GSM network architectureThe network architecture which provides GSM with radio coverage and enablestwo end-users to contact each other is composed of several different hardware andsoftware nodes. Figure 2.1 gives an overview of this network architecture.

11

12 Background

BSC

VLRMSC

Air interface

PSTN

BTS

MS

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 themobile network. This equipment is most commonly a mobile phone. The capacityof 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 controlledand transmitted by the BTS. It is composed of radio equipment such as antennasand transceivers which are needed in order to provide radio coverage in the par-ticular area. Several BTSs can be controlled by a single BSC, and together, thesetwo 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 relatedfunctions in a GSM network. For example, it controls handovers when an MS istransferred between different cells. Several BSCs can be controlled by one singleMSC.

Mobile services switching center & visitor location register (MSC/VLR)

The MSC provides the mobile system with telephony switching functionality. Itcontrols calls to and from other telephony and data networks, such as the Public

2.1 GSM 13

Switched Telephone Network (PSTN) which can be described as the telephony net-works’ equivalence to the Internet. The VLR is a database and is often integratedinto the MSC. Its function is to provide information about the subscribers visitingthe particular MSC service area.

Cells and location areas (LAs)

To describe the geographical coverage area of the GSM network structure, oneshould be familiar with cells and LAs. A cell can be described as the geographicalarea where radio coverage of a BTS is provided. Usually, three adjacent cells arecovered 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 2

LA 1

VLRMSC

Figure 2.2. Cells and location areas (LAs)

2.1.2 Time Division Multiple Access (TDMA)There are different technologies that utilize the resources in a radio network indifferent ways; GSM uses a technology called TDMA. The principle of this tech-nology 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 totransmit and receive data on the same frequency. When a call is made, an MS useris assigned TSs on two different frequencies. One frequency is used to transmit

14 Background

data; this frequency is called the uplink (UL) frequency. The other frequency isused for receiving data; this frequency is called the downlink (DL) frequency.

In GSM, eight timeslots are defined as a TDMA frame. This enables eightdifferent calls to be carried by one single frequency. The data sent on a singletimeslot, during a single TDMA frame, is called a burst and is composed of anumber of bits. In a normal burst the tail bits (TBs) are placed at the begin-ning and end of the burst to indicate the start and stop of the TS. The trainingsequence is a bit pattern that is known by both the MS and the BTS. The re-ceiver uses this pattern to determine and correct any error affected bits that mayhave occurred during the transmission on the air interface. The data bits are theactual information to be sent while the guard period is an empty period used toseparate the information on adjacent timeslots. Figure 2.3 show the structureof a normal burst. Furthermore, it takes four bursts to transmit an entire radioblock. Although, when using EDGE (see Section 2.2) this can be modified by us-ing Reduced Transmission Time Interval (RTTI) which means that the bursts aredivided between two consecutive TSs. This means that only two TDMA frames(instead of four) are needed to transmit an entire radio block.

0

TB3

Data bits57

Training seq.26

Data bits57

TB3

GP8,25

7654321

1 TDMA frame = 8 timeslots (~4,615 ms)

1 timeslot = 156,25 bit durations (~0,577 ms)

1 1Normal

burst

Figure 2.3. The relationship between a normal burst and a TDMA frame.

2.1.3 ChannelsThere are two types of channels; physical channels and logical channels. Eachphysical channel is a timeslot on a TDMA frame, which means that there areeight physical channels on each TDMA frame. These physical channels are used fortransferring different types of data. Depending on what type of data is being sent,different types of logical channels are mapped onto the physical channels. Thereare two basic groups of logical channels; control channels and traffic channels.The control channels are used for the transfer of control information which can beLA identity information, cell identity information, call setup procedures etc. Thetraffic 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).

2.2 GPRS 15

2.1.4 Channel allocationChannel allocation is the functionality that provides a certain user with a radioresource to be able to send and receive its data. A radio resource is composed ofone, or several, frequencies and timeslots.

2.2 GPRSThe General Packet Radio Service (GPRS) is often described as 2,5G, enablingGSM mobile users to send packet data. Traffic sent as packet data is called packetswitched traffic (PS) and is different from CS traffic; instead of reserving the fullbandwidth of a channel for the entire duration of the call, PS traffic let multipleusers share the same channel by only using bandwidth whenever they actually aresending any packets.

In order to achieve enhanced data rates in the GSM/GPRS network, newmodulation methods and channel coding schemes have been introduced. Thisfeature is called Enhanced Data rates for GSM Evolution (EDGE) and is capableto triple the data rates per user (compared to ’normal’ GPRS). The RTTI featureis also a part of the EDGE technology and is a prerequisite for using VoIP andadvanced MMTel services such as video streaming, web surfing and multimediamessages in the GSM network. For further information see [6].

2.2.1 GPRS network architectureWhen introducing GPRS to the GSM network a couple of new nodes are introducedin 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 itsgeographical service area. It also handles other functions such as authenticationand charging.

Gateway GPRS Support Node (GGSN)

The GGSN acts as the interface between the GPRS network and other externalIP-based networks. The GGSN handles routing of incoming external traffic andexchanges routing information with external IP-based networks. The backbonenetwork is the collection of connections that provide the GGSN and SGSN with acommunication path.

16 Background

BSC

GGSN

SGSN

VLRMSC

Air interface

PSTN

External IP-basednetworks

Backbone network

BTS

MS

Figure 2.4. The GPRS network architecture.

2.2.2 The GPRS protocol stack

In order to understand how the user data traverses from the MS, through the airto 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 comefrom. These bits include application information as well as information providedby 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 withaddress information. These bits are then passed down further in the protocolstack and added to the Subnetwork Dependent Convergence Protocol (SNDCP)bits. This protocol compresses and decompresses user data and protocol controlinformation [2].

The LLC layer is primarily concerned with functions related to multiplexing/de-multiplexing, error control and ciphering/deciphering SNDCP packets. After theLLC layer the data bits pass through the RLC/MAC layer. RLC stands for RadioLink Control and provides a reliable radio link between the MS and BTS. MACstands 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 givenfrequency and timeslot to the BSS.

2.2 GPRS 17

BSSMS

Application

IP

SNDCP

LLC

RLC

MAC

GSM RF

Application

ApplicationIP

ApplicationIPSNDCP

LLC ApplicationIPSNDCP

RLC/MAC LLC ApplicationIPSNDCP

Relay

L1bisGSM RF

MACNetworkService

BSSGPRLC

Figure 2.5. The GPRS protocol stack.

2.2.3 Quality of Service (QoS)QoS is a feature available for PS traffic that enables separate handling and prioriti-zation of different types of traffic. By grouping different types of traffic flows (thatfor example share the same delay requirements) together, several traffic classes canbe defined. In year 2000, the 3rd Generation Partnership Project (3GPP) releaseda QoS profile in their standard that consists of four unique traffic classes [1]:

• Conversational - This QoS traffic class is defined to support two-way, real-time services. Since there are people at both ends of the communicationwhen using this class, the tolerance to delay and delay variation (jitter) isvery low and directly affects the end-user performance. The most obviousservice belonging to the conversational QoS traffic class is speech traffic. Asnew multimedia services are developed, other types of traffic may belong tothis class, such as real-time video conferencing.

• Streaming - This QoS traffic class is designed to support one-way videoand audio streaming. The tolerance for delay is higher than that for theconversational class, but the tolerance for jitter is low.

• Interactive - The interactive QoS traffic class is applied when the end-user is using services that request data online and therefore is expecting theresponse quite quickly, such as web-browsing.

• Background - This QoS traffic class is used when the end-users aren’tdependent of the exact arrival time of the packets. Services belonging tothis QoS traffic class could be e-mail and file transfer.

18 Background

By the use of these defined QoS traffic classes the scheduling algorithm can beadapted to, for example, give voice calls higher priority than web surfing traffic.The scheduling concept is discussed further in Section 2.2.4.

2.2.4 Scheduling conceptThe scheduling concept refers to the algorithm in the BSC that determines inwhich order clients should send their data on the radio resources, both in uplinkand in downlink. When several users want to send their data on the same frequencyat the same time, the scheduler needs to decide in which order the users shouldtransmit their data. By using the QoS traffic classes the scheduler can differentiatebetween different types of traffic, enabling the scheduler to schedule traffic in thefollowing order:

1. Signaling (GMM/SM)

2. Conversational (VoIP)

3. Streaming (Video streaming etc.)

4. Interactive (Web surfing)

5. Background (E-mail, MMS etc.)

The most important traffic type is GPRS signaling called GPRS Mobility Man-agement and Session Management (GMM/SM). Mobility management refers tosignaling that informs the network of a user’s availability, i.e. the physical locationof a user and whether the user is attached or detached to the GPRS network. Ses-sion management is used to setup sessions between the user and a service networkor 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 onthe same radio resources. In these cases the scheduler needs to consider otherparameters than just the QoS traffic class. A common way to separate betweentwo 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 theweight is often based on packet delay. When two users wants to send packets atthe same time and on the same frequency, the user with the longest packet delaywill get the highest weight. Since higher weight often equals higher priority, theuser with the highest weight will be scheduled first.

For other services that may not be delay sensitive, the weight can be based onother parameters, such as the number of times the user has been scheduled. Thisresults 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 forsetting up, modifying and terminating sessions and is independent of underlying

2.3 Session Initiation Protocol (SIP) 19

transport protocols. A session is a connection between two, or more, users thatinteract using voice, video, audio or any other type of media. SIP itself is unawareof what type of media that is being managed; it only knows how to managethe session. Furthermore, SIP is text based, making it easy to interpret andunderstand, similar to its relatives HTTP and SMTP [18].

2.3.1 SIP network architectureIn order to establish a SIP session, a number of major network components needto be used. In this section however, these will be generalized and put into twocategories: SIP user agents (UAs) and SIP proxy servers [11]. UAs are the physicalequipment (mobile phones, PDAs, PCs etc.) and software used by the end-usersto initiate and manage SIP sessions and SIP proxy servers are the intermediate,physical or logical, nodes. A SIP proxy server ensures that SIP requests arepassed to another node closer to the end destination. A SIP proxy server can alsointerpret, and if necessary, rewrite parts of a request before it gets forwarded.

2.3.2 SIP request methodsSIP request methods are used by UAs and proxy servers to communicate. Eachrequest method usually invokes a series of consecutive SIP messages that end witha response message (see Section 2.3.3). SIP uses a number of different requestmethods [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 notifiedwhen a certain user publishes an event.

2.3.3 SIP responsesA SIP response can either be a final or a provisional response. A final responseis the ultimate result of the processed request, while a provisional response pro-vides additional information concerning the server’s current action. There are sixcategories of responses identified by an integer from 100 to 699:

• 1xx - Provisional responses giving additional information on a server’s ac-tions. For example, 180 Ringing indicates that the recipient’s phone is ring-ing.

20 Background

• 2xx - Positive final responses indicating that the request was successful. Forexample, 200 OK can indicate that the recipient has accepted the INVITErequest.

• 3xx - Responses used for redirecting a caller. For example, 380 Alternativeservice indicates that the call was unsuccessful but that alternative servicesare available.

• 4xx - Negative final response indicating that there is a problem on the client’sside. For example, 401 Unauthorized indicates that the request requires userauthentication.

• 5xx - Negative final response indicating that there is a problem on theserver’s side. For example, 513 Message too large indicates that the serverwas unable to process the message due to its size.

• 6xx - A final response indicating a global failure. For example 603 Declineindicates that the recipient was contacted successfully but explicitly doesn’twant to or cannot participate.

See Figure 2.6 for an example of how the SIP request methods and responsesinteract in order to setup and terminate a call between two UAs.

User A Proxy Server User B

INVITE

180 Ringing

200 OK

ACK

SESSION

BYE

INVITE

100 Trying

180 Ringing

200 OK

ACK

200 OK

BYE

200 OK

Call Setup

Call Termination

Figure 2.6. SIP session call setup and termination.

2.3 Session Initiation Protocol (SIP) 21

2.3.4 SIP presence signalingPresence, or presence information, is a service provided in order to get status infor-mation about a user without direct contact. This type of service emerged as earlyas 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 havenever been a set of standards for presence, the Internet Engineering Task Force(IETF) has developed an extension to SIP to provide this functionality. The ex-tension is called Session Initiation Protocol for Instant Messaging and PresenceLeveraging Extensions (SIMPLE) and is an open standard [12], [13], [14].

A client that wants to receive presence information is called a watcher and theset of users that the watcher wants to receive information from is called presenti-ties. Furthermore, a group of presentities is referred to as a buddy-list. In orderto get the updates, the watcher needs to subscribe to the presentities’ presenceinformation. With the use of a buddy-list a watcher can be informed whenevera presentity in the buddy-list updates its presence information. Figure 2.7 showsan example of a UA that updates his presence information (initiates a PUBLISHrequest) and subscribes to a presentity (initiates a SUBSCRIBE request).

UA Presence Server

PUBLISH

200 OK

SUBSCRIBE

200 OK

200 OK

NOTIFY

200 OK

NOTIFY

UA sending an updateto the presence server

UA subscribing onsome presentity

Figure 2.7. A SIP presence session between a UA and a SIP presence server.

22 Background

There are two different methods to send buddy-list updates to a watcher fromthe server. Either, a push-based system or a pull-based system is used. In a push-based system the server automatically sends updates to the watcher as soon asthe 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, dependingon the number of presentities in the buddy-list.

In a pull-based system the watcher polls the server in order to get the desiredupdates. This method can reduce the amount of presence traffic since the pollinterval is independent of the number of updates sent by the presentities to thepresence server; i.e. the poll interval determines the trade-off between an updatedbuddy-list and presence traffic intensity. For example, a short polling interval leadsto frequent updates and therefore an up to date buddy-list, but large amountof presence traffic also arise. One of the drawbacks of a pull-based system isthat polling occurs even if no presentities in the buddy-list have updated theirinformation, which will lead to unnecessary traffic.

Chapter 3

Multiplexing methods

In this chapter the methods for multiplexing are discussed; this includes the im-plemented allocation algorithm, scheduling algorithms and MS multislot classes.

3.1 General

Multiplexing is a widely used concept that indicates that multiple data streamsshare the same transport medium. In this study, multiplexing is referred to whenseveral users share the same radio resource. Multiplexing of SIP signaling withother traffic types have been studied [20], but its impact on VoIP capacity haspreviously been overlooked in GSM studies. The objective of this thesis is to fillthis gap and evaluate how SIP signaling could be multiplexed with other types oftraffic 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 thephysical layers, protocols as well as the traffic. What is not implemented though, isthe use of actual control channels. All physical channels in the simulator softwareare regarded as PDCHs. This software was originally designed for simulating otherradio networks and has later on been adapted for simulating the GSM network.

In this study, only conversational and background traffic flows are used alongwith SIP. The streaming traffic class is not considered in this study since its fairlystrict 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 implementedin the simulator software. Background traffic on the other hand, is convenient touse since it is not delay sensitive. Also, since this class will be represented by asimple 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

24 Multiplexing methods

3.2 Allocation algorithmChannel allocation is a method used to provide a certain user with a number ofTSs and frequencies on which the user can transmit and receive data. Previously,no dynamic allocation algorithm was implemented in the simulator software. TSsand 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 wouldget allocated to these TSs for the entire simulation. Obviously, this static way ofallocating 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 to-gether, PS traffic and CS speech will have to share frequencies (TS sharing is notpossible 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 primarilyallocated from right to left. In this study however, no CS traffic is included andtherefore all TSs are available for PS traffic. Furthermore, since RTTI is used inthe simulations, two consecutive TSs can be seen as a ’bin’. This means that onlyfour different positions on the TDMA frame are available for allocation. These arethe characteristics by which the implemented allocation algorithm is designed.

The algorithm begins by placing the PS clients in the rightmost bin and con-tinues by placing them to the left. Also, since the UL frequency is most likelyto act as a bottleneck (further discussion in Section 3.4) it is necessary to utilizeas many TSs in the UL as possible. Therefore an evaluation is made so that theclient 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 allocatedto the client.

3.3 MS multislot classesAn MS multislot class defines the number of TSs an MS can utilize in the ULand DL. In this study, two different MS multislot classes have been implemented.The first multislot class represents an MS capable of transmitting and receivingon two TSs in the DL and UL frequency respectively. The second multislot classrepresents an MS capable of receiving information on four consecutive TSs in theDL 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 becauseit is at present time a widely used MS multislot. Multislot class 31 on the otherhand, is not used today but might very well be more common in the future. Figure3.1 presents these MS multislot classes graphically.

ULDL

ULDL

Figure 3.1. MS multislot class 5 to the left and multislot class class 31 to the right.

3.3 MS multislot classes 25

When using the allocation algorithm described above, clients of multislot class31 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 framewith the implemented allocation algorithm. In order to utilize the UL as muchas possible, the leftmost bin will always be allocated by a client of multislot class5. See Figure 3.2 and 3.3 for an illustration of how the implemented allocationalgorithm allocates TSs for clients of the different multislot classes.

0 7 TDMA frame654321ULDL

1

ULDL

8

ULDL

7

ULDL

6

ULDL

5

ULDL

2

ULDL

3

ULDL

4

Figure 3.2. TS allocation for clients of multislot class 5.

0 7 TDMA frame654321ULDL

1

ULDL

8

ULDL

7

ULDL

6

ULDL

5

ULDL

2

ULDL

3

ULDL

4

Figure 3.3. TS allocation for clients of multislot class 31.

26 Multiplexing methods

3.4 SchedulingWhen multiplexing several clients, the scheduler needs to determine in which orderthey should send their data on the radio resource. Previously, the implementedscheduling algorithm was a simple Round-Robin scheduler (called Scheduler Cin this study) that assigned a weight to each user. If two users had the sameQoS traffic class the priority would be based on this weight. The weight wascalculated by calculating the number of times a user had been scheduled. Thisway 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 hadbeen scheduled many times less important than users who hadn’t.

Since VoIP utilizes the PS domain, several VoIP users might need to sharethe same radio resource with other PS service users. In order to maintain thedelay requirements for the conversational traffic class, the scheduler needs to becomplemented with functionality that determines how long a certain VoIP packethas been in queue for transmission. The reason for this is that the VoIP service bydefinition is very delay sensitive, which means that packets quickly get out-of-dateand thereby dropped. On the other hand, this sensitivity doesn’t apply to trafficof the background QoS traffic class.

As previously mentioned, the UL is assumed to be the bottleneck since theBSC 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 everyTDMA 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 theUL. 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 afair way, the perceived quality might drop due to packet delay. This is not an issuein the DL since the BSC has full insight of what data is to be sent to each MS.

3.4.1 Scheduling algorithmsTwo different schedulers (Scheduler A and Scheduler B) have been derived andanalyzed. The schedulers are delay sensitive and their penalties are determined bytheir weight. Both schedulers take packet age and queue sizes into considerationin the DL weight calculation while the UL weight calculation only is dependenton packet age. However, in the UL penalty, Scheduler A is also dependent onprevious penalties while Scheduler B is not. Also, in order to increase the chancefor a down-prioritized service to get scheduled, the schedulers assign a zero weightto VoIP users who are trying to transmit data very soon after having a successfultransmission.

The minimum age threshold plays an important role in the scheduling algo-rithms for the UL; it regulates the balance between user performance and the levelof multiplexing. The threshold defines the time a user gets blocked from schedulingafter having a successful transmission. A high threshold thereby let more usersget a chance to get scheduled while a low threshold let less users get the samechance. This fairness of giving other users a chance to get scheduled after a suc-

3.4 Scheduling 27

cessful transmission is needed in the UL, in order to let down-prioritized servicesget scheduled more frequently.

In the DL on the other hand, it is easier to foresee how much resources thatwill be needed by each user. Since the BSC knows how much data each userwants to transmit and how long the packets have been waiting, it is reasonable tolet these parameters (i.e. queue size and packet age) determine the weight. Bydoing so, users with a large queue size may get scheduled more frequently to avoidletting packets get out-of-date. In the same fashion, users with old packets maybe scheduled more frequently.

Since traffic flows of the background traffic class aren’t delay sensitive, theweight is simply set to a static value. This is adequate in this study since thepurpose of including background traffic flows is to simply determine whether theseflows get any throughput at all and not exactly how much.

Chapter 4

Traffic Models

This chapter describes how each traffic flow is represented in the simulator soft-ware. It also presents in what way these traffic flows have been configured tobehave in an sufficiently realistic way.

4.1 GeneralIn the simulator software, each traffic model represents one single traffic type andis used to generate the corresponding traffic flow. In this study there are fourdifferent types of traffic models that define the MS clients that will be used in thedifferent traffic scenarios (see Chapter 5). The VoIP traffic model represents thePS speech traffic and this is the traffic flow that will be investigated in terms ofcapacity loss when introducing SIP signaling. SIP signaling is divided into twoseparate traffic models; the SIP traffic model and the presence traffic model. TheSIP traffic model represents the call setup and termination part of the signaling,while the presence traffic model only represents the presence traffic. The fourthand last traffic model to be used is the web traffic model that will represent a filetransfer. From this point on, SIP call setup and termination will be referred to asSIP signaling while SIP presence traffic will be referred to as presence traffic.

4.2 VoIP traffic modelThe VoIP traffic model generates the traffic flow between two VoIP users. Thistraffic models is treated as the conversational QoS traffic class, as described in[1]. This means that this traffic flow will have absolute scheduling priority overtraffic flows of the background QoS traffic class. Also, the VoIP traffic modelutilizes the UDP protocol. UDP is an unreliable transport protocol, meaningthat it doesn’t do any retransmissions of lost packets. This is desirable becausespeech traffic is a real time communication where both ends are occupied by realpersons. Very delayed packets will therefore be useless, since they contain out-of-date information. In this case, it is better to drop these packets and move on to

29

30 Traffic Models

the next. End user perception will thus be less affected by lost packets than latepackets. In this study, the delay threshold has been set to 300 ms which meansthat packets that arrive at the recipient with a greater delay than this thresholdwill be dropped and thereby regarded as lost.

Table 4.1 shows interesting parameters used to define the behavior of the VoIPtraffic in the simulations. These parameters are based on the findings from previousstudies in related areas [7], [15].

Parameter Value DescriptionTalk spurt duration 40 s The duration of each speech

sequence.Voice activity 0.5 The speech intensity. A

value of 0.5 means that atleast one of the two endusers is talking.

Graceful termination True Setting this parameter to’true’ means that the life-time of each user will beequal to the length of theconversation.

Conversation duration 120 s The length of each conversa-tion.

Frame size 344 bits The size of the voice frames.Represents AMR 7.95kbit/s.

Max delay 0.3 s Packets that have a delaythat exceeds this value areconsidered as lost.

Frame Period 0.04 s This parameter defines thetime between each voiceframe transmission.

Encoding delay 0.015 s The time it takes to encodethe voice frames.

Decoding delay 0.015 s The time it takes to decodethe voice frames.

Terminal capability (UL and DL) Dual timeslot This corresponds to usingRTTI (10 ms).

Table 4.1. VoIP traffic model parameters.

4.3 SIP traffic modelThe SIP traffic model simulates the call setup and call termination. This trafficmodel doesn’t belong to any QoS traffic class and will therefore in the simulationsbe 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

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 thisinformation 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]. Table4.2 shows the implemented messages and their corresponding sizes.

Message type Size (byte)183 SESSION IN PROGRESS 1270INVITE 1113PRACK 1014200 OK 890180 RINGING 888BYE 878ACK 427PUBLISH 800NOTIFY 700SUBSCRIBE 600

Table 4.2. The implemented SIP messages and their corresponding size.

INVITE request method

The implementation of the INVITE request method in the simulator softwareallows users to setup media sessions. In Figure 4.1 the message flow of the INVITEmethod 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. Thefirst retransmission is done after 500 ms, which corresponds to the Round TripTime (RTT), and the consecutive retransmissions are done at 2*RTT (RTT is anestimate of the transaction time between the client and server). This continuesuntil the retransmission interval hits a 4 s limit. For further details regarding theseparameter values and the retransmission timer, see [9].

32 Traffic Models

183 Session In Progress

PRACK

180 Ringing

INVITE

200 OK

200 OK

ACK

User A User B

Pick-up Delay

Establish Radio Bearer

Establish Radio Bearer

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 requestmethod. This method uses the same retransmission timer as the INVITE requestmethod. As seen in Figure 4.2, this method is a lot less complex than the INVITErequest method. For more details regarding the implementation of SIP in thesimulator software, see [19].

BYE

200 OK

User A User B

Figure 4.2. SIP call termination session.

4.4 Presence traffic model 33

4.4 Presence traffic modelThe presence traffic model simulates a SIP UA and a presence server and generatesthe presence traffic sent between them. The implementation is based on a push-based system where the client registers to the server and subscribes to a virtualbuddy-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 sentto the client. Figure 4.3 show the message flow generated by a user when entering apresence session. Furthermore, Table 4.3 and 4.4 shows the interesting parametersettings for the presence client and the presence server respectively that is used inthe simulations. The publish intervals for the client and the server should be thesame if it is assumed that they share the same SIP signaling configuration.

Parameter Value DescriptionPublish 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 re-

registrations 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 DescriptionPublish interval 20 min The time between two consecutive PUB-

LISH messages sent by the presentities tothe server.

Re-registration timeout 60 min If no re-registration is received from theclient during this period, the client is re-moved from the registered list.

Subscription list length 5 The size of the buddy-list.

Table 4.4. Presence server parameters.

34 Traffic Models

200 OK

PUBLISH

200 OK

SUBSCRIBE

200 OK

NOTIFY

User Server

. . .

Figure 4.3. Presence message flow.

4.5 Web traffic modelThis is the traffic model used to simulate a DL oriented file transfer. The modelconsists of two different entities; the web client and the web server. The webclient always initiates the communication by sending an HTTP request to the webserver. In response to this request, a web object is sent from the web server tothe client. These objects could represent anything from an HTML web page to anmp3-file. A rather small object size is used to represent simple web pages whilea rather large object size could represent some kind of media file. In this studythe object size is set to 5 MB in order to avoid the web traffic model from goinginto an idle state and thereby having zero packets in the queue. Table 4.5 showsinteresting parameters used to define the web traffic in the simulations.

Parameter Value DescriptionObject 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.

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

5.1 StagesTo be able to determine the impact of SIP signaling, different traffic scenarios needto be defined and analyzed. The scenarios are divided into different stages; there’sonly 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 thesystem (for further information about frequency hopping, see [5]). This is donein order to reduce vulnerability, secure transmission quality and maximize systemperformance. In the simulator software, all clients use the same frequency hoppattern at all time. In order to get enough representable data, the number ofsimulation iterations have been set to 20.

Parameter ValueSimulation length 120 sNumber of base stations 1Number of cells 1Number of frequencies per cell 124Frequency hopping YesNumber of TSs available for VoIP 8Minimum Age Threshold (minAgeThd) 30 msSimulation iterations 20

Table 5.1. Parameter settings used in all scenarios.

Furthermore, each stage is composed of scenarios with different radio conditionsand scheduling prioritizations. Radio conditions are determined by the Carrier

35

36 Traffic scenarios

to Interference Ratio (CIR) and are treated by using an appropriate Modulationand Coding Scheme (MCS). A low CIR value indicates that the radio conditionsare poor and implies that the BSC should use a low MCS. A low MCS meansthat a greater part of the sent packet is composed of coding bits that make thetransmission less sensitive to packet drops. For example, if a packet is droppedusing MCS-8, more data bits will be lost than if using MCS-5. In this study, staticCIR 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 helpreduce interfering signals and thereby the perceived CIR value will be improved.Since no IRA has been implemented in the simulator software, a static addition of8 dB has been added to the CIR values [7]. When accommodating the maximumnumber of users, at most 5% of the VoIP users are allowed to have an averagevoice frame loss rate of no more than 4% in each traffic flow direction. This limitis defined as the system’s capacity limit.

CIR CIR + IRA Coding scheme14 dB 22 dB MCS-518 dB 26 dB MCS-722 dB 30 dB MCS-8

Table 5.2. The CIR values and MCSs used in the different scenarios.

5.1.1 Stage 1 - Only VoIPThe purpose of this stage is to determine the maximum possible number of simul-taneous VoIP users in the system and obtain a capacity reference for the comingstages. Since the users are modeled only by a VoIP traffic model, no call setup ortermination is done in this stage.

According to [8], a CIR value of 14 dB and MCS-5 can be seen as a border caseof when it is possible to run VoIP over EDGE with decent quality. This is why 14dB 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 accommodate16 simultaneous users under good radio conditions [17]. By using half rate trafficchannels the maximum number of CS users in GSM is 16 (on eight TSs). Sincethe idea of introducing VoIP is to enable compatibility with future radio networksand maintain current performance and capabilities, the desired maximum numberof VoIP users in this study is also 16.

5.1.2 Stage 2 -VoIP & SIPIn 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 purposeof this stage is to investigate how the SIP signaling is supposed to be prioritizedcompared to the VoIP traffic. As previously mentioned, there are only two options

5.1 Stages 37

for SIP prioritization since only the background and conversational QoS trafficclasses are used. The best way to prioritize is determined by examining the numberof retransmitted SIP messages. By studying the number of SIP retransmissionsit is possible to see how the call setup and termination times vary which gives anidea of the SIP performance. Furthermore, the capacity will be the same as inStage 1, since the SIP signaling only occurs at the beginning and at the end of thesimulations and therefore doesn’t interfere with the VoIP traffic throughout thewhole simulation.

5.1.3 Stage 3 -VoIP, SIP & PresenceIn Stage 3 the users also utilize the presence traffic service. The purpose of thisstage is to evaluate the impact of presence traffic on VoIP capacity, dependingon priority and the presence intensity. As in Stage 2, there are two levels ofprioritization: background and conversational. As presence intensity in realitymight vary, two different levels of presence intensity will be evaluated in this stageto see how they will affect VoIP packet delays and losses. The presence intensitiesare varied by changing the client and server publish intervals and the subscriptionlist length (see Tables 6.5 and 6.6).

5.1.4 Stage 4 - VoIP, SIP, Presence & MMTelIn the last stage, the DL payload is increased by adding another traffic flow rep-resenting a file transfer. The purpose of this stage is to evaluate if it is possibleto include a multiplexed MMTel service with sustained VoIP capacity. If this isnot the case, then it will be investigated how much VoIP capacity that have tobe sacrificed in order to achieve decent web traffic quality. The added web trafficmodel is a so called best-effort-service that does not have any specific delay re-quirements. Therefore it is suitable to measure the throughput of this traffic flowto determine what data rates that can be achieved. Also, since MS multislot class31 adds extra DL capabilities, it will be investigated to see if the DL throughputincreases by using this MS multislot class.

Chapter 6

Simulations

This chapter was supposed to present the actual simulation results, but due to bugsand 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 resultsshowed that the VoIP capacity in fact was increased when including presencetraffic. Also, when using mobile stations of MS multislot class 31 the packet lossesskyrocketed to insane levels around 90%. These bugs and issues among other minorerrors in the simulator software made it impossible to finish the simulations withinthe given timeframe. Therefore, the results presented in this chapter are totallyfictional but are nonetheless within reasonable limits of what can be expectedfrom such simulations. Since the purpose of the fictional data presented in thischapter is only to give an image of a possible outcome, the fictional data quantityis limited.

6.1 Stage 1 - Only VoIPThe radio conditions used in the scenarios of this stage are presented in Table6.1 while Section 6.1.1 shows the expected results of this stage. The expectedresults are based on an ongoing study at Ericsson AB [17] where the maximummultiplexing 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 expectationspresented in Section 5.1.1 but since the results of the simulations in [17] also mightbe affected by some bugs and issues in the simulator software, these results cannot yet be fully trusted.

Scenario MCS CIR Priority1.1a 5 22 -1.1b 7 26 -1.1c 8 30 -

Table 6.1. Priorities and radio conditions used in each scenario.

39

40 Simulations

6.1.1 Results - Stage 1It can be seen that Scheduler A proved to be the better choice throughout thesimulations due to it’s ability to favor users having transmission difficulties. IfScheduler B is used the maximum number of simultaneous users decreases, as seenin Figure 6.2, since the packets in the queue easier get out of date when a user ishaving transmission issues. As can be seen in Figure 6.1, at most 16 users can beaccommodated when using Scheduler A if at most 5% of the users are allowed tolose no more than 4% of their speech frames. Scheduler C proved to be able toprovide the same capacity as Scheduler B, but when looking at Figure 6.2 and 6.3it can be seen that Scheduler C has an overall lower satisfied user share.

0 5 10 15 2090

91

92

93

94

95

96

97

98

99

100

Nr of users

Satis

�ed

user

sha

re [%

]

Scheduler A

Scenario 1.1aScenario 1.1bScenario 1.1c

Figure 6.1. The amount of satisfied users when using Scheduler A in Stage 1.

6.1 Stage 1 - Only VoIP 41

0 2 4 6 8 10 12 14 1690

91

92

93

94

95

96

97

98

99

100

Nr of users

Satis

�ed

user

sha

re [%

]

Scheduler B


Figure 6.2. The amount of satisfied users when using Scheduler B in Stage 1.

0 2 4 6 8 10 12 1490

91

92

93

94

95

96

97

98

99

100

Nr of users

Satis

�ed

user

sha

re [%

]

Scheduler C


Figure 6.3. The amount of satisfied users when using Scheduler C in Stage 1.

42 Simulations

6.2 Stage 2 - VoIP & SIPThe radio conditions and priorities used in the scenarios of this stage are presentedin Table 6.2. According to [8] it is not unrealistic to have setup times spanning from5 to 8 s. In this study, an uninterrupted session of the implemented SIP INVITErequest method would at most take about 5 s. Therefore, it is assumed that about3,5 SIP retransmissions will be sent in the worst case, resulting in a setup time of6 to 7 s (given that the retransmissions are not consecutive). Also, some of thepredicted retransmissions might be sent during the BYE session, resulting in lowersetup times but longer termination times. By lowering the SIP prioritization, itis reasonable to believe that the SIP retransmissions would increase while morefavorable radio conditions would decrease the retransmissions. Based on theseassumptions, Table 6.3 shows the mean amount of SIP retransmissions in eachscenario for each scheduler (at high VoIP intensity).

Scenario MCS CIR Priority2.1a 5 22 VoIP = SIP2.1b 5 22 VoIP > SIP2.2a 7 36 VoIP = SIP2.2b 7 26 VoIP = SIP2.3a 8 30 VoIP > SIP2.3b 8 30 VoIP = SIP


6.2.1 Results - Stage 2It is easily concluded that the prioritization of SIP should be done equally as VoIPin order to keep setup and termination times fairly low. It can be seen in Table6.3 that roughly one extra SIP retransmissions is added per session when down-prioritizing SIP compared to VoIP. This might not seem as a big deal, but since aSIP retransmission is made at least 500 ms after sending a request, it shows thatthe delays seem to be quite high. This conclusion is also in line with the findingsin [16] where it was found that VoIP and SIP should be equally prioritized in the3G network.

Scenario Scheduler A Scheduler B Scheduler C2.1a 2,8 3,0 3,72.1b 3,7 4,0 4,12.2a 2,2 2,4 3,22.2b 3,5 3,6 3,62.3a 2,2 2,3 3,22.3b 3,4 3,6 3,6

Table 6.3. The mean number of SIP retransmissions sent per user and session whenreaching maximum capacity.

6.3 Stage 3 - VoIP, SIP & Presence 43

6.3 Stage 3 - VoIP, SIP & PresenceTable 6.5 show the parameter settings used to differentiate the presence intensitieswhile the radio conditions and priorities used in the scenarios of this stage arepresented in Table 6.4. The results in Figures 6.4 to 6.6 represents the satisfied usershare when applying low presence intensity. When introducing presence signalingthat is lower prioritized than VoIP, the total amount of satisfied users are expectedto be lowered by about 1%, but when prioritizing presence equal to VoIP thereduction is believed to be bigger. Also, the relative mean packet loss for highpresence intensities is expected to be much higher than for low intensities, asseen in Table 6.7. Since the packet loss rate at maximum capacity already isclose 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 presentedin Table 6.7 while the UL delay probability functions for the same scheduler ispresented in Figures 6.10 and 6.11. The results in this stage are based on theabove 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 Priority3.1a 5 22 VoIP & SIP > Presence3.1b 5 22 VoIP & SIP = Presence3.2a 7 26 VoIP & SIP > Presence3.2b 7 26 VoIP & SIP = Presence3.3a 8 30 VoIP & SIP > Presence3.3b 8 30 VoIP & SIP = Presence


Parameter High Low Descriptionintensity intensity

Client publish interval 30 min 60 min The time between two con-secutive publish messagessent to the server.

Server publish interval 30 min 60 min The time between two con-secutive publish messagessent by the presentities tothe server.

Subscription list length 15 5 The size of the buddy-list.

Table 6.5. Parameters representing the presence intensities.

44 Simulations

6.3.1 Results - Stage 3When presence signaling is introduced it can be seen that the highest VoIP capacityis achieved by down-prioritizing presence compared to VoIP and SIP. Since the ULis not expected to perform as well as the DL, the UL is the traffic flow directionstudied when looking at the delays and packet losses. Table 6.7 shows the relativemean packet loss (for the UL) using Scheduler A compared to the same schedulerin Stage 1. A low presence intensity shows that the mean packet loss increases byabout 0.2-0.3% when prioritizing presence lower than the other traffic types. If iton the other hand is prioritized equal to VoIP and SIP the mean packet loss isincreased by 0.4-0.7% depending on radio conditions. For high presence intensitiesthe 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), theseemingly low values can still have some impact on the total VoIP capacity, asseen in Figure 6.4. Furthermore, the UL delays are presented in Figures 6.7 and6.8. Figure 6.7 shows that about 98% of all packet delays for all users are lowerthan 300 ms when applying a low presence intensity. If a high presence intensityis applied however, about 97% of all packet delays for all users are lower than 300ms. This means that for high presence intensities, the packet drop rate has risenwith about 1%.

0 5 10 15 2090

91

92

93

94

95

96

97

98

99

100

Nr of users

Satis

�ed

user

sha

re [%

]

Scheduler A

Scenario 3.1aScenario 3.1bScenario 3.2aScenario 3.2bScenario 3.3aScenario 3.3b


6.3 Stage 3 - VoIP, SIP & Presence 45

0 2 4 6 8 10 12 1490

91

92

93

94

95

96

97

98

99

100

Nr of users

Satis

�ed

user

sha

re [%

]

Scheduler B



0 2 4 6 8 10 12 1490

91

92

93

94

95

96

97

98

99

100

Nr of users

Satis

�ed

user

sha

re [%

]

Scheduler C



46 Simulations

Scenario High intensity Low intensity Nr of users1a +1,35 % +0,34 % 81b +1,82 % +0,72 % 82a +1,27 % +0,31 % 162b +1,54 % +0,62 % 163a +1,12 % +0,22 % 163b +1,36 % +0,41 % 16

Table 6.6. Relative mean packet loss in UL for Scheduler A compared to same schedulerin Stage 1.

0.1 0.2 0.3 0.4 0.5 0.60

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Delay [s]

CDF

Uplink - Low presence intensity

Figure 6.7. The delay probability function for Scheduler A in Scenario 3.3a with 16users and low presence intensity.

6.4 Stage 4 - VoIP, SIP, Presence & MMTel 47

0.1 0.2 0.3 0.4 0.5 0.60

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Delay [s]

CD

F

Uplink - High presence intensity

Figure 6.8. The delay probability function for Scheduler A in Scenario 3.3a with 16users and high presence intensity.

6.4 Stage 4 - VoIP, SIP, Presence & MMTelIn this stage, the impact of including the web traffic model is investigated. Theresults 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 whilethe radio conditions and priorities used in the scenarios of this stage are presentedin Table 6.8.

Scenario MCS CIR Priority4.1a 5 22 VoIP & SIP > Presence & MMTel4.1b 5 22 VoIP, SIP & Presence > MMTel4.2a 7 26 VoIP & SIP > Presence & MMTel4.2b 7 26 VoIP, SIP & Presence > MMTel4.3a 8 30 VoIP & SIP > Presence & MMTel4.3b 8 30 VoIP, SIP & Presence > MMTel


6.4.1 Results - Stage 4In this stage it can be seen that when simulating with very high VoIP payloadsthe results were just about the same as in Stage 3. Since the web traffic is down-prioritized compared to VoIP, the VoIP capacity was not affected by this extraDL 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

48 Simulations

be accommodated with Scheduler A under good radio conditions while the webthroughput is fair, as seen in Figures 6.11 to 6.14. The throughput was shown tovary when changing the presence prioritization and switching between the two im-plemented MS multislot classes. When prioritizing presence higher than the webtraffic the amount of measurements showing zero throughput was increased withabout 10% compared to prioritizing presence equal to the web traffic. The differ-ence seen when using MS multislot class 5 and 31 was that when some throughputwas registered, it was slightly higher when using MS multislot class 31. This factshows that the extra DL capability actually makes some difference when enoughresources are available to the down-prioritized service. If the VoIP traffic is toointense though, the extra TSs in the DL won’t matter because of the VoIP payloadand prioritization.

0 2 4 6 8 10 12 14 16 1890

91

92

93

94

95

96

97

98

99

100

Nr of users

Satis

�ed

user

sha

re [%

]

Scheduler A




0 2 4 6 8 10 1290

91

92

93

94

95

96

97

98

99

100

Nr of users

Satis

�ed

user

sha

re [%

]

Scheduler B



0 2 4 6 8 10 1290

91

92

93

94

95

96

97

98

99

100

Nr of users

Satis

�ed

user

sha

re [%

]

Scheduler C



50 Simulations

0 5 10 15 20 25 30 350

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Throughput [kbit/s]

CDF

MS multislot class 5 - Scenario 4.3a

Figure 6.12. Throughput probability function for 12 users using Scheduler A with MSmultislot class 5 in Scenario 4.3a.

0 5 10 15 20 25 30 350

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Throughput [kbit/s]

CDF

MS multislot class 31 - Scenario 4.3a

Figure 6.13. Throughput probability function for 12 users using Scheduler A with MSmultislot class 31 in Scenario 4.3a.


0 5 10 15 20 25 30 350

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Throughput [kbit/s]

CDF

MS multislot class 5 - Scenario 4.3b

Figure 6.14. Throughput probability function for 12 users using Scheduler A with MSmultislot class 5 in Scenario 4.3b.

0 5 10 15 20 25 30 350

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Throughput [kbit/s]

CDF

MS multislot class 31 - Scenario 4.3b

Figure 6.15. Throughput probability function for 12 users using Scheduler A with MSmultislot class 31 in Scenario 4.3b.

Chapter 7

Discussion

This chapter discusses the expectations and predictions on the traffic scenariosthat are not yet simulated. Conclusions and recommendations are also presentedalong with future work proposals.

7.1 Expectations & predictionsIt is expected that using different MCSs will show a significant capacity differ-ence. The scenarios where MCS-5 is used will be the least successful since MCS-5provides lower data rates compared to MCS-7 and MCS-8. Furthermore, the ca-pacity limits are believed to end up at four, eight, twelve or sixteen users. This isreasonable to assume since, for example, if nine users can be accommodated withsatisfactory results, then so could twelve users since all users stay on the same TSsfor the entire simulation. So if there only were nine users, there would be threetimeslot bins left to accommodate one user each, resulting in a total of twelveusers.

Scheduler A is believed to give the best performance among the analyzed sched-ulers which suggests that the dependency of previous penalties in the UL wouldbe significant. The reason for this assumption is that letting the UL schedulingbe dependent on previous penalties means that a recently scheduled user doesn’tnecessarily have to wait for a very long time until being scheduled again. This mayhappen because the other users might have a larger accumulated penalty than thescheduled user. Therefore, users who have trouble getting successful transmissionswill be favored over time, since their penalty accumulates slower than users withno transmission problems. This enables the users to quickly transmit stacked uppackets that are about to get out-of-date. In Scheduler B the penalty in the ULdoes not depend on previous penalties and therefore the UL penalty is only de-pendent on the weight. This means that the user with the longest time since thelast successful transmission will receive the highest priority; in this sense, this ULscheduling could be defined as a ’delay sensitive Round-Robin’. By not havinga memory, users with transmission issues that utilize Scheduler B might get lesssuccessful transmissions over time. Imagine a user with transmission issues that

53

54 Discussion

finally gets a successful transmission, the user will then be treated equally as theother users gaining no favor from his problems. Furthermore, when using a delaysensitive service, such as VoIP, Scheduler C will most certainly prove to give theworst results among the schedulers. This because it does not take packet delaysand queue sizes into consideration which means that too many packets will getout of date when the amount of multiplexed users increases beyond two users foreach timeslot bin.

MS multislot class 31 is not believed to give any significant advantages untilsome kind of heavy DL oriented traffic is added. When the web traffic model isadded, it is believed that the usage of MS multislot class 31 won’t affect the VoIPcapacity but it might improve the throughput of the web traffic. This is not acertain fact though, since the extended DL capacity only offers the possibility ofincreased throughput.

The results of Stage 1 are, as mentioned before, supposed to give a point ofreference to the following stages. Since Scheduler B does not have the ability toschedule evenly over time, it is believed that this scheduler won’t perform as wellas Scheduler A. Furthermore, even though Scheduler B is delay sensitive, it canstill be seen as a Round-Robin variant. Therefore it isn’t impossible that SchedulerB will perform only slightly better than Scheduler C.

In Stage 2 the focus lies on the choice of SIP priority compared to the VoIPtraffic. Giving SIP a lower scheduling priority than VoIP is expected to result inlonger call setup and termination times. This is expected because SIP messageswill then have to wait for a longer time until being transmitted. Furthermore, byletting SIP messages wait for a longer time the SIP protocol is forced to generatemore retransmissions since less responses are registered to these messages. Everydropped (or lost) SIP message could be quite costly in terms of call setup andtermination time since a retransmission is triggered no sooner than after 500 ms.Therefore it is important to reduce retransmissions by prioritizing SIP equally asVoIP, 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 asSIP and VoIP the voice frame delays will be increased due to tougher competitionin the scheduling. Therefore, it is assumed that the mapping of the presenceprioritization should be done onto the background QoS traffic class. Also, sincepresence signaling is simply used to get status updates from users on the buddy-list, it is logical to down-prioritize these messages; it is far more important to leta voice frame reach its destination on time than, for example, finding out thatyour buddy is out for lunch. Also, it should be noted that the SIP message sizesare static in the current implementation in the simulator software which doesn’tcorrespond to real life scenarios where the sizes can vary.

Since the VoIP service will be favored in the scheduler compared to the webtraffic, 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 e-mail transfer. But if the multiplexed service is something thatrequires a limited amount of interactivity, such as web surfing, the problem mightbe more prominent. Therefore, when aiming at getting decent delays for themultiplexed web traffic, the capacity limit of this stage are expected to be lower.

7.2 Conclusions & recommendations 55

7.2 Conclusions & recommendationsWith the above discussions in mind, it is recommended to prioritize SIP signalingequal to VoIP while letting presence signaling have a lower priority in order tomaximize VoIP capacity. It is also concluded that Scheduler A will be the bestscheduling algorithm to use under these circumstances. Furthermore, it should notbe expected that any great performances will be received out of down-prioritizedMMTel services when very high VoIP traffic loads are present. The multiplexedMMTel service performance might however be improved when using MS multislotclasses with greater capabilities when the VoIP payload is not too high.

7.3 Future workWhen using Scheduler A and B in this study, the parameter minAgeThd is set toa static value of 30 ms. Since the use of RTTI reduces the transmission time ofa radio block to 10 ms, setting this parameter to 30 ms makes a scheduled userwait until three other users have been scheduled until being scheduled again. 30ms is therefore optimized for multiplexing four users on the same timeslot binwhich results in a total of sixteen users on eight TSs. In a future study, it wouldbe interesting to let this parameter be set dynamically depending on the level ofmultiplexing. When no multiplexing is present, the value should be set to zeroand then increase by 10 ms for each added level of multiplexing. Obviously, thereis 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 userswhich means that no calls would have been initiated or terminated except at thevery beginning and at the end of the simulations. This is obviously far from reallife behavior and therefore a dynamic flow of user arrivals and departures wouldbe preferred when running simulations of this kind. This would impact the VoIPcapacity even more due to increased SIP signaling payload.

It could also be interesting to investigate how different user types could affectthe system capacity. For example, it would be interesting to know what impactusers only utilizing the presence service would have on the system. Since a sessioninitiation has to be done for each sent presence message (if only utilizing the pres-ence service), the choice of flow release time would probably affect the performancea great deal.

Furthermore, the human hearing sense can compensate for occasional packetlosses, but when several consecutive packets are lost the perceived speech qualityis decreased. Therefore, it might be interesting to evaluate not only the overallpacket loss rates, but also the number of consecutively lost packets.

Bibliography

[1] 3GPP. Ts 23.107 quality of service (qos) concept and architecture v6.3.0.URL: http://www.3gpp.org/ftp/Specs/archive/23_series/23.107/23107-630.zip [2008-10-18], 2005.

[2] 3GPP. Ts 44.065 mobile station (ms) - serving gprs support node(sgsn); subnetwork dependent convergence protocol (sndcp) v8.0.0. URL:http://www.3gpp.org/ftp/Specs/archive/44_series/44.065/44065-800.zip[2009-01-30], 2005.

[3] 3GPP. Ts 45.002 multiplexing and multiple access on the radio path v7.7.0.URL: http://www.3gpp.org/ftp/Specs/archive/45_series/45.002/45002-770.zip [2008-11-02], 2008.

[4] Ericsson AB. Gprs system survey. LZU 108 876 R3A, 2003.

[5] Ericsson AB. Gsm system survey. EN/LZU 108 852 R5A, 2003.

[6] Ericsson AB. The evolution of edge - white paper. URL:http://www.ericsson.com/technology/whitepapers/3107_The_evolution_of_EDGE_A.pdf [2008-10-11], 2007.

[7] Andreas Bergström. Voip over edge evolution - single session performance andservice coverage. Ericsson Confidential Report: EAB-07:067819 Uen, 2007.

[8] Per Synnergren & Jan Christoffersson. Analytical delay calculation of theshort ims session setup proposal using wcdma and edge. Ericsson ConfidentialReport: EAB-05:041425 Uen, 2005.

[9] IETF. Rfc 3261 sip: Session initiation protocol. URL:http://tools.ietf.org/html/rfc3261 [2008-10-16], 2002.

[10] IETF. Rfc 3262 reliability of provisional response sin the session initiationprotocol (sip). URL: http://tools.ietf.org/html/rfc3262 [2008-10-25], 2002.

[11] IETF. Rfc 3263 session initiation protocol (sip): Locating sip servers. URL:http://tools.ietf.org/html/rfc3263 [2008-10-16], 2002.

[12] IETF. Rfc 3265 session initiation protocol (sip)-specific event notification.URL: http://tools.ietf.org/html/rfc3265 [2008-10-16], 2002.

57

58 Bibliography

[13] IETF. Rfc 3903 session initiation protocol (sip) extension for event statepublication. URL: http://tools.ietf.org/html/rfc3903 [2008-10-15], 2002.

[14] IETF. Rfc 3856 a presence event package for the session initiation protocol(sip). URL: http://tools.ietf.org/html/rfc3856 [2008-10-15], 2004.

[15] Jan Christoffersson & Tomas Jönsson. Presence traffic impact on gsm/edgecapacity. Ericsson Limited Internal: EAB -04:013005 Uen, 2005.

[16] Fan Rui & Wang Min. Impact of presence traffic on downlink voip systemperformance. Ericsson Confidential Technical Report: EAB-06:030370 Uen.

[17] Daniel Puaca & Sofia Svedevall. Support for multiple qos conversational usersin gsm mixed traffic. Ericsson Internal Technical Report: EAB/FJG-08:1915Uen (Ongoing study), 2009.

[18] Ubiquity. Understanding sip - white paper. URL:http://www.sipcenter.com/sip.nsf/html/WEBB5YNVK8/$FILE/Ubiquity_SIP_Overview.pdf [2008-10-15], 2003.

[19] Mats Wernersson. Scheduling of multi-media over 3gpp lte. Ericsson InternalReport: EAB-07:011403 Uen, 2007.

[20] Mats Wernersson. Effects of sip setup signaling on voip performance in lte.Ericsson Wide Internal Report: EAB-07:039951 Uen, 2008.

Appendix A

Abbreviations

AMR Adaptive Multi RateBSC Base Station ControllerBSS Base Station SystemBTS Base Transceiver StationCIR Carrier to Interference RatioCS Circuit SwitchedGGSN Gateway GPRS Support NodeGMM/SM GPRS Mobility Management and Session ManagementGPRS General Packet Radio ServiceGSM Global Service for Mobile transmissionIMS IP Multimedia SubsystemIRA Interference Rejection AlgorithmLA Location AreaMCS Modulation and Coding SchemeMMTel MultiMedia TelephonyMS Mobile StationMSC Mobile Services Switching CenterPS Packet SwitchedPSTN Public Switched Telephone NetworkQoS Quality of ServiceSGSN Serving GPRS Support NodeSIP Session Initiation ProtocolSMS Short Message ServiceTDMA Time Division Multiplex AccessTS TimeslotUA SIP User AgentVLR Visitor Location RegisterVoIP Voice over IP

59

UpphovsrättDetta 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äraomstä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 icke-kommersiell forskning och för undervisning. Överföring av upphovsrätten vid ensenare tidpunkt kan inte upphäva detta tillstånd. All annan användning av doku-mentet kräver upphovsmannens medgivande. För att garantera äktheten, säker-heten och tillgängligheten finns det lösningar av teknisk och administrativ art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsmani den omfattning som god sed kräver vid användning av dokumentet på ovan be-skrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan formeller i sådant sammanhang som är kränkande för upphovsmannens litterära ellerkonstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press se för-lagets hemsida http://www.ep.liu.se/

CopyrightThe publishers will keep this document online on the Internet — or its possi-ble replacement — for a period of 25 years from the date of publication barringexceptional circumstances.

The online availability of the document implies a permanent permission foranyone to read, to download, to print out single copies for his/her own use andto use it unchanged for any non-commercial research and educational purpose.Subsequent transfers of copyright cannot revoke this permission. All other uses ofthe document are conditional on the consent of the copyright owner. The publisherhas taken technical and administrative measures to assure authenticity, securityand accessibility.

According to intellectual property law the author has the right to be mentionedwhen his/her work is accessed as described above and to be protected againstinfringement.

For additional information about the Linköping University Electronic Pressand its procedures for publication and for assurance of document integrity, pleaserefer to its www home page: http://www.ep.liu.se/

c© Pasha Ayani & Petter Gustafsson

Documents

Impact and Multiplexing of SIP Signaling in GSMliu.diva-portal.org/smash/get/diva2:634053/FULLTEXT01.pdf · Department of Science and Technology Institutionen för teknik och naturvetenskap