How to Enable Better Service Assurance Using the PCRF

K E R S T I N B E N G T S S O N

Master of Science Thesis Stockholm, Sweden 2006

How to Enable Better Service Assurance Using the PCRF

K E R S T I N B E N G T S S O N

Master’s Thesis in Computer Science (20 credits) at the School of Computer Science and Engineering Royal Institute of Technology year 2006 Supervisor at CSC was Henrik Eriksson Examiner was Stefan Arnborg TRITA-CSC-E 2006:154 ISRN-KTH/CSC/E--06/154--SE ISSN-1653-5715 Royal Institute of Technology School of Computer Science and Communication KTH CSC SE-100 44 Stockholm, Sweden URL: www.csc.kth.se

How to Enable Better Service Assurance Using the PCRF

Abstract Service Assurance (SA) is a highly interesting area today due to the large amount of services that are emerging, such as VoIP, streaming and mobile TV. The term SA can be defined as a guarantee that a service should be provided as expected by the end-user. Another reason for the importance is the joining of different kind of networks, e.g. fixed telephony networks and IP networks. These two issues have raised the need of being able to control the quality of services. The latest release of the telecom network, from the organization 3GPP, has provided a new node, the PCRF, which will enable the control of SA. In the master’s project a prototype was implemented in order to investigate how the information that flows through the node could be used in this area. As suspected, a lot of information flows through the new node, which can be used in the work of providing better service assurance to an end user. The PCRF is a good complement to other sources of information, together forming a complex collection of performance measurements. It would be interesting to perform further studies to investigate whether more of the information provided could be used.

Hur PCRF kan användas för att förbättra Service Assurance

Sammanfattning Service Assurance (SA) är ett högintressant område på grund av det stora antal tjänster som lanseras idag, såsom VoIP, streaming och mobil TV. Termen SA kan definieras som en garanti att en tjänst tillhandahålls som förväntat av slutanvändaren. En annan anledning till att SA är viktigt är arbetet med att slå samman olika typer av nätverk, till exempel nätverk för fast telefoni samt IP- nätverk. Dessa två punkter har ökat behovet av att kunna kontrollera tjänstens kvalitet. I den senaste releasen av telekommunikationsnätverk, från organisationen 3GPP, finns en ny nod, PCRF, som kommer att vara till nytta för att kontrollera SA. Under examensarbetet har en prototyp implementerats för att undersöka hur informationen, som flödar genom noden, kan användas inom detta område. Som förmodat flödar mycket information genom den nya noden som kan användas i arbetet att ge en slutanvändare bättre SA. PCRF är ett bra komplement till andra källor med information, och dessa kan tillsammans bilda en komplex samling mätdata. Det vore intressant att göra fler studier för att undersöka om mer av informationen till PCRF kan användas.

Preface This thesis is the result of a master’s project at Nada, Royal Institute of Technology carried out at Ericsson Research. Supervisor at Nada has been Henrik Eriksson. I would like to thank the people of department KI/EAB/TGF/F at Ericsson Research for their support and involvement throughout the project; Niklas Björk, Mona Matti, Tor Kvernvik, Tony Larsson and Mattias Lidström. A special thanks to my supervisor at Ericsson, Mattias Lidström who was always willing to answer my questions. I also want to thank my family and Ken for their support during this period.

Table of Contents

1 INTRODUCTION ................................................................................. 1

1.1 Assignment and objectives ..................................................................................................... 1

2 SERVICE ASSURANCE...................................................................... 2

2.1 Advantages with Implementing Service Assurance................................................................ 2

2.2 Quality of Service ................................................................................................................... 3 2.2.1. Key Performance Indicators........................................................................................... 4 2.2.2 Classes ............................................................................................................................ 5 2.2.3 Service Layer Agreement................................................................................................ 5

3 SERVICE ASSURANCE AT ERICSSON............................................. 6

3.1 End-to-End Service Assurance Architecture .......................................................................... 6

3.2 Measurements of KPIs............................................................................................................ 7 3.2.1 Active measurements ...................................................................................................... 7 3.2.2 Passive measurements..................................................................................................... 7

4 NETWORK .......................................................................................... 8

4.1 The 3GPP................................................................................................................................ 9

4.2 Radio Access Network............................................................................................................ 9

4.3 Core Network........................................................................................................................ 10 4.4 PDP Context..................................................................................................................... 11

4.5 Policy and Charging Control ................................................................................................ 11 4.5.1 Release 6 ....................................................................................................................... 11 4.5.2 Release 7 ....................................................................................................................... 12

4.6 The Diameter Protocol.......................................................................................................... 14 4.6.1 Diameter Header ........................................................................................................... 15 4.6.2 Attribute Value Pairs..................................................................................................... 15

5 PRESTUDY ....................................................................................... 17

5.1 Method.................................................................................................................................. 17

5.2 The Flow of Information through the PCRF......................................................................... 17 5.2.1 Use Case: IMS Voice Telephony.................................................................................. 19

5.2.1.1 Description ............................................................................................................ 19 5.2.1.2 Actors .................................................................................................................... 19 5.2.1.3 Assumptions .......................................................................................................... 19

5.2.1.4 Sequence diagram ................................................................................................. 19 5.2.1.5 KPIs....................................................................................................................... 20 5.2.1.6 Loss of Bearer scenario ......................................................................................... 20

5.2.2 The General IMS Case.................................................................................................. 24 5.2.3 User Location AVP....................................................................................................... 25

6 THE PROTOTYPE............................................................................. 27

6.1 The Traffic generator ............................................................................................................ 27

6.2 The PCRF ............................................................................................................................. 29

6.3 Service Tracing..................................................................................................................... 32 6.3.1 The implementation ...................................................................................................... 32

6.4 Extraction of data to an XML file......................................................................................... 35

7 CONCLUSIONS................................................................................. 36

LITERATURE ....................................................................................... 38

APPENDIX A: MESSAGES OVER RX ................................................. 42

APPENDIX B: MESSAGES OVER GX................................................. 45

APPENDIX C: UML OF SERVICE TRACING....................................... 47

APPENDIX D: ABBREVIATIONS ......................................................... 48

1

1 Introduction Do you get annoyed when you cannot reach your friend on your mobile phone? And what about that time when you sent a message to your colleague that you were running late and it turned out that she never got it? Today your mobile phone can handle more services than just voice telephony. A lot of effort is put into introducing services such as video call, mobile TV, streaming, Push to talk etc. As a user you want to be certain that when you pay for a service it will work properly! No matter whether it is because you want to make sure that you will be able to see that particular episode of your favourite programme or because you want to be certain that you can reach your business partner at any time. As an operator, there are a number of advantages of being able to measure the performance in order to be able to guarantee a certain quality of the services. One of these advantages is the possibility to prioritize traffic flows of customers that generate high revenue streams. More and more people are starting to use IP telephony according to Computer Sweden [45], but at the same time the sound quality is steadily degrading. The number of calls where the quality is unacceptable has increased from 15 to 20 percent during only one year. Still, 20 million people are using the Internet for telephony today. Considering the fast development in this area it is highly likely that the number of users will increase significantly. As I hope you have now realized, service assurance is a highly interesting area and will most likely only become more and more important. Additional benefits will be further discussed in chapter 2.1.

1.1 Assignment and objectives Today, the performance of a service is measured in a number of places in the network and the resulting information is then aggregated in a central system. This makes it a complex, time consuming and expensive task to get an end-to-end view of the service performance. A chance of getting a better end-to-end view was encountered in the new release of the network and the merging of two nodes. The resulting node seems to receive a continuous flow of information about each session. The goal of this master thesis was to examine the possibilities of facilitating service assurance with the help from the new node. Special attention was paid to the prospect of simple service tracing. The work has been carried out at Ericsson Research, Service Layer Technologies in Kista under the supervision of Mattias Lidström.

2

