MEE10:08

ANALYSIS OF IP MULTIMEDIA SUBSYSTEM FOR NETWORKS

BY

Mohammad Rezaul Hossain Morshed Md. Humayun Kabir

A Thesis Presented in partial fulfillment of the requirements for the degree of Master of Science in Electrical Engineering with specialization in

Blekinge Institute of Technology December 2009

Blekinge Institute of Technology School of Engineering Department of Telecommunication Systems Supervisor: Alexandru Popescu Thesis Abstract

The IP Multimedia Subsystem is seen as the promising solution for the next generation multimedia communication. The IP Multimedia Subsystem will make Internet technologies almost anywhere, anytime and on any device such as email, web, instant messaging, presence and videoconferencing. Presence is one of the most important basic services in IMS. It is the service that allows a user to be informed about the reachability, availability and willingness to communicate with other user. Push to talk over Cellular (PoC) is one more service in IMS that allows users to engage in immediate communication with one or more users. Instant Messaging (IM) is the service that allows a user to send some content to another user in near real time.

In this thesis work, we have discussed overall IMS architecture and identity the major issues to improve the existing protocols in IMS for better system performance. Our work is centered on Presence service, Push to talk over Cellular, Instant Messaging and IMS session setup. In this thesis three possible session establishment scenarios in a mobile environment is compared by using an analytical model. The other problem areas in optimizing presence service, dimensioning a PoC service and analyzing service rate of IM relay extensions in IMS are identified.

i

Acknowledgement

We would like to express our immerse gratitude to our supervisor Alexandru Popescu for his guidance and encouragement towards the completion of our thesis work. We would also like to thank our parents for their support and prayers and our friends who have contributed one way or the other to the success of this work. God bless you all.

ii Table of Contents

Thesis Abstract ...... i

Acknowledgement ...... ii

List of Figures ...... v

Chapter 1 ...... 1

1.1 Background ...... 1

1.2 Overview of IMS ...... 2

1.3 Motivation for the use of IMS ...... 2

1.4 Protocols used in IMS ...... 3

1.5 QoS support in IMS ...... 5

1.6 Thesis Motivation ...... 6

1.7 Thesis Out line ...... 7

Chapter 2 ...... 8

2.1Introduction ...... 8

2.2 IMS Architecture Design ...... 8

2.3 IMS and SIP ...... 13

2.4 SIP and ...... 18

Chapter 3 ...... 19

3.1 Introduction ...... 19

3.2 The Couple Model ...... 23

3.3 The Associated Model using one policy server ...... 25

3.4 The Associated Model using two policy server ...... 26

3.5 The Non‐Associated Model ...... 28

3.6 Conclusions ...... 29

Chapter 4 ...... 30

4.1 Introduction ...... 30

4.2 SIP presence architecture ...... 32

iii 4.3 Analysis of presence server traffic load ...... 33

4.4 Mathematical Analysis ...... 34

Chapter 5 ...... 40

5.1 Introduction ...... 40

5.2 Proposed Access priority Model ...... 41

5.3 Proposed Timer ...... 42

5.4 Proposed Model to Optimize Simultenious Sessions ...... 44

Chapter 6 ...... 48

References: ...... 50

iv List of Figures

Figure1. 1: COPS Principle ...... 4

Figure ‐2. 1: IMS Architecture Overview ...... 9

Figure ‐2. 2: SIP session setup example with SIP trapezoid ...... 15

Figure 3.1: Generic media authorization network model...... 21

Figure 3. 2: The couple model ...... 23

Figure 3. 3: The Associate model using one policy server...... 26

Figure 3. 4: The Associated Model using Two Policy Servers ...... 27

Figure 3. 5: The Non‐Associated Model ...... 28

Figure 4. 1: SIP presence service message flow ...... 31

Figure 4. 2: SIP presence architecture ...... 32

Figure 4. 3: Publish and Notify Queues in a PS...... 35

Figure 4. 4: State Transition Graph for Queue System with Batch Arrival and Controlled Vacation...... 38

Figure 5. 1: Example of PoC 1 to many Group session (voice transmission)[5‐4] ...... 40

Figure 5. 2: Markov model for accessing session ...... 42

Figure 5. 3: Markov model for PoC server states ...... 44

Figure 5. 4: session states of a PoC Client ...... 46

v Chapter 1 Introduction

IP Multimedia subsystem is a set of arrangements that explains the Next Generation Networking (NGN) architecture for executing IP based telephony and multimedia services. IMS describes a complete architecture and framework that facilitates the convergence of video, voice, data and mobile network technology over an IP‐based infrastructure. IMS remove the gap between two most successful communication models that is cellular and Internet technology. There was a time we can’t even imagine to play an online game or join a videoconference from anywhere using 3G handheld devices. This is the main vision of IMS to provide all service in cellular that the Internet provides. [1‐1]

1.1 Background

IP Multimedia subsystem was firstly defined by the 3rd Generation partnership Project (3GPP), which is collaboration agreement among a number of telecommunication standard bodies and that was the part their standardization work for supporting GSM network and radio technology evolution. IMS was first launched in 3GPP Release 5 where “session initiated protocol (SIP)” was selected as the key protocol for IMS. To include other feature like presence and group management, internetworking with WLAN, CS based system, fixed broadband access IMS has been enhanced in Release 6 and 7 of 3GPP. [1‐1]

Another standards body, 3rd Generation Partnership Project 2(3GPP2) also standardized their own IMS, which is fairly similar but not exactly same with 3GPP.3GPP2 added proper correction for their specific issues [1‐1].

IMS was intended to create the relationship between the existing traditional telecommunication technology and Internet technology, so that IMS can help mobile operators in initiating new and innovative services that will draw new subscriber and maintain their existing base. IMS allow network operators to play a vital role in traffic distribution and that’s why IMS has generated intense research and standardization efforts.

1 1.2 Overview of IMS

The Internet protocol (IP) is used to interconnect a large number of people all over the world. Currently more than 15% population of the world has access to the Internet and this rate is rapidly increasing day by day. The Internet provides interoperability at a very huge scale, helping people using different terminal to communicate. [1‐2]

First generation of the Internet was mostly devoted to the transport of non real time data; services with rigorous Quality of Services (QoS) requirements are now largely adopted (e.g. telephony over IP (ToIP), video conferencing). The operator’s revenue is expected to grow in the next few years because of the share of multimedia services. [1‐3]. The move toward all IP architecture for service delivery seems to be a strong trend. In this situation customers desire an access to personalized interactive, multimedia services on any device and anywhere. This desire required new network infrastructures. The IP Multimedia subsystem (IMS) is seen as the perfect solution for fulfilling this requirement. IMS refers functional architecture of multimedia services, depends on Internet protocols. The main goal of IMS is to merge Internet and cellular worlds in order to facilitate rich multimedia communications. [1‐3].

1.3 Motivation for the use of IMS

Basic Principles:

One the most important aim of IMS to make the easier network management. Therefore it separates bearer and control functions. It means that IMS features an overlay service delivery network on a packet switched infrastructure. Furthermore IMS should allow the migration of circuit switched services for example voice telephony to the packet switched domain. As a result IMS can make network management easier because all IP integrated network is easy to manage. IMS is an end‐to‐end architecture that should support different kind of equipments. In addition, IMS service delivery should be independent of the underlying access technology. Therefore the use of open Internet protocol is specified

In IMS for better interoperability. IMS supports between different networks (3GPP Release 6). The level of QoS that can be afforded in IMS networks decides the services that can be deployed in such network. So In IMS network QoS service delivery is significant. As a result QoS management functionality is incorporated in the IMS architecture.

2 IMS provides a set of common functions called service enablers that are possible to use by a number of services (e.g. group/list management, presence, provisioning, billing etc). This creates service implementation much easier and faster. In addition it allows a tight interaction between different services.

Business and technical Motivation:

While several network operators getting trouble because of decreasing average revenue per user, IMS is seen as a solution for network operators. It permits the network operator to play a vital role in service delivery, and bundle smart services with their basic offer. Furthermore IMS should support the creation and deployment of modern services by operators or third parties and as a result make new business standpoint. The quick deployment of IMS services should decrease the time to market and stimulate innovation.

The combination of different services in one session, the single sign on and unified billing are expected to increase customer’s interest and revenue prospect. In IMS the operator is aware of the authentic services the customer is using for that reason; suitable billing schemes can be developed [1‐4].

