Your SlideShare is downloading. ×
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
IPTV Charging in the IP Multimedia Subsystem
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

IPTV Charging in the IP Multimedia Subsystem

2,279

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,279
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
117
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 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
  • 2. 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 i
  • 3. 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. ii
  • 4. 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. iii
  • 5. 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 iv
  • 6. 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 v
  • 7. 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 vi
  • 8. 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 vii
  • 9. 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 viii
  • 10. 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 ix
  • 11. 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 x
  • 12. 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 xi
  • 13. 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 xii
  • 14. 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 xiii
  • 15. 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 xiv
  • 16. 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 1
  • 17. 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. 2
  • 18. 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. IPTV Open IMS Core Application Server Media Server IMS Client 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 3
  • 19. 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 4
  • 20. 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. 5
  • 21. 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. 6
  • 22. 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 7
  • 23. 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 8
  • 24. [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 9
  • 25. 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 10
  • 26. 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 11
  • 27. 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. 12
  • 28. 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 3 rd 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 13
  • 29. 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 14
  • 30. 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 15
  • 31. 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. 16
  • 32. 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 3 rd 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. 17
  • 33. Service Layer OSA AS SIP AS IM-SSF Control Layer HSS MFRC SLF S-CSCF MRFP I-CSCF BGCF P-CSCF MGCF IP Network PSTN Mobile Phone PDA Laptop Telephone 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 18
  • 34. 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 19
  • 35. 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. 20
  • 36. 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 21
  • 37. 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 22
  • 38. 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:Alice.Smith@domain.com sip:Bob.Brown@example.com sip:carol@wsl234.domain2.com;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:Alice.Smith@Adomain.com 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 23
  • 39. 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. 24
  • 40. IPTV application server platform IPTV AS Media Server ISC Sh ISC Sh IMS core Media control and Cx distributed media Cx delivery architecture Xa HSS Ut S-CSCF I-CSCF MDF MCF Xc P-CSCF Xd Gm RTP RTSP IMS User HTTPS Diameter SIP 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. 25
  • 41. 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. 26
  • 42. 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. 27
  • 43. 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 28
  • 44. 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 Bx Operator’s post processing system Bo Charging Function Charging Function Gateway Gateway Accounting Balance Rating Management Function Function Ga Ga Rc Re Online Charging Charging Data Function Function Offline Charging Charging Trigger Online Charging Ro Function Rf Figure 5.1: Charging in the IMS 29
  • 45. 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 Rf Billing CDF Ga CGF Gi Domain P-CSCF I-CSCF S-CSCF 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 30
  • 46. 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. 31
  • 47. CTFs IMS-AS MRFC Optional Billing S-CSCF ISC IMS-GWF Ro OCF Bo Domain 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 32
  • 48. 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 Diameter Diameter Credit Diameter SIP Application for Application for Cx Control Application Sh Interface Interface 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. 33
  • 49. 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. 34
  • 50. 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 35
  • 51. 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: 36
  • 52. 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. 37
  • 53. 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 38
  • 54. 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. 39
  • 55. 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. 40
  • 56. 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 41
  • 57. 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. HSS AS Diameter UDR Diameter UDA 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. 42
  • 58. HSS AS Diameter PUR Diameter PUA 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. 43
  • 59. HSS AS Diameter SNR Diameter SNA User data changes Diameter PNR Diameter PNA 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. 44
  • 60. 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 45
  • 61. 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. 46
  • 62. 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 47
  • 63. 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. CTF CDF Service Delivery ACR (EVENT) Process Accounting Request ACA 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. 48
  • 64. CTF CDF Service Request ACR (START) Open CDR ACA Timer ACR(INTERIM) Update CDR ACA Service Termination ACR (STOP) Close CDR ACA 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. 49
  • 65. 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 50
  • 66. 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. 51
  • 67. CTF Service Request CCR (EVENT_REQUEST) Perform Direct Debiting CCA 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. 52
  • 68. CTF OCS Service Request CCR (INITIAL_REQUEST) Perform Charging Control CCA Service Delivery CCR (TERMINATION_REQUEST) Perform Charging Control CCA 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 53
  • 69. 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. CTF OCS Session Request CCR (INITIAL_REQUEST) Perform Charging Control CCA Session Delivery CCR(INTERIM_REQUEST) Timer Perform Charging Control CCA Session Termination CCR (TERMINATION_REQUEST) Perform Charging Control CCA 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: 54
  • 70. 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. 55
  • 71. 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 56
  • 72. 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 57
  • 73. 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 58
  • 74. 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. 59
  • 75. 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. Rf Sh CDF IMS core Cx Cx Ro ISC HSS IPTV AS I-CSCF S-CSCF OCF P-CSCF Media Server Diameter SIP RTP/RTSP IMS Client Figure 7.1: IPTV Charging Architecture 60
  • 76. 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. 61
  • 77. 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 62
  • 78. 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 63
  • 79. 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 64
  • 80. 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 65
  • 81. 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 66
  • 82. 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. 67
  • 83. 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 68
  • 84. 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. 69
  • 85. 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 70
  • 86. 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 71
  • 87. 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. 72
  • 88. 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. 73
  • 89. 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 74
  • 90. 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. 75
  • 91. 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 . 76
  • 92. 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 77
  • 93. 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 78
  • 94. 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 79
  • 95. 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. 80
  • 96. 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 81
  • 97. 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] 82
  • 98. 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 83
  • 99. sip:channel1@iptv.open-ims.test or sip:channel1@media.open-ims.test) 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. 84
  • 100. 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:video_name@iptv.open-ims.test 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 85
  • 101. 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 86
  • 102. 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. 87
  • 103. 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; 88
  • 104. 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 avpn"); return 0; } if (AAAAddAVPToMessage(m,avp,m->avpList.tail)!=AAA_ERR_SUCCESS) { LOG(L_ERR,"ERR: Failed adding avp to messagen"); 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); 89
  • 105. 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) { 90
  • 106. 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; } } 91
  • 107. 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. 92

×