2 Service Assurance One of the main challenges today is the convergence of a large number of networks, mobile as well as fixed, into one single packet based IP network [18] [35]. The network of today is optimized for one service, namely voice telephony and the network is circuit switched. With the new focus on delivering a number of different services to an end-user, the network will become a multiservice packet switched network [40]. Service assurance (SA) will be an important factor, where the term is defined as a guarantee that a specific service will be quantitatively and qualitatively provided as expected by the end user.

2.1 Advantages with Implementing Service Assurance Being able to provide SA has a number of advantages [40] [4]. The service providers will have a chance to increase their revenue by assuring a certain service quality. When price and service features become more and more similar between different service providers a key differentiator for the customer will be quality. It will improve customer loyalty and the end-user will be more eager to use the service. It will also reduce churn and influence the possibilities for additional services in a positive way. By providing an expected quality of the services, the service provider might get the image of a “trusted and respected provider” as Antony Oodan [4] puts it. There will always be a segment of the market that is more interested in high quality and reliability, and is willing to pay more in order to get it. The revenues can also be increased through the possibility to reduce the Time-To-Market of a service. This is realized thanks to quick modelling and monitoring of the service quality. If the network is overloaded it is possible to prioritize the services that generate high revenue streams. The operational expenditure (OPEX) will decrease because of the improved operational processes. Problems can also be solved proactively through early alarms about service performance degradations. This enables the operator to discover problems and resolve them before they get too big. Thus the cost for resolving problems can be reduced. Surveying and maintaining the network will be more effective since personnel at all levels will have the same information about service quality and usage. The operator can also reduce over provisioning of network resources since measurements of the actual service quality can be made.

3

2.2 Quality of Service When talking about service assurance the term Quality of Service (QoS) is a keyword. It is defined by ITU and ETSI as “the collective effect of service performance which determine the degree of satisfaction of a user of the service.” [2]. QoS has a number of features that should be considered [4]. First of all it is important to understand that there are different views on service quality. The end user has an end-to-end view, that is, she measures the quality of the total experience. The network/service provider on the other hand is often interested in the performance of individual network elements. This also illustrates that the same performance parameters cannot be used by providers and by customers. It is important to express the quality in terms meaningful to the customer, instead of the provider’s technical language. As an example the customer might require that at least 99 of 100 calls should work without any problems. The service provider then translates this by applying requirements on the different network components, e.g. minimum response time or delay. The most common failures a traffic stream can experience are [15]:

• Packet loss [%] As the term implies, the percentage of the sent packages that fail to reach their destination. Nowadays, the failure is seldom caused by errors in the network or corrupted frames. The more probable reason is that the network deliberately drops packages in order to avoid congestion [32]. The receiving application then has to ask for a retransmission of the data which might cause critical delays [15]. Packet loss is a severe problem when dealing with real-time traffic such as streaming media and voice. A guideline is given in Cisco’s QoS in IP-Networks [32]; a highly available network should experience less than one percent loss and the packet loss for voice traffic should come close to zero.

• Delay/latency [s] Refers to the time it takes for a package to move from its source to its destination. The reason for delays might be that the package gets held up in long queues or have to take a longer route to avoid congestion. There are also fixed delays e.g. when serializing or encoding/decoding data. Voice is again especially vulnerable. Delays will cause the two parties of the conversation to talk over each other. The guideline here is that the total time for a voice packet to reach the target should be less than 150ms.

4

• Jitter (variations in delay) [s] Jitter refers to the variation in the delay of successive packets. A jitter buffer can be used to smooth the transmission. It can seriously affect streaming audio and video, causing jerky motion or even loss of video. The design rule in Cisco’s QoS in IP-Networks [32], states that the jitter should be no more than 30ms.

In case of congestions it is easy to believe that simply increasing the bandwidth will solve the problem. This is however not the case. The protocols that caused the congestion might merely use up the added bandwidth, causing the same congestion problems as before. It is also impossible to foresee what demands might be set upon bandwidth in the future. The best known IP network today is of course the Internet where traffic is carried with best-effort. This means that there is no guarantee when the network will deliver the packets, nor if they will at all be delivered. Packets can be dropped on the way in case of for example congestion. Different services may require different quality. File Transfer Protocol (FTP) for example, is not that sensitive to network delay or to bandwidth limitations. Of course, the downloading will take longer but the end result will not be affected. This can be compared with services such as Voice and Video which are very sensitive to network delay and to variations in delay. It is almost impossible to keep a normal conversation over the phone if the voice packets are delayed more than 150-200 ms. The dialogue will sound choppy and distorted. In these cases QoS can be used to provide assured services. There is also the case of different users needing different quality. Corporate customers in the banking or publishing industry cannot tolerate outages and failure in transmissions [4]. They are obviously willing to pay more to be ascertained good quality. Other businesses might not be as sensitive and prefer to pay a lower price. These corporate customers should set up an agreement with the service provider, a Service Level Agreement (SLA), defining what quality the customer pays for. This concept is further described in chapter 2.2.3. A private customer on the other hand is often cost conscious and satisfied with somewhat poorer quality.

2.2.1. Key Performance Indicators Key Performance Indicators (KPIs) are parameters that provide measurements of a specific aspect of the performance of a service resource [22]. These parameters can be for example availability of the service, response time, delay and memory utilization.

5

2.2.2 Classes In order to be able to assure a certain quality of service, the traffic of the network can be divided into classes. In the so-called Olympic Service, packets are assigned to three service classes: gold, silver and bronze. In the network the gold class should then experience a lighter load then silver, and silver accordingly a lighter load than bronze. In other words, the packets belonging to the best class have a greater possibility of being delivered on time. [42] [21] [31]. If the link is congested, the packets with gold service will get the largest part of the link. In case there are no gold or silver packets, packets assigned to bronze can use up the whole link. A possible scenario would be an end-user putting voice traffic as a gold service and less critical services e.g. FTP as a bronze service. This also enables the operator to bill the user according to the chosen service class.

2.2.3 Service Layer Agreement Service assurance can be implemented by setting up a Service Level Agreement (SLA). An SLA in this context is a written contract between a service provider and a service recipient that states what performance should be provided for a certain network service [34] [16]. These performance parameters are called Service Level Objectives (SLOs) and indicate that e.g. the response time or availability of the service should be kept at a certain level. The actual value of the parameters is then measured and compared with the value stated in the SLO [40]. The agreement often states penalties that should be paid in case of non-compliance [4].

6

3 Service Assurance at Ericsson Ericsson’s service assurance solution strives to put the operator in control of the quality of each service [40]. Using monitoring systems and processes makes the operator aware of how well the agreed service quality is met. This may constitute a base for possible renegotiations regarding the SLA.

3.1 End-to-End Service Assurance Architecture The architecture is explained in figure 3.1 below.

Data refinement

Access and CoreNetwork Service Network

raw data

aggregatedQoS data

Private BackboneNetwork

KPI reports &QoS alarms

Infrastructure QoS Traffic Stream QoS End User Experience QoS

PI's PI's

xDRbuilder

ServiceLevel Manager

SLOReporter

SLO reporting

KPI/KQI thresholds

aggreg.tool

Cross Industry Business Support Solution

Revenue M

anagement

Trou

ble

Man

ager

Real time SLO monitoringService & SLA definition

KPI summaryreports QoS

alarms

aggreg.tool

reporttool

KPI reports &QoS data

QoSalarms

KPI's

PI's

aggreg.tool

reporttool

alarmtool

reporttool

reporttool

Service alarmlogging

alarmtool

Service levelinformationSe

rvic

e To

polo

gy Fulfillment

Fig. 3.1: Data about the performance is collected from the network. This information is then aggregated into KPIs and monitored in the Service Level Manager. Source: Service Assurance for Communication Networks: Solution Description [40]. Quality of Service data is gathered from the access, core and service network through performance monitoring processes [40]. The data can be classified as belonging to either infrastructure QoS, traffic streams QoS or end user QoS. It is

