Impact and Multiplexing of SIP Signaling in GSM

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 SIP

Signaling in GSM

Pasha Ayani

Petter Gustafsson

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 2009-02-20

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ö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

http://www.ep.liu.se/

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:

http://www.ep.liu.se/

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 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 delay sensitive scheduling algorithms have been derived and analyzed along with a dy-namic 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 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 GSM system, the presence signaling should be lower prioritized than VoIP and SIP sig-naling. 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 down-prioritized MMTel service should not be expected to be high when the VoIP traffic is intense.

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 VoIP-användare, har nya fördröjningskänsliga algoritmer för schemaläggning och allok-ering tagits fram och utvärderats. En dynamisk allokallok-eringsalgoritm 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.

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.

Contents

1 Introduction 9

1.1 Problem description . . . 9

1.2 Thesis objective & work description . . . 10

1.3 Outline of report . . . 10

2 Background 11 2.1 GSM . . . 11

2.1.1 GSM network architecture . . . 11

2.1.2 Time Division Multiple Access (TDMA) . . . 13

2.1.3 Channels . . . 14

2.1.4 Channel allocation . . . 15

2.2 GPRS . . . 15

2.2.1 GPRS network architecture . . . 15

2.2.2 The GPRS protocol stack . . . 16

2.2.3 Quality of Service (QoS) . . . 17

2.2.4 Scheduling concept . . . 18

2.3 Session Initiation Protocol (SIP) . . . 18

2.3.1 SIP network architecture . . . 19

2.3.2 SIP request methods . . . 19

2.3.3 SIP responses . . . 19

2.3.4 SIP presence signaling . . . 21

3 Multiplexing methods 23 3.1 General . . . 23 3.2 Allocation algorithm . . . 24 3.3 MS multislot classes . . . 24 3.4 Scheduling . . . 26 3.4.1 Scheduling algorithms . . . 26 4 Traffic Models 29 4.1 General . . . 29

4.2 VoIP traffic model . . . 29

4.3 SIP traffic model . . . 30

4.4 Presence traffic model . . . 33

4.5 Web traffic model . . . 34 7

5 Traffic scenarios 35

5.1 Stages . . . 35

5.1.1 Stage 1 - Only VoIP . . . 36

5.1.2 Stage 2 -VoIP & SIP . . . 36

5.1.3 Stage 3 -VoIP, SIP & Presence . . . 37

5.1.4 Stage 4 - VoIP, SIP, Presence & MMTel . . . 37

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

6.1.1 Results - Stage 1 . . . 40

6.2 Stage 2 - VoIP & SIP . . . 42

6.2.1 Results - Stage 2 . . . 42

6.3 Stage 3 - VoIP, SIP & Presence . . . 43

6.3.1 Results - Stage 3 . . . 44

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

6.4.1 Results - Stage 4 . . . 47

7 Discussion 53 7.1 Expectations & predictions . . . 53

7.2 Conclusions & recommendations . . . 55

7.3 Future work . . . 55

Bibliography 57

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

Pro-tocol (SIP) signaling. Therefore it is interesting to investigate how SIP signaling

will affect system capacity and end-user performance. 9

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

mul-tiplexed 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.

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.

2.1.1

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.

BSC VLR MSC 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 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 par-ticular 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

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 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 2

LA 1

VLR MSC

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 in different 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 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

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 begin-ning and end of the burst to indicate the start and stop of the TS. The traibegin-ning sequence 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 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 us-ing 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

7

6

5

4

3

2

1

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

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

1 1

Normal burst

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

2.1.3

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

2.2 GPRS 15

2.1.4

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

2.2.1

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.

BSC GGSN SGSN VLR MSC Air interface PSTN External IP-based networks 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 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/de-multiplexing, 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.

2.2 GPRS 17 BSS MS Application IP SNDCP LLC RLC MAC GSM RF Application Application IP Application IP SNDCP LLC SNDCP IP Application RLC/MAC LLC SNDCP IP Application Relay L1bis GSM RF

