IPTV Charging in the IP Multimedia Subsystem

i

IPTV Charging in the IP Multimedia Subsystem

Prepared by:

Joyce B. Mwangama

Supervised by:

Neco Ventura

Submitted to the Department of Electrical Engineering in partial fulfillment of the

requirements for the degree of Bachelor of Science in Electrical and Computer

Engineering at the University of Cape Town

October 2008

i

Declaration

I declare that this undergraduate thesis, IPTV Charging in the IP Multimedia Subsystem, is my own

work. All sources that I have used or quoted have been indicated and acknowledged in the

references. This work has not been submitted to any other university for any other degree or

examination.

Joyce B. Mwangama Date

ii

Acknowledgements

I would like to thank the following individuals for their help during the course of this project.

My parents, thank you for always believing in me.

Mr. Neco Ventura, for his supervision and guidance throughout the duration of this project.

Richard Spiers for his invaluable advice and assistance throughout the project.

Communications Research Group members Richard Good, Lesang Dikgole and Tapfuma Mvere for

their much appreciated guidance and assistance

Robert Marston and previous PhD student David Waiting for the development of the UCT IPTV

Application Server, without which this project would not have been possible.

All my closest friends and most cherished loved ones for all their encouragement and support.

iii

Abstract

With the emergence of next generation networks, the availability of higher bandwidth connections

and better quality of service, it is becoming more plausible for service providers to offer improved

applications and services. Furthermore, the emergence of the IP Multimedia Subsystem has provided

network operators with an effective service delivery platform that is designed to allow for rapid

service development. One key service of interest is IPTV, which is seen as the transfer of digital

video and audio over an IP based network.

While the importance of rapid and efficient service development cannot be stressed enough, another

equally important aspect of service development is the charging mechanisms that will be associated

with the service. This is of the utmost importance if service providers want to generate sustainable

revenue for an offered service that will leave them competitive in the market and still be able to

turnaround a substantial profit.

Charging for any service is complex within the IMS as most services rely on different charging

models to suit their implementation. This complexity is further increased when considering charging

models for IPTV systems as other factors such as QoS and third party media vendors are brought

into play. Considering all this and including the fact that the charging system should be efficient

enough for the network operator to see profits from deployment, as well as flexible enough so as to

cater for the users charging requirements, a charging system for IPTV in the IMS was designed and

developed.

The system developed comprises of an Application Server that is capable of detecting chargeable

events relating to users and has the ability to contact the charging functions upon the occurrences of

these events. Also included in the system implementation is the development of both offline and

online charging functions and the reference points that interconnect all the different modules.

This system was evaluated to highlight the fundamental functionality of the charging system. The

system takes into consideration the lengths at which users utilize the IPTV service. Charging credits

are allocated to a specific period of time, providing a fair charging system to the user.

iv

Table of Contents

IPTV CHARGING IN THE IP MULTIMEDIA SUBSYSTEM ............................................................................. I

DECLARATION ......................................................................................................................................................... I

ACKNOWLEDGEMENTS ....................................................................................................................................... II

ABSTRACT .............................................................................................................................................................. III

TABLE OF CONTENTS ......................................................................................................................................... IV

GLOSSARY .............................................................................................................................................................. XI

CHAPTER 1 INTRODUCTION .............................................................................................................. 1

1.1 PROBLEM DEFINITION ......................................................................................................................... 2

1.2 THESIS OBJECTIVES ............................................................................................................................ 3

1.3 SCOPE AND LIMITATIONS OF REPORT .................................................................................................. 4

1.4 THESIS OUTLINE .................................................................................................................................. 5

CHAPTER 2 RELATED WORK ............................................................................................................ 7

2.1 NGN CHARGING ARCHITECTURES ....................................................................................................... 7

2.1.1 ITU-T NGN – Accounting for NGN services ........................................................................... 7

2.1.2 3GPP charging standards ....................................................................................................... 8

2.1.3 IETF......................................................................................................................................... 9

2.2 IMS CHARGING SOFTWARE ................................................................................................................. 9

2.2.1 OpenBlox ................................................................................................................................. 9

2.2.2 Intec ....................................................................................................................................... 10

2.3 IPTV CHARGING IMPLEMENTATIONS ................................................................................................. 10

2.3.1 ITU – Focus Group on IPTV ................................................................................................. 10

2.3.2 K. Casier et. al....................................................................................................................... 11

CHAPTER 3 BACKGROUND TO THE THESIS............................................................................... 13

3.1 INTRODUCTION TO IMS .................................................................................................................... 13

3.2 INTRODUCTION TO IPTV AND VOD ................................................................................................. 14

3.3 INTRODUCTION TO AAA................................................................................................................... 15

3.3.1 Authentication ....................................................................................................................... 15

v

3.3.2 Authorization ......................................................................................................................... 15

3.3.3 Accounting ............................................................................................................................. 15

3.4 BACKGROUND TO PROJECT............................................................................................................... 16

CHAPTER 4 IMS AND IPTV ................................................................................................................ 17

4.1 IMS ARCHITECTURE ......................................................................................................................... 17

4.1.1 Transport Layer .................................................................................................................... 18

4.1.2 Control Layer ........................................................................................................................ 18

4.2 PROTOCOLS IN THE IMS ................................................................................................................... 22

4.3 SIP ................................................................................................................................................... 22

4.3.1 Diameter ................................................................................................................................ 23

4.4 IPTV AND VOD OVER IMS .............................................................................................................. 24

4.4.1 IMS-based IPTV architecture ................................................................................................ 24

4.4.2 IPTV Service Control Functions............................................................................................ 26

4.4.3 IMS-based IPTV services ....................................................................................................... 26

4.4.4 IPTV AS ................................................................................................................................. 26

4.4.5 IMS-based IPTV in action ..................................................................................................... 27

CHAPTER 5 CHARGING AND AUTHENTICATION ...................................................................... 28

5.1 3GPP CHARGING ............................................................................................................................. 28

5.2 CHARGING IN THE IP MULTIMEDIA SUBSYSTEM ................................................................................ 29

5.2.1 Offline charging .................................................................................................................... 30

5.2.2 Online charging..................................................................................................................... 31

5.3 THE CHARGING PROTOCOL IN THE IMS - DIAMETER ........................................................................ 32

5.3.1 Format of a Diameter Message ............................................................................................. 34

5.3.2 Attribute Value Pairs ............................................................................................................. 36

5.3.3 Diameter base protocol commands ....................................................................................... 37

5.3.4 Diameter Base Protocol AVPs............................................................................................... 38

CHAPTER 6 AAA INTERFACES IN THE IMS ................................................................................. 40

6.1 THE SH INTERFACE ........................................................................................................................... 40

6.1.1 Command Codes Defined in the Diameter Application for the Sh Interface ........................ 41

6.2 THE RF INTERFACE ........................................................................................................................... 46

6.2.1 Command Codes Defined in the Diameter Application for the Rf Interface ........................ 46

6.3 THE RO INTERFACE .......................................................................................................................... 50

6.3.1 Immediate Event Charging.................................................................................................... 51

vi

6.3.2 Event Charging with Unit Reservation ................................................................................. 52

6.3.3 Session Charging with Unit Reservation .............................................................................. 53

CHAPTER 7 IPTV CHARGING DESIGN ........................................................................................... 56

7.1 ADHERING TO 3GPP DEFINITIONS AND STANDARDS ......................................................................... 56

7.1.1 Charging Guidelines for the IMS .......................................................................................... 56

7.2 IMS TESTBED ................................................................................................................................... 57

7.3 CHARGING TRIGGER FUNCTION ........................................................................................................ 58

7.4 THE OFFLINE CHARGING FUNCTION ................................................................................................. 59

7.5 THE ONLINE CHARGING FUNCTION................................................................................................... 59

7.6 THE CHARGING SYSTEM INTERFACES ............................................................................................... 59

CHAPTER 8 IPTV CHARGING IMPLEMENTATION .................................................................... 61

8.1 UCT ADVANCED IPTV SOFTWARE ................................................................................................... 61

8.2 ADDED INTERFACES ......................................................................................................................... 64

8.2.1 AS HSS ............................................................................................................................. 64

8.2.2 AS CDF ............................................................................................................................ 65

8.2.3 AS OCF ............................................................................................................................ 65

8.3 C DIAMETER PEER............................................................................................................................ 66

CHAPTER 9 RESULTS ......................................................................................................................... 68

9.1 SYSTEM ARCHITECTURE ................................................................................................................... 68

9.2 TESTING FOR PERFORMANCE............................................................................................................. 69

9.3 TESTING FOR CONFORMANCE ........................................................................................................... 70

9.3.1 Evaluating offline charging................................................................................................... 70

9.3.2 Evaluating online charging ................................................................................................... 74

CHAPTER 10 CONCLUSIONS AND RECOMMENDATIONS ....................................................... 78

10.1 CONCLUSIONS.............................................................................................................................. 78

10.2 RECOMMENDATIONS AND FUTURE WORK ................................................................................... 79

REFERENCES .......................................................................................................................................................... 81

APPENDIX A: ........................................................................................................................................................... 83

HOW TO INSTALL THE DIAMETER ENABLED SIP IPTV AS ........................................................................................ 83

CONFIGURE THE FHOSS........................................................................................................................................... 83

SETUP XML FILE THAT MAPS CHANNEL REQUESTS TO RTSP ADDRESSES ................................................................. 84

vii

SETTING UP A 3RD PARTY RTSP ENABLED MEDIA SERVER ...................................................................................... 85

SET UP XML FILE THAT ALLOWS THE SERVER TO LOCATE DIAMETER PEERS ............................................................. 86

APPENDIX B: ........................................................................................................................................................... 88

APPENDIX C: ........................................................................................................................................................... 92

viii

List of Figures

Figure 1.1: IPTV in IMS ....................................................................................................................... 3

Figure 4.1: IMS Functional Architecture ............................................................................................ 18

Figure 4.2: IMS-based IPTV Architecture .......................................................................................... 25

Figure 5.1: Charging in the IMS ......................................................................................................... 29

Figure 5.2: Offline Charging in the IMS ............................................................................................. 30

Figure 5.3: Online Charging in the IMS ............................................................................................. 32

Figure 5.4: Diameter Base Protocol and Applications........................................................................ 33

Figure 5.5: Format of a Diameter Message......................................................................................... 35

Figure 5.6: Structure of an AVP ......................................................................................................... 36

Figure 6.1: UDR and UDA Messages ................................................................................................. 42

Figure 6.2: PUR and PUA Messages .................................................................................................. 43

Figure 6.3: SNR, SNA, PNR and PNA Messages .............................................................................. 44

Figure 6.4: Event Based Offline Charging .......................................................................................... 48

Figure 6.5: Session Based Offline Charging ....................................................................................... 49

Figure 6.6: IEC Direct Debiting .......................................................................................................... 52

Figure 6.7: ECUR for Event Based Online Charging ......................................................................... 53

Figure 6.8: SCUR for Session Based Credit Control .......................................................................... 54

Figure 7.1: IPTV Charging Architecture ............................................................................................ 60

Figure 9.1: (1) Requirement in AS...................................................................................................... 71

ix



Figure 9.4: (4) Requirement in CDF ................................................................................................... 72




Figure 9.8: (8) and (9) Requirements in AS ....................................................................................... 74


Figure 9.10: (3) Requirement in AS ................................................................................................... 75

Figure 9.11: (4) Requirement in OCF................................................................................................. 75




Figure 9.15: (8) and (9) Requirements in AS ..................................................................................... 76


x

List of Tables

Table 5.1: Command Codes of Base Protocol .................................................................................... 38

Table 6.1: List of Commands for Sh Interface .................................................................................... 41

Table 6.2: AVPs defined for Sh Interface ........................................................................................... 45

Table 6.3: Mandatory AVPs defined for Rf Interface ......................................................................... 47

Table 6.4: AVPs Defined for Ro Interface .......................................................................................... 50

Table 8.1: Contents of an ACR message............................................................................................. 62

Table 8.2: Contents of a CCR message ............................................................................................... 63

Table 9.1: Delays in message processing ............................................................................................ 70

xi

Glossary

2G 2nd Generation

3G 3rd Generation

3GPP 3rd Generation Partnership Project

3GPP2 3rd Generation Partnership Project 2

AAA Authentication Authorization and Accounting

ABMF Account Balance Management Function

AS Application Server

AVP Attribute Value Pair

B2BUA Back to Back UA

BGCF Border Gateway Controller Function

CCF Charging Collection Function

CDF Charging Data Function

CDMA Code Division Multiple Access

CDR Charging Date Record

CGF Charging Gateway Function

CoD Content on Demand

CSCF Call Service Control Function

CTF Charging Trigger Function

xii

DHCP Dynamic Host Configuration Protocol

DNS Domain Name System

DSL Digital Subscriber Line

EPG Electronic Programme Guide

GPRS General Packet Radio Service

GSM Global System for Mobile communications

HSS Home Subscriber Server

HTTPS Hypertext Transfer Protocol over Secure Socket Layer

I-CSCF Interrogation CSCF

IETF Internet Engineering Task Force

IM Instant Messaging

IMS IP Multimedia Subsystem

IM-SSF IP Multimedia Service Switching Function

IP Internet Protocol

IPTV Internet Protocol Television

IPv4 Internet Protocol version 4

IPv6 Internet Protocol version 6

ITU International Telecommunication Union

ITU-T ITU Telecommunication Standardization Sector

MCF Media Controller Function

xiii

MDF Media Discovery Function

MGCF Media Gateway Controller Function

MRF Media Resource Function

MRFC Media Resource Function Controller

MRFP Media Resource Function Provider

NGN Next Generation Network

OCF Online Charging Function

OCS Online Charging System

OSA Open Service Access

P-CSCF Proxy CSCF

PDF Policy Decision Function

PSTN Public Switched Telephone Network

QoS Quality of Service

RF Rating Function

RFC Request for Comments

RTP Real-time Transport Protocol

RTSP Real Time Streaming Protocol

SCS Service Capability Server

S-CSCF Serving CSCF

SDF Service Discovery Function

xiv

SIP Session Initiation Protocol

SLF Subscriber Location Function

SSF Service selection Function

TCP Transmission Control Protocol

TISPAN Telecoms & Internet converged Services & Protocols for Advanced

Networks

UA User Agent

UDP User Datagram Protocol

UMTS Universal Mobile Telecommunications System

URI Uniform Resource Identifier

VoD Video on Demand

VoIP Voice over IP

WCDMA Wideband CDMA

WiMax Worldwide Interoperability for Microwave Access

WLAN Wireless Local Area Network

1

Chapter 1 Introduction