7

then aggregated in the Data Refinement layer and KPIs are defined. Thresholds are set up in order to be able to issue service alarms and reports. The status of the service components is presented to the Service Level Manager in the form of events and statistical reports. The Service Level Manager in turn, gathers the information and correlates it if necessary in order to create an either general or individual performance view. The KPIs are then compared with the pre-defined Service Level Objectives (SLOs) agreed upon in the SLA. While the Service Level Manager provides a real-time view, the SLO reporting function provides a historical view. It is used for follow-up and final analysis of the service performance and SLA agreements.

3.2 Measurements of KPIs In order to obtain the KPIs, either passive or active measurements can be made.

3.2.1 Active measurements Synthetic traffic is created to measure the behaviour of the network. Monitor Master is such software that simulates the use of a service. This is an easy and cheap alternative. It is however just a spot test of the network. It also generates further traffic load on the network [7].

3.2.2 Passive measurements Passive measurements involve placing probes and agents in the network. This often requires the operator to invest in additional hardware or software [43]. Also, the solution from Ericsson does not give an end-to-end view of the service performance.

8

4 Network The challenge today is the connection of all different networks; Internet, networks for mobiles phones as well as for fixed telephones etc [5]. The complexity is best expressed by figure 4.1. I will only explain the most important elements present in this picture. The intention of the picture is to get an insight into the many nodes, and versions of network standards that has to be considered when connecting the many networks. A more detailed description of the interesting parts of the networks will follow in later chapters.

Fig. 4.1: The figure shows the packet switched and circuit switched networks as well as the IP Multimedia Subsystem (IMS). Source: UMTS Networks and Internet Telephony [14]. GSM Radio, GERAN and UTRAN are access networks where the user connects to the network. Depending on if they are using GSM, GPRS or 3G they are then redirected through the network. The IP Multimedia Subsystem (IMS) is a standardised architecture for providing multimedia services via mobile and fixed telephone networks. Poikselkä et al. [5] propose the following definition of the IMS. IMS is a global, access-independent and standard-based IP connectivity and service control architecture that enables various types of multimedia services to end-users using common Internet-based protocols.

9

The relevant parts of the network can be divided into Radio Access Network (RAN) and Core Network (CN) which will be further described in chapter 4.2 and 4.3.

4.1 The 3GPP The third Generation Partnership Project (3GPP) is a collaboration agreement in order to make a global applicable third generation mobile phone system [6]. It was established in 1998 and consists of standardization organizations from Europe, Japan, China, North America and South Korea. 3GPP standards are defined as releases. Presently, work is being put into release 7. Hundreds of documents are produced and available on their web site: www.3gpp.org.

4.2 Radio Access Network The radio access network consists of [20]:

• Radio Base Station (RBS), also called Node B • Radio Network Controller (RNC)

Figure 4.2 shows the radio access network with its elements.

Fig. 4.2: The access network consisting of the radio network controller and the radio base stations.

Core Network

RNC

RBS RBS RBS RBS

Access Network

UE UE UE UE UE UE

RNC

10

The RBS receives signals from the User Equipment (UE), converts it and forwards it to the RNC [3]. It provides the physical radio link to the network [12]. The RNC in turn, is responsible for the control of the radio resources. An RBS is connected to one RNC.

4.3 Core Network The main elements of the core network are [1] [3] [19]:

• Serving GPRS Support Node (SGSN) • Gateway GPRS Support Node (GGSN) • Home Location Register (HLR)

Figure 4.3 provides an overview of the components in the core network.

Fig. 4.3: The SGSN, the GGSN and the HLR are the main components of the core network. The task of the SGSN is to keep track of the location of the UE. It also carries out security functions and access control [17]. Two types of subscriber data are stored in the location register function of the SGSN [1]:

Core Network

11

• Subscription information: o IMSI o One or more temporary identities o Zero or more PDP addresses

• Location information:

o Cell/routing area of the UE o The GGSN address of each GGSN for which an active PDP

context exists The SGSN receives information from the HLR about each subscriber who is allowed to use the network. The HLR is a central database that keeps details of every SIM card, such as IMSI (International Mobile Subscriber Identity), the telephone number (known as MSISDN), information on allowed services, forbidden roaming areas, current location of the subscriber etc [3] [11]. GGSN is connected to SGSN and detunnels user data from the GPRS Tunnelling Protocol (GTP). The information is then sent out as normal user data IP packets. To external packet networks such as e.g. the internet, the GGSN works as an IP router. In order to protect the integrity of the core network it also performs firewall and filtering functionality [9].

4.4 PDP Context The PDP context is a data structure which is contained in both the SGSN and the GGSN [10]. The context holds information about routing, QoS, billing etc [13]. When a user wants to use GPRS she has to activate a PDP context and deactivate it when ending the service.

4.5 Policy and Charging Control

4.5.1 Release 6 In release 6, R6, of 3GPP’s specification of the network there are two nodes handling policies and charging respectively. These are the Policy Decision Function, PDF, and the Charging Rule Function, CRF. The PDF communicates with GGSN via the Go interface and with the Application Function, AF via the Gq interface. The CRF in turn, communicates through the Gx interface when contacting the GGSN and through the Rx interface when contacting the AF. Figure 4.4 describes this relationship.

12

Fig. 4.4: The Policy Decision Function (PDF) and Charging Rules Function (CRF) communicate with the Application Function (AF) and the GGSN via the interfaces Gq, Go, Rx and Gx. The PDF provides Service-Based Local Policy (SBLP) control [37]. This is done by authorizing required QoS resources and storing the SBLP for the session. The decisions are based on session and media related information obtained from the AF via the Gq interface. When a bearer authorization request is sent from the GGSN to the PDF, the PDF authorizes the request based on the stored service based local policy information for this particular session. The GGSN is then informed to open the gate if the session was authorized. The CRF provides Charging Rules and informs the AF about bearer session events. Charging rule decisions are based on session and media related information obtained from the AF, the bearer and subscriber related information obtained via the Gx interface as well as any other subscriber and service related data the CRF is aware of. The AF hereby indicates to the CRF whether the IP flows should be enabled or disabled at the bearer level. The CRF also informs the AF via Rx regarding bearer events such as bearer release and bearer establishment. How these nodes interact with the user equipment will be further described in the next chapter.

4.5.2 Release 7 In 3GPP R7 the two nodes PDF and CRF are merged into one single node, the Policy and Charging Rules Function, PCRF [36]. The intention is to simplify the architecture. This will decrease the required signalling and enable a unified filter handling. The resulting network can be viewed in figure 4.5 below.

AF

PDF CRF

GGSN

Gq Rx

Gx Go

13

Subscription Profile Repository (SPR) is a database for storing information about the user’s policies. The user might for example be a gold subscriber and thus entitled to more bandwidth than the average.

Fig. 4.5: The Policy and Charging Rules Function (PCRF) is connected to the Application Function (AF) and the Gateway GPRS Support Node (GGSN) via the interfaces Rx+ and Gx+. The Subscription Profile Repository (SPR) contains information about the subscriber and its policies. The network has a layered architecture which aims to separate the media and control signalling [28] [3] [23]. All entities in the control plane control media streams and signalling links between other entities. Some examples of tasks are routing call signalling and telling the media plane what traffic to allow. The media plane on the other hand, handles all actual information sent and received by the user. This can be for example coded voice from a voice call or packets sent in an Internet connection. In figure 4.6 the two layers are marked as the control plane and the media plane (also called traffic plane, user plane, data plane, bearer plane).

AF

Rx+

Gx+

GGSN

PCRF

SPR

Session data

14