IMS is also designed to permit substantial network infrastructure and management savings as a result get better cost effectiveness. Probable services on IMS network are push to talk over cellular (PoC), Instance Messaging (IM), Mobile gaming or a combination of different existing services.

IMS is aimed to facilitate the deployment of “better and richer” services. It should enable the delivery of real‐time IP based communications [1‐3]. It should build the incorporation of real‐time, near real‐time and non real‐time applications easier. It should permit a user to access its services from any supported media.

1.4 Protocols used in IMS

Nearly all of the protocols used in IMS are standardized by the IETF. They are shortly discussed in the following section.

Signaling and media flow description:

The key signaling protocol used in IMS is called the session initiation protocol (SIP). It was firstly defined in RFC 2543 (obsolete) and later on RFC 3261 [1‐5, 1‐6]. SIP uses some

3 principles of HTTP and SMTP, which are most successful Internet protocols. SIP has been chosen in IMS importantly because it fulfill IMS requirement and it is considered flexible (several extensions are standardized) and secure. The major function of SIP is the establishment, modification, and termination of multimedia session between two terminals. The body of SIP message illustrated using the Session Description Protocol (SDP). SDP describe media flows like address, port, media type, encoding etc.

SIP is possibly key protocol in IMS architecture. SIP is capable to manage subscriber management, service control, single sign on, QoS authorization, billing, resource management etc.

Authentication, Authorization and Accounting:

Diameter is a current Authentication, Authorization and Accounting protocol changing the RADIOUS protocol [1‐7]. security is granted by IPSEC or TLS. Diameter is used in IMS service framework by the Application servers (Ass), I‐CSCF, and S‐CSCF in their exchanges with HSS including user profiles. It’s also used in the exchanges among RACS and the AS and CLF.

Policy Support:

The Common Open Policy service (COPS) is a protocol that supports policy control over Quality of Service (QoS) signaling protocols like RSVP. It is used to communicate decisions and policy requests between Policy Enforcement Points (PEP) and Policy Decisions Points (PDPs) (see figure 1.1 [1‐2])

PDP

COPS

PEP

Figure1. 1: COPS Principle

4 COPS support two policy management models:

1) The outsourcing model identifies that PDP‐PEP exchange happen for each policy decisions (e.g. COPS for RSVP RFC 2748 and RFC 2749 [1‐2])

2) In the configuration or provisioning model the PEP accumulates policy rules named by the PDP and use them for policy decisions. This offered brilliant scalability for the associated protocols (COPS‐PR).

In the configuration model, the policy rules require to be stored in the PEP. The equivalent data structure is called the Policy Information Base (PIB). It explains the configurable mechanisms for implementing policies in the PEP also the events that can trigger the exchange of policy information.

Additional Protocols:

H248 is descendant of the Control Protocol (MGCP) used for managing media serving functions in an IMS environment. It is classified in RFC 3015 [1‐8].

The Real Time Protocol (RTP) offers transport function for transmitting real time data. It is used in concurrence with a control protocol called Real Time Control protocol (RTCP) in order to permit monitoring of the data delivery and to present minimal control and identification functionality.

It is to be note down that the use of IPV6 is obligatory in IMS networks complying with 3GPP release 5 but different apparatus vendor implementations support both IPV4 and IPV6.

1.5 QoS support in IMS

The scheme of transforming a well effort IP network by initiating end‐to‐end QoS guarantees is a significant driver for the deployment of IMS. This is key concern because the QoS that the IMS architecture is able to present determines the services that can be deployed on it, and the value is supposed to reside in real time multimedia services.

Two policies are typically associated for providing a good level of quality of service in packet networks. The first entails avoiding congestion phenomena. This can be made by

5 Employing Connection Admission Control (CAC), resource reservation, or simply over dimensioning the network. The second technique center on managing congestion it typically relies on traffic differentiation for providing better QoS to most important flows. Different standards are related to this idea; the most common one is DiffServ.

As we discussed above IMS opens up new standpoints for network operators. But different technical and business challenges have to face in order to allow the wide adoption of this promising technology. Furthermore IMS has to solve its inherent negations: it communicates on IP technologies allowing free communication but aims at controlling IP services.

1.6 Thesis Motivation

IMS is the technology that will combine the internet () with the cellular word (). It will build Internet technologies like mail, web, video conferencing, instant messaging, and presence almost all over. Main reasons for introducing IMS was to provide quality of service (QoS) needed for enjoying real time multimedia sessions. Other reasons were to be able to charge multimedia sessions appropriately. Moreover the aim of IMS is to provide all services, current and future, that the Internet provide.

Problem statement:

Presence server can easily be overloaded while there are many numbers of watcher and subscriber requesting for presence service at the same time so we need to mitigate message‐processing load of a presence server. The Push‐to‐Talk over cellular (PoC) server needs to be dimensioned to make revenue for service provider.

In the thesis we will explain different session establishment method then we will identify the best method for session setup in mobile environment for the IMS terminal and we will discuss briefly presence server of IMS system. We will study different kind of Queuing mechanism. Finally we will propose a new queuing mechanism that will increase performance of presence server at IMS system and we will discuss several models to dimension IMS Push‐to‐Talk over cellular service.

6 1.7 Thesis Out line

Chapter 1: Chapter 1 will contain Basic information of IMS and Literature review.

Chapter 2:In chapter 2, will draw a IMS architecture and will explain different component of IMS architecture like SIP server, User database known as home subscriber server (HSS), Application server (AS), Media resource function (MRF), Public switch telephone network (PSTN) etc.

Chapter 3: There are many methods for session establishment .At first we will explain different session establishment method and then we will introduce the best method for session setup in mobile environment for the IMS terminal.

Chapter 4: we will discuss briefly presence server of IMS system in this chapter. We will study different kind of Queuing mechanism. Finally we will propose a new queuing mechanism that will increase performance of presence server at IMS system.

Chapter 5:In this chapter we will discuss about the dimension of PoC service for service providers with regards to controlling PoC session access, optimal PoC session timer, path optimization and number of allowable simultaneous PoC sessions for given network grade of service.

Chapter 6: conclusion and future work.

7 Chapter 2 IMS Architecture

2.1Introduction

The describes the functional architecture for a managed ip based network. The aim of IMS is to acclimatizing to different applications e.g. push to talk over cellular, presence, instant messaging, streaming, multiplayer game etc. IMS construct on IETF protocol like SIP, SDP, DIAMETER, MGCP etc. to make complete multimedia system providing a wide range of session border control. Call access control, reachability and security.

The third‐Generation partnership project (3GPP) has proposed IMS in release 5 on Internet protocol version 6(Ipv6) but it is negotiated for Ipv4 because the industry is not ready to migrate to Ipv6 now. [2‐1].

The IMS has become raisingly admired both with wire line and wire less service provider as it is intended to increase carrier revenues, deliver integrated multimedia service, and an open, standard‐based network.

2.2 IMS Architecture Design

In the General architecture of IMS 3GPP standardize functions but not nodes. So we can say that the IMS architecture is a collection of functions linked by standardized interfaces [Figure 2.1]. If any implementer want they can merge two functions into single node as well as they can divide single function into two or more nodes.

Figure 2.1 shows an overview of the IMS architecture as standardized by 3GPP.here we include only most important nodes.

8 SIP-AS IM-SSF MRFC