Digital television has been evolving for the past several years. Following recent advancements in

technology, what started out as terrestrial or satellite digital television can now be delivered over

fixed and mobile broadband networks [1]. From this evolution IP Television (IPTV) was born. It is

essentially the streaming of high quality video content over an IP network. In contrast to traditional

television, IPTV includes a whole multitude of incorporated services. Aside from the traditional

commercial-grade multicasting of television channels IPTV can also be integrated with the

following services [2]:

Video on Demand (VoD)

Voice over IP (VoIP)

Web and email access

Presence and Instant Messaging

User interaction

IPTV cannot be thought of as a single service unit; it is a mixture of communication, computing,

and content [3]. Essentially it is an integration of broadcasting and telecommunications. It is

reasonable to assume that such a service would require a high quality of service (QoS) for it to be

deployed successfully as an alternative and competitor to traditional TV systems.

In addition to the provisioning of adequate QoS another fundamental area that needs to be addressed

is the provisioning of feasible and viable billing functions for the service. This is important for the

service provider because of the potential revenue that can be made from IPTV as media content has

proved to be a popular source of entertainment to the viewing public. A trend being observed in

developing countries is that revenue generation from telecommunication services is on the decline

[4]. Traditional services such as voice and messaging are being rivalled by data services, for

example, the ability to make voice calls over the internet at much cheaper rates will result in reduced

2

average revenues per customer. Thus for network operators to remain competitive, they need to

introduce feature-rich communication and multimedia services to keep customer interest.

The IP Multimedia Subsystem (IMS) is a next generation networking architecture that provides for

interoperability between existing voice and data networks and provides multimedia services for fixed

and mobile operators. IPTV is one of the services that would attract many customers and provide

telecom operators with incredible revenue generating opportunities. [5]

1.1 Problem Definition

VoD systems allow users to request and watch video content at times of their own choosing. This

differs from television broadcasts where the schedules and viewing times of content is preset by the

service provider and which the user has no control over. VoD systems can either stream content to

the user allowing for real time viewing or the user can download the content onto a device where

they will be able to view it at a later time. VoD in this thesis will refer to the former where only

streaming is considered and no storage of content occurs at the user side.

This Thesis concerns the design and implementation of a charging system for VoD over the IMS

framework according to existing standards. Such a system would need to consider how sessions will

be initiated and how media will be streamed to the user. Another factor that also needs to be

considered is how users are authorised and authenticated to make sure that they have permissions to

view the content. Billing is an important aspect of media service provision as most content has

proprietary value.

In order to truly enhance customer experience through the provisioning of attractive multimedia

service packages like IPTV, operators will need a converged customer care and billing solution with

real-time charging capabilities. Finding a suitable billing technique to implement for an IPTV

system is quite complex. The traditional charging model previously adopted by network operators

was a subscription model where the user would be charged a fixed rate that is usage-length

independent. This does not fit in place with the IPTV paradigm as service usage would fluctuate

from user to user and allocating a fair charging scheme to all users would be impossible. Thus a

suitable charging model needs to be proposed to provide the needed flexibility to the user. The

design and implementation of such a billing solution is the scope of this thesis.

3

For the service to comply with the IMS standard it will need to conform to the architecture and

protocols involved with the network. For example the figure below shows how an IPTV server

would interact with the IMS network and the user.

IMS Client

Media Server

IPTV

Application ServerOpen IMS Core

Figure 1.1: IPTV in IMS

Currently charging in the IMS is predominantly undergoing further specification and

standardization. There is a lack of actual billing implementations of charging architectures within

the IMS. Novel approaches to IMS services charging systems are needed in order to provide

commercial success for IMS network operators.

1.2 Thesis Objectives

The IMS is a telecommunication framework that is designed to allow the rapid prototyping of

services. It contains the necessary features that allow for user authentication, QoS and billing

mechanisms. The main objective of this thesis will be to design and implement an IPTV Application

4

Server (AS) with charging capabilities that can be deployed in a suitable IMS testbed. In addition to

the AS, a set of charging functions with the capacity to handle charging within the IMS will be

implemented. The AS and the charging functions will constitute the charging system for the IPTV

service.

The objectives of the thesis are set as follows:

Design and implement a complete charging system. The charging system will consist of two

parts: an online function and an offline function. These functions will be able to provide

prepaid and post-paid charging solutions to the user.

Use an existing IPTV AS that will be enhanced to perform charging triggering functions and

communicate with the charging elements. The AS would then be able to properly allocate

service usage once the adequate charging operations have been performed.

Implement the interfaces between the AS and the billing functions to provide a secure and

efficient communication between the entities.

Evaluate the system to determine if it performs effectively. This can be done by identifying

the functional requirements of the charging systems and testing for conformance to these

requirements.

Enhance the system to allow for more user interaction on the evoking of which type of

billing occurs

To be able to implement these charging functions the Diameter base protocol and the relevant

Diameter Application Protocols will be used to achieve a billing solution that complies with the

charging architecture proposed by the 3rd

Generation Partnership Project (3GPP) for the IMS.

Research into finding a flexible and efficient charging system within the IMS is very important for

the IMS to succeed in catching the interest of telecommunication companies [6]. This thesis focuses

on this area of research and uses the VoD service to test how proposed charging architectures would

be implemented over the IMS.

1.3 Scope and limitations of report

5

Charging in the IMS can occur at many different levels and thus is handled differently depending on

the level of charging that is occurring. There is bearer-level charging which is essentially charging at

the lowest level. It occurs in circuit-switched and packet-switched domains. There is subsystem-level

charging which is the charging that occurs in the IMS. Lastly there is service-level charging.

Charging on this level occurs for different services e.g. multimedia messaging service, push-to-talk

over cellular, multimedia broadcast, and multicast service. These charging levels were specified by

the 3GPP and form the basis for charging in the IMS. Charging in the context of this thesis will

focus on service-level charging where the focus is on how the user will be charged for IPTV

services.

The scope of this project does not include the design and implementation of an IPTV or VoD server.

An existing VoD AS will be extended. This application server is the UCT advanced IPTV server.

The project will focus solely on the authorization and billing capability of service provision in the

IMS, with the service being VoD from an IPTV server.

Not in the scope of this thesis is how pricing would be implemented for the VoD service. This can be

handle many different ways and is most often left to the discretion of the operator providing the

service.

1.4 Thesis outline

The remainder of this document will be structured in the following manner:

Chapter 2 reviews related work that is relevant to the focus of the thesis. The work reviewed is

comprised of papers that present proposed architectures relevant to the thesis and implemented

charging solutions currently available.

Chapter 3 presents background information on the core topics of this project: namely the IMS,

IPTV, VoD, and AAA (Authorization, Authentication and Accounting). These are the key topics

relating to this thesis, and their relevance to the thesis is explained at the end of the chapter

Chapter 4 presents and explains the IMS; its architecture, protocols and standards. The chapter then

goes on to present IPTV and VoD and how it is implemented in practise. Lastly, an IMS based IPTV

architecture is discussed and an example of how it works is presented.

6

Chapter 5 discusses the concept of charging. This section discusses how charging within the IMS

can achieved and the standards that are specified by the 3GPP. The section then goes on to discuss

the Diameter Protocol, which is the protocol the IMS uses for AAA purposes.

Chapter 6 discusses the interfaces that that directly depend on IPTV charging within the IMS.

These are the Sh, Ro and Rf. 3GPP specifies certain protocol messages and flow of messages that

can occur over these interfaces and this section covers this in more detail.

Chapter 7 describes the evaluation framework, including the specific implementation that the

author used as a testbed. The section presents a design of the IPTV charging architecture and

highlights the functions and performance required from such a system.

Chapter 8 details how the IPTV charging design system was implemented for the practical

component of the project. Each entity developed is presented and explained to show the functional

operation of the entity.

Chapter 9 reports the results that were obtained from the evaluation of the charging system that was

implemented.

Chapter 10 presents a set of conclusions that were drawn from the design and implementation of the

IPTV charging system. The chapter also presents a set of recommendations and proposes future

work that can be applied in this area of research.

7

Chapter 2 Related work

This section reviews some of the planned or existing implementations pertaining to charging

architectures, IPTV charging systems and charging within the IMS. The section can be further

broken up into three key areas:

NGN Charging architectures

IMS Charging software

IPTV Charging implementations

2.1 NGN charging architectures

2.1.1 ITU-T NGN – Accounting for NGN services

This paper identifies the need for more research into the development of NGN charging architectures

[7]. Traditional telecommunication and internet services are known to adopt simple charging

mechanism such as fixed and flat-rate options. NGN introduces complexity to charging as a variety

of multimedia services are offered with each having diverse and complex issues pertaining to its

deployment. This makes charging difficult to implement for these services. These complexities arise

because consideration of how content delivery is provided to the end user needs to be taken. New

constraints are introduced such as multiple levels of Quality of Service or whether content is

originally provided by third party content providers, as is the usual case in IPTV where the network

operator is not the primary provider of the media content. The multitude of services results in having

many different charging models that need to cater for the different types of services offered in an

NGN network. Even more complexity is introduced when we consider that a user might be

subscribing to different services simultaneously and the network operator has to manage the user’s

account both accurately and efficiently. Some networks may even chose to have fluctuating rates i.e.

depending on the time of time of day the service was requested. All these factors emphasize the need

to develop efficient standardized charging architectures to ensure commercial success for NGN

8

networks.

This paper highlights the new types of services that can now be offered over NGN networks and

emphasizes that these services require new charging capable functions. For example the service of

interactive TV and VoD for mobile users would introduce a very complex billing environment due

to the multiple service providers that would be involved in such an implementation. Additionally,

various charging policies would need to be administered for the different service providers that could

have different billing requirements. The obvious conclusion that can be gathered from such a

scenario is that simple flat-rate and even time based charging might not be efficient enough to cater

for the system.

The paper concludes by stating that to be able to develop successful NGN networks and services,

one of the obstacles that stand in the way is finding ways to fill the gaps in charging implementation

for these networks and their services.

2.1.2 3GPP charging standards

The 3GPP has produced extensive work relating to how charging can be achieved. They produce a

numerous number of Technical Specifications that relate to all types of charging that may be

required in different types of networks. Networks include GPRS, WLAN, Fixed Broadband, Packet

Switched networks, Circuit Switched networks, the IMS and higher service level charging

implementations. Additionally, specifications are released that pertain to particular charging

scenarios to provide a more in-depth perspective to how charging should be handled at these

different levels and in different networks. Examples of specifications that relate to charging are listed

below:

Policy and Charging Control Architecture [8]

Telecommunication management; Charging management and IMS Charging [9]

Telecommunication Management; Charging Management; Online Charging System

(OCS):Applications and Interfaces [10]

Telecommunication Management; Charging Management; Diameter Charging Applications

9

[11]

Overall High Level Functionality and Architecture Impacts of Flow Based Charging [12]

The work that the 3GPP has done in providing specifications for charging architectures makes it

much easier to start developing charging systems that can be evaluated for conformance over

testbeds and ultimately deployed in a commercial context.

2.1.3 IETF

The Internet Engineering Task Force (IETF) is a non-profit global organization that develops and

promotes Internet standards. The IETF defines AAA protocols and the related information models

that can be implemented for charging purposes. These protocols are explicitly defined in their

respective RFCs. One such protocol that is used extensively for charging purposed is the Diameter

protocol defined in RFC 3588 [13]. The Diameter base protocol is intended to provide an AAA

framework for applications such as network access or IP mobility. It is also structured to provide

functionality for roaming user equipment. This specific RFC defines the base protocol and higher

level application protocols are defined in other RFCs. They are based on the functionality of the base

protocol and the required functionality needed from the application protocol.

The AAA protocol is used for most charging architecture specifications and is used extensively by

the 3GPP in its charging specifications. For this reason all charging implementations that claim

conformance to 3GPP Technical Specifications use the Diameter protocol; base protocol and

application protocols.

2.2 IMS charging software

2.2.1 OpenBlox

OpenBlox Traffix C++ and Java Diameter stack is a full implementation of the IETF diameter

protocol as specified in RFC 3588. It consists of 3GPP, 3GPP2 and ETSI diameter interfaces and

applications. The system implements both the optional and mandatory parts of the diameter protocol.

The system is divided into the base protocol and different applications such that the base protocol

will need to be implemented with a mixture of interface and application modules. These modules

10

include interface implementations for Rf, Ro, Sh, Cx, Gx and many other interfaces. OpenBlox is

continuously developing more interfaces to cater for most of the Diameter interfaces that are used in

the IMS. The software is available in a dual license as an open source and commercial product

however the C++ version of the software is not available as open source. OpenBlox claim to posses

80% of the market share in IMS charging solutions and that they are the benchmark for diameter

implementations [14].

2.2.2 Intec

Intec is a provider of business and operations support systems. They provide product solutions to

major global network operators such as AT&T, Deutsche Telekom and Virgin Mobile. They deliver

prepaid, post-paid and real time charging solutions over a single platform. They also provide

databases on which vendors can manage customer information to provide efficiency in the charging

systems. Their charging rating mechanisms allow the network operators to easily implement rating

management. One of the products that they provide is the Intec IMS charging solution. Intec claims

to have a solution that has gone through extensive interoperability testing with network equipment

manufacturers. The solution is fully compliant with 3GPP specifications and implements the

relevant functions and interfaces. They also state proven scalability, performance and reliability for

deployment and practical use. The Intec IMS charging solution caters for offline and online

charging, providing support for ease of development of the related charging functions. The Intec

IMS charging solution assures system security, rating management, account balance management

and unified accounting management with a capacity to handle roaming for the user terminal [15].

2.3 IPTV charging implementations

2.3.1 ITU – Focus Group on IPTV

This organization intends to propose a terms of reference for the network and control aspects of

IPTV [16]. IPTV network reference architecture is based on the evolution of existing

telecommunication and broadcast networks. The group identifies three different scenarios or

network environments.

IMS-based service scenario (ITU-T NGN and 3GPP) is based on the NGN architecture for

11

integrated fixed and wireless network protocols; on PSTN/ISDN protocols; IP and

3GPP/IMS protocols.

Internet-based IP TV service scenario (IETF) is based on the Internet architecture and on IP

protocols including PIM/SSM, IPv4 and IPv6.

Cable-based service scenario is based the cable TV.

The organization focuses on many important requirements that need to be addressed for IPTV

deployment. One of these requirements is the architecture for providing charging in IPTV. Some of

the aspects reviewed are how charging handled in IPTV will support various business models, most

importantly the usage-based charging model for IPTV. Another requirement is how Charging Data

Records are created within the IPTV paradigm.

IPTV standardization for the IMS has been ongoing for the past few years and is not yet fully