Fig. 4.6: All control signalling between the user equipment and the PCRF is sent on the control plane. The media plane in turn handles the transfer of media information. Similar to R6 and the tasks of the PDF and the CRF, the PCRF provides the GGSN with network control regarding service data flow detection, gating, QoS and flow based charging [36]. The AF provides the PCRF with session and media related information and in turn receives information about traffic plane events. The reference points Gx+ and Rx+ are based on the Diameter protocol [27] [24] which is further described in the next chapter.

4.6 The Diameter Protocol The Diameter protocol is an AAA protocol where AAA stands for Authentication, Authorization and Accounting [24] [8]. The purpose of the protocol is to:

• provide transport of user authentication information and thereby enabling the authentication of the user.

• transport service specific authorization information between client and server. This allows the peers to decide weather to grant the user’s access request or not.

• exchange information about resource usage. • relay, proxy and redirect Diameter messages.

GGSN

PCRF

Control Plane

Media Plane

AF

15

A Diameter message consists of a Diameter Header followed by Attribute Value Pairs (AVPs) [5].

4.6.1 Diameter Header The Diameter header consists, among other things, of a Command Code. This code is a number defining the type of message. There are many kinds but the ones relevant in this report are presented in table 4.1 [24] [25] [26]. One of the command flags specifies whether the message is a request or an answer. Table 4.1: The table shows some Command Codes that define the type of message sent. Command Name Abbreviation Command Code Abort-Session-Request ASR 274 Abort-Session-Answer ASA 274 Authorization-Application-Request AAR 265 Authorization-Application-Answer AAA 265 Credit-Control-Request CCR 272 Credit-Control-Answer CCA 272 Re-Auth-Request RAR 258 Re-Auth-Answer RAA 258 Session-Termination-Request STR 275 Session-Termination-Answer STA 275 Some AVPs are associated with a specific Command Code and can be mandatory or optional.

4.6.2 Attribute Value Pairs All data delivered by the protocol is in the form of AVPs [24] which are identified by unique numbers (codes). They contain information elements for authorization, authentication and accounting, but also information about routing, security and configuration [24] [5]. An AVP is a collection of tuples where an information element is stored together with its code. Some examples of AVPs can be found below in table 4.2. Table 4.2: Some AVPs with name, code and data type. Attribute Name Code Data Type Session-Id 263 UTF8String Termination-Cause 295 Enumerated Origin-Host 264 DiamIdent Origin-Realm 296 DiamIdent AF-Application-Identifier 504 OctetString

16

As mentioned in previous chapter, some AVPs are connected to a certain message. Session-Id is for example always present in all messages and each session has two unique identifiers, one for the Rx+ interface and one for the Gx+ interface. The attribute AF-Application-Identifier contains information in order to identify which service the session belongs to [38].

17

5 Prestudy

5.1 Method The approach to solve the task is here briefly described:

1. Discussions were held with, among others, Dick Bergström, Strategic Solution Architect for SA at Ericsson, and Per Sundin, Operational Product Manager of NTM (see chapter 6.4) who are working in the area of Service Assurance. The intention was to understand what kind of information that could be interesting to derive from the network in order to enable Service Assurance.

2. We examined the flow through the PCRF by analysing papers from 3GPP, use cases as well as discussing with people familiar with the area. We were especially interested in what information was transported to the PCRF. Use cases were made regarding the services voice telephony (at Ericsson MMTel), WeShare and MMS.

3. The next step was to compose relevant KPIs. 4. Studies were performed on the existing prototype, consisting of a traffic

generator and the PCRF node. 5. We implemented an improved version of the traffic generator. 6. An examination took place regarding what further information was

necessary to store in the database of the PCRF, in order to derive the requested KPIs.

7. The design of the Service Tracing program was presented to relevant persons for approval. The GUI was further discussed with a specialist on interaction design, Didier Chincholle, senior specialist in interaction design for mobile services at Ericsson.

8. I implemented the service tracing program. 9. Extraction of KPIs to an XML file.

5.2 The Flow of Information through the PCRF In order for the traffic to be transported from the source to the destination, an IP-CAN bearer has to be established. The bearer is set up as soon as the user turns on his or her mobile phone. The flow is shown in figure 5.1 [39].

18

Fig. 5.1: The flow at IP-CAN session setup and disconnect. When the user has established an IP-CAN session, it is possible to start a session, such as voice telephony or streaming. We made a use case covering the flow during voice telephony which can be reviewed in more detail in chapter 5.2.1. The idea was to find how to calculate KPIs as well as to look at how loss of bearer could be handled by the network.

UE GGSN PCRF

1. Initiate Primary PDP

4. CCA

6. Accept Primary PDP

SGSN

2. Activate PDP Context

5. Activate PDP Context

3. CCA

7. .Initiate Primary PDP

10. CCA

12. Accept PrimaryPDP

8. Delete PDP Context Request

11. Delete PDP Context

9. CCA

ONLINE

19

5.2.1 Use Case: IMS Voice Telephony The Jacobson model of the use case can be found below in figure 5.2.

Fig. 5.2: Use case diagram showing the IMS Voice Telephony service.

5.2.1.1 Description An end-user calls another person and expects the recipient to be notified about the connection attempt. If the recipient accepts the call, the two parties expect to be able to talk to each other without distortion.

5.2.1.2 Actors Sender: The actor that initiates the phone call (Mobile Originator). Recipient: Person who receives the phone call (Mobile Terminator).

5.2.1.3 Assumptions For MMTel session setup a large number of different session alternatives exist. This use case covers only the general approach including two users which both are IP-CAN connected.

5.2.1.4 Sequence diagram

When making a phone call through IMS, the flows of messages are as described below in figure 5.3. The diagram is derived from the 3GPP specifications [27] [35] [36] [37] [38] and to some extent from Service Delivery Control (SDC) Use Cases [41].

Perform voice conversation

Sender (MO) Recipient (MT)

20

Fig. 5.3: Sequence diagram of IMS Multi Media Telephony with simplified SIP signalling.

5.2.1.5 KPIs [The text under this heading has been removed for confidentiality reasons.]

5.2.1.6 Loss of Bearer scenario The loss of bearer scenario can be divided into two sub scenarios. The first one leads to termination of the session. In the second scenario the bearer is recovered before any Charging Rule (CR) loss-of-bearer timer expires in the PCRF.

MO GGSN PCRF P-CSCF MT

1. SIP2. AAR3. AAA

4. SIP5. Initiate 2ry PDP Context

7. CCR8. CCA

10. Accept 2ry PDP Context

12. Media

13. SIP14. STR

17. STA

15. RAR16. RAA

SGSN

6. Activate PDP Context

9. Activate PDP Context

11. SIP

21

5.2.1.6.1 Loss of bearer leads to session termination This scenario is mapped from Enhanced Policy Decision Function and Gx+ [38] to match this MMTel use case. The network recognizes a change in bit rate to 0 Kbit/s [39] and a timer starts in the PCRF. If the timer expires before the bearer has been recovered, the session is ended. Preconditions The preconditions are that the all signalling before step 10 in figure 5.4 were performed without failure and that two notifications to enable both loss-of-bearer and recovery-of-bearer were included in the AAR message sent from AF to PCRF. These notifications are defined in TS 29.209 [38] and are included in the Specific-Action-AVP. It should be transmitted in step 2 to make the PCRF apply these features. The SIP BYE signalling can be initiated from the network. This is made in step 17 and 18, figure 5.4, which violates a basic idea of SIP signalling, where messages are only initiated by the end-points, in this case represented by MO and MT.

22

Sequence Diagram The sequence diagram for the loss of bearer in a dedicated MMTel session is shown in figure 5.4.

Fig.5.4. Loss of bearer leads to session termination when timer expires. 5.2.1.6.2 Loss of bearer followed by bearer recovery This scenario is mapped from [29] to match this MMTel use case. Here the network recognizes a change in bit rate to 0 Kbit/s [38] and the timer starts in the PCRF. But before the timer expires, the network acknowledges a change in bit rate from 0 Kbit/s and the session continues. Preconditions Preconditions are that all signalling before step 10 in figure 5.4 was performed correctly and a notification to enable this information was included in the AAR message sent from AF to PCRF. The notification is defined in TS 29.209 [38] and is included in the Specific-Action-AVP. It should be sent in step 2 to make the PCRF apply the loss-of-bearer and recovery-of-bearer features.