Access ` Network P-CSCF MRFP

HSS

SGW S-CSCF

Access Network MGCF P-CSCF SLF

I-CSCF MGW

BGCF

Figure ‐2. 1: IMS Architecture Overview

An IMS network consists of many SIP servers known as CSCFs (Call Session/Control Functions), user databases known as Home Subscriber Servers (HSS). Application Servers (AS), Media Resource Functions (MRF), Public Switched Telephone Network (PSTN) Gateways etc.

Call Session/Control Function (CSCF):

CSCF is a SIP (Session Initiation Protocol) server, which is mainly responsible for SIP signaling in the IMS. CSCFs are very essential in the IMS architecture. Its service independent access point distributes all incoming calls to application services and manages initial subscriber authentication. The CSCF uses SIP message to forward the call event to the service and adds additional header information to maintain control of the call.

9 The CSCF component uses IMS service control interface to intercept call signaling and pass it to application services for processing. There are three types of CSCFs depending on the functionality they provide. The descriptions of these three types of CSCFs are here under:

1. P‐CSCP (Proxy‐CSCF)

The P‐CSCP is the first point of contact between the IMS terminal and the IMS networks. According to SIP principle P‐CSCP acts as an inbound/outbound SIP proxy server that is all requests initiated by the IMS terminal or destined to the IMS terminal pass through P‐CSCP. The P‐CSCP is responsible for security of all messages between the network and user. Firstly it set up IPSec security associations in the direction of IMS terminal. When the P‐CSCP authenticates the user the P‐CSCP states the identity of the user for the all others node in the network.

Furthermore, The P‐CSCP verifies the accuracy of SIP request sent by the IMS terminal. The P‐CSCP also includes a compressor and a decompressor of SIP messages and PDF (Policy decision Function). The PDF manages quality of service over the media plane.

An IMS network normally includes a number of P‐CSCF for the sake of scalability and redundancy. Each of them serves a number of IMS terminals depending on the capacity of the node.

2. I‐CSCF (Interrogating‐CSCF)

The I‐CSCF presents functionally of a SIP proxy server located at the edge of an administrative domain. I‐CSCF has DIAMETER interfaces to the SLF (Subscriber Location Function) and HSS (Home Subscriber Function) and retrieves user location information and route to the appropriate destination, typically an S‐CSCF.

The I‐CSCF may also encrypt the parts of the SIP messages that contain important information about the domain like the number of servers in the domain, their DNS names or their capacity. I‐CSCF ‘s IP address is published in the DNS of the domain as, that domain is the entry point of all SIP packets.

10 3. S‐CSCF (Serving‐CSCF)

The S‐CSCF is a SIP server that performs session control. Beside this it also act as a SIP register. The S‐CSCF is the central node of the signaling plan and always located in the home network. It maintains a binding between the user location and the user’s SIP address of the record (also known as public user identity). The S‐CSCP also has a diameter interface to HSS like I‐CSCF. One of the main functions of the S‐CSCF is to present SIP routing service.

Application Server (AS)

The AS (Application Server) is a SIP entity that hosts and executes IP Multimedia Services. IMS permit quick service creation and delivery. Several Services like telephony and messaging can be hosted in a single application server. Different services in a single application server reduce the workload of CSCF in the control layer.

Media Resource Function (MRF)

The MRF (Media Resource Function) provides the source of media in the home network. It is divided into two parts; one is the signaling plane node referred, as Media Resource Function Controller (MRFC) and the other is media plane node referred as Media Resource Function Processor (MRFP). The MRFC communicates with an application service and directs a separate media server to manage the media stream. It manages the resource in the MRFP via an H.248 interface. The MRFP implements all the media related functions like playing or mixing media.

Breakout Gateway Control Functions (BGCF)

The BGCF (Breakout Gateway Control Function) is a SIP server that incorporates routing functionality based on telephone numbers. It is only used in sessions that are initiated by an IMS terminal.

The Public Switched Telephone Network (PSTN) Gateways

The PSTN gateway provides an interface to a circuit‐switched Network, allowing IMS terminals to make and receive calls to and from the PSTN or any other circuit switched

11 network. A PSTN gateway can be decomposed in to MGCF (Media Gateway Control Function), SGW (Signaling Gateway), and MGW (Media Gateway).

MGCF (Media Gateway Control Function)

This is the essential node of PSTN gateway that routes calls from or to SS7/TDM channels or PSTN/PLMN networks. All calls routed through this media gateway enter the IMS core network as SIP/RTP media streams. RTP streams are routed directly between media servers, gateways and endpoints. The MGCF manage the resources in MGW.

Signaling Gateway (SGW)

The signaling Gateway interfaces the signaling plane of the PSTN network or circuit switched networks. Signaling Gateway performs lower layer protocol conversion.

Media gateway (MGW)

The MGW interfaces the media plane of the PSTN (Public Switched Telephone Network) and CS (Circuit Switched) Network. The MGW is able to send and receive IMS media over the Real Time Protocol (RTP). MGW also uses one or more PCM (Pulse Code Modulation) time slots to connect to the CS network. In addition, the MGW performs trans‐coding when the IMS terminal does not support the codec used by the CS side.

Home Subscriber Server (HSS)

The Home Subscriber Server (HSS) provides a central repository for subscriber information in IMS architecture. The HSS stores all subscriber information necessary to handle session between users and provide service to subscriber. The information includes among other item, security information, and location information, user profile information including the services that the user is subscribed to and the S‐CSCF allocated to the user.

A network may contain more then one HSS when the number of subscriber is too high. Network with a single HSS do not need a Subscriber Location Functions (SLF) but if network contain more then one HSS do require SLF. The SLF is a simple database that maps user’s address to HSSs.

12 Charging Entities

Charging entities are used to maintain billing information for subscribers using network service. For offline (Rf) and online (Ro) charging entities IMS uses diameter messages. To provide different service IMS uses different functional components. For example to transport media, IMS uses Call Session Control Function (CSCF), IMS Service Control Interface (ISC), Session Border Controller (SBC), Media Gateway Control Function (MGCF), Media Resources Function (MRF), Media Resource Function Controller (MRFC), Home Subscriber Server (HSS) and Charging Entities.

2.3 IMS and SIP

The IP Multimedia Subsystem is an important service notion allowing next generation networks to maximize their potential from full multimedia service offering. IMS has a different number of protocols each having a particular function. This provides flexibility, simplicity, modularity and extensibility for a robust and complex network infrastructure. SIP is a signaling protocol. Signaling protocol means end point involved in the call and the network routers treat this signaling packet as any regular data.

The session initiation protocol (SIP) [2‐2] lies at the core of the IMS architecture. It is a prominent protocol today in the third generation networks. SIP is a real‐time communication protocol mainly facilitates multimedia data transfer in IMS.SIP has been chosen in IMS to play the main role for setting up the session while inter‐working with other protocols. It is a lightweight, text‐based protocol highly flexible and readily scalable. SIP is about initiating interactive communications sessions between users.

It also manages termination and modifications of session in progress as well. When the requirement is real time session establishment SIP can reside in the communication device and manage these sessions. SIP has been expanded to support video and instant‐messaging applications. IMS defines standard control plane interfaces based on SIP for creating new applications. There are much more areas that SIP perform: sessions call setup and tear down and signaling for features like call hold, caller ID, conferencing and call transferring. SIP implementation is well accepted because of its compatibility with other standards like voice XML. Also the SIP framework accept service provider to quickly introduce extensions like security compression etc to meet the service needs

13 Overview of SIP Operations:

SIP Support five aspects of establishing and terminating multimedia communication:

User location: determination of the end system for communication.

User availability: determination of the eagerness of the called party to involve communications.

User capabilities. Determination of the media and media parameters.

Session setup: set up session parameters at both called and calling party.

Session management: transfer and termination of sessions, modifying session parameters and invoking services.

SIP can be used with other IETF protocols to make complete multimedia architecture. Normally, this architecture will include protocols like the Real‐Time transport protocol (RTP) (RFC 1889 [2‐3]) for real time data transfer and providing QoS. The Real‐Time streaming protocol (RTSP) (RFC 2326 [2‐4]) for managing distribution of streaming media, the Media Gateway Control Protocol (MEGACO) (RFC 3015 [2‐5]) for managing gateways to the Public Switched Telephone Network (PSTN) and Session Description Protocol (SDP) (RFC 2327 [2‐6]) for illustrating multimedia sessions. So in order to provide complete service SIP should be used in conjunction with other protocols.

Now we introduce the basic operations of SIP using simple example [2‐7]. Figure 2.2 shows a typical example of a SIP message exchange between two user’s Morshed and Sumon (all message labeled with letter M). In this example Morshed call sumon from his pc using a SIP application (namely soft phone) over the Internet. There are two SIP proxy servers that act on behalf of Morshed and sumon to provide the session establishment.

Morshed calls sumon using his SIP identity, a type of Uniform Resource Identifier (URI) called a SIP URI. In this case, it is sip: [email protected] where tcl.com is the domain of sumon’s SIP service provider. Morshed has a SIP URI of sip: [email protected]. SIP is a HTTP‐ like request/response transaction model. Every transaction consists of a request that invokes a specific function on the server, at least one response. In our example the transaction starts with Morshed’s soft phone sending an INVITE request addressed to sumon’s SIP URI. The INVITE request contains a number of header fields. Header fields provide additional information about a message. INVITE include a unique identifier for the call, the destination

14 address, Morsehd’s address and information about the type of session that Morshed wishes to establish with Sumon.

flora.com tcl.com proxy proxy

Morshed’s Sumon’s Softphone SIP phone

INVITE M1

INVITE M2 100 Trying M3 INVITE M4 100 Trying M5 180 Ringing M6 180 Ringing M7

180 Ringing M8 200 OK M10 200 OK M9

200 OK M11

ACK M12

Media Session

BYE M13

200 OK M14

Figure ‐2. 2: SIP session setup example with SIP trapezoid

15 The INVITE (Message M1 in Figure 2) might look like following:

INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP pc33.flora.com;branch=z9hG4bK776asdhds Max-Forwards: 70 To: sumon From: morshed ;tag=1928301774 Call-ID: [email protected] CSeq: 314159 INVITE Contact: Content-Type: application/sdp Content-Length: 142

The first line of the message contains the method name (INVITE). The lines that follow are a list of header fields. Our example contains a minimum required set. The header fields are briefly discussed below:

Via contains the address (pc33.flora.com) at which Morshed is expecting to get response to this request. It also contains branch parameter that identifies this transaction.

To contain a display name (sumon) and the SIP URI of the destination (SIP: [email protected])

From also contain display name (Morshed) and the SIP URI (sip: [email protected]) that specify the creator of the request.

Call‐ID contains a unique identifier for this call, created by combination of a random string and the soft phone host name or IP address.

Cseq contains a method name and an integer.

Max‐Forwards limits the number of hops, a request can make to its destination.

Content‐type contains a description of the message body (not shown)

Content‐length contains an octet (byte) count of the body.

16 In this example the proxy server (flora.com) receives the invite request and sends 100 (trying) response to Morshed’s softphone. The 100 (trying) response specifies that the INVITE has been received and the proxy is working on it to route the INVITE to the destination. The tcl.com proxy server receives the INVITE and 100 (trying) response back to the flora.com indicates that INVITE has received and is processing the request. tcl.com server proxies it to the sumon’s SIP phone. Sumon’s phone receives the INVITE and aware Sumon that incoming call from Morshed. Sumon’s SIP phone shows this in a 180 (Ringing) response, which is routed back in a reverse direction. In our example sumon make decision to receive the call. When he picks up the handset his SIP phone sends a 200 (ok) response, indicate that the call has been responded. The 200 (ok) (Message M9 in figure 2) might look like this following:

SIP/2.0 200 OK Via: SIP/2.0/UDP server10.tcl.com ;branch=z9hG4bKnashds8;received=192.0.2.3 Via: SIP/2.0/UDP bigbox3.site3.flora.com ;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2 Via: SIP/2.0/UDP pc33.flora.com ;branch=z9hG4bK776asdhds ;received=192.0.2.1 To: Bob ;tag=a6c85cf From: Alice ;tag=1928301774 Call-ID: [email protected] CSeq: 314159 INVITE Contact: Content-Type: application/sdp Content-Length: 131

The first line of the response contains the response code (200) and reason phrase (ok). The remaining lines contain header fields.

17

2.4 SIP and Quality of Service

To provide a best effort IP network by introducing end-to-end QoS guarantees is an important driver for the development of IMS. This is a main consideration because the level of QoS that the IMS architecture can provide determines the services that can be deployed on it and value is assumed to reside in real time multimedia service. IMS ensures QoS by session layer negotiation with resource granted at transport layer.

SIP establishes connection between two or more end point in an IP network. The QoS parameters for the session are negotiated during the setup. So the performance assessment of IMS based network should be from QoS perspective.

18 Chapter 3 Session establishment

3.1 Introduction

Several methods have been introduced through which end hosts can use a session management protocol like session management protocol (SIP) to complete that requirement of quality of service (QoS) must be meeting in order to have a successful session establishment. Furthermore a resource reservation protocol (RSVP) is used to request the resources need to fulfill the end‐to‐end QoS for media streaming. In order to protect deception and make sure perfect billing, some linkage is uses to make sure that the resources being used to provide the requested QoS are in‐line with the media streams requested for the session [3‐1]

In this of this thesis we are going to describe that sort of linkage through use of a token that presents capabilities like of a gate in and of a ticket in the push model. A session management server or a policy server produce that token and is transparently broadcast throughout the end host to the edge router where it is used as component of the policy – controlled flow admission process [3‐2].

There are few environments, authorization of media streams can expand by the fact that pre‐established relationship subsists between elements of the network like session management server, edge routers, policy servers and end hosts. Pre‐established relationship shows that the several network elements are configured based on the identities of other network elements and if it is required that are configured with security keys, need to establish a true relationship. In further environments, on the other hand such pre‐ established relationships may not exist either because of the difficulty of creating these applications like in a network with many elements or because of several business entities engaged like service provider and access provider or due to the dynamic nature of these associations like mobile environment. In this chapter we will explain several scenarios and methods used for exchanging data between networks elements in order to authorize the resource uses for a service and to organize actions between the

19 Session and resource management bodies. Particular extensions to session management protocols, to resource reservation and COPS for dealings along with policy server. The framework can be launched to a multimedia services scenario by using several type of signaling protocols.

In this chapter we are going to describe media authorization concept through SIP for session signaling, for resource reservation RSVP and COPS for dealings with the policy server. This framework is possible to introduce to a multimedia services picture by using different of signaling protocols.

Figure 3.1 provides a generic model for session establishment, QoS and Policy enforcement.

20 +------+ +---+

| Service Control Domain | | | | +------+ +------+| | I | | |Session management | |Policy || | n | | |server | |Server || | t | | | +------+ +------+ | | +----+||<->| e | | | |SIP Proxy| |PEP |<-|-|->|PDP ||| | r | | | +------+ +------+ | | +----+|| | - | | +------+ +------+| | c | | | | o | +------+ | n | | n | +------+ | e | | RCD - Resource Control Domain | | c | | | | t | | | | i | | +------+ +------+ | | n | +------+ | |Edge Router | |Policy Server| | | g | | End | | | | | | | | | | Host | | |+------+| |+------+ | | | N | |+------+| | ||RSVP Agent|| ||PDP | | | | e | ||RSVP ||<->| |+------+|<-->|+------+ | |<->| t | ||Client || | |+------+| | | | | w | |+------+| | || PEP || | | | | o | ||SIP User|| | |+------+| | | | | r | ||Agent || | +------+ +------+ | | k | |+------+| | | | | +------+ +------+ +---+

Figure 3.1: Generic media authorization network model.

21 End Host (EH): The End Host is a sort of device that is used by subscriber to contact with network service. To request network services the End Host incorporate a client like SIP and also another client for requesting network resource like RSVP.

Edge Router (ER): it is a network element that joints between the end host to the rest of the resource resources of the control domain. The Edge Router has held a PEP to impose policies interrelated to the resource usage in the resource control domain by the End Host. Its also holds a signaling agent for managing resource reservation request which is provided by End Host [3‐3].

Policy Decision Point (PDP): the policy decision point is a type of logical entity that is placed in the policy server that is accountable for authorizing or ignoring access between services.

Policy Enforcement point (PEP): The PEP is also a type of logical entity which can be enforcing policy decision made by the policy decision point.

Policy Server (PS): this is a one type of network element that can hold a PDP. We should be in mind service control must be containing PS. Domain for controlling use of services and there might be a different PS between the resource control domain to manage use of resources along with the packet forwarding path. Also the topology of network might involve so many policy servers in also domain. Though, they provide pleasant policy decisions to explain the appearance of a single PDP in every Domain [3‐4].

Resource Control Domain (RCD): The resource control domain is a one type of logical grouping of elements, which afford connectivity among the packet forwarding path to and from the End Host. The RCD holds ER and PS entities those responsibilities comprise management of resource along with the packet forwarding paths.

Service Control Domain (SCD): this is also a type of grouping of elements that executes application and content to subscribe of their services. The session management server

Reside in the SCD with the PS. May be there are more than one Scads within an autonomous domain.

Session Management Server (SMS): The SMS is one type of network element which providing session management services for example telephony call control. The session management server holds a PEP to implement policies that related by using of services from the End Host. Moreover its contain unique type of signaling agent or proxy server like SIP for handling service requests within the End Host [3‐5].

22 3.2 The Couple Model

In some environments, a pre‐established genuine relationship exists between elements of the network (like edge router, end hosts, session management servers and policy servers) in this chapter we referred this as a “coupled model” which show the fixed relationship along with the entities that is presumed. The key feature for this scenario is described below:

 Policy decisions, that comprises media authorization is made by particular policy server.

 Session management server, the edge router, and policy server concerned by establishing the session. For example the end host must be configured to use a session management server connected with the Edge Router by which the EH is established [3‐5].

 There are pre‐defined protected relationship between the SMS and the PS and between the ER and the PS.

+------+ | | | | 1 +------+ 2 | | | |------>| Session Management |----->| | | |<------| Server |<-----| | | | 4 +------+ 3 | | | End | | Policy | | Host | | Server | | | | | | | 5 +------+ 6 | | | |------>| Edge |----->| | | |<------| Router |<-----| | | | 8 +------+ 7 | | +------+ | | +------+

Figure 3. 2: The couple model

23

Coupled Model Message Flows:

PS and SMS and between the PS and ER, communications with these entities are possible to describe. Here we are going to describe only the originating side flow because of simplicity. Here we will only consider there is one policy server is serving both the service control and the resource control domains. And there is pre‐defined protected relationship among the terminating side also.

 The End Host send a session setup request (like SIP invite) to the session management server monitoring. The media stream should be used in the session. As a division of this step, the End host might be authenticating itself to the session management server [3‐5] [3‐6].

 The session management server, probably just after waiting for the negotiation of the media streams would be completed, sending a policy decision request (like COPS REQ) by the policy server as it could conclude if the session set up request could be allowed to be proceeding.

 The policy server send a decision (COPS, DEC) to the session management server, maybe after modification of the parameters in the media should be used. Incorporated in this response is a ‘token’ that can be used by the policy server for classifying the session and the media should be authorized.

 The session management server sends a signal to the End Host (SIP 200 or 183) mentioning that session set up is complete or in progressing. Included in this response is an explanation of the negotiated media beside the token with the policy server.

 Policy server that the end host issued a request (RSVP, PATH) to preserve the resources need for providing the necessary QoS for the media stream.

 The Edge Router interrupts the reservation request through sending a policy request (COPS, REQ) to the policy server for formative if the resource reservation request might be permitted to proceed. Including in this request is the token from the policy server which is provide by the End Host. This token are

24 uses by the policy server to association the request to resources among the media authorization that is before provided to the session management server.

 The policy server is throw a decision (example COPS, DEC) to the edge router. May be after modification of the parameters of the resources must be preserve.

 The Edge Router may be after waiting for end‐to‐end negotiation for resources to be completed, by sending response to the End Host (Example RSVP, RESV) representing that resource reservation is almost complete or is in progressing.

3.3 The Associated Model using one policy server

In this scenario, there is one more instance of the session management servers, policy servers and Edge Router. This show the way to the network of so complexity that is prevents issued knowledge of the network topology to every type of net work entities. The main features of this set‐up explain as below:

Policy decisions also media authorization is made by the similar type of policy server for equally the Edge Router and the session management server. Though the policy server can change on an every transaction basis.

Session management server, the edge router and the policy server is engage in establishing the session is not known a priori. For example the end host probably dynamically configured to use one of pool of session management server and the entire session management server probably statically configured by using one of a pool of policy servers.

The End host should be mobile and continually charging the edge router that from its point of attachment user to communicate with the rest of the network.

There are secret relationship between the SMS and the PS and in between the ER and the PS.

25 +------+ +------+ | SMS 'n' |<-->| PS 'm' | +------+ +------+ | +------+ : : : | | | | | 1 +------+ 2 | | | | |------>| Session Management |----->| | | | |<------| Server 1 |<-----| | | | | 4 +------+ 3 | | | | End | | Policy | | | Host | +------+ | Server | | | | | ER 'n' | | 1 | | | | 5 +-+------+ | | | | | |------>| Edge |-+ 6 | | | | |<------| Router |----->| | | | | 8 +------+ 7 | | | +------+ <-----| |-+ +------+

Figure 3. 3: The Associate model using one policy server.

3.4 The Associated Model using two policy server

In this scenario, there are also more than one instance of the session management server, Edge Router and Policy server this lead to a network of sufficient difficulty that it prevents distributing knowledge of network topology to all other network entities. The main feature of this scenario is describing below:

 Policy decision with media authorization is prepared by policy servers.

 There is a PS in the resource control domain which is detaching form the PS on the service control domain.

26  The Edge Router, Session Management Server and Policy Servers are engaged in set up the session is not known a priori. For example, the End Host may be dynamically configured to use one of a pool of Session Management Servers 3‐7].

 There is one type of pre‐defined secret relationship between the SMS and the SCD, PS

 There is a kind of firstly defined secret relationship between the ER and the RCD PS.

 There is also a secret relationship within the RCD and SCD policy server.

+------+ +------+ | SMS 'n' |<-->| PS 'm' | +------+ +------+ | +------+ : : : | | | | | 1 +------+ 2 | | | | |------>| Session Management |----->| | | | |<------| Server 1 |<-----| | | | | 4 +------+ 3 | | | | End | | Policy | | | Host | +------+ | Server | | | | | ER 'n' | | 1 | | | | 5 +-+------+ | | | | | |------>| Edge |-+ 6 | | | | |<------| Router |----->| | | | | 8 +------+ 7 | | | +------+ <-----| |-+ +------+

Figure 3. 4: The Associated Model using Two Policy Servers

27 3.5 The Non­Associated Model

In the case of non associated model, the session management server and the edge routers connected with several types of policy servers. The network entities do not have any priori knowledge on the topology of the network and there is no pre‐established secret correlation between the entities in the resource control domain and in the service control domain [3‐8]. The key features of these scenarios are illustrating below:

 The PS along with the resource control domain is divided from the PS with the service control domain.

 Here there is a pre‐defined secret relationship between the SCD PS and the SMS.

 There is also a pre‐defined relationship between the ER and RCD PS.

 But there is no pre‐defined secret relationship between the SCD and RCD policy server and between the ER and SMS.

+------+ +------+ | | | | 1 +------+ 2 | SCD | | |------>| Session Management |----->| Policy | | |<------| Server |<-----| Server | | | 4 +------+ 3 | | | End | +------+ | Host | | | +------+ | | 5 +------+ 6 | | | |------>| Edge |----->| RCD | | |<------| Router |<-----| Policy | | | 8 +------+ 7 | Server | +------+ | | +------+

Figure 3. 5: The Non‐Associated Model

28

3.6 Conclusions

In this chapter mainly we have describe three models for session set up with media authorization.

The coupled model that presumes a priori knowledge of the network topology and there are pre‐established secret relationship’s be present within all network entities.

 The associated model, where there is a common or secret policy server but network topology knowledge is not well‐known as a priori.

 In the Non‐Associated model network topology knowledge is also not well‐known as priori. There are different policy server are engaged and there is no secure Relationship between all the policy servers.

The Associated model is suitable with the environment where network entities are engages by establishing a session which has a pre‐determined secret relationship but there elements should be concrete dynamically in the session set up time. The Non‐Associated model is perfect for some kind of environment where network topology is complex and there is no trust relationship between domains. For any given network one or more of these model is possible to apply while the model to be used might be chosen on the session establishment time depends on knowledge of the end points engage in the call.

29 Chapter 4 IMS Presence Server

4.1 Introduction

Presence service permits a user to be informed about the reachability, availability, and willingness to correspond with other user. It has turn into a key enabler for many admired applications like instant messaging and push‐to‐talk. The presence service is capable to point out whether the other user is online or not and if they are online, whether they are busy or idle. In addition the presence service permits user to give details of their communication means and capabilities. However from a recent study we can see presence service is responsible for 50% or more of the signaling traffic the IMS core network manages [4‐1]. This is pretty a trouble for a real IMS network and should be tackled. In this chapter we will analysis the traffic load distribution that NOTIFY messages account for the big part of the traffic load on a presence server. We will study a mathematical model of a queuing system with batch arrival and controlled vacation to explain the processing of a NOTIFY message within a presence server.

A presence service contains four elementary entities [4‐2]: a principle, presentity, watcher and a presence server (PS) which can be subsist independently or as a part of application servers like IM or PTT. A principle suggest to a user maintained by a presence service and the holder of the presentity; presentity information stand for the principal’s capability and eagerness to communicate and rules on how this information is possible to accessed. A watcher is an entity which requests information from presentity; a presence server is a network entity which is liable for handling presence information. Figure 4.1 depict three essential SIP methods close to the presence service [4‐3] [4‐4].these is SUBCRIBE, PUBLISH and NOTIFY. In the first occasion a watcher subscribes to a meticulous presentity through a SUBSCRIBE method (SIP message). The PS validates either this watcher authorized or not to subscribe to this particular presentity. If yes it response with a 200 OK method and send the present state of the presentity to the watcher through a NOTIFY method [4‐5].if a presentity changes its state it uses the PUBLISH method to inform PS of the change. Therefore the PS alerts all subscribed

30 Watchers that the presentity’s state change. There is also other way for getting presence information for example through the home subscriber server (HSS).

Presentity Presence Server Watcher

SUBSCRIBE

200 OK

NOTIFY

200 OK

PUBLISH

200 OK

NOTIFY

200 OK

Figure 4. 1: SIP presence service message flow

Form the standard call flow of the presence service as depict in figure 4.1, we can see that presence service can produce high amount of signaling traffic even if there is no application carrier traffic (e.g. IM, PTT) [4‐1], as one presentity state change will result in several notification messages to watchers. A traffic representation for presence service is offered in [4‐1] and it illustrates that presence service correlated load on Call Session Control Function (CSCF) could be 50% or more of the whole signaling load it manages. That traffic load has huge impact on IMS network performance and it is important to control signaling traffic load through different systems [4‐6]. An admission control mechanism is offered to organize watcher’s subscription time so that traffic load can be reduced [4‐7]. Whereas reducing traffic load is a significant technique to get better

31 Quality of a presence service, activities of components in the service system have more impact. End‐to‐End delay dimension for IM relay nodes has been studied in [4‐8] and an optimization model is offered to reduce delay with respect to the relay node throughput, utilization and buffer volume. Although end‐to‐end delay analysis if presence service is enviable, it will be very good for operators or PS developers to be familiar with system behavior in terms of heavy traffic and that are performance bottlenecks.

The operators should be aware of the traffic load distribution and its impact on the product’s performance, need to know matters interrelated with network sizing before set up service and what is the bottleneck of the service.

Network sizing in very important to make sure that adequate bandwidth and resources are obtainable to carry and process mission critical traffic. From the alcate‐Lucent study paper [4‐2] we can see big portion of the traffic load to the PS is generated form NOTIFY message, which are applied to inform the watcher of a presentity that presentity has change its status. Therefore we study a mathematical model to explain the processing of NOTIFY message within the presence server.

4.2 SIP presence architecture

Figure 4.2 illustrate the SIP presence architecture. We will describe the scenario very shortly.

Publish Subscribe

Bob watcher PUA

` PUA Alice Presentit Presence Server