complete. Even though a great deal of work has gone into standardization not much has gone into

finding charging solutions that cater uniquely for the IPTV IMS case.

2.3.2 K. Casier et. al.

K. Casier et. al. [17] presents an IPTV adoption approach for effective and fair pricing. Firstly it is

very difficult to construct a successful and sustainable IPTV implementation over most network

infrastructures. An added complexity introduced for the network operator is to find ways to price

IPTV services and still be competitive against other operators. This paper gives an overview of a

typical business case for IPTV pricing. This entails taking into consideration factors that directly

affect successful revenue generation. These factors include customer behaviors, equipment pricing,

content pricing and existing infrastructure. They then go on to present a detailed discussion of the

adoption and evaluation of the outcome. They show that by allocating costs fairly to IPTV and all

other services, more competitive yet still sustainable lower boundaries on pricing can be calculated.

The results of this article indicate the importance of a correct choice of adoption model and related

parameters. The approach discussed in the article could easily be extended with a highly detailed

cost model of the network architecture and technology, leading to a full business case for IPTV

introduction by a telecom operator

12

The paper does not address which charging functions handle the pricing, nor does it explain how

they would do so. It is, however, a good starting point for the actual implementation of IPTV pricing

once a functional charging system has been developed and actual parameters have been identified

for the development of an IPTV business model.

What can be concluded from this review is that as NGN networks like the IMS become utilized to

provide new services (like IPTV), new charging mechanisms have to be introduced to address

charging complexities. This issue is being addressed by various standardization bodies. What is

lacking is actual physical implementation of these mechanisms. Some companies are offering

solutions however these solutions provide for generic charging implementations that do not cater for

specific service types. From IPTV development, very little work is going into identifying charging

models for the service over the IMS. This thesis focuses on designing and developing an IPTV

charging system.

13

Chapter 3 Background to the thesis

This chapter provides background information to the key topics discussed in this thesis.

3.1 Introduction to IMS

The IP Multimedia Subsystem (IMS) was originally defined by the 3rd

Generation Partnership

Project (3GPP) as a mobile network infrastructure that enabled the integration of data, speech and

mobile network technology over a common IP base. This was later changed to allow for the support

of other networks besides traditional mobile networks. These networks include WLAN,

CDMA2000 and fixed line.

IMS was designed to fill the gap in existing telecommunication technology and internet technology

[18]. This meant that mobile technology could now be blended with the rich applications that were

already being offered on the internet. IMS especially helps for the provisioning of real time mobile

services such as internet telephony, video telephony, instant messaging, and push services. An

increase in the amount of bandwidth available could not alone be able to achieve this and the IMS

allows operators to be able to offer new and innovative services to the end user.

There are many reasons why IMS is fast becoming the most desirable Service Delivery Platform for

next generation networks. Firstly it allows for the blending of services, where previously different

types of services were separated from each other. This is appealing to the end user as they feel they

get more value for money from their service providers. Secondly it is a subsystem and allows for

different access technologies. This means that most users will be catered for under the framework.

Thirdly because the IMS has a common horizontal service layer it makes it easier for the

development of services as they do not need to have their own control functions.

IMS was originally defined by an industry forum called 3G.IP, formed in 1999. 3G.IP developed

the initial IMS architecture, which was brought to 3GPP, as part of their standardization work for

14

3G mobile phone systems in UMTS networks. It first appeared in release 5 (evolution from 2G to

3G networks), when Session Initiation Protocol (SIP-based) multimedia was added. Support for the

older mobile networks such as GSM and GPRS was also provided. 3GPP2 is a different

organization that based their CDMA2000 Multimedia Domain (MMD) on 3GPP IMS, adding

support for CDMA2000. 3GPP release 6 added interworking with WLAN. 3GPP release 7 added

support for fixed networks, by working together with TISPAN release R1.1 [19, 20].

3.2 Introduction to IPTV and VOD

Internet Protocol TV is a system where television services are provided over an IP network. In direct

contrast to traditional television broadcasting mechanisms such as satellite and cable, IPTV delivers

its broadcast through computer network technologies. IPTV is often offered in conjunction with

other services but one of the most prominent is Video on Demand. VOD is a system where users are

able to select and watch content at times of their own choosing, independent from a preset broadcast

schedule.

IPTV differs from regular broadcasting in many ways, one of which is the fact that video is now

obtainable from any device that can recognize IP. This means content can be streamed to PC’s,

mobile phones and televisions provided they have a set-top box. Since this technology relies on

computer networks, it has been restricted by the lack of high bandwidth connections. However this is

becoming less of a problem with the emergence of broadband connections with a projected number

of households that will have broadband estimated to be 400 million by the year 2010 [21].

IPTV has many advantages to traditional TV systems. The main one is its ability to integrate

televisions with other IP-based services like high speed internet or VoIP. The user has more choice

on their viewing where they can select content that they want, instead of having it pushed to them as

traditional broadcasting does. IPTV allows user interaction where traditional broadcasting does not.

Not all IPTV has to be interactive; it can also be a simple static broadcast IPTV.

Because IPTV requires the transmission of real-time data and uses the Internet Protocol, it is

sensitive to packet loss and delays. It is not the streamed data that is the problem but rather the

transmission medium that introduces this complexity. If the IPTV connection is not fast enough,

picture break-up or loss may occur. To be able to compete with current television broadcasting

15

systems that incur almost no picture degradation, IPTV will need a high degree of quality of service

before it can adequately compete with these systems. Extensive work has gone into finding ways to

ensure Quality of Service and Quality of Experience that can be regarded as acceptable [22].

3.3 Introduction to AAA

The term AAA refers to Authentication, Authorization and Accounting activities. All of these

activities are crucial for the operation of an IPTV network [23].

3.3.1 Authentication

Authentication refers to the process of establishing the digital identity of one entity to another entity.

Commonly one entity is a client and the other entity is a server. Authentication is accomplished via

the presentation of an identity and its corresponding credentials. Examples of types of credentials are

passwords, one-time tokens, digital certificates, and phone numbers.

3.3.2 Authorization

Authorization refers to the granting of specific types of resources to an entity or a user, based on

their authentication, what resources they are requesting and the current system state. Authorization

may also be based on restrictions, for example time-of-day restrictions, or physical location

restrictions, or restrictions against multiple logins by the same user. Most of the time the granting of

a resource constitutes the ability to use a certain type of service.

3.3.3 Accounting

Accounting refers to the tracking of the consumption of network resources by users. This

information may be used for management, planning, or billing purposes. Real-time accounting refers

to accounting information that is delivered concurrently with the consumption of the resources.

Batch accounting refers to accounting information that is saved until it is delivered at a later time.

Typical information that is gathered in accounting is the identity of the user, the nature of the service

delivered, when the service began, and when it ended.

All of the above concepts are closely linked. For example, one cannot gather accounting information

16

without first knowing who the information belongs to (authentication) and what resource the

information is about (authorization).

In order to develop a working IPTV delivery system over the IMS that incorporates efficient

charging mechanisms to guard which and how users can view content on demand, it is necessary to

take into account these three topics. .

3.4 Background to project

The IMS is essentially the ideal platform for the provisioning of multimedia services. Most of the

current IPTV services are delivered on non-NGN architectures. Although they allow for some

interworking, they generally have their own separate service and control layers. Deploying IPTV

over IMS has many benefits [1]:

Integrated registration and authentication

Session management

Integration of existing NGN services e.g. IM or presence

Roaming

QoS

Unified billing and charging

For service providers to reap the benefits of the service they need to have in place the adequate

authentication and charging functions for the service. The project sets out to propose an IPTV-VOD

architecture that has authorization and billing functions. The system will work over the IMS

framework.

17

Chapter 4 IMS and IPTV

Before we can understand how IPTV can be provided over the IMS, we first need to look closely at

the underlying architecture of the IMS. The IMS defined by the 3rd

Generation Partnership Project

defines a set of functions [4]. It is important to note that the 3GPP did not standardize nodes but

rather a set of functions, leaving implementers the freedom of deciding whether a node would

represent a single function, many nodes representing the same function or one node representing

many functions. However, the most common approach that implementers take is to design one node

for each function.

4.1 IMS Architecture

The NGN functional architecture has three main layers: transport, control, and service. IMS is at the

architecture’s core. The following figure depicts this architecture.

18

Mobile Phone PDA LaptopTelephone

IP NetworkPSTN

P-CSCF

BGCF

MRFP

MFRCS-CSCF

I-CSCF

SLF

HSS

OSA AS

MGCF

SIP AS IM-SSF

Service Layer

Control Layer

Figure 4.1: IMS Functional Architecture

4.1.1 Transport Layer

The transport layer is the network-access layer. It lets different IMS devices and user equipment

connect to the IMS network. IMS devices connect to the IP network in the transport layer using

various technologies, including fixed access (DSL, cable, modems, Ethernet), mobile access

(WCDMA, CDMA-2000 and GPRS) and wireless access (WLAN and WiMax). The transport layer

also lets IMS devices place and receive calls to and from the public switched telephone network

(PSTN) or other circuit-switched networks through the media gateway.

4.1.2 Control Layer

The control layer consists of some of the most important nodes in the IMS. The HSS is located at

19

this layer and is responsible for storing user information. Also at this layer are the Call Service

Control Functions (CSCFs), Media Resource Functions and the Border Gateway Controller

Function.

4.1.2.1 HSS and SLF

The HSS is the central repository for user related information. This information can include

subscriptions related data that is used to handle multimedia sessions such as:

Location information

Authentication information

Authorization information

User profile information

S-CSCF allocated to user

If there is more than one HSS in the home network then a Subscription Locator Function will also

reside in the home network so that information can be routed to the correct HSS. Along with the

SLF (if there is one present) the HSS has links to the I-CSCF and the S-CSCF through the Cx

interface (if there is a SLF then the Dx interface will connect the SLF with the two CSCFs). The Cx

and Dx interfaces only allow for the sending of Diameter Protocol messages which relay AAA

information.

4.1.2.2 P-CSCF

The P-CSCF is the first point of contact in the signalling plane that the IMS terminal will have with

the IMS network. The P-CSCF is allocated to the IMS terminal during registration. Before any

communication can take place the IMS terminal needs to know the address of the P-CSCF, usually it

can find this with the help of a DHCP server. The P-CSCF is essentially a SIP message forwarder as

it forwards SIP messages from the terminal into the network and forwards all SIP messages

originating from the network to the terminal. It will never generate any terminal related messages on

its own.

The P-CSCF will perform security checks on all SIP messages that it received from the IMS

20

terminal to make sure that they indeed originated from the terminal and where not altered along the

way. Once the user is authenticated, it will assert this to the other nodes in the network so that they

do not need to perform any security checks of their own.

The P-CSCF will also verify the correctness of all SIP messages that it receives from the IMS

terminal, pass on valid messages and filter out the incorrect ones. It can also act as a compressor and

decompressor of SIP messages; it does this because SIP messages can tend to be quite large based on

the fact that SIP is a text based protocol. Reducing the size of the messages will reduce the time it

takes to transmit the message.

A P-CSCF can include a Policy Decision Function (PDF). This function will authorize the use of

media plane resources and control QoS over the media plane. It can also forward charging

information to the Charging Collector Node.

The P-CSCF will only be directly linked to IMS terminal, the I-CSCF and the S-CSCF. The P-

CSCF assigned to an IMS terminal can reside in the home network or the visited network.

4.1.2.3 I-CSCF

The I-CSCF is located at the edge of the administration domain. The address of the I-CSCF will be

in the DNS records on the domain. When a SIP server needs to find the next hop for a SIP message it

will obtain the address of an I-CSCF in the destination domain and in this way, it functions as a SIP

proxy server. Otherwise, it has links with the SLF and HSS in the domain that is used to request

location information from. It will also direct SIP messages to the allocated S-CSCF.

The I-CSCF is usually located in the home network.

4.1.2.4 S-CSCF

The S-CSCF is the central node in the signalling plane. As opposed to the I-CSCF and the P-CSCF,

the S-CSCF is a SIP server where the other two are SIP proxies. The S-CSCF performs session

control where it will manage all media sessions that are ongoing to an IMS terminal.

It can also perform as a registrar that will bind user location information such as the terminal’s IP

address and the user’s SIP address which is also known as the Public User Identity.

21

The S-CSCF will also implement a Diameter protocol Dialogue with the HSS. It does this to obtain

the following information:

Download authentication vectors of the user trying to register with the IMS and use these to

perform authentication on the user

Obtain all user profile information that will include the service profile that a specific user

will have. It will also include a set of triggers that may cause the invocation of one of the

application servers.

Tell the HSS that it is the S-CSCF for a specific user for the duration of registration

All SIP signalling from and to the IMS terminal will go through the allocated S-CSCF. It is always

located in the home network.

4.1.2.5 MRF

The Media Resource Function provides a source of media in the home network. It handles most of

the media related broadcasts within the network. This node can further be broken up into the MRFC

and the MRFP:

Media Resource Function Controller is the signalling plane node

Media Resource Function Provider is the media plane signalling node

The MRF is always located in the home network.

4.1.2.6 BGCF and MGCF

These are SIP servers that provide the link between the IMS and circuit-switched networks such as

PSTN and PLMN networks. They contain addresses of users that reside in these circuit-switched

domains.

4.1.2.7 Service Layer

This layer can alternatively be called the application layer, as this is where application servers

reside. The transport and control layers provide an integrated and standardized network platform to

let service providers’ offer various multimedia services in the service layer. Application servers host

22

and execute the services and provide the interface with the control layer using the SIP protocol

4.1.2.8 AS

The AS (Application Server) is a SIP entity that hosts and executes services. Depending on the

actual service the AS can operate in SIP proxy mode, SIP UA (User Agent) mode (i.e., endpoint), or

SIP B2BUA (Back-to-Back User Agent) mode (i.e., a concatenation of two SIP User Agents). The

AS has a link with the S-CSCF through which SIP messages are exchanged. The AS can optionally

have a link with the HSS using the Diameter protocol over the Sh interface. The AS uses this link to

upload and download user data stored in the HSS. It will also sometimes use this interface to find

out the addresses of the charging functions in the network.

There are three types of AS that can reside in the IMS network.

SIP AS (Application Server): this is the native Application Server that hosts and executes IP

Multimedia Services based on SIP. It is expected that new IMS-specific services will likely

be developed in SIP Application Servers.

OSA-SCS (Open Service Access-Service Capability Server): this application server provides

an interface to the OSA framework Application Server. It inherits all the OSA capabilities,

especially the capability to access the IMS securely from external networks

IM-SSF (IP Multimedia Service Switching Function): this specialized application server