MO MT

UE GGSN PCRF IMS IMS PRCF GGSN UE 1

234

56 7

8

9

17.SIP BYE

Timer expires. SA registration!

18. SIP BYE

11. Update PDP

14. Update PDP

Timer starts13. CCA 12. CCR

15. RAR

10. Media

16. RAA

19.RAR 20.RAA

21.STR22.STA

23.RAR

23

Sequence Diagram The sequence diagram for the loss-of-bearer and recovery-of-bearer in a dedicated MMTel session is shown in figure 5.5.

Fig. 5.5 Loss of bearer followed by recovery of bearer. 5.2.1.6.3 Conclusions/Comments There are both advantages and disadvantages with this feature. The two main advantages are:

It enables the operator to register what cells are near, or include, bad radio access areas. Creating an indicator of this kind, will give the possibility to dynamically offer the operator recommendations on what cells should be upgraded or where handovers between cells regularly fails. By enabling this feature, the KPIs cut-off call ratio and call completion ratio will increase in accuracy.

The feature enables the operator to acknowledge a subscriber during loss

of bearer. This helps the operator to increase its service assurance. Churn can be reduced since the subscriber can get an operator notification that his/her session failure has been registered, and the trust in the operator can thereby remain. An operator also has the ability to compensate the affected subscriber.

UE GGSN PCRF IMS IMS PRCF GGS UE1234

567 8

9

MO MT

11. Update PDP

14. Update PDP

Timer starts 13. CCA

15. Update PDP

18. Update PDP 17. CCA

Timer stops

No bearer

Bearer

10. Media

12. CCR

16.CCR

24

There are also some disadvantages connected to these scenarios.

The introduction of timers in the PCRF is both time and resource consuming.

There is no standardized way how to trigger the loss of bearer in any of the nodes listed in the scenarios. None of the UE, SGSN or GGSN has today any ability to trigger this event. There is according to Kvernvik [44] a possibility that the RNC node will record the bit rate in the dedicated bearers in a near future, but no decisions has been made in this area.

There will be an increased signalling on the Rx+ and Gx+ interfaces.

5.2.2 The General IMS Case We also studied two different general flows used to set up a session based on the information provided by 3GPP [39]. The two flows are shown in figure 5.6 and 5.7.The arrows marked with SIP indicates that control signalling is performed between the two parties. For convenience, the flows will be denoted “flow 1” respectively “flow 2”. In flow 1, the session establishment and termination is initiated by the user. This is, in flow 2, instead initiated by the PCRF.

Fig. 5.6: Flow 1, the flow when session establishment and termination is initiated by the UE.

15. SIP

MO GGSN PCRF P-CSCF MT

7. Media

1. SIP

2. AAR

4. CCR 5. CCA

3. AAA

8. SIP

13. STR 14. STA

6. SIP

9. CCR 10. CCA

12 ASA11. ASR

25

Fig. 5.7: Flow 2, the flow when session establishment and termination is initiated by the PCRF. The KPIs were then taken from the IMS Voice Telephony use case and slightly adjusted to fit the general flows. We also added three new KPIs. The calculations of the first four KPIs were made in the same manner as when calculating the IMS Voice Telephony KPIs but with the triggers at different messages. [The text has been removed for confidentiality reasons.]

5.2.3 User Location AVP GGSN has information about the location of the UE. This is transferred in the information element User Location Information via the GTP protocol [30] at create PDP context and update PDP context. The information is in the form of Local Area Code and Cell Identity and uniquely defines the cell the user is in. Our proposal is to send this information in a User Location AVP. The User-Location AVP (AVP code 1100) is of the type Grouped and it defines the

MO GGSN PCRF P-CSCF MT

7. Media

1. SIP

2. AAR

3. RAR

4. RAA 5. AAA

8. SIP

10. RAR

11. RAA

9. STR

12. STA 13. SIP

6. SIP

26

location of the UE. Below is the new AVP presented in the form of an ABNF Grammar according to the specifications in RFC 3588 [24]. User-Location ::= < AVP Header: 1100 > { Local-Area-Code } { Cell-Identity } Both the Local-Area-Code AVP (AVP code 1101) and the Cell-Identity AVP (AVP code 1102) are of type Integer32. The idea is to send this AVP in CCR and RAA to the PCRF. Our first thought was to store the last and the second last visited cell in the PCRF. This might help in finding weak spots when handover fails between two cells. However, this turned out to be a bit troublesome since the user location information is not updated as frequently as would be necessary. During a session a modify message might be sent which contains the user location information [30], but this does not happen often enough to be considered reliable. The result would be that what is marked as the second last cell can in fact be a much older cell. We finally decided to only store the last position of the UE. This eliminates the confusion which the above described problem might raise. But it still gives a good indication on where the problem occurred.

27

6 The prototype A prototype existed, consisting of the PCRF node and a traffic generator. There was however a need to improve it. The structure of the traffic generator had to be updated in order to support new flows as well as different flows depending on the type of service. Changes also had to be made to the PCRF part. The traffic generator simulates the traffic from a UE and implements both the Rx+ and the Gx+ interfaces. A descriptive figure can be found below where blue marks the PCRF part and green the parts of the traffic generator.

Fig. 6.1: The prototype consists of two parts; the PCRF including the databases (blue) and the traffic generator (green). A number of assumptions have been made for the implementation of the prototype:

• Only one session per user is active at the same time. • The users involved in the communication have the same service

provider. • There exists only one PCRF. • Two users are involved in a session.

6.1 The Traffic generator We had to implement a new traffic generator to simulate the new flows. This was realized by keeping track of all sessions in a database. In the graphical interface the user can state the number of local areas (LAs) and the number of sessions in each LA. Each LA in turn, has a fixed number of 12 cells associated with it. Five services can be started and their distribution can be

28

stated as the percentage of the active sessions in that LA. The time of a certain session can also be changed. The graphical interface can be found in figure 6.2 and 6.3.

Fig. 6.2: The graphical interface of the traffic generator. The user chooses to start a new simulation and gets default values of the number of sessions and local areas. These figures can be edited as well as the distribution of services and their uptime.

29

Fig. 6.3: The default values can be changed for each local area. When the user pushes the button “Generate Traffic”, an IP-CAN is set up per user, simulating that the user turns on her mobile phone. One service is thereafter started per user, i.e. only one session at a time per user is active. Half of the sessions represent the MOs who make a connection to the MTs. Depending on the value of the Radio Access Technology (RAT) Type, one of the two flows is selected. Some access technologies support the network initiated flow, i.e. flow 2. The RAT Type is an AVP using integer as data type. We have chosen to state that all sessions with a RAT Type equal to or smaller than 3, are to use flow 2. We also assume that RAT Types smaller than 3 are R7+ compliant.

6.2 The PCRF It was also necessary to make some small changes in the PCRF in order to receive the new information and store it together with timestamps. Most of this work was however made by Mattias Lidström. The database of the PCRF consists of the tables that can be seen in figure 6.4. It also has two more tables, ipcanlogg and sessiondatalogg, that are exact copies of ipcan respectively sessiondata for longer storage of information.

30

The table policy contains information about what performance a customer should have when using a certain service, depending on what service class the customer is associated with. Table spr holds records about the subscriber, such as service class and what services that are enabled for that particular user (stored under the attribute services). The table ipcan stores all information that can be obtained when the IP-CAN is established. As the name implies, sessiondata consists of all data gathered during a session. Timestamps are set, making it possible to calculate the KPIs discussed in chapter 5.2.2. For flow 1, the timestamps were placed at step 1, 4, 6 respectively 11 in figure 5.6. For flow 2 they were placed at step 1, 4, 6 respectively 9 in figure 5.7. The attribute errormessage is OK by default, but if the network is out of resources or the bearer is lost, this is indicated by this attribute.