MAC Network_Service BSSGP RLC

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 (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, real-time 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 end-user 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 e-mail and file transfer.

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

2.2.4

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 (E-mail, MMS etc.)

The most important traffic type is GPRS signaling called GPRS Mobility

Man-agement and Session ManMan-agement (GMM/SM). Mobility manMan-agement 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. Ses-sion management is used to setup sesSes-sions 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

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

2.3.1

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.

2.3.2

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.

2.3.3

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 pro-vides 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 ac-tions. For example, 180 Ringing indicates that the recipient’s phone is ring-ing.

• 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 180 Ringing 200 OK ACK SESSION BYE INVITE 100 Trying 180 Ringing 200 OK ACK 200 OK BYE 200 OK Call Setup Call Termination

2.3 Session Initiation Protocol (SIP) 21

2.3.4

SIP presence signaling

Presence, 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 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 ex-tension 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 presenti-ties. 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 SUBSCRIBE 200 OK 200 OK NOTIFY 200 OK NOTIFY UA sending an update to the presence server

UA subscribing on some presentity

There are two different methods to send buddy-list updates to a watcher from the server. Either, a based system or a pull-based system is used. In a push-based 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.

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

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 to-gether, 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 con-tinues 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

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.

0

1

2

3

4

5

6

7

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

0

1

2

3

4

5

6

7

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.

3.4.1

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 algo-rithms 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-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.

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 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-of-date information. In this case, it is better to drop these packets and move on to

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 life-time of each user will be equal to the length of the conversation.

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

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 0.015 s The time it takes to encode the voice frames.

Decoding delay 0.015 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

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 Size (byte)

183 SESSION IN PROGRESS 1270 INVITE 1113 PRACK 1014 200 OK 890 180 RINGING 888 BYE 878 ACK 427 PUBLISH 800 NOTIFY 700 SUBSCRIBE 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 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].

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

BYE 200 OK

User A

User B

4.4 Presence traffic model 33

4.4

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 push-based 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 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 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 re-moved from the registered list.

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

200 OK PUBLISH 200 OK SUBSCRIBE 200 OK NOTIFY

User

Server

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.

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

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.

5.1.1

Stage 1 - Only VoIP

The 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 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 16.

5.1.2

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

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.

5.1.3

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

5.1.4

Stage 4 - VoIP, SIP, Presence & MMTel

In 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 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 re-quirements. 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.

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 6.1.1 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 5.1.1 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 5 22

-1.1b 7 26

-1.1c 8 30

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

6.1.1

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.

0 5 10 15 20 90 91 92 93 94 95 96 97 98 99 100 Nr of users Sa

tisfied user shar

e [%]

Scheduler A

Scenario 1.1a Scenario 1.1b Scenario 1.1c

6.1 Stage 1 - Only VoIP 41 0 2 4 6 8 10 12 14 16 90 91 92 93 94 95 96 97 98 99 100 Nr of users Sa

tisfied user shar

e [%]

Scheduler B

Scenario 1.1a Scenario 1.1b Scenario 1.1c

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

0 2 4 6 8 10 12 14 90 91 92 93 94 95 96 97 98 99 100 Nr of users Sa

tisfied user shar

e [%]

Scheduler C

Scenario 1.1a Scenario 1.1b Scenario 1.1c

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.

6.2.1

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 down-prioritizing 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

6.3 Stage 3 - VoIP, SIP & Presence 43

6.3

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 6.11. 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 con-secutive publish messages sent to the server.

Server publish interval 30 min 60 min The time between two con-secutive publish messages sent by the presentities to the server.

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

6.3.1

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 0.2-0.3% 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 0.4-0.7% 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%. 0 5 10 15 20 90 91 92 93 94 95 96 97 98 99 100 Nr of users Sa

tisfied user shar

e [%] Scheduler A Scenario 3.1a Scenario 3.1b Scenario 3.2a Scenario 3.2b Scenario 3.3a Scenario 3.3b

6.3 Stage 3 - VoIP, SIP & Presence 45 0 2 4 6 8 10 12 14 90 91 92 93 94 95 96 97 98 99 100 Nr of users Sa

tisfied user shar

e [%] Scheduler B Scenario 3.1a Scenario 3.1b Scenario 3.2a Scenario 3.2b Scenario 3.3a Scenario 3.3b

Figure 6.5. The amount of satisfied users when using Scheduler B in Stage 3.

0 2 4 6 8 10 12 14 90 91 92 93 94 95 96 97 98 99 100 Nr of users Sa

tisfied user shar

e [%] Scheduler C Scenario 3.1a Scenario 3.1b Scenario 3.2a Scenario 3.2b Scenario 3.3a Scenario 3.3b

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. 0.1 0.2 0.3 0.4 0.5 0.6 0 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 16

6.4 Stage 4 - VoIP, SIP, Presence & MMTel 47 0.1 0.2 0.3 0.4 0.5 0.6 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 Delay [s] C D F

Uplink - High presence intensity

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.

6.4.1

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 down-prioritized 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