Cynthina PUA Watcher

Figure 4.2: SIP presence architecture

From the figure we can see there are five scenarios.1) Alice presentity 2) PAU 3) presence agent 4) Bob/Cynthia. Here,

32 . Alice is the publisher whose presence information will be published by PAU to the presence server.

. PAU is the user’s presence user agent.

. Presence agent is a presence server which is liable for handling presence information.

. Bob/Cynthia is watcher who subscribe from PS to information on Alice’s presentity.

4.3 Analysis of presence server traffic load

Presence service replicates the user’s update status; user’s behavior model is highly related with the traffic load to a PS. The logoff/ login time, online behavior, and the number of contacts everything have great impact on the traffic load to a presence server. Each and every SIP request message to a presence server can raise generating a transaction and the amount of transactions processed by a SIP server is a key parameter that establishes the presence server capability [4‐9]. The process fixed cost needed by a presence server to process transactions is different. Suppose when a user logs in first PUBLISH message is sent to a presence server, as a result in some authentication process and the formation of a latest SIP transaction to organize some information; when the user changes his state and send the modifying PUBLISH message; the presence server simply require to recover the information stored throughout processing of previous transaction and much less overhead in needed. User actions invoke SIP messages as following:

User Login and Logout:

A user’s login creates a first PUBLISH message to the presence server, after that refresh PUBLISH messages are produced occasionally and lastly a terminating PUBLISH message is sent to the presence server upon the user’s logout.