allows us to reuse CAMEL services that were developed for GSM in the IMS.

4.2 Protocols in the IMS

4.3 SIP

SIP was specified by the IETF as a protocol to establish and manage multimedia sessions over IP

networks, SIP was gaining momentum at the time 3GPP was choosing its session control protocol.

SIP follows the well-known client-server model. Generally the client sends SIP requests and the

server sends back SIP responses. SIP messages are text based. SIP endpoints are also known as UAs

or User Agents. UAs can both generate and respond to SIP messages. SIP messages can be carried

23

using a variety of transports, such as UDP or TCP, and a given message can shift between transport

protocols as it is forwarded through proxies. SIP itself defines transaction-level state machines and

timers that invoke retransmission for providing reliability over transports such as UDP that may

experience packet loss.

SIP identifies users using SIP URIs, which are similar to email addresses; they consist of a user

name and a domain name. Additionally, SIP URIs can contain a number of parameters (e.g.,

transport), which are encoded using semi-colons. The following are examples of SIP URIs:

sip:[email protected]

sip:[email protected]

sip:[email protected];transport=tcp

At the beginning of a SIP message there is a start line. In request messages this is known as the

request line and in response messages it is known as the status line. The SIP AS will act as a SIP

server and process requests from the IMS client. It will thus need to differentiate between the

different requests it receives. The request line will contain a method name on which the SIP AS will

need to perform a corresponding action before sending a SIP response. An example of a request line

is shown below:

INVITE sip:[email protected] SIP/2.0

SIP messages contain a set of header fields. There are mandatory fields that appear in every message

and optional header fields that are included when necessary.

4.3.1 Diameter

The Diameter protocol was chosen to be the AAA protocol on the IMS. Diameter consists of a base

protocol that is complemented with relevant Diameter Applications. Diameter applications are

customizations or extensions to Diameter to suit a particular application in a given environment. An

example of this is how the diameter protocol was extended to provide an application specifically for

the Sh interface, which is the reference point between the HSS and the AS.

All IMS entities that need to send and receive AAA messages need to be able to understand the

24

Diameter Protocol. This means that the AS and charging functions in this case will need to have an

interface to this protocol as they will be sending and receiving accounting messages.

4.4 IPTV and VOD over IMS

Over the past couple of years much effort has gone into the standardization of IPTV. These efforts

have yet to yield standardization for an IPTV implementation over the 3GPP defined IMS. Non-

NGN-based IPTV systems are currently the most popular IPTV solutions on the market. This

architecture calls for separated control and application layers that are dedicated solely to the use of

the IPTV system. These systems are not considered NGNs because of this fact.

NGN non-IMS-based IPTV architectures enabled interaction and interworking over specified

reference points between IPTV dedicated functions and some existing NGN elements. But this is still

not enough.

IMS-based IPTV architecture specifies IPTV functions based on the IMS subsystem and enables the

reuse of IMS functionality and SIP-based service initiation and control mechanisms. IMS-based

IPTV has quite a few advantages over other types of IPTV [1]:

Support for mobility

Interaction with service enablers

Service personalization

Integration with voice, data, video and mobile services

4.4.1 IMS-based IPTV architecture

The functional architecture of IMS-based IPTV presented here contains the main functions and

reference points defined in ETSI TISPAN IMS-based IPTV architecture.

25

IMS User

Media Server

IPTV AS

P-CSCF

S-CSCF

I-CSCF

HSS

MDF MCF

Media control and

distributed media

delivery architecture

IMS core

IPTV application server platform

XcXd Gm

Cx

ISC

ISC Sh

Sh

Xa Ut

Cx

Diameter

SIP

RTP

RTSP

HTTPS

Figure 4.2: IMS-based IPTV Architecture

The core IMS is used to forward the SIP signalling that controls all session management. The media

streams themselves do not traverse through the IMS core. Two new functions are introduced in the

IMS-based IPTV architecture; the Service Discovery Function (SDF) and the Service Selection

Function (SSF). The SDF has the function of providing service attachment information about

accessible IPTV services. The SSF is responsible for providing service information and personalised

user preference information. In addition, information from an Electronic Program Guide (EPG) will

provide users with available data on media content.

26

4.4.2 IPTV Service Control Functions

IPTV SCFs handle all IPTV-related requests and execute service and session control for all IPTV

services. These functions can be performed by the existing CSCFs in the IMS core. Specific to IPTV

the CSCFs will have the following responsibilities

Session initiation and service control for IPTV services

Service authorization and validation of user requests for selected content, based on the user

profile information

Selection of the relevant IPTV media control/delivery functions

Customization of the user experience, for example, TV channels presented to subscribers can

be selected according to user profiles

Credit control so that IPTV service charging can occur.

4.4.3 IMS-based IPTV services

Currently there are three types of services that exist for this architecture. Broadcast services would

provide services like live TV or radio channel streaming. Content on Demand (CoD) would send a

unicast stream of the requested content to a user on demand. This content could include music and

movies. Personal Video Recorder services would allow users the ability to pause streaming content

and later to continue viewing it from last viewed position in all cases including live TV.

4.4.4 IPTV AS

The IPTV application server would have SDF functions. This is used to provide service information

for the IMS user equipment. The IPTV AS also includes SCFs that can interact through the ISC

interface over core IMS directly with Media Control Functions (in this case the CSCFs). The IPTV

AS also supports the Sh interface to HSS to retrieve user profiles with all user subscriptions and

preferences. Using the information retrieved from associated media control servers and applying

IPTV user profiles from the HSS, a list of available multimedia services can be created for a

particular IMS user according to his or her preferences and subscriptions.

27

4.4.5 IMS-based IPTV in action

IMS terminal needs to first establish a connection with the IMS core before anything can happen.

Usually it will have the address of a P-CSCF to allow for the terminal to register with the IMS core.

Once registered the terminal can then begin to initiate service sessions and request for content. It

would need to communicate with the IPTV AS to find out which services are available to the user.

This means that the terminal must know the SIP identifier for the AS so that it can send a SIP

INVITE message to the AS for the service session initiation. Once the session has been established

the user can then view the available content and request for a media session. The core IMS can then

initiate a resource reservation process for network resources that are required by the IPTV stream

according to the capabilities of the IMS terminal user equipment. The IMS terminal can then

establish a separate media link with the media delivery plane that is outside of the IMS core. This

link would usually support RTSP for the control of the media streams and RTP for the actual

transportation of media traffic such as audio and video packets.

This chapter has presented the IMS architecture and the IMS-based IPTV architecture. In the next

chapter the billing architecture will be investigated.

28

Chapter 5 Charging and Authentication

The IP multimedia subsystem enables a service-rich communication landscape and the convergence

of mobile and fixed networks. However, IMS solutions can succeed only when charging for these

new services is supported in a flexible and efficient manner [12]. IMS charging is part of a larger

charging concept defined within the 3GPP Release 6 charging framework

5.1 3GPP Charging

IMS charging in 3GPP Release 6 is not isolated but rather is part of an overall charging concept. In

the release a common framework for charging was created by describing the general charging

functionality in a single standard. One standard is very necessary because of the growing number of

technologies and services that would make individual charging functions impossible to handle over

the IMS network. This should not be confused with the fact that individual charging models are

needed for different types of services. The goal in IMS charging is to provide charging functions that

can implement all these models in a centralized manner. In the release they identified common

logical charging functions that provide the different aspects of the required functionality for all the

charging-relevant parts of a 3GPP network and integrated them into a common logical architecture.

In this architecture, there are service specific specifications which define the exact detail in charging

that must occur within the service. These specifications are divided into three groups that describe

the three different charging levels defined by the 3GPP:

Bearer-level charging – circuit-switched, packet-switched domain, and the 3GPP

interworking WLAN

Subsystem charging – in the IMS

Service level charging – multimedia messaging service, push-to-talk over cellular,

multimedia broadcast, and multicast service

29

Regardless of the level of charging that is employed in the system, there are two distinguishable

types of charging, namely online charging and offline charging. In offline charging the actual

process of charging occurs after the service has been rendered, where records are kept of how much

the client used and then the client is charged accordingly. This form of charging requires no real-

time charging communication to happen during the session. In direct contrast to offline charging is

online charging. This type of charging involves a real-time interaction between the charging process

and the service being rendered. If the user’s credit runs out during the provisioning of a service then

the providers could choose to end the media session. These two charging mechanisms should not be

confused with prepaid and postpaid billing. Prepaid billing is billing by which a user has to purchase

usage credits prior to being authorized to using network services whereas post-paid billing is billing

where the user is allowed to use network services and gets billed after service usage. Although there

are similarities between each pair of functions they are not the same.

5.2 Charging in the IP Multimedia Subsystem

The following figure depicts the proposed structure of the charging system in the IMS framework.

Billing Domain

Operator’s post processing system

Charging Function

Gateway

Charging Data

Function

Online Charging

Function

Accounting Balance

Management FunctionRating

Function

Charging Function

Gateway

Rf

Ga

Bx

Ro

Rc Re

Bo

Offline Charging Online ChargingCharging Trigger

Function

Ga

Figure 5.1: Charging in the IMS

30

5.2.1 Offline charging

As shown in fig 5.1, offline charging consists of three logical functions: the Charging Trigger

Function (CTF), the Charging Data Function (CDF) and the Charging Gateway Function (CGF).

The CTF is an integrated function on any charging relevant resource or service element. For

example an AS will have a function that will start to send charging information to the CDF

whenever a service has been requested by a user. Different functional entities will have distinct

charging events. The figure below shows which entities can have a link to the CDF through the Rf

reference point. Each entity will contain an embedded CTF.

IMS-AS

MRFC

BGCF

MGCF

P-CSCF

I-CSCF

S-CSCF

CDF CGFBilling

DomainRf Ga Gi

Figure 5.2: Offline Charging in the IMS

The functional entities would have mechanisms to monitor signalling traffic and filter for specific

traffic that should result in charging information to be passed on to the CDF. The information that is

passed on is mostly charging reports that have been captured about the resource usage of the user so

31

that subsequent billing can be implemented (for example on a monthly basis).

The charging information that is relayed on the Rf interface is in the form of Diameter messages.

More detail on the Diameter base protocol and various application protocols will be covered later in

this chapter.

The CDF is the logical entity that is responsible for the generation of charging data records (CDR)

from the information that was passed on to it through the Rf interface. It then sends these CDR to the

CGF, which acts as a gateway between the IMS and the billing domain. The CGF stores all the

information received into files, which are then passed on to the billing domain in a push or pull

manner.

The described architecture discusses the Release 6 of the 3GPP charging. The previous release had

discussed a different logical entity the Charging Collecting Function (CCF). Essentially the only

difference is that in Release 6 the CDF and the CGF are two separate entities where as in Release 5

the two where combined as the CCF.

It is important to note that the Rf reference point is only accessible within the home network and

foreign or visiting network will only report to their own CDF functions.

5.2.2 Online charging

As shown in fig 5.3, there are two logical charging entities involved in online charging: the CFT and

the Online Charging System (OCS). The OCS is compromised of three functional entities, namely

the Online Charging Function (OCF), the Rating Function (RF) and the Account Balance

Management Function (ABMF).The figure below shows how the functions are interconnected.

32

IMS-AS

MRFC

IMS-GWFS-CSCF OCFBilling

Domain

CTFs

ISC Ro Bo

Optional

Figure 5.3: Online Charging in the IMS

The OCF which is directly connected to the CTF through the Ro interface is responsible for two

charging modules: the event based charging function which is responsible for charging that is event

based and the session based charging function that handles charging that is session based. An

example of event based charging is charging for sending of a Multimedia message, the charge occurs

once of at the time the message is sent. Session based charging is more suited for services that last

for an ongoing amount of time. Both need to ensure that they are executed correctly as they directly

determine the usage rights of the user on the requested resource.

The CTF must be extended for online charging to include real time communications with the OCS

over the Ro reference point. It must be able to delay the response to a resource request until it has

established that the user has sufficient credit to allow for authorised usage of the resource. It must

then be able to monitor the decrement of credits during the usage of said resource and be able to

terminate the service when the user has run out of credits. It is essential that all this happens in real

time as the user is allocated the resource.

In this case the Diameter Credit Control Application is used over the Ro interface. It is just the

extension of the number of Attribute Value Pairs (AVPs). In the case of online charging the number

of functional entities that have the CTF is limited to only three, as is depicted in the above figure.

5.3 The Charging Protocol in the IMS - Diameter

33

The IMS uses the Diameter protocol to transport all AAA messages between the functions. Diameter

is specified as a base protocol and is complemented by a set of application protocols that add on to

the base protocol functionality. The base protocol is implemented at all Diameter nodes independent

of the application. Applications are extensions of the base protocol and will cater to the specific

needs of the node that implements the Diameter protocol [13]. The following figure depicts the

relationship between the base protocol and the application protocols.

Diameter

Application for

Sh Interface

Diameter

Application for Cx

Interface

Diameter Credit

Control

Application

Diameter SIP

Application

Diameter Base Protocol

Figure 5.4: Diameter Base Protocol and Applications

Diameter is designed to run over a transport protocol that offers reliable connections (e.g. TCP).

This is important because lost Diameter messages can be retransmitted, thus it cannot be used over a

transport protocol such as UDP. The Diameter protocol can be performed on different nodes and

each node can have a different Diameter function:

Diameter Client – an entity that performs access control with the help of information

obtained from a Diameter Server.

Diameter Server – an entity that handles Authentication, Authorization and Accounting

request in a domain or realm.

34

Diameter Proxy – an entity that forwards Diameter messages. It can also change the

Diameter messages to implement policy decisions, such as controlling resource usage and

providing admission control.

Diameter Relay – an entity that forwards Diameter messages based on routing information

and realm-routing table entries. A Relay cannot modify data in a Diameter message.

Redirect agent – an entity that refers clients to servers so that they can communicate directly.

Translation agent – a functionally entity that translates Diameter messages to those of other

AAA protocols.

Diameter is a peer-to-peer protocol. This means that any Diameter node can send and receive

Diameter messages asynchronously and out of turn, as opposed to a client-server mode where clients

send request to servers and servers respond to these request. Both Diameter Clients and Servers can

send requests and respond to these requests.

Diameter messages are either requests or answers. A request is almost always replied to with one

answer, barring very few exceptions. This means that a sender of a Diameter request always knows

the fate of the Diameter message that it sent and in the case of errors, retransmits the message.

Diameter is a binary encoded protocol and unlike SIP is not human readable.

5.3.1 Format of a Diameter Message

A Diameter message consists of a 20-octet header and a number of Attribute Value Pairs (AVP).