policy serviceclassservice maxdl maxul qci

spr number imsi serviceclassusername services

Fig. 6.4: Some of the tables in the database of the PCRF. In order to calculate the KPIs timestamps were set in the database of PCRF at the positions pointed out in chapter 5.2.2. A better overview of the timestamps can be found in figure 6.5 and figure 6.6.

ipcan sessionid subscriptionidtype subscriptioniddata ipv4address ipv6address sessionstart sessionend ipcanstatus ccrequestnumber rattype lac cellid

sessiondata source sourceport destination destinationport maxul maxdl serviceclass serviceid state rxsessionid gxsessionid qci timestamp1 timestamp2 timestamp3 timestamp4 lac cellid errormessage sgsn ggsn

31

Fig. 6.5: The “T” marks where timestamps in flow 1 are taken to be stored in the database of the PCRF.

Fig. 6.6: The “T” marks where timestamps in flow 2 are taken to be stored in the database of the PCRF.

MO GGSN PCRF P-CSCF MT

7. Media

1. SIP

2. AAR

3. RAR

4. RAA 5. AAA

8. SIP

10. RAR

11. RAA

9. STR

12. STA 13. SIP

6. SIP

15. SIP

MO GGSN PCRF P-CSCF MT

7. Media

1. SIP

2. AAR

4. CCR 5. CCA

3. AAA

8. SIP

13. STR 14. STA

6. SIP

9. CCR 10. CCA

12. ASA 11. ASR

32

6.3 Service Tracing The aim of service tracing is to be able to locate a particular session. A specific goal of this master’s project was to take advantage of the PCRF node. It was therefore a wish that only information, which could be extracted from the node itself, should be presented in the service tracing programme. It is however of course possible to combine this data with information from e.g. a customer database. Data about each session is taken from the table sessiondatalogg which at the moment stores information about all sessions. This is however in reality not a likely scenario since it would mean too much information to store. There are then four different alternatives how this could be handled:

• All information is stored during a certain period of time, e.g. for a week. • Only information about the sessions that went wrong is stored. • Only aggregated information, such as KPIs, is stored for each user and

service. • There is a possibility to activate troubleshooting and then store all

information about the chosen user. Storing information for a week, like in the first alternative, might still result in too much information. But it is likely that gathering data during an even smaller time span will not give enough facts in order to analyse the problem accurately. The second alternative will significantly reduce the number of sessions stored. On the other hand, the sessions that worked without problems might be a good source of information when analysing why only certain sessions failed. In the third alternative the figures are updated with every new session, but it is a constant number of data stored. E.g. the number of failed sessions is stored for user A and the service MMS. The obvious downside with this solution is that it is not possible track the session that failed to see what caused the failure.

6.3.1 The implementation How much information that should be stored is a decision that has to be made by an operator. I have in my master’s project chosen to show what information could be retrieved from the PCRF in a troubleshooting scenario. KPIs are also calculated. The preconditions are that a user has contacted the operator due to repeated failures when using the mobile phone. The search is then made by entering the IMSI number since this is the only way to identify a user in the PCRF (see figure 6.7).

33

Fig. 6.7: The search is made by entering the IMSI of the user. A window with two tabs is then opened (see figure 6.8). Personal details about the user are presented, taken from the table spr. Below this area, key performance indicators are shown for the different services. In the figure 6.8 the KPIs are greyed out due to confidentiality reasons.

Fig. 6.8: Personal information as well as key performance indicators are presented under the tab GENERAL INFO.

34

Under the next tab, all sessions can be found since the troubleshooting started (see figure 6.9). A list of the sessions together with date, time and the kind of service is found to the left. When a session is marked, all information about that particular session is presented. If there was a problem, the type of problem is shown like in figure 6.10. It is possible to see the other IMSI that was involved in the communication and who initiated it. Since the quality of the session might depend on what quality the other user is entitled to, that type of information is also presented. Additionally, the last route the communication took can be followed from one end point to another.

Fig. 6.9: Information about each session can be found under the tab SESSION INFO.

35

Fig. 6.10: If an error occurred, the type is presented. It is also possible to see if the failure happened in the present user’s part of the network or in the partner’s. The most likely scenario is that these features are only offered to corporate customers since these are the customers who have an SLA.

6.4 Extraction of data to an XML file As explained earlier in the text, this master’s project was about showing what kind of information that could be retrieved from the PCRF. Ericsson has a programme called NTM (Network Traffic Management) which is used to present this kind of information and the idea was to export information in the form of KPIs to NTM. This was made possible by including the information in XML files. This feature was implemented together with Fredrik Linderbäck but since the programming of the XML transformation was mostly made by Fredrik, I refer to his master’s thesis for further information [33].

36

7 Conclusions The PCRF clearly receives a lot of information about the sessions that are active. There is however still much work going on which might open up even more possibilities. The PCRF can be a good complement to other sources of information, together forming a complex collection of performance measurements. It will still require the creation of synthetic traffic to get an end-to-end view of the service quality. Service assurance is however clearly a highly important area in which more studies have to be made. Sending location information about the UE to the PCRF is an interesting possibility that could be worth looking into more. But then further investigations have to be made regarding how often the location can be updated. As of today, the location is not send at delete PDP context, and modify PDP context is not sent often enough to present any reliable information in the PCRF. I think that the most important issue to investigate is the possibility of getting information about the location also at delete PDP context. This would enable us to locate where the failure occurred which I consider to be the number one reason why you want to get location information. It could also be interesting to examine whether there are more interesting AVPs sent to the PCRF. The new node also opens up for other opportunities, e.g. statistics on how the different services are used. Together with a customer database, it would be possible to tell what services that are preferred by certain age groups, what services that are most often used together with others etc. As pointed out in chapter 5.2.2, the KPIs calculated from the data in the PCRF do not perfectly correspond to the definitions. Most of these are however impossible to calculate without simulating a session, e.g. a telephone call. The time when the end user pushes the button “Send” can quite clearly not be observed at any point in the core network. On the other hand, some of the KPIs are actually more accurately calculated from the PCRF. We have used the proposed KPIs as general performance parameters since we have assumed that the flow is the same for all these services and thus are the same KPIs interesting. It is nevertheless important to remember that different services require different measurements to be made. Some parameters can be service specific. More effort has to be put into finding appropriate KPIs the services. For this task I would recommend Telecommunications: Quality of Service Management: from legacy to emerging services [4]. It would also be interesting to analyse how much memory that would be required in order to store all information about the sessions. Is it at all possible? Should the stored information be exclusively for corporate customers? Another thing worth mentioning is that not all services will have a flow of information through the PCRF. Best effort services like e.g. SMS might pass

37

through the network without going through the new node. On the other hand, the quality of most of these services are not subjects to any SLA. Discussions have also been made regarding the possibility to use deep packet inspection in the cases where it could be interesting to measure the quality.

38

Literature BOOKS [1] CASTRO, J., All IP in 3G CDMA Network : the UMTS Infrastructure and

Service Platforms for Future Mobile Systems. Chichester, John Wiley & Sons Ltd 2004. ISBN: 0470853220.

[2] GOZDECKI, J., JAJSZCZYK, A., STANKIEWICZ, R., Quality of Service Terminology in IP Networks. IEEE Communications Magazine, March 2003. ISBN: 0470019069. [3] HOLMA, H., TOSKALA, A., 2004. WCMDA for UMTS: RadioAccess For Third Generation Mobile Communications. John Wiley & Sons Ltd, Chichester. ISBN: 0-470-87096-6 [4] OODAN, A., WARD, K., SAVOLAINE, C., DANESHMAND, M., HOATH, P.,