Presence Subscription:

Subscription of a user presentity causes in a first SUBSCRIBE message being sent to the presence server. After that refresh SUBSCRIBE messages will be sent to the presence

Server. A finishing SUBSCRIBE message follows at last to unsubscribe the other user’s presentity.

33 Presence Status Updates:

The change of user’s status effects in a modifying PUBLISH message.

Traffic type: Traffic to a presence server is separated in to eight types: initial publish, refresh publish, modify publish, terminal publish, initial subscribe, refresh subscribe, terminal subscribe and notify [4‐2]. Process time of each traffic type is different

From a reference implementation [4‐2] we can see that NOTIFY message have huge impact on traffic load to a presence server also to the IMS core network, and its arrival rate differ greatly with the time of a day. So controlling NOTIFY message also optimizing their process method is significant to assurance performance of presence servers. In the next sections we will study the NOTIFY message process system in a presence server to ensure service quality.

4.4 Mathematical Analysis

In this part we are going to analyze the queuing mechanism of NOTIFY message in a presence server and calculate performance parameters of the mechanism. A presence server stores its user’s status and a user status can be subscribed by various watches. Once a user has change his status, A PUBLISH message is sent to the presence server and the presence server reply the PUBLISH message with a 200 ok message, then NOTIFY message are programmed to be sent to the all online watcher who have subscribed for this user’s status. We can denote the total number of watcher of a user Nw and the number of online watchers for this user can be denoted as nw≤ Nw.

