Upload
rockys11
View
2.536
Download
5
Embed Size (px)
DESCRIPTION
Citation preview
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.2: (2) Requirement in AS...................................................................................................... 71
Figure 9.3: (3) Requirement in AS...................................................................................................... 71
Figure 9.4: (4) Requirement in CDF ................................................................................................... 72
Figure 9.5: (5) Requirement in AS...................................................................................................... 72
Figure 9.6: (6) Requirement in AS...................................................................................................... 73
Figure 9.7: (7) Requirement in CDF ................................................................................................... 73
Figure 9.8: (8) and (9) Requirements in AS ....................................................................................... 74
Figure 9.9: (9) Requirement in CDF ................................................................................................... 74
Figure 9.10: (3) Requirement in AS ................................................................................................... 75
Figure 9.11: (4) Requirement in OCF................................................................................................. 75
Figure 9.12: (5) Requirement in AS ................................................................................................... 75
Figure 9.13: (6) Requirement in AS ................................................................................................... 76
Figure 9.14: (7) Requirement in OCF................................................................................................. 76
Figure 9.15: (8) and (9) Requirements in AS ..................................................................................... 76
Figure 9.16: (9) Requirement in OCF................................................................................................. 77
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];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
Attribute Name AVP Code
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
Attribute Name AVP Code
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.
Figure 9.2: (2) Requirement in AS
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.
Figure 9.3: (3) Requirement in AS
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).
Figure 9.5: (5) Requirement in AS
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
Figure 9.6: (6) Requirement in AS
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)
Figure 9.7: (7) Requirement in CDF
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)
Figure 9.9: (9) Requirement in CDF
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.
Figure 9.10: (3) Requirement in AS
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).
Figure 9.12: (5) Requirement in AS
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
Figure 9.13: (6) Requirement in AS
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)
Figure 9.14: (7) Requirement in OCF
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)
Figure 9.16: (9) Requirement in OCF
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
[10] 3GPP TS 32.296, “Telecommunication Management; Charging Management;
Online Charging System (OCS): Applications and Interfaces,” Rel. 7
[11] 3GPP TS 32.299, “Telecommunication Management; Charging Management;
Diameter Charging Applications,” 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.
[26] 3GPP TS 32.299, “Telecommunication Management; Charging Management;
Diameter Charging Applications,” Rel. 7.
[27] 3GPP TS 32.240, “Telecommunication Management; Charging Management;
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
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.
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"/><!-- 3GPP Cx --> <Auth id="16777216" vendor="4491"/><!-- CableLabs Cx --> <Auth id="16777216" vendor="13019"/><!-- ETSI/TISPAN Cx --> <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
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.