Telecommunication: Quality of Service Management: from legacy to emerging services. London: The institution of Electrical Engineers 2003. ISBN: 0852964242.

[5] POIKSELKÄ, M., MAYER, G., KHARTABIL, H., NIEMI, A., The IMS: IP

Multimedia Concepts. Chichester: John Wiley & Sons Ltd 2006. INTERNET SOURCES [6] 3GPP, Wikipedia. Last visited: 2006-09-17. URL: http://en.wikipedia.org/wiki/3gpp [7] CARLE, G., ZANDER, S., ZSEBY, T., Evaluation of Building Blocks for

Pure Passive One-way-delay measurements. Last visited: 2006-08-22. URL: http://www.ripe.net/pam2001/Abstracts/poster_04.html

[8] DIAMETER, Wikipedia. Last visited: 2006-09-17. URL: http://en.wikipedia.org/wiki/DIAMETER [9] GGSN, mpirical. Last visited: 2006-09-17 URL: http://www.mpirical.com/companion/mpirical_companion.html [10] GPRS Core Network, Wikipedia. Last visited: 2006-09-17. URL: http://en.wikipedia.org/wiki/PDP_Context [11] Network Switching Subsystem, Wikipedia. Last visited: 2006-09-17. URL: http://en.wikipedia.org/wiki/GSM_core_network

39

[12] Node B, mpirical. Last visited: 2006-09-17 URL: http://www.mpirical.com/companion/mpirical_companion.html [13] PDP context, mpirical. Last visited: 2006-09-17 URL: http://www.mpirical.com/companion/mpirical_companion.html [14] PETRAK, L., HOENE, C., UMTS Networks and Internet Telephony. 2006. Last visited: 2006-09-17

URL: http://net.informatik.uni-tuebingen.de/fileadmin/RI/teaching/umts-voip/ss2006/UMTS_Abbreviations.pdf#search=%22ggsn%20sgsn%20%22node%20b%22%20ims%22

[15] Quality of service, Wikipedia. Last visited: 2006-09-16. URL: http://en.wikipedia.org/wiki/Quality_of_service [16] Service Level Agreement, Wikipedia. Last visited: 2006-09-17. URL: http://en.wikipedia.org/wiki/Service_level_agreement [17] SGSN, mpirical. Last visited: 2006-09-17 URL: http://www.mpirical.com/companion/mpirical_companion.html [18] VEGESNA, S., Ip Quality of Service. Indianapolis: Cisco Press 2003. URL: http://books.google.com/books?vid=ISBN1578701163& id=p1H9wVJJujAC&pg=PA5&lpg=PA5&dq=quality+of+service&sig= oGJc-YQXl1fP06EK_lml1Kiq_EI [19] YAN, Z., 2.5G/3G-compatible PS-domain Core Network Solution. Last

visited: 2006-09-17. URL: http://www.huawei.com/publications/view.do?id=216&cid=90 &pid=61

PAPERS / REPORTS [20] Basic Concepts of WCDMA Radio Access Network. Ericsson Radio

Systems AB 2001. URL: http://www.ericsson.com/technology/whitepapers/ e207_whitepaper_ny_k1.pdf

[21] BAUMGARTNER, F., BRAUN, T., HABEGGER, P., Differentiated Services:

A New Approach for Quality of Service in the Internet. Chapman &Hall. Last visited: 2006-09-17. URL: http://www.iam.unibe.ch/~baumgart/pubs/hpn98.pdf#search=%22

[22] BHUSHAN, B., Measurment and Analysis of End-to-end Service Quality of 3G Networks and Services. Fraunhofer FOKUS 2004. URL: http://www.ist-albatross.org/QoSWhitePaper.pdf

40

[23] BJÖRK, N., Service Control and Service Delivery Control. Internal power

point presentation: SC_20060124_overview.ppt. [24] CALHOUN, P., LOUGHNEY, J., GUTTMAN, E., ZORN, G., ARKKO, J., Diameter Base Protocol. IETF, rfc 3588, September 2003. [25] CALHOUN, P., LOUGHNEY, J., GUTTMAN, E., ZORN, G., ARKKO, J., Diameter Credi- Control Application. IETF, rfc 4006, August 2005. [26] CALHOUN, P., ZORN, G., SPENCE, D., MITTON, D., Diameter Credi- Control Application. IETF, rfc 4005, August 2005. [27] Charging rule provisioning over Gx interface, 2006-03. 3GPP TS 29.210 v6.5.0. [28] CUMMING, J., Session Border Control in IMS. Data Connection Limited

2005. URL: http://www.dataconnection.com/network/download/ whitepapers/SBCinIMS.pdf

[29] Enhanced Policy Decision Function and Gx+, 1/155 17-HSC 113 05/2

Uen. [30] GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface, 2006-06. 3GPP TS 29.060 v7.2.0. [31] HEINANEN, J., BAKER, F., WEISS, W., WROCLAWSKI, J., Assured

Forwarding PHB Group. IETF, rfc 2597, June 1999. Last visited: 2006-09-17 URL: http://www.ietf.org/rfc/rfc2597

[32] LIDSTRÖM, M., 2005-06-14. Cisco’s QoS in IP-Networks. Ericsson, Uen. [33] LINDERBÄCK, F., PCRF Information Contributions to Service Assurance and Dimensioning. Master’s thesis, 2006-10. [34] MULLER, N., Managing ServiceLevel Agreements. International Journal

of Network Management. John Wiley & Sons, Ltd 1999. URL: http://delivery.acm.org.focus.lib.kth.se/10.1145/340000/ 336747/p155-muller.pdf?key1=336747&key2=6364158511& coll=ACM&dl=ACM&CFID=71260489&CFTOKEN=50734145

41

[35] NILSSON, T., Toward third-generation mobile multimedia communication. Ericsson Review no. 3, 1999. URL: http://www.cms.livjm.ac.uk/library/cd3014/2002/Reference %205%20-%20Nilsson.pdf

[36] Policy and Charging Control over Gx reference point, 2006-05. 3GPP TS 29.212 v0.3.0. [37] Policy control over Go interface, 2005-09. 3GPP TS 29.207 v6.5.0. [38] Policy control over Gq interface, 2006-06. 3GPP TS 29.209 v6.5.0. [39] Policy and Charging Control signalling flows and QoS, 2006-05. 3GPP TS 29.213 v0.1.0. [40] Service Assurance for Communication Networks: Solution Description, 2004-11-11. Ericsson, 221 01-FGB 101 241 Uen. [41] Service Delivery Control (SDC) Use Cases. TGF/F, 2005-08-19. [42] Using Quality of Service to Deliver Customer-Focused Metro Ethernet

Services. Cisco Systems 2004. URL: http://www.cisco.com/application/pdf/en/us/guest/netsol/ns223/ c654/cdccont_0900aecd8020a0ff.pdf

ORAL SOURCES [43] BERGSTRÖM, D., Strategic Solution Architect, Ericsson BUGS, 2006-05-04. [44] KVERNVIK, T., Ericsson Research, System Management, 2006-06-22. MAGAZINES [45] ÅSBLOM, J., ”Allt sämre kvalitet på ip-telefoni”, Computer Sweden. 2006-07-28. nr 73, sid 5.

42

Appendix A: Messages over Rx The following information is taken from TS 29.209 [37] and describes what information is sent with the different messages via the Rx interface.

AA-Request (AAR) command <AA-Request> ::= < Diameter Header: 265, REQ, PXY > < Session-Id > { Auth-Application-Id } { Origin-Host } { Origin-Realm } { Destination-Realm } *[ Media-Component-Description ] *[ Flow-Grouping ] [ AF-Charging-Identifier ] [ SIP-Forking-Indication ] *[ Specific-Action ] *[ Proxy-Info ] *[ Route-Record ] *[ AVP ]

AA-Answer (AAA) command <AA-Answer> ::= < Diameter Header: 265, PXY > < Session-Id > { Auth-Application-Id } { Origin-Host } { Origin-Realm } [ Result-Code ] [ Experimental-Result ] [ Authorization-Token ] *[ Access-Network-Charging-Identifier ] [ Access-Network-Charging-Address ] [ Error-Message ] [ Error-Reporting-Host ] *[ Failed-AVP ] *[ Proxy-Info ] *[ AVP ]

Re-Auth-Request (RAR) command <RA-Request> ::= < Diameter Header: 258, REQ, PXY > < Session-Id > { Origin-Host } { Origin-Realm } { Destination-Realm } { Destination-Host } { Auth-Application-Id } *{ Specific-Action } *[ Access-Network-Charging-Identifier ] [ Access-Network-Charging-Address ] *[ Flows ] [ Abort-Cause ] [ Origin-State-Id ] *[ Proxy-Info ] *[ Route-Record ] *[ AVP ]

43

Re-Auth-Answer (RAA) command <RA-Answer> ::= < Diameter Header: 258, PXY > < Session-Id > { Origin-Host } { Origin-Realm } [ Result-Code ] [ Experimental-Result ] *[ Media-Component-Description ] *[ Flow-Grouping ] [ Origin-State-Id ] [ Error-Message ] [ Error-Reporting-Host ] *[ Failed-AVP ] *[ Proxy-Info ] *[ AVP ]

Session-Termination-Request (STR) command <ST-Request> ::= < Diameter Header: 275, REQ, PXY > < Session-Id > { Origin-Host } { Origin-Realm } { Destination-Realm } { Termination-Cause } { Auth-Application-Id } [ Destination-Host ] *[ Class ] [ Origin-State-Id ] *[ Proxy-Info ] *[ Route-Record ] *[ AVP ]

Session-Termination-Answer (STA) command <ST-Answer> ::= < Diameter Header: 275, PXY > < Session-Id > { Origin-Host } { Origin-Realm } [ Result-Code ] [ Experimental-Result ] [ Error-Message ] [ Error-Reporting-Host ] *[ Failed-AVP ] [ Origin-State-Id ] *[ Redirect-Host ] [ Redirect-Host-Usage ] [ Redirect-Max-Cache-Time ] *[ Proxy-Info ] [ AVP ]

44

Abort-Session-Request (ASR) command <AS-Request> ::= < Diameter Header: 274, REQ, PXY > < Session-Id > { Origin-Host } { Origin-Realm } { Destination-Realm } { Destination-Host } { Auth-Application-Id } { Abort-Cause } [ Origin-State-Id ] *[ Proxy-Info ] *[ Route-Record ] [ AVP ]

Abort-Session-Answer (ASA) command <AS-Answer> ::= < Diameter Header: 274, PXY > < Session-Id > { Origin-Host } { Origin-Realm } [ Result-Code ] [ Experimental-Result ] [ Origin-State-Id ] [ Error-Message ] [ Error-Reporting-Host ] *[ Failed-AVP ] *[ Redirected-Host ] [ Redirected-Host-Usage ] [ Redirected-Max-Cache-Time ] *[ Proxy-Info ] *[ AVP ]

45

Appendix B: Messages over Gx The following information is taken from TS 29.210 [27] and describes what information is sent with the different messages via the Gx interface.

CC-Request (CCR) command <CC-Request> ::= < Diameter Header: 272, REQ, PXY > < Session-Id > { Auth-Application-Id } { Origin-Host } { Origin-Realm } { Destination-Realm } { CC-Request-Type } { CC-Request-Number } [ Destination-Host ] [ Origin-State-Id ] *[ Subscription-Id ] [ Framed-IP-Address ] [ Framed-IPv6-Prefix ] [ 3GPP-RAT-Type ] [ Termination-Cause ] [ User-Equipment-Info ] [ 3GPP-GPRS-Negotiated-QoS-Profile ] [ 3GPP-SGSN-MCC-MNC ] [ 3GPP-SGSN-Address ] [ 3GPP-SGSN-IPv6-Address ] [ Called-Station-ID ] [ Bearer-Usage ] [ PDP-Session-Operation ] *[ TFT-Packet-Filter-Information ] *[ Proxy-Info ] *[ Route-Record ] *[ AVP ]

CC-Answer (CCA) command <CC-Answer> ::= < Diameter Header: 272, PXY > < Session-Id > { Auth-Application-Id } { Origin-Host } { Origin-Realm } [ Result-Code ] [ Experimental-Result ] { CC-Request-Type } { CC-Request-Number } *[ Event-Trigger ] [ Origin-State-Id ] *[ Charging-Rule-Remove ] *[ Charging-Rule-Install ] [ Charging-Information ] [ Error-Message ] [ Error-Reporting-Host ] *[ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] *[ AVP ]

46

Re-Auth-Request (RAR) Command <RA-Request> ::= < Diameter Header: 258, REQ, PXY > < Session-Id > { Auth-Application-Id } { Origin-Host } { Origin-Realm } { Destination-Realm } { Destination-Host } { Re-Auth-Request-Type } [ Origin-State-Id ] *[ Proxy-Info ] *[ Route-Record ] *[ AVP]

Re-Auth-Answer (RAA) Command <RA-Answer> ::= < Diameter Header: 258, PXY > < Session-Id > { Origin-Host } { Origin-Realm } [ Result-Code ] [ Experimental-Result ] [ Origin-State-Id ] [ Error-Message ] [ Error-Reporting-Host ] *[ Failed-AVP ] *[ Proxy-Info ] *[ AVP ]

47

Appendix C: UML of Service Tracing

ServiceTracingMain ServiceTracingMain() initGUI() actionPerformed(ActionEvent) searchUserActionPerformed()

UserFrame UserFrame() initGUI() fillList(DefaultListModel) createJList(DefaultListModel) valueChanged(ListSelectionEvent)

DetailsPanel DetailsPanel() initGUI()

KPITextPane KPITextPane() insertText() addStylesToDocument(StyledDocument)

SessionTextPane SessionTextPane(String l) addStylesToDocument(StyledDocument) updateInfo(String, String, String) getError(String, String)

KPICalculator KPICalculator(String, int) getAccessRatio() getCutoffCommunicationRatio() getCommunicationCompletionRatio() getSetupTime() getTeardownTime() getMeanHoldingTime() getAvgCommunicationTime()

SQLHandler SQLHandler() getSessionsWithIP(String) getIP(String) getSessionInfo(String, String) getContactedIMSI(String, String) getPartnerInfo(String, String) getPartnerInfoIfFailed(String, String) getAccessNumbers(String, int) getCutoffNumbers(String, int) getCompletionNumbers(String, int) getSetupTime(String, int) getTeardownTime(String, int) getMeanHoldingTime(String, int) getAverageCommunicationTime(String, int) getDetailsImsi(String) userPresentInDB(String)

48

Appendix D: Abbreviations 3GPP 3rd Generation Partnership Project AAA Authentication, Authorization and Accounting AF Application Function AVP Attribute Value Pair CN Core Network CR Charging Rule CRF Charging Rule Function FTP File Transfer Protocol GGSN Gateway GPRS Support Node GTP GPRS Tunnelling Protocol HLR Home Location Register IMS IP Multimedia Subsystem IMSI International Mobile Subscriber Identity KPI Key Performance Indicator LA Local Area MO Mobile Originator MT Mobile Terminator NTM Network Traffic Management OPEX Operational Expenditure PCRF Policy and Charging Rules Function PDF Policy Decision Function QoS Quality of Service RAN Radio Access Network RBS Radio Base Station RNC Radio Network Controller SA Service Assurance SBLP Service-Based Local Policy SGSN Serving GPRS Support Node SLA Service Level Agreement SLO Service Level Objective SPR Subscription Profile Repository UE User Equipment

TRITA-CSC-E 2006:154 ISRN-KTH/CSC/E--06/154--SE

ISSN-1653-5715

www.kth.se