Figure 4.3 shows the procedure that when a user sends a PUBLISH message, and nw NOTIFY message are generated. Assume that the arrival process of PUBLISH message verifies to Poisson distribution with parameter λp and the PUBLISH message process time verifies to exponential distribution then form the reference [4‐10], the outgoing process of 200 ok message is as well Poisson distribution with parameter λp. The arrival procedure of NOTIFY messages is batch Poisson distribution by parameter λp. And batch

Number nw.

34

p

PUBLISH 2000K

p

NOTIFY

p nw

Figure 4. 3: Publish and Notify Queues in a PS.

As quick as possible 200 ok messages are sent to the user to stop message re‐transmission. But NOTIFY messages are normally sent periodically with time period T. because of several traffic control requirements. Now we going are sent periodically and if the queue do not have any NOTIFY messages, the server to study queuing mechanism of NOTIFY messages as it has a great impact on the traffic load of a presence server.

Queuing System with Controlled Vacation and Batch Poisson Arrival:

From the earlier description, queue of NOTIFY messages can be seen as a queuing system with controlled vacation and batch Poisson arrival. That means NOTIFY message organizing the NOTIFY queue will be on vacation. When the vacation will be finished after the time interval T, NOTIFY message in the queue will be sent. For all PUBLISH message effects in multiple NOTIFY messages to separate watchers, the arrival procedure to NOTIFY queue is in the batch of nw.B is the highest quantity of messages that can be buffered NOTIFY queue and once the buffer is full, arriving messages are discarded. We can make the statements for the NOTIFY queue system shown in the figure 4.3.statements is given below:

1) NOTIFY messages appear at the system following to Poisson process, parameter is λp and only one server in the system.

2) Service time a NOTIFY message is supposed to be exponentially distributed by mean

1/µ.intesity of traffic is ρ= (λp nw)/ λp < 1.

35 3) Once the queue turn into empty, the server starts a vacation whose length is exponentially distributed by mean T=1/θ. Upon end of a vacation, the server restarts if the queue is not clear. Or else it takes another vacation.

4) All aforesaid random variables are independent of all other

Let S (t) =0 and S (t) =1 indicate the events that the server is busy and on vacation at time t correspondingly. Define

Q (t) indicates the amount of messages in the system at time t and the maximum buffer size is B. According to Markov chain theory it follows that {Q (t), S (t), t≥0} has unique equilibrium distribution [4‐2].

Setting,

Figure 4.4 describe the state transition graph for the NOTIFY message queue with batch arrival and controlled vacation. For the simplicity of analysis we assume that B is divided by nw. from figure 4.4 we find the following state transition equation:

36 (1)

(2)

(3)

(4)

(5)

(6)

(7)

(8)

These linear equations (1) to 30 is indicated as model M. the propensity’s status is noticed to watches by notify message and it is unwanted if notify messages are missing unpredictably and user get wrong state information. So it’s very significant to manage queue length of NOTIFY to control the message loss probability. The probability that a message can arrive and there are more than K message in the buffer is:

37

     

(1,0) (2,0) … (nw,0) (nw + 1,0) (nw+2,0) … (2nw,0) … (B ‐ nw,0) … (B,0)

     

     …. 

(0,1) (1,1) (2,1) … (nw,1) (nw+1,1) … (2nw,1) …. (B‐nw, 1) … (B,1)

   

Figure 4.4: State Transition Graph for Queue System with Batch Arrival and Controlled Vacation.

The probability of the buffer can be full is: PB = pB,1 + pB,0