The length of the header is fixed for all messages. The number of AVPs is variable, depending on the

particular message. An AVP is a container of AAA data. The following figure shows the format of a

Diameter message.

35

Version Message Length

Command Flags Command-Code

Application ID

Hop-by-Hop Identifier

End-to-End Identifier

AVP 1

AVP 2

[…]

AVP n

Figure 5.5: Format of a Diameter Message

The header starts with a Version field. Currently there is only version 1. The Message Length field

contains the length of the Diameter message including the header and following AVPs. The

Command-Flags contain:

If the message is a request or an answer

If the message can be forwarded by a proxy

If the message contains a protocol error in terms of its format not conforming to the

Diameter protocol

If the message is a retransmitted message

36

The Command Code has the value of the actually command contained in the message. Command

codes for request and answers reside in the same field, the command-flags will tell if it a request or

an answer. The Application-ID field indicates which Diameter Application sent the message. The

hop-by-hop identifier contains a value that each hop set when sending the request. The answer will

have the same identifier so that a Diameter node can easily correlate the answer to the corresponding

request. The sender of the request will set an end-to-end identifier that does not change at any

forwarding node. Together with the origin’s host identity the end-to-end identifier can help the

receiver detect duplicate requests.

5.3.2 Attribute Value Pairs

AVPs are containers of data. As shown in the following figure an AVP will contain an AVP code,

flags, an AVP length and data. Having a vender ID is optional.

0 15 31

AVP Code

Flags AVP Length

Vendor-ID

Data

Figure 5.6: Structure of an AVP

The Flags field indicates:

37

the need for encryption to guarantee end-to-end security;

whether support for the AVP is mandatory or optional. If the sender indicates that support

for the AVP is mandatory and the receiver does not understand the AVP the Diameter

request is rejected;

whether the optional Vendor-ID field is present or not

5.3.3 Diameter base protocol commands

As previously stated, Diameter messages are either requests or answers. A request and its

corresponding answer will have the same command-code number. The command code tells the

diameter node that received the diameter message what actions it needs to perform. The diameter

node will need to refer to the command-flags field to find out if the message is a request or an

answer. The following table shows the command codes and corresponding code numbers for base

protocol diameter messages.

38

Table 5.1: Command Codes of Base Protocol

Command-Name Abbreviation Command-Code

Abort-Session-Request ASR 274

Abort-Session-Answer ASA 274

Accounting-Request ACR 271

Accounting-Answer ACA 271

Capabilities-Exchange-Request CER 275

Capabilities-Exchange- Answer CEA 275

Device-Watchdog-Request DWR 280

Device-Watchdog-Answer DWA 280

Disconnect-Peer-Request DPR 282

Disconnect-Peer-Answer DPA 282

Re-Auth-Request RAR 258

Re-Auth-Answer RAA 258

Session-Termination-Request STR 275

Session-Termination-Answer STA 275

5.3.4 Diameter Base Protocol AVPs

39

Each request and answer defines which AVPs are present in the message. Some AVPs may be

optional in a particular request or answer, others may be mandatory. The list of Diameter base

protocol AVPs is quite large. It can be found in RFC 3588 [14]. Among the most important ones

are:

Authorization-Lifetime AVP which indicates how long a user can be authorized before re-

authorization

User-Name AVP contains the user name of a user. In the IMS this is the Private User

Identity

Result-Code AVP contains whether a request was successfully completed or not.

Origin-Host AVP is the Fully Qualified Domain Name (FQDN) of sending node

Origin-Realm AVP is the realm a node belongs to

Destination-Host AVP contains the FQDN of destination node

Destination-Realm AVP is the realm the destination node belongs to

Session-ID AVP contains an identifier of the session; all messages sent within a diameter

session will carry the same value.

As the implementation of this thesis requires that the elements implemented are able to communicate

using Diameter messages, the interfaces that connect these elements need to be defined in more

detail. The next section gives details on these interfaces.

40

Chapter 6 AAA Interfaces in the IMS

Quite a few interfaces within the IMS implement the Diameter protocol, some for Authentication

and Authorization purposes and others for Accounting purposes. Among the most relevant to this

thesis are the Sh, Rf and Ro interfaces.

6.1 The Sh interface

The Sh interface specifies the connection between an AS and the HSS. It mainly provides for a data

storage and retrieval type of functionality. The AS will either be downloading user data from the

HSS or uploading data to the HSS. This data is related to the service that is offered by that

application server. An AS does not have to implement the Sh interface as some services are not

required to have communications with the HSS. The protocol used over the Sh interface is called the

“Diameter Application for the Sh interface” [11, 24].

There are different types of data that are exchanged over the Sh interface.

Repository data: the AS uses the HSS to store transparent data. The data is only understood

by the specific Application Servers that implement the service. The data is different from

user to user and from service to service

Public identifiers: the list of Public User Identities allocated to the user.

IMS user state: the registration state of the user in the IMS. A user can be registered,

unregistered, pending while being authenticated, or unregistered but an S-CSCF is allocated

to trigger services for unregistered users.

S-CSCF name: contains the address of the S-CSCF allocated to the user.

41

Initial filter criteria: contain the triggering information for a service. An Application Server

can only get the initial filter criteria that route SIP requests to it.

Location information: contains the location of the user in the circuit-switched or packet

switched domains.

User state: contains the state of the user in the circuit-switched or packet-switched domains.

Charging information: contains the addresses of the charging functions.

6.1.1 Command Codes Defined in the Diameter Application for the Sh

Interface

The Sh interface Diameter Application defines eight new command codes. These are in the table

below.

Table 6.1: List of Commands for Sh Interface

Command-Name Abbreviation Command-Code

User-Data-Request UDR 306

User-Data-Answer UDA 306

Profile-Update-Request PUR 307

Profile-Update-Answer PUA 307

Subscribe-Notification-Request SNR 308

Subscribe-Notification-Answer SNA 308

Push-Notification-Request PNR 309

Push-Notification-Answer PNA 309

42

6.1.1.1 User Data Request and Answer (UDR and UDA)

An AS will send a UDR message to the HSS to request data that is defined over the SH interface.

The HSS will respond with a UDA and attach the requested data. The following figure depicts the

data flow.

Diameter UDR

Diameter UDA

HSS AS

Figure 6.1: UDR and UDA Messages

6.1.1.2 Profile Update Request and Answer (PUR and PUA)

An AS may wish to change the information in a user profile. It will send the PUR messages attached

with the changes to the HSS. The HSS will respond with a PUA and where the changes where

successfully made. The following figure shows the message flow.

43

Diameter PUR

Diameter PUA

HSS AS

Figure 6.2: PUR and PUA Messages

6.1.1.3 Subscribe Notifications Request and Answer (SNR, SNA)

An AS can subscribe to changes in user data that it is allowed to obtain. It sends an SNR to the HSS

which then sends a SNA to the AS telling it that it will be notified as changes occur. Thus when data

changes the HSS will send PNR messages with changed data to the AS. The message flow is

depicted below.

44

Diameter SNR

Diameter SNA

HSS AS

Diameter PNR

Diameter PNA

User data changes

Figure 6.3: SNR, SNA, PNR and PNA Messages

6.1.1.4 Push Notification Request and Answer (PNR, PNA)

When data is changed in a user profile for a user that the AS is currently servicing and the AS has

subscribed for notifications the HSS will send PNR messages to the AS with the changes attached.

The AS will respond with a PNA.

6.1.1.5 AVPs Defined in the Diameter Application for the Sh Interface

The Diameter Application for the Sh interface defines new AVPs to be used over it. The table below

shows these AVPs.

45

Table 6.2: AVPs defined for Sh Interface

Attribute Name AVP Code

User-Identity 100

MSISDN 101

User-Date 102

Date-Reference 103

Service-Indication 104

Subs-Req-Type 105

Requested-Domain 106

Current-Location 107

Server-Name 108

The User-Identity is a grouped AVP that contains the identity of the user either as a Public User

Identity, in which case it contains a Public-Identity AVP (borrowed from the Diameter Application

for the Cx interface), or as a Mobile Subscriber Integrated Services Digital Network (MSISDN)

number, in which case it contains an MSISDN AVP. The User-Data AVP contains the user data

according to the definition of user data in the Sh interface. The type of user data is specified in a

Data-Reference AVP, which can contain a value that represents any of the different types of user

data. The Service-Indication AVP contains an identifier of the repository data stored in the HSS.

This allows an AS that implements several services to store data for each of the services in the HSS

and still be able to distinguish and associate each data set with each corresponding service. The

Subs-Req-Type AVP contains an indication of whether the AS subscribes to the notification service

46

in the HSS. The Requested-Domain AVP indicates whether the AS is interested in accessing circuit-

switched domain data or packet-switched domain data. The Current-Location AVP indicates

whether a procedure called "active location retrieval" should be initiated. The Server-Name AVP

mirrors the AVP with the same name in the Diameter Application for the Cx interface [25].

To implement an AS that can communicate with the HSS to perform charging functions we would

use the Sh interface to inquire which charging functions a user is attached to, as well as to inquire

what type of charging the user is currently signed up for. This would be achieved by sending an

UDR and extracting the relevant information from the UDA received from the HSS. For

completeness the AS could be able to register for user data updates that relate to a user that is

currently being serviced by the AS using the SNR command. If, for example, the charging function

that the user is attached to changes, or the type of charging that they are registered to changes, the

AS could be able to act accordingly upon the receiving of a PNR from the HSS. From then onwards

the AS would be able to contact the specific charging functions and perform the correlating type of

charging.

6.2 The Rf interface

The Rf interface is based on the Diameter base protocol (specified in RFC 3588 [13]) together with

a vendor-specific “Diameter Application for the Rf/Ro interfaces.” The Rf is specified between

either an IMS-AS, MRFC, BGCF, MGCF, P-CSCF, I-CSCF or an S-CSCF and the Charging Data

Function (CDF). This interface is used to report offline charging information to the CDF [26].

6.2.1 Command Codes Defined in the Diameter Application for the Rf

Interface

Only two new command codes are defined for the Rf interface, namely the Accounting-Request

(ACR) and Accounting-Answer (ACA) messages. The ACR and ACA messages are used to report

accounting information to the CDF and can contain a number of AVPs relating to charging

information. The table below shows the 3GPP defined AVPs that relate to accounting information

sent over the Rf interface.

47

Table 6.3: Mandatory AVPs defined for Rf Interface


Session Identifier 263

Origin Host 264

Origin Realm 296

Destination Realm 283

Accounting Request Type 480

Accounting Request Number 485

Result Code (in ACA only) 268

Although there is only one type of Request message that is passed along on this interface, it can be

subcategorized into four different types of Accounting request messages

START

INTERIM

STOP

EVENT

The Accounting-Record-Type AVP will hold the value of the type of accounting request the

message is. The ACR types START, INTERIM and STOP are used for session based accounting

messages. The ACR type EVENT is used to relay event type accounting messages.

6.2.1.1 Event based accounting

Event based charging is when the CTF relays charging information on an event basis, without the

use of any timers. The CTF will send an ACR of type EVENT to the CDF once at when a

48

chargeable event occurs to inform the CDF that a service is being rendered. The following diagram

shows the message flows between the CFT and the CDF using event based charging.

ACR (EVENT)

ACA

CTF CDF

Service Delivery

Process Accounting Request

Figure 6.4: Event Based Offline Charging

6.2.1.2 Session Based Accounting

Session based charging is the process of reporting service usage reports for a session for example

streaming of media content. When the session is initialised by a user requesting a service, the CTF

sends an ACR of type start to the CDF. The CDF will then start a timer relating to the user and send

back an ACA. Upon the receipt on the ACA the CTF can then provide the user with the service. The

CTF has to periodically send ACR messages of type INTERIM to the CDF relating to the session so

that the CDF can reset the timer. If the CTF fails to send these interim messages then the CDF will

assume a failure has occurred at the CTF and end the charging session for the user. When the user

stops using the service the CTF will send an ACR of Type STOP to the CDF. The CDF will then

stop the timer and create a CDR associated with the user to send to the billing domain. The billing

domain can then bill the user at a later date. The following flow diagram depicts the interaction

between a CTF and a CDF using session based accounting.

49

ACR (START)

ACA

CTF CDF

ACR(INTERIM)

ACA

Service Termination

Service Request

Open CDR

Tim

er

Update CDR

ACR (STOP)

ACA

Close CDR

Figure 6.5: Session Based Offline Charging

Of the two types of offline charging, it would seem that the session-based offline charging would be

a better system to implement for IPTV, for the following reasons

The system is stateful and both functions always know which state the other is in. If the CDF

is in a state where it is currently performing charging functions and the CTF does not re-

acknowledge the state, it can then assume that a failure has occurred. At this point, it can

either perform some exploratory actions, or just end the charging actions that it was

performing.

50

Session based charging is more suited for the IPTV service. Event based charging does not

capture the necessary charging information, such as usage period lengths, that would be

created by the usage of the IPTV service. One of the primary goals of the charging system is

to provide flexibility and fairness to the user. Session based charging is able to provide this

flexibility. Users are charged for exact lengths they use the service and thus fairness is

ensured.

6.3 The Ro interface

The Ro interface is based on the Diameter base protocol together with a vendor-specific “Diameter

Credit-Control application.” The Ro is specified between either an IMS-AS, MRFC or an IMS-

GWF and the Online Charging Function (OCF). This interface is used to send online charging

information.

Two new diameter command messages in this application are the Credit-Control Request (CCR) and

the Credit-Control Answer (CCA). The following figures show the AVPs that are contained in these

messages [27].

Table 6.4: AVPs Defined for Ro Interface


Session Identifier 263

Origin Host 264

Origin Realm 296

Destination Realm 283

Credit Control Type 416

Credit Control Number 415

Result Code (in CCA only) 268

51

Once again there are four types of CCA messages that can be transferred on the Ro interface:

INITIAL_REQUEST

UPDATE_REQUEST

TERMINATE_REQUEST

EVENT_REQUEST

The Credit-Control Type AVP holds the value of what type of CCA message it is. There are three

ways user credit control can be achieved in an online charging implementation: Immediate Event

Charging (IEC), Event Charging with Unit Reservation (ECUR) and Session Charging with Unit

Reservation (SCUR).

6.3.1 Immediate Event Charging

When the CTF receives a service request from the user it sends a CCR message of type

EVENT_REQUEST to the OCS. At this point direct debiting occurs on the user’s account, for a

service rendering of a certain predefined period. The OCS will then send a CCA that will contain

information of whether the debiting was successful or not (i.e. the user has sufficient credits for the

duration of the service period). The following diagram depicts the message flows for IEC.

52