Mean of queue length is:

Variance of queue length is:

38 With B=100, λp=1, nw= 4, µ=6, from reference [4‐2] we get p j, 0, j=0,..... B and p j, 1, j=1,..... B for θ= ½ , 1/6, 1/10.in the reference [4‐2] figure 7 gives the distribution of queue length with different vacation interval T=1/θ. With the longer vacation time, the variation of queue length becomes bigger. From the figure 8 in reference [4‐2] we can see the calculated result for mean and variance of the length of queue also the probability of queue length get bigger than 80% of the buffer capacity. Figure 8 in reference [4‐2] shows that the longer vacation time, the longer the queue length, and the larger the probability of queue length greater than 80%B.

This model M is pretty perfect description of the notify message queue but it is a little complex system like it’s difficult to get a close form of expression. It’s possible to further study other simple to model to get a control timer value to meet the performance requirements and we can use Poisson Arrival Process to approximate the Poisson arrival process of a NOTIFY queue system to have a close form solution of the system state also parameter of the NOTIFY queue system.

39 Chapter 5 Dimension of a PoC service

5.1 Introduction

It is possible to see Push‐to‐Talk as an instant messaging with voice facilities. PoC is the first commercial execution of the IMS architecture for mobile network. Push‐to‐Talk over Cellular (PoC) is proposed to offer fast communication for business and consumers of mobile network. PoC will permit user data and voice communication shared with one recipient that is one‐to‐one or between group’s recipients that is one‐to‐many. Such as in figure 5.1

Figure 5. 1: Example of PoC 1 to many Group session (voice transmission)[5‐4]

The main focus of this chapter is following:

40 1. Offering access priority to special sessions that is based on existing RTUs (Transmit/ Receive unit)

2. Optimizing the session timer for PoC controller.

3. During busy hour, optimize the number of session initiation for a PoC client.

We would like to dimension the PoC controller that is based on the hypothesis that is provided by the network grade of service [5‐1]. By this way PoC server could control PoC functionalities.

5.2 Proposed Access priority Model

By usages of GPRS in PoC have two main scenarios:

1. Short interactive session (type 1)

2. Long session with sporadic, interactive talk periods. (Type 2)

The main difference between two talks is that one contains chat session after a long interval inside a single session. And other one required to the distinct sessions for every

Steps need to be performed are:

1. paging in which the PoC server provide the location of the PoC terminal on the cell level.

2. Cell Update by which the terminal tells the PoC server in which specific cell it is located.

3. Radio resource assignment methods that are the part of session set up method.

4. PoC signaling.

Surely the long session will favor a pre‐established session than on demand session set up. In this report we focus the access priority for these two kinds of session set up. Priority is provided by demand session set up depends on amount of available TRUs. Type 2 (pre‐ established) sessions is not suitable through busy hour where as type 1(on demand) session is preferable to use any TRU. Let type 2 sessions could use a specific time slot when total amount of busy TRU is less than some protection level of number b.

41

1 2  N

0 1 2 … b b+1 … N

1+2 1

Figure 5. 2: Markov model for accessing session

The markov model state change with probabilities is depicted in figure 5.2.

Here,

K= the number of sessions that is presented by PoC server 1, 2.

μk= arrival and service rate of type 1 and type 2 sessions at state k respectively. Depends on the above markov mode we can calculate the blocking probability of sessions and preferred threshold level.

5.3 Proposed Timer

A usual PoC session should not go beyond 40 second in busy hour [5‐2]. In this part our purpose is to control lifetime of the PoC sessions for a PoC controller.

Define, q(x) = the probability that x number of times a PoC session goes throughout a time slot of TRU through time interval T. p = the probability of all time slots are busy through the interval T. t = a time slot duration (20 ms)

N = total amount of TRUs

We find,

42 P= (1)

Given that a session is active through the entire interval T. the Poisson distribution q(x) is

q(x)= (2)

A session can go through any of the N TRUs in a PoC server. So

q(x)<= ( ) (3)

We get from equation (1) and (3) =>

(4)

with the taylor series ,

(5)

So we find,

(6)

43 From the avobe expression we can see it is clear that the expression offers a relation between blocking probability and the session timer.

5.4 Proposed Model to Optimize Simultenious Sessions

In this part our main purpose is to control the amount of simultenious sessions for a PoC client through rush hour.while, northstream report recommend that cost analysis depends on time slots of PoC server genarate same outcomes as that of TRUs, we think our next analysis depends on amount of time slots. Gilbert’s model have describe that a plain two‐ state markov chain can calculate packet loss over the internet efficiently. We will use same concept to calculate the number the optimal session for a PoC client.

The two state natures of figure 5.3 and 5.4 can calculate the bursty nature of the amount of simultanious sessions in rush hour. Figure 5.3 shows the model has two state and that is blocking or busy and not busy. H1 and H2 are the transition probabilites state [5‐3].

H1

1-H1 1-H2

Not busy Blocking H2

Figure 5. 3: Markov model for PoC server states

The PoC server reaches to blocking state 0, when every channels or time slots are busy at a random point of time that is possible to calculate from Erlang’s method. In this state amount of session arrival in the server is larger than 5NT.where NT is the total amount of time slots. Suppose that a time slots give out 5 PoC sessions at the same time on the average.

44 = (.7)

Where a = the total traffic offered.

We assume, the service grade H2 is provided. It goes to not busy state 1.if there is only one time slot is available it is possible to calculated form Binomial distribution. When the server is in the state 0 every new session will be blocked. A successful session establishment is only depends on the current state. Because of the throttled nature of the PoC sessions, a session alter between idle and busy, the presented traffic per session is let,

α= total traffic offered

λ= total arrival rate

µ= total service rate

(8)

The statistical analysis describes that the voice activity factor has found to be 67 % [5‐2].

So we can say that 33% of a conversation is interrupted.

In the case of non busy state,

(9)

The transition between two states happens at each session establishment or termination. Thus in the case of steady state,

P (0) + P (1) = 1 (10)

The state transmission matrix is given by

45

(11)

The session blocking is same as the state probability P (0). In the same way the probability of successful session establishment is same to the state probability P (1). Figure 5.4 shows the nature of a session initiation condition of a PoC client. State A

Characterizes a client initiating one session and state B stand for multiple session initiation.

I1 and I2 are the transition probabilities. The probability that a PoC client initiates a session that is the mean arrival rate of a PoC Client and this is

H1

1-H1 1-H2

Not busy Blocking H2

Figure 5. 4: session states of a PoC Client

= = (12)

Where Nc is the number of PoC clients being served by a PoC server.

The probability of a simultaneous session initiation of PoC clients through the known period T can be measured by

= 1 Pr

46 (13)

Here ts = PoC clients session life time.

P (A) +P (B) =1 (14)

The state transition Matrix:

(15)

As the PoC server going to busy state based on total number of sessions, we suggest to

Concatenate two models to calculate the simultaneous sessions which will lead the PoC server for the optimal value.

47 Chapter 6 Conclusions and future work

The development of IP Multimedia Subsystem introduced new multimedia oriented communication service through cooperating telecom with data on access free IP core network. The junction of data, voice and video has enlarged the demand for the service with new presentation characteristics. The customer expectation has increased from service provider due to the new technology. In our thesis we have introduced the queuing mechanism of NOTIFY message in presence server and evaluate its performance parameter. The presence server is a central part in IMS architecture. The presence server performance is vital for almost all applications in IMS. In this thesis our study presents NOTIFY message is mainly responsible for big portion of traffic load in presence server. Here we have use mathematical model to describe queue length distribution of NOTIFY message. There are still lots of work for further study here we only think one service policy but in case of real system there are many variation.

We have also explained different optimal characteristics to dimension a PoC server. If we see from cost point of view, in the whole service delivery chain optimized expertise required for deployment. A service provider can be easily benefited from the models which we have discussed in chapter 5. Proposed models are fine‐tuned to implement in IP Multimedia Subsystems to provide resourceful PoC service to IMS terminals. We can further study about the case of prioritizing and classifying PoC traffic in expressions of session dropping probabilities.

In the other area of this thesis explore different model for IMS session set up in mobile environment, introduction to IMS and basic architecture of IP multimedia subsystems. Expansion of IMS architecture needs a meticulous change in the existing network of service providers. Service provider should be monitor and optimize the network performance to meet up the assurance levels of service committed to there customers. Service providers should be model and dimension their network to estimate trends in the network before deploying it.

48 Our future work can be focus on queuing mechanism for signaling part in IMS environment and performance evaluation by using simulations.

49 References:

[1‐1] Introduction to IP Multimedia Subsystem (IMS), Part 1: SOA Parlay X Web services The Next Generation Network architecture for Telecom industry

Rebecca LJ Chen ([email protected]), Staff Software Engineer, IBM Taiwan

Elisa CY Su ([email protected]), Staff Software Engineer, IBM Taiwan

Victor SC Shen ([email protected]), Software Engineer, IBM Taiwan

Yi‐Hong Wang ([email protected]), Software Engineer, CSDL, IBM Taiwan

[1‐2] The IP Multimedia Subsystem in next generation networks. Gilles Bertrand, may 30 2007

[1‐3] UMTS Forum, “Ranking of top 3G services,”UMTS forum, Tech. Rep., 2001

[1‐4] G. Camarillo and M. A. Garcia‐Martin, The 3GIP Multimedia Subsystem ‐ merging the internet and the cellular worlds. John Wiley & sons, Ltd, 2004.

[1‐5] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, “RFC 2543: SIP: Session Initiation Protocol,” IETF, Tech. Rep., 1999. [Online]. Available: www.ietf.org/rfc/rfc2543.txt

[1‐6] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, “RFC 3261: SIP: Session Initiation Protocol,” IETF, Tech. Rep., 2002. [Online]. Available: www.ietf.org/rfc/rfc3261.txt

[1‐7] M. Handley and V. Jacobson, “RFC 2327: SDP: Session Description Protocol,” IETF, Tech. Rep., 1998. [Online]. Available:www.ietf.org/rfc/rfc2327.txt

[1‐8] F. Cuervo, N. Greene, A. Rayhan, C. Huitema,B. Rosen, and J. Segers, “RFC 3015: Megaco Protocol Version 1.0,” IETF, Tech. Rep., 2000.[Online]. Available: www.ietf.org/rfc/rfc3015.txt

[2‐1] The importance of standard IMS architecture, Rakesh Khan Delwal consultant, and tata consultancy services Limited.

[2‐2] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnson, J. Peterson, R. Sparks, M. Handley, and E. Schooler. The session initiation protocol (SIP) RFC 3261. Internet

50 Engineering Task Force, 2001.

[2‐3] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real‐Time Applications", RFC 1889, January 1996.

[2‐4] Schulzrinne, H., Rao, R. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.

[2‐5] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B. and J. Segers, "Megaco Protocol Version 1.0", RFC 3015, November 2000.

[2‐6] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.

[2‐7] The Internet Engineering Task Force, Network working group. J.Rosenberg, dynamicsoft,H. Schulzrinne,Columbia U.,G. Camarillo, Ericsson,A. Johnston, WorldCom,J. Peterson, Neustar, R. Sparks, dynamicsoft, M. Handley, ICIR, E. Schooler, AT&T, June 2002

[3‐1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[3‐2] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R. and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000.

[3‐3] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R. and A. Sastry, "COPS usage for RSVP", RFC 2749, January 2000.

[3‐4] Hamer, L‐N., Gage, B., Kosinski, B. and H. Shieh, "Session Authorization Policy Element", RFC 3520, April 2003.

[3‐5] Handley, M. and V. Jacobson, "SDP: session description protocol," RFC 2327, April 1998.

[3‐6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.

[3‐7] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation protocol (RSVP) ‐‐ version 1 functional specification," RFC 2205, September 1997.

[3‐8] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.

51 [3‐9] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K., Herzog, S., Reichmeyer, F., Yavatkar, R. and A. Smith, "COPS Usage for Policy Provisioning (COPS‐PR)", RFC 3084, March 2001.

[4‐1] Carlos Urrutia‐Valds, Amit Mukhopadhyay, and Mohamed El‐Sayed,“Presence and Availability with IMS: Applications Architecture, Traffic Analysis, and Capacity Impacts”, Bell Labs Technical Journal 10(4),2006, 101 − 107.

[4‐2] IMS Presence Server : Traffic Analysis and Performance Modelling C. Chi Bell Laboratories, Alcatel‐Lucent chic@alcatel‐lucent.com ,R.Hao Bell Laboratories, Alcatel‐ Lucent rbhao@alcatel‐lucent.com , D.Wang Bell Laboratories, Alcatel‐Lucent wangd@alcatel‐lucent.com , Z. Cao Institute of Information Science Beijing Jiaotong University caozhenzhen1983@gmail

[4‐3] 3rd Generation Partnership Project, “Presence Service Based on Session Initiation Protocol; Functional Models, Information Flows and Protocol Details (Release 6)”, 3GPP TR 24.841, June 2004, .

[4‐4] M. Day, S. Aggarwal, G. Mohr, and J. Vincent, “Instant Messaging/Presence Protocol Requirements”, IETF RFC 2779, Feb.2000,.

[4‐5] A. B. Roach, “Session Initiation Protocol (SIP)ł Specific Event Notification”,IETF RFC 3265, June 2002, .

[4‐6] M.Pous, et.al.“Performance Evaluation of a SIP Based Presence and Instant Messaging Service For UMTS”, The Institution of Electrical Engineers. 254 − 258.

[4‐7] Muhammad T. Alam,Zheng Da Wu, “Admission Control Approaches in the IMS Presence Service”, INTERNATIONAL JOURNAL OFCOMPUTER SCIENCE VOLUME 1 NUMBER 4 2006 ISSN 1306‐4428,299 − 314.

[4‐8] Muhammad T. Alam,Zheng Da Wu,“End‐to‐End Delay Measurement for Instant Messaging Relay Networks”, .

[4‐9] Henning Schulzrinne, Sankaran Narayanan and Jonathan Lennox, “SIPstone ‐ Benchmarking SIP Server Performance”,

52 support/whitepapers/sipstonebenchmarking‐sip‐server‐performance>

[4‐10]Hayes, Jeremiah F., Chapter 7 in “Modeling and Analysis of ComputerCommunications Networks”, 1984 Plenum Press, New York.

[5‐1] Kim P., Balazs A., Broek E., Kieselmann G., Bohm W. (2005). “IMS‐based Push‐to‐Talk over GPRS/UMTS” IEEE Wireless Communications and Networking Conference, Vol 4, pp: 2472‐2477.

[5‐2] Proposed Techniques to Dimension aPush‐To‐Talk over Cellular Server

Muhammad T. Alam_ Zheng da Wu†

[5‐3] Gilbert, E. N. (1960). “Capacity of a burst‐noise channel,” Bell Syst. Tech. J., vol. 39, pp: 1253‐1265.

[5‐4] OMA, Open Mobile Alliance. Push to talk over Cellular (PoC)‐Architecture.

Push to Talk Over Cellular Working Group. 2005; URL: http://www.openmobilealliance.org.

53 Appendix A Abbreviations

IMS IP Multimedia Subsystem

NGN Next Generation Networking

3GPP 3rd Generation Partnership Project

SIP Session Initiated Protocol

QoS Quality of Service

ToIP Telephony over IP

SDP Session Description Protocol

COPS Common Open Policy Service

PIB Policy Information Base

MGCP Media Gateway Control Protocol

RTP Real Time Protocol

RTCP Real Time Control Protocol

CAC Connection Admission Control

PoC Push‐to‐Talk over Cellular

CSCF Call Session/Control Function

HSS Home Subscriber Server

AS Application Server

MRF Media Resource Function

PSTN Public Switched Telephone Network

BGCF Breakout Gateway Control Function

54 SLF Subscriber Location Function

URI Uniform Resource Identifier

RSVP Resource Reservation Protocol

PDP Policy Decision Point

PS Policy Server

ER Edge Router

EH End Host

PEP Policy Enforcement Point

RCD Resource Control Domain

SCD Service Control Domain

55 Appendix B

The explanation of equations, we have calculated from figure 4.4(State Transition Graph for Queue System with Batch Arrival and Controlled Vacation) are following:

Initially, probability of state λp0,1, Equal to probability of state μp1,0 in a Possion process.

Possion distribution with time variation.

When notify queue is full message is discarding.

From the state diagram, For each PUBLISH message results in multiple NOTIFY messages to different watchers, the arrival process to NOTIFY queue is in the batch of nw.

nw online watchers, nw NOTIFY messages are generated. The arrival process of NOTIFY messages is batch Poisson distribution with parameter λp and batch number nw

when queue is full the message are discarding.

Summation of the probability of Queuing System with Controlled Vacation and Batch

Poisson Arrival is equal to 1.

56