CCR (EVENT_REQUEST)

CCA

CTF

Service Request

Perform Direct Debiting

Service Delivery

Figure 6.6: IEC Direct Debiting

6.3.2 Event Charging with Unit Reservation

Before a service request can be processed the CTF first sends a CCR messaged of type

INITIAL_REQUEST to the OCS. Upon the receiving of this message the OCS reserves a certain

amount of credit from the user account. The OCS will then send a CCA to the CTF with information

of whether the reservation was successful. The service can then be provided. Once the service

session is over the CTF will send a CCR message of type TERMINATION_REQUEST to the OCS.

The OCS only at this point debits the user account and releases any unused reserved credits. The

message flows for ECUR is shown in the diagram below.

53

CCR (INITIAL_REQUEST)

CCA

CTF OCS

Service Request

Perform Charging Control

Service Delivery

CCR (TERMINATION_REQUEST)

CCA

Perform Charging Control

Figure 6.7: ECUR for Event Based Online Charging

6.3.3 Session Charging with Unit Reservation

Before processing a service request the CTF will send a CCR message of type INITIAL_REQUEST

to the OCS. The OCS will then reserve a certain amount of credit for a specified period. At this point

the OCS will start a timer running and then send a CCA message to the CTF. The CTF has to

periodically send CCR messages of type UPDATE_REQUEST related to the session. When the

OCS gets these messages it debits the amount of credits that were used and then reserves more

credits while also resetting the timer. Once the CTF stops servicing the user it will send a CCR

message of type TERMINATE_REQUEST at which point the OCS will perform the final debiting

on the user account and release any unused credits. If at any point in the exchange the timer on the

54

OCS times out, then it will assume a failure and either debit or release the credits and assume the

session was terminated. If the OCS received an UPDATE_REQUEST from the user and could not

reserve the required credits due to insufficient funds then it will send a CCA message to the CTF

with information that the reservation was unsuccessful at which point the service will immediately

be terminated. The message flow for this is shown in the diagram below.

CCR (INITIAL_REQUEST)

CCA

CTF OCS

CCR(INTERIM_REQUEST)

CCA

Session Termination

Session Request

Perform

Charging Control

Tim

er

CCR (TERMINATION_REQUEST)

CCA

Perform

Charging Control

Perform

Charging Control

Session Delivery

Figure 6.8: SCUR for Session Based Credit Control

Of the three types of online charging that can be implemented the best one to implement would be

the SCUR for session-based credit control. It was chosen for the following reasons:

55

It is similar to the offline session-based offline charging in terms of stateful-ness and ability

to recover from failures of the CTF.

Once again, a session based charging system is more suited to IPTV over an event based

system order to provide flexibility to users.

The goal of implementing an online charging system is to provide real-time prepaid billing

to the user. Considering that the user has pre purchased usage credits and requests to use the

service, the charging system should be able to verify that there are sufficient credits. This

verification should occur at the beginning and for the remainder of the service usage. This

verification needs to occur in conjunction with the account decrementing for the service. A

once-off message exchange, as is the case for event based charging, will not be able to

achieve this. Session based charging will allow for the frequent monitoring and adjustment

of the users account such that a prepaid billing solution is affectively offered.

A complication introduced by NGN networks such as the IMS is that users can receive

multiple services simultaneously. This complicates charging, as each service will be

verifying and adjusting the users account. Credit reservation solves this complication by not

directly debiting the user’s account but rather reserving the credits and only debiting the

reserved credits at certain time intervals.

56

Chapter 7 IPTV charging Design

In order to create an effective charging architecture for the IMS a number of things need to be taken

into consideration. This chapter presents a charging design that would be used for the IPTV charging

system.

7.1 Adhering to 3GPP definitions and standards

3GPP standards are complete and very detailed, and provide insight into how the cellular industry

works. 3GPP systems are deployed across much of the established GSM market [28]. To consider

developing a charging system for the IMS, we needed to follow very closely the specifications

defined by the 3GPP, as these are the systems that are likely to be used in industry. In addition, the

specifications for online and offline charging systems in the IMS are quite recent and not much work

has been produced in this area at the time of preparing this thesis.

7.1.1 Charging Guidelines for the IMS

The main goal in any charging design should be able to provide a truly flexible charging system that

is convenient for both the users of the IMS and the network service providers. Since the IMS would

be able to provide a wide range of services, one single charging mechanism would not be an

acceptable solution as it does not offer any flexibility to the user. A charging system would need to

able to provide different charging options that best fit each service. An example of this is to

implement per message charging for text or multimedia messaging as opposed to implementing real-

time content usage charging for services like audio and video streaming. The different types of

charging options can thus be categorised into the following groups [12]:

Charging by duration of the session where the actual service is provided

Charging by QoS requested and/or delivered

57

Once-off set up charge

Charging by volume of data

Charging by event (e.g. text message)

For a service like IPTV, the most viable charging options would be charging by duration of the

video streaming session and charging by the QoS received. This is because IPTV services are real-

time and the length of the service session is not usually known at the start of the session.

Charging in the IMS should be able to allow users to have options of how they pay for their services.

A user should be able to opt for a pre-paid solution where they pay in advance for usage of services.

To allow for this the charging system must be able to have an always-available real-time link to the

user’s account. In addition, the system would also need to have the ability to change the value of this

account as service usage occurs in real-time. This would comprise the online aspects of the charging

system.

Another case could be where the user would opt to post-pay for IMS services after a pre-set interval

of service usage. The charging system would be able to keep accurate records of usage in the time

interval and be able to build billing information that could then be requested from the user before

any further usage is allowed. The information collected should contain the user identity and network

services usage records. This would then compromise the offline aspects of the charging system.

7.2 IMS testbed

To implement the IPTV charging system in the IMS a suitable environment was needed to provide

the needed IMS functions and interfaces. The FOKUS Open IMS Core was used to provide this

environment. All the components contained in the Open IMS Core make use of Open Source

software (e.g. the SIP Express Router (SER) or MySQL) [29].

This IMS Core can be broken up into four important modules:

Home Subscriber Server – HSS

The Call Service Control Functions – CSCFs

58

The Java Diameter Peer

The C Diameter Peer

The HSS in the Open IMS Core is written in Java and incorporates database functionality. It utilises

the Java Diameter Peer module to send and receive the necessary Diameter messages in order to

support the different AAA messages. The HSS has a web interface that allows for the configuration

of network characteristics such as adding an AS or creating service triggering parameters. The

CSCFs are all written in C. They all incorporate the use of the SER to provide the ability to send,

receive and process SIP messages. In addition the S-CSCF and the I-CSCF contain the C Diameter

Peer which gives the functions the ability to send and receive Diameter messages to and from the

HSS.

The FOKUS Open IMS Core is ideal for developing an IPTV charging system as it provides a

reference IMS core implementation. This implementation can be used for testing IMS technology

and prototyping IMS applications for research purposes.

7.3 Charging Trigger Function

A CTF is the function in the network that will create charging events used for both online and offline

charging. It creates these events based on network resource usage, for example the usage of IPTV

services. The IPTV AS will thus need to be enhanced to provide this functionality. In addition to the

current ability of service provision the AS will need to perform the following functions.

Process all requests for content and be able to identify the user and the user’s consumption of

the resource in real-time.

Forward all recorded data to the relevant charging function.

In the case of online charging, be able to delay the servicing of a request only until the user

has been authorized to access the content and has sufficient credits.

In the case of online charging, be able to supervise the usage of the service and how it

directly reflects on the users account thus allowing the CTF the ability to end a service

59

session when credits have been consumed

To be able to execute the above mentioned functions the UCT IPTV AS will need to be extended in

order to perform further logic for each service request. This means that a new CTF module has to be

designed and incorporated into the AS. Currently, the UCT IPTV AS can only send and listen for

SIP messages. It will be extended to have the added ability to send and listen for Diameter messages

from the HSS, the Online and the Offline Charging Functions.

7.4 The Offline Charging Function

The Charging Data Function (CDF) essentially performs all the offline charging functions. It is a

module that collects charging information through a link with the CTF. From this information it will

then be able to create a CDR that can be sent to the Billing Domain for further processing. This

module will need to be able to receive the Diameter messages conveying the user and resource

usage. For this reason, the CDF implements the Diameter Rf interface with the CTF.

7.5 The Online Charging Function

The OCF designed for this implementation will be a Session Based Charging Function. This means

that the charging will be content charging i.e. for how long a user receives the IPTV service. It will

have a Rating Function that has the responsibility of calculating the service usage in terms of credits.

Since the OCF is using a SBCF, the RF will need to perform these calculations based on a timing

scale and with prior knowledge of tariff information. The OCF also has the added responsibility of

alerting the CTF when the user’s credits have been used up so that the CTF can end the network

service to the user. The module will thus need to be able to receive and listen for Diameter messages

for the CTF. It will implement the Diameter Ro interface.

7.6 The Charging System Interfaces

Three IMS reference points will be developed for this implementation.

Sh: to cater for the relationship between the AS and the HSS. This interface in a charging

context relays information to the AS about the address of the charging functions.

60

Rf: to cater for the relationship between the AS and the CDF. This interface will mainly

allow the CTF to relay the charging information to the CDF so that it can then create CDR.

Ro: to cater for the relationship between the AS and the OCF. This interface will allow for

the sending and receiving of online Credit Control messages. These messages will fully

encapsulate the function of online charging in the IMS.

This then completes the IPTV charging architecture presented. The following figure depicts this

architecture in its entirety.

IMS Client

Media Server

IPTV AS

P-CSCF

I-CSCF S-CSCF

HSS

CDF

OCF

CxCx ISC Ro

IMS core

SIP

Diameter

RTP/RTSP

Sh

Rf

Figure 7.1: IPTV Charging Architecture

61

Chapter 8 IPTV Charging Implementation

This section specifies the IPTV charging system implementation.

8.1 UCT advanced IPTV Software

To create a CTF we needed to incorporate CTF functions into an IPTV AS. The UCT advanced

IPTV indirection server is the IPTV AS that will be extended. The server and client were developed

by members of the UCT Communications Research Group in order to provide a standards compliant

implementation of an IMS based IPTV service.

The architecture of the IPTV streaming system includes the Open IMS Core, the indirection IPTV

AS and a third Party RTSP Media Server. The end user client software in this implementation is the

UCT IMS client.

Referring to the Chapter 1 figure 1.1 the IPTV architecture involves three main stages [30]:

1st Stage: The UCT IMS Client creates an SIP INVITE request for one of the IPTV services

and sends this request to the Indirection AS. A prior knowledge of available content is needed

otherwise the request cannot be serviced.

2nd Stage: The Indirection AS consults a hash table that links service requests to RTSP

addresses, and returns the relevant RTSP address to the UCT IMS Client in a SIP 200 OK

response.

3rd Stage: The UCT IMS Client initiates an RTSP session with the 3rd party media server.

The IPTV AS as well as the IMS Client are both based on the eXosip software package. This

software provides a convenient API for the sending and listening of SIP messages. This allows

developers the ability to catch specific SIP events and take actions upon receiving these messages.

62

The most important SIP event that the AS catches is the EXOSIP_CALL_INVITE as this is the

message that contains the content that the client is requesting. After mapping the request to the

address of where the user can obtain the content the AS builds a response. This response contains

this information and is a SIP 200 OK message. It includes a header that contains the information of

where the client can obtain the media content.

Once the AS was extended to incorporate the new CTF, a new sequence of events takes place:

1st Stage: The UCT IMS Client creates an SIP INVITE request for one of the IPTV services and

sends this request to the Indirection AS. A prior knowledge of available content is still needed.

2nd

Stage: The AS sends the required messages to the online and offline functions. To the offline

function the AS would send a:

cdf = Rf_ACR(session_id, origin_host ,origin_realm, destination_realm,

START, acr_number, destination_host) this Diameter message contains all the

AVPs for an ACR message as stated in table 5.3. The values for the AVP are shown

in the table below:

Table 8.1: Contents of an ACR message

Attribute Name AVP Value

Session Identifier Unique session generated ID

Origin Host iptv.open-ims.test

Origin Realm open-ims.test

Destination Realm open-ims.test

Accounting Request Type START

Accounting Request Number Unique request number

Destination Host cdf.open-ims.test

63

To the online function the AS would send a:

ocf = Rf_ACR(session_id, origing_host, origin_realm, destination_realm,

INITIAL_REQUEST, cc_number, destination_host) this Diameter message

contains all the AVPs for a CCR message as stated in table 5.4. The values for the

AVP are shown in the table below:

Table 8.2: Contents of a CCR message

Attribute Name AVP Value

Session Identifier Unique session generated ID

Origin Host iptv.open-ims.test

Origin Realm open-ims.test

Destination Realm open-ims.test

Credit Control Request Type INITIAL_REQUEST

Credit Control Request Number Unique request number

Destination Host ocf.open-ims.test

In both cases the AS will wait until it receives a response from the charging functions before it

carries on with servicing the client request. The sent message contains the AVPs necessary for the

charging functions to initialize charging activities. Calling these functions invokes the AS to create

Diameter messages and wait for the corresponding responses to those specific messages. In the case

of Offline charging, sending an Accounting Record Request should be replied with an Accounting

Record Answer with the corresponding Session Id and a Result code of Success. Similarly in the

64

case of Online charging, sending a Credit Control Request should be replied with a Credit Control

Answer with the corresponding Session ID and a Result code of Success. All the Diameter aspects of

the AS are implemented based on the C Diameter Peer software Package.

3rd

Stage: Once the AS receives the responses from the charging functions (and after checking that

they contain a result code indicating that it was a successful response) the AS can then consult a

hash table that links service requests to RTSP addresses. It then returns the relevant RTSP address to

the UCT IMS Client in a SIP 200 OK response.

4th

Stage: The UCT IMS Client initiates an RTSP session with the 3rd party media server.

5th

Stage: To achieve session based charging for both the offline and online charging functions the

use of timers was added to the AS. The AS will continually send messages to the charging function

when it is providing a service to the user, in regular intervals. This allows the charging function to

know that no failures have occurred.

6th

Stage: When the media session ends the AS will the alert the charging functions to stop

performing charging functions and end the charging session.

8.2 Added Interfaces

8.2.1 AS HSS

This interface can be used for many different purposes. However, in a charging context, the HSS

provides the AS with information of where to locate the charging functions. It sends a User Data

Request that causes the HSS to respond with a User Data Answer where one of the AVPs would

contain the addresses of the charging functions that the current user is mapped to. This interface was

implemented for completeness, as it is not used currently as there are only two charging functions

whose addresses are already known.

In the case of sending the UDR to the HSS:

Firstly we create the AAA message using the C Diameter Peer and add the important

65

information to the message. This information comprises of elements such as an application

ID (in this case the Sh ID) and the command code to the AAA message.

Then we add the relevant AVPs to the message.

Once the message is complete, we prepare it for sending by adding it to a transaction list.

The message is then sent to the HSS and we wait until we receive a reply. A specific timeout

period is built in to avoid waiting indefinitely in case there was an error.

Once a successful reply is received the message is removed from the transaction list and the

message is destroyed lastly, we return the replied message.

Once the required information is extracted from the message we can move on to perform the next

step which is communicating with the charging functions.

8.2.2 AS CDF

This interface enables the CTF and CDF to perform session-based offline charging. When the AS

receives a request it sends an ACR to the CDF. The first messages will have an Accounting Type

AVP with the value set to START. During the media session the CTF will send messages with the

Accounting Type AVP set to INTERIM. Lastly when the AS stops recording the media session, it

will send a message with the Accounting Type AVP set to STOP.

The procedure of sending the message to the CDF is similar to the one above detailing the message

sent to the HSS. In offline charging, no further actions need to be taken by the AS once it receives

the reply from the CDF.

8.2.3 AS OCF

This interface enables the CTF and OCF to perform session-based online charging with credit

reservation. When the AS receives a request it sends a CCR to the OCF. The first messages will

have a Credit Control Type AVP with the value set to INITIAL_REQUEST. During the media

session the CTF will send messages with the Credit Control Type AVP set to

INTERIM_REQUEST. When the AS stops recording the media session, it will send a message with

66

the Credit Control Type AVP set to STOP_REQUEST.

The procedure of sending the message to the OCF is similar to the one above detailing the message

sent to the HSS.

In online charging, the AS will need to take different actions depending on the result code of the

message sent. If it receives a success message from the OCF, it can start to or continue to provide the

service to the user. However, if it receives a message of type failure it will not provide or it will stop

providing the service to the user if for example, there are insufficient credits to continue any further.

To be able to send and receive these messages the use of the C Diameter Peer software package was

used and its functionality is explained in the next section.

8.3 C Diameter Peer

The AS, CDF and OCF all run the C Diameter Peer software. The HSS uses the Java Diameter

Peer. C Diameter Peer was chosen for the following reasons:

The AS was already written in C and thus expanding on it would be much easier if the C

Diameter Peer was chosen over the Java Diameter Peer.

C as a programming language holds some advantages over Java. Even though it would have

been easier to use the Java version, using C would provide for better performance than Java.

C is portable, fast and has a wide range of existing libraries.

The C Diameter Peer module was also used in the Open IMS CSCFs. Thus the prior work

would assist in developing the Diameter enabled AS.

This module has functions that allow for the creation and sending of AAA. Messages can be sent

synchronously or asynchronously, depending on the desired result. As most Diameter messages are

usually sent in pairs it is better to send them synchronously and wait until a reply for the message

has been received. This is achieved by adding a new transaction to the Transaction list. This list

contains a list of all the messages that need to receive replies. Adding a transaction to the

Transaction list causes blocking. This means that the process that sent the messages synchronously

67

will be blocked until a reply for that particular message has been received.

The C Diameter Peer also provided a suitable basis for the timers used in the implementation. When

each of the functions start running, a timer process is forked that allows for checking after a certain

amount of time if certain events have occurred and what actions to take if this is the case.

68

Chapter 9 Results

This chapter evaluates the functionality and performance of the IPTV charging architecture that was

implemented. One of the key issues that involve testing of charging systems is identifying and

performing the appropriate tests that determine the system’s true nature and functionality. Due to

timing constraints, a fully functional implementation of both the offline and online charging

functions including their correlating interfaces was not possible. Instead, an elementary charging

system was implemented that highlights the key functionalities of charging systems within the IMS.

This section is broken up into four subsections:

System architecture

Testing for relative performance

Testing for conformance

9.1 System architecture

For testing purposes, the system proposed in the chapter 6 was implemented including all nodes and

interfaces. As shown in figure 6.1 the IPTV charging functions can be subdivided into the client, the

IMS core, the IPTV AS, a third party media server and the charging functions.

As previously stated, the node functioning as the client is the UCT IMS Client. The IMS

implementation was the FOKUS Open IMS Core. The IPTV AS runs a Diameter compliant version

of the UCT Advanced IPTV Server. The third party RSTP media server was the VLC RSTP

streaming server module. Lastly, the charging functions are stand-alone C Diameter Peer servers

with added interface and charging functionality.

Due to time constraints, a distributed evaluation was not possible. The system design allows for the

69

separation of all the modules such that each entity can run on a different machine. All the functional

nodes ran over a single machine with the following specifications:

Operating system: Ubuntu Hardy 8.04

Processor: Intel Core 2 Duo 2.33 GHz, 2.39 GHz

System RAM: 1.95 GB

A domain name called the “open-ims.test” realm was created to run over the local machine. This

was implemented by using the loopback virtual network interface on the machine. A loopback

interface is useful for testing client software that communicates with server software over the same

computer while using the full IP stack functionality of the operating system. This means packets

could be sent to the different functions whilst they all ran on the same machine. To ensure that all

packets destined for the individual functions would actually reach their destination a Domain Name

System (DNS) had to be set up on the virtual host network to resolve all the functions names

accordingly.

9.2 Testing for performance

The added complexity that charging systems add to service provision is that they need to function

without the users’ knowledge. Any service that the AS provides to the end user should not be

affected by the implementation or modification of various charging mechanisms. These

modifications should be transparent to the user, and as such an important metric to test is the delay

introduced by the charging session establishment introduced at the beginning of all service requests.

During the normal operation of the charging system, readings were taking each time the AS would

send messages to the charging functions. For the offline case a random distribution of the four types

of ACR messages were sent and similarly was done for the online case with the CCR messages. The

following table shows the averaged results from sending 30 messages to each of the charging

functions.

70

Table 9.1: Delays in message processing

Node Mean value (seconds) Variance

CDF 0.24167 0.0606

OCS 0.4857 0.297

An analysis of the results shows that the delay introduced by the offline messages is almost constant

and hardly varying. This can be attributed to the fact that for the offline case all of the messages sent

to the CDF are handled in a similar manner and an answer is build for transmission after very little

processing done by the CDF The delay introduced by the online messages varies by almost 0.3

seconds. For the online case, different messages sent will result in different procedures being

performed by the OCS and the results of these procedures determines the length of time it takes the

OCF to build and transmit a response. These results are only applicable to a scenario where all

charging functions are implemented on the same machine. This was done to test whether each

function could adequately send and receive the relevant Diameter messages. In a distributed system

deployment where the charging functions would be located on different machines new variables such

packet loss and network delays would affect the operation of the system. The timing delays

produced above essentially highlight the processing delays of transactions within the charging

system. Assuming that the function ran on different machines a good system performance can be

obtained if the network joining the functions is relatively fast and not overly congested.

9.3 Testing for conformance

This testing is performed to determine if the charging system adheres to the charging specifications

set out by the 3GPP technical specifications for offline and online charging. For the purposes the

evaluation, it was assumed that the client “Alice” was registered for offline charging and the client

“Bob” was registered for online charging.

9.3.1 Evaluating offline charging

71

Of the two charging scenarios set forward for offline charging, the more robust session based option

was implemented. The requirements for session based offline charging are set forth below:

1. The AS has the ability to service user requests. The AS is always in a state where it is listening for

SIP messages that would contain a service request. This functionality is shown below.

Figure 9.1: (1) Requirement in AS

2. The AS has the ability to maintain ongoing service requests. If the AS is currently providing

services to the user, it will continue to do so until the user ends the service session. This functionality

is shown.


3. Upon receiving a request from the user for the IPTV service, the AS builds and sends an

Accounting Record message to the CDF. This message contains the identity of the user and

information relaying that a service is being request so charging management should be started for

that user. This function is shown below.


72

4. The CDF handles request for charging function. Upon receiving the ACR the CDF begins to

record the session and then sends an ACA message to the AS. The ACA contains information on

whether session recording was successfully initiated.

Figure 9.4: (4) Requirement in CDF

5. On success, AS starts timer for charging session management to implement session based

charging with the CDF. The AS then subsequently responds to the user’s service request and begins

to provide services to the user (shown below).


6. AS continuously updates CTF at timeout instances, in this case 30 seconds, while service is

ongoing. It does this by sending ACR messages with the Accounting Record Type AVP set to

INTERIM. The AS does this for the duration of the charging session.

73


7. CDF continuously acknowledges the updates. Upon receiving an INTERIM message from the

user, the CDF resets the session managing timer and sends back ACA of type SUCCESS. (seen

both above and below)


8. The AS informs CTF when service is no longer being provided to the user. When the user stops

using the service the AS will receive notification that the SIP session is concluded. Upon receiving

this information it sends an ACR message of type STOP to the CDF.

74

Figure 9.8: (8) and (9) Requirements in AS

9. The CDF will stop recording charging for the session upon receiving the ACR and informs the

AS that the session has ended with an ACA. (shown both above and below)


10. At this point charging sessions will be terminated on both the AS and the CDF.

9.3.2 Evaluating online charging

There are two sub-functions for online charging that affect its principles and require a more detailed

description. These functions are the rating and unit determination. The rating refers to the value of

units and how they relate to the user’s monetary account balance. Unit determination is the process

of giving weighting to the units in terms of the service provided to the user i.e. are units determined

on a time or volume basis. In the implemented architecture both these functions are handled by the

OCS. Additionally the charging system implements the “Session charging with Unit Reservation”.

The requirements of this system are set forth below:

1. The AS has the ability to service user requests. The AS is always in a state where it is listening for

SIP messages that would contain a service request. This functionality similar to the offline case

above.

2. The AS has the ability to maintain ongoing service requests. If the AS is currently providing

services to the user, it will continue to do so until the user ends the service session. Once again, this

is similar to the functionality of the offline case.

3. Upon receiving a request from the user for the IPTV service, the AS builds and sends a Credit

75

Control message to the OCF. This message contains the identity of the user and information

relaying that a service is being request so charging management, which includes account verification

and credit reservation, should be started for that user. This function is shown below.


4. The OCF handles request for charging function. Upon receiving the CCR the OCF first verifies

the amount of credits in the user’s account. Once this is done the OCF begins to record the session

and then sends a CCA message to the AS. The CCA contains information on whether session

recording was successfully initiated.

Figure 9.11: (4) Requirement in OCF

5. On success, AS starts timer for charging session management to implement session based

charging with the OCF. The AS then subsequently responds to the user’s service request and begins

to provide services to the user (shown below).


6. AS continuously updates OCF at timeout instances while service is ongoing. It does this by

sending CCR messages with the Credit Control Type AVP set to UPDATE_REQUEST. The AS

does this for the duration of the charging session.

76


7. OCF continuously acknowledges the updates. Upon receiving an UPDATE_REQUEST

message from the user, the OCF performs account verification and account debiting and upon

success resets the session managing timer and sends back CCA of type SUCCESS. (seen both

above and below)


8. The AS informs OCF when service is no longer being provided to the user. When the user stops

using the service the AS will receive notification that the SIP session is concluded. Upon receiving

this information it sends a CCR message of type STOP_REQUEST to the OCF

Figure 9.15: (8) and (9) Requirements in AS

.

77

9. The OCF will stop recording charging for the session upon receiving the CCR and informs the

AS that the session has ended with a CCA. (shown both above and below)


10. At this point charging sessions will be terminated on both the AS and the OCF

78

Chapter 10 Conclusions and Recommendations

There are many existing charging solutions that can be implemented over various different network

levels and layers. Most of these solutions are not suited for all types of NGN services. This project

provided a charging implementation for the case on IPTV over the IMS. The architecture used in

the implementation was chosen to provide the best possible charging, catering for both performance

and functionality.

The production of this thesis required research, design and development skills. Research on existing

IPTV architectures, as well as future IPTV architectures was carried out in order to gain a deep

understanding of how IPTV functions operate. Additionally, extensive research went into

distinguishing between the different types of charging solutions for the IMS. With this knowledge of

IPTV and charging, a charging system was designed and partially implemented in order to test the

fundamental system functionality

10.1 Conclusions

The three essential modules that were developed for the implemented IPTV charging system set the

basis for service level charging with the IMS context. A fully functional IPTV charging system is

quite complex due to the nature of the protocols and architectures involved, and thus could not be

implemented due to timing constraints. For example, it is assumed that the offline functions will

send charging data record to the billing domain for post-processing. It is also assumed that either the

online charging function maintains its own databases or it interacts with the billing domain. Both

these extensions were not implemented here as they lay outside of the scope initially set.

The implementation allowed two different users to have different charging mechanisms. This was a

prototype implementation and proves that the functionality to differentiate between different users

exists. As previously stated, it was assumed that IMS user Alice was on offline (post-paid) charging

and that IMS Bob was on online (pre-paid) charging. The AS handles the differentiation of the two

79

users.

A basic version of the rating management and unit reservation systems were implemented. It was

assumed that the Online Charging System performs all these functions. As these functions directly

affect the user’s account (through the OCS) an added layer of security is added to the proposed Ro

interface with authentication AVPs that would make sure accounting is managed securely.

The implementation illustrates the advantages of having a session based charging system. Session

based charging is more robust and efficient that event based charging. Additionally it is better suited

for an IPTV service charging in contrast to event based charging. Event charging is better suited for

once off services that don’t have variable lengths. IPTV, on the other hand would not be able to

provide fair billing to neither the network operator nor the user if the lengths of the service sessions

were not taken into account for charging purposes. The requirements of real-time charging

mechanisms for the implementation of pre-paid billing are adequately handled by the online

charging function. A user account can be verified and debited while the user is using the IPTV

service and this function is handled in an efficient manner.

The overall conclusion obtained here illustrates that this type of charging model effectively manages

the charging required for this service. Charging is based on a time-based usage model and the

introduction of charging does not affect the efficiency of the AS to provide the service. This model

allows for a fair charging scheme to be implemented such that customers would become attracted to

the service resulting in higher revenue generation for the network operator.

10.2 Recommendations and Future Work

Any service level charging could be implemented using the work presented in this thesis as a basis.

For example, a VoIP server has similar charging requirements to IPTV in terms of keeping track of

service period lengths in order to calculate and debit the user account. The C Diameter Peer software

makes it simple to add the needed Diameter functionality for a specific application implementation.

Any network layer charging functions could use the offline charging system for its implementation

of the Diameter Accounting Record Request and Answer messages. The offline function just gathers

information on the type of charging that occurs, maps this information to a user and then ultimately

80

sends this information to the billing domain.

Any charging interface could be implemented with the basis of the Sh, Ro and Rf interfaces that

were developed for this project. Additionally, with added functionality any diameter interface could

be implemented. This means interfaces for authentication and authorization as well as accounting.

Even though the Sh interface was implemented for this project it was not used as the two charging

functions where already known and charging information need not be exchanged between the AS

and the HSS. However, the Sh interface offers more than just charging functionality and expansion

on this could allow any AS to communicate with the HSS for various reasons should the need arise.

Thus, this thesis provides a very good starting point for a full IPTV charging implementation.

Incorporating mechanisms to provide scalability and more functionality on implemented nodes

would be a step towards implementing such a system.

81

References

[1] E. Mikoczy, J. I. Moreno, D. Sivchenko and B. Xu. “IPTV Services over IMS:

Architecture and Standardization”. IEEE Communications Magazine. May 2008.

[2] Y. Xiao, X. Du, J. Zhang, F. Hu, S. Guizani. “Internet Protocol Television (IPTV):

The Killer Application for the Next-Generation Internet”. IEEE Communications

Magazine. November 2007.

[3] R. Jain, “I Want My IPTV,” IEEE Multimedia, vol. 12, no 3, July–Sept. 2005, pp. 95–

96.

[4] Görmer and M Schläger. “Charging in the IP Multimedia Subsystem: A Tutorial.”

IEEE Communication Magazine. July 2007

[5] [Online] Available: http://www.eurocomms.com/features/111075/Billing_IMS_-

_Exploiting_possibilities.html [2008, October 16]

[6] [Online] Available : http://www.ericsson.com/technology/tech_articles/IMS.shtml

[2008, October 16]

[7] T. Choi. Accounting, “Charging and Billing for NGN Services and Network”, ITU-T

NGN Technical Workshop. March 2005.

[8] 3GPP TS 32.299, “Telecommunication Management; Charging Management;

Diameter Charging Applications,” Rel. 7.

[9] 3GPP TS 32.260, “Telecommunication Management; Charging Management; IP

Multimedia Subsystem (IMS) Charging,” Rel. 7


Online Charging System (OCS): Applications and Interfaces,” Rel. 7



[12] 3GPP TS 23.125, “Overall High Level Functionality and Architecture Impacts of

Flow Based Charging; Stage 2,” Rel. 6.

[13] P. Calhoun et al., “Diameter Base Protocol,” IETF RFC 3588, Sept. 2003.

[14] [Online] Available: http://www.traffixsystems.com/site/content/t1.asp?Sid=49&Pid=24

[2008, October 16]

[15] [Online ] Available :

http://www.intecbilling.com/Intec/Products+Services/Products/Charging+and+Billing/

[2008, October 16]

[16] F. Onimaru, T. Ishii, “Survey Report on the Activities of Information and

82

Communications related Fora” The Telecommunication Technology Committee.

March 2007

[17] K. Casier, B. Lannoo, J. Van Ooteghem. “Adoption and Pricing: The Underestimated

Elements of a Realistic IPTV Business Case” IEEE Communications Magazine.

August 2008

[18] S. Q. Khan, R. Gaglianello, M. Luna. “Experiences with Blending HTTP, RTSP, and

IMS”. IEEE Communications Magazine. March 2007R Kühne, G

[19] 3GPP Version TSG, “Overview of 3GPP Release 6”, Release 6, 2006.

[20] 3GPP Version TSG, “Overview of 3GPP Release 7”, Release 7, 2008.

[21] [Online] Available: http://www.instat.com/press.asp?Sku=IN0603199MBS&ID=1634

[2008, October 16]

[22] M. Volk, J. Guna, A. Kos, and J. Bester. “Quality-Assured Provisioning of IPTV

Services within the NGN Environment”. IEEE Communications Magazine. May 2008.

[23] G. Camarilla, M. A. Garcia-Martin. “The 3G IP Multimedia Subsystem.” John Wiley

& Sons Ltd. May 2006.

[24] 3GPP TS 29.329 “Sh Interface based on the Diameter protocol,” Rel. 8.

[25] 3GPP TS 29.228, “IP Multimedia (IM) Subsystem Cx and Dx Interfaces; Signalling

Flows and Message Contents,” Rel. 6.




Charging Architecture and Principles,” Rel. 7.

[28] [Online] Available: http://www.umts-forum.org/content/view/2000/98/ [2008, October

16]

[29] [Online] Available: http://www.openimscore.org/ [2008, October 16]

[30] [Online] Available: http://uctimsclient.berlios.de/uctviptv_advanced_howto.html [2008,

October 16]

83

Appendix A:

How to Install the Diameter Enabled SIP IPTV AS

Before installing the AS, it is assumed that there is an Open IMS Core installed on the machine. For

instructions of how to install the Open IMS Core, one can refer to:

http://uctimsclient.berlios.de/openimscore_on_ubuntu_howto.html

Installing from source will need to have the required packages installed first:

libosip (2.2.3)

libeXosip (2.2.3)

libosip-dev

libexosip-dev

Then simply type make from the root directory.

Configure the FHoSS

Configure the FHoSS to forward IPTV requests to the machine running the AS.

The steps are:

1. Access the HSS http console at http://localhost:8080.

Username: hssAdmin

Password: hss

2. Add an application server (the server runs on port 8010)

3. Add a trigger point (the example given below matches requests such as

http://uctimsclient.berlios.de/openimscore_on_ubuntu_howto.html

http://localhost:8080/

84

sip:[email protected] or sip:[email protected])

4. Link the application server and trigger point with the initial filter criteria

5. Add the iFC to the default service profile

For more information of performing these steps refer to the Open IMS Core website:

http://www.openimscore.org/

Once complete the Trigger Point should look like this:

Setup XML file that maps channel requests to RTSP addresses

The AS maps the channel requested to a specific RTSP address.

http://www.openimscore.org/

85

We need to create an XML file that contains the SIP URI key and RTSP value for each media file

your media server provides. This file will be passed as an argument when running the Indirection

AS.

It should look as follows:

Example XML File:

<?xml version="1.0" encoding="UTF-8"?>

<key-value_pairs> <key-value_pair> <key>channel1</key> <value>rtsp://media_server_address.domain:8000/requested_channel</value> </key-value_pair> </key-value_pairs>

NOTE: The key_val is the part of the SIP URI that the client will be inviting e.g.

sip:[email protected] The val_val is the corresponding RTSP address of the video

that will be streamed to the client. e.g. rtsp://media_server_address:port/video_name

When the server starts up it reads this XML file inserting all the values and the corresponding keys

into the hash table.

Setting up a 3rd Party RTSP enabled Media Server

VideoLAN Client

1. Download the latest version of VLC from http://www.videolan.org/vlc/.

2. Install VLC.

3. There are a number of ways of setting up VLC to act as a media server and they can be

found at (http://wiki.videolan.org/Documentation:Streaming_HowTo/VLM) See the “Video

on Demand” section for a fairly easy way of setting up a video that will be streamed to

requesting clients.

4. See “Scheduled broadcasting” under the “Multiple Streams” section of the above link for

setting up broadcast streams.

Co-ordination is needed between the AS hash table that maps channel requests to RTSP addresses

and the RTSP addresses of the media server. E.g. If you are streaming a video called "movie1" on

86

the RTSP address rtsp://media_server_address/movie1, you need to edit the key_value_file such

that channel "movie1" is mapped to RTSP address rtsp://media_server_address/movie1

Set up XML file that allows the server to locate Diameter peers

An example of the configuration file that allows the server to connect to other Diameter servers.

<?xml version="1.0" encoding="UTF-8"?> <DiameterPeer FQDN="iptv.open-ims.test" Realm="open-ims.test" Vendor_Id="10415" Product_Name="CDiameterPeer" AcceptUnknownPeers="0" DropUnknownOnDisconnect="1" Tc="30" Workers="4" QueueLength="32" > <Peer FQDN="hss1.open-ims.test" Realm="open-ims.test" port="3868"/> <Peer FQDN="hss2.open-ims.test" Realm="open-ims.test" port="3868"/> <Acceptor port="3868" /> <Acceptor port="3869" bind="127.0.0.1" /> <Acceptor port="3870" bind="192.168.1.1" /> <Auth id="16777216" vendor="10415"/> <Auth id="16777216" vendor="4491"/> <Auth id="16777216" vendor="13019"/> <Realm name="my.open-ims.test"> <Route FQDN="blackjack" metric="2"/> <Route FQDN="test1" metric="3"/> <Route FQDN="test2" metric="5"/> </Realm> <Realm name="test1.open-ims.test"> <Route FQDN="test3" metric="7"/> <Route FQDN="test4" metric="11"/> </Realm> <Realm name="test2.open-ims.test"> <Route FQDN="test5" metric="13"/> </Realm> <DefaultRoute FQDN="hss1.open-ims.test" metric="15"/> <DefaultRoute FQDN="hss2.open-ims.test" metric="13"/> </DiameterPeer>

Run the Indirection AS

http://www.openimscore.org/docs/ser_ims/icscf__pg_8sql.html#37ff02c0a0695c115cdc2a671d82904d

87

Usage: main [key-value_file] [peer-diameter-file] debug

Key-value_file is the file mapping channels and videos to the content on the media server

Peer-diameter-file is the diameter configuration file

Debug is the integer number setting the level of debug mode for running the server

The server is not reader to except requests.

88

Appendix B:

This section contains the more important code developed for this thesis.

Code in the AS

Method to send ACR messages to CDF. The method to send CCR messages to OCF is similar to this

one:

AAAMessage *Rf_ACR(str session_id, str ohost, str orealm, str drealm,

unsigned int acc_type, str acc_number, str dhost)

{

AAAMessage *acr=0,*aca=0;

AAASessionId sessId={0,0};

AAATransaction *trans=0;

unsigned int hash=0,label=0;

sessId = AAACreateSession();

trans = AAACreateTransaction(IMS_Rf,IMS_ACR);

acr = AAACreateRequest(IMS_Rf,IMS_ACR,Flag_Proxyable,&sessId);

if (!acr) goto error;

// mandatory avps

if (!Rf_add_vendor_specific_appid(acr,IMS_vendor_id_3GPP,IMS_Rf,0 /*IMS_Rf*/)) goto

error;

if (!Rf_add_origin_host(acr, ohost)) goto error;

if (!Rf_add_destination_host(acr, dhost)) goto error;

if (!Rf_add_origin_realm(acr, orealm)) goto error;

if (!Rf_add_destination_realm(acr, drealm)) goto error;

if (!Rf_add_Accounting_Record_Type(acr, acc_type)) goto error;

if (!Rf_add_Accounting_Record_Number(acr, acc_number)) goto error;

trans->hash=hash;

trans->label=label;

trans->application_id=acr->applicationId;

trans->command_code=acr->commandCode;

if (!AAASendMessageToPeer(acr,&dhost,0,0)) goto error;

AAADropSession(&sessId);

AAADropTransaction(trans);

return aca;

89

error:

//free stuff

if (trans) AAADropTransaction(trans);

if (sessId.s) AAADropSession(&sessId);

if (acr) AAAFreeMessage(&acr);

return 0;

}

Method to add an AVP to the Diameter message:

static inline int Ro_add_avp(AAAMessage *m,char *d,int len,int avp_code,

int flags,int vendorid,int data_do,const char *func)

{

AAA_AVP *avp;

if (vendorid!=0) flags |= AAA_AVP_FLAG_VENDOR_SPECIFIC;

avp = AAACreateAVP(avp_code,flags,vendorid,d,len,data_do);

if (!avp) {

LOG(L_ERR,"ERR: Failed creating avp\n");

return 0;

}

if (AAAAddAVPToMessage(m,avp,m->avpList.tail)!=AAA_ERR_SUCCESS) {

LOG(L_ERR,"ERR: Failed adding avp to message\n");

AAAFreeAVP(&avp);

return 0;

}

return 1;

}

Code in the CDF

Method to receive diameter message from AS. OCF contains similar method.

AAAMessage* Rf_ACA( AAAMessage * acr)

{

AAAMessage *aca_msg;

int acr_data;

aca_msg = AAACreateResponse(acr);

if (!aca_msg) return 0;

if (Rf_get_accounting_record_type(acr, &acr_data))

msg_handler(acr_data);

Rf_add_vendor_specific_appid(aca_msg,IMS_vendor_id_3GPP,IMS_Rf,0 /*IMS_Rf*/);

Rf_add_result_code(aca_msg,DIAMETER_SUCCESS);

90

return aca_msg;

}

Method to perform charging functions in the CDF

void msg_handler(int msg_type)

{

a_client *new_cl;

switch (msg_type)

{

case START:

//Start Session Recording

LOG(L_WARN,"Client requested service, recording of sessiong will begin.\n");

list_of_clients->clocking = Running;

list_of_clients->events = SStart;

break;

case INTERIM:

// reset the timer

list_of_clients->events = Interim;

LOG(L_WARN,"Interim message recieved, timer will be reset... credits so far

%d \n",list_of_clients->credits);

break;

case STOP:

// stop the timer

LOG(L_WARN,"Session Closed, recording will end. %d \n",list_of_clients-

>credits);

list_of_clients->events = SStop;

list_of_clients->clocking = Not;

break;

case EVENT:

//not used

list_of_clients->events = Event;

break;

}

}

Code in the OCF

Method to perform charging functions in the OCF

void msg_handler(int msg_type, int *result)

{

*result = 0;

switch (msg_type)

{

91

case START:

//Start Session Recording

if (msg_time->credits > 0){

msg_time->events = SStart;

msg_time->clocking = Running;

*result = 1;

LOG(L_WARN,"Client requested service, recording of session will

begin.\n");

}

break;

case INTERIM:

// reset the timer

if (msg_time->credits > 0){

msg_time->events = Interim;

LOG(L_WARN,"Interim message recieved, timer will be reset... credits

so far %d \ n",msg_time->credits);

*result = 1;

}else LOG(L_WARN,"Insufficient credits. \n");

break;

case STOP:

// stop the timer

LOG(L_WARN,"Session Closed, recording will end. %d \n",msg_time-

>credits);

msg_time->events = Event;

msg_time->clocking = Not;

*result = 1;

break;

case EVENT:

//not used

msg_time->events = Event;

break;

}

}

92

Appendix C:

Accompanying CD-ROM

This appendix describes the contents of the attached CD-ROM.

Source Code

Contains the source code of the IPTV Charging system

Research Documents

Contains some of the research papers used.

Thesis Document

This folder contains the thesis document in PDF and DOC format.

IPTV Charging in the IP Multimedia Subsystem

Documents

Transcript of IPTV Charging in the IP Multimedia Subsystem