An IMS-based VOD Service Supporting Session Continuation

(1)

Institutionen för systemteknik

Department of Electrical Engineering

Examensarbete

An IMS-based VOD Service Supporting Session

Continuation

Examensarbete utfört i Informationskodning vid Tekniska högskolan i Linköping

av

Jonatan Johansson LITH-ISY-EX--07/4048--SE

Linköping 2009

Department of Electrical Engineering Linköpings tekniska högskola

Linköpings universitet Linköpings universitet

(2)

(3)

An IMS-based VOD Service Supporting Session

Continuation

Examensarbete utfört i Informationskodning

vid Tekniska högskolan i Linköping

av

Jonatan Johansson LITH-ISY-EX--07/4048--SE

Handledare: Peter Johansson

isy, Linköpings Universitet

Åsa Detterfelt

Attentec AB

Examinator: Robert Forchheimer

isy, Linköpings Universitet

(4)

(5)

Avdelning, Institution Division, Department

Division of Information Coding Department of Electrical Engineering Linköpings universitet

SE-581 83 Linköping, Sweden

Datum Date 2009-12-15 Språk Language Svenska/Swedish Engelska/English ⊠ Rapporttyp Report category Licentiatavhandling Examensarbete C-uppsats D-uppsats Övrig rapport ⊠

URL för elektronisk version

http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-52343

ISBN — ISRN

LITH-ISY-EX--07/4048--SE Serietitel och serienummer Title of series, numbering

ISSN —

Titel

Title An IMS-based VOD Service Supporting Session Continuation

Författare Author

Jonatan Johansson

Sammanfattning Abstract

IP-based TV (IPTV) is gradually replacing traditional means for broadcasting. At the same time, players from the telecom industry is seeking to create a new, standardized architectural framework for delivering all kinds of multimedia services over IP to end users; the IP Multimedia Subsystem (IMS).

This thesis is about video on demand, one of the more popular services enabled by IPTV. The thesis starts out by introducing the reader to IMS and IPTV and presents the current work in the area of IMS-based IPTV, done by the TISPAN committee of the ETSI.

The author then takes an explorative approach in investigating how a signaling schema for an IMS-based VOD service could look like, based on TISPAN’s existing work. The service is subject to an extra requirement; it should support session continuity, meaning it should be possible to resume the streaming of a video where the user left off, possibly on a different device. The investigation shows that it is possible to combine SIP and RTSP in several ways to get the desired behaviour.

The second part of the results consists of a proof of technology-implementation of the signaling schema that is the output from the first part. The implemented service runs on an IPTV set-top box on the client side, and a regular PC on the server side. The service uses open source software to a great extent and is fairly portable. A sample VOD session using the implemented system is presented along with full message contents.

The thesis concludes with a summary of the results and a discussion on what has been left out from the implementation and possibly subject to further studies. Finally, there is a brief summary on the recent developments within the field of IMS-based IPTV.

Nyckelord

(6)

(7)

Abstract

IP-based TV (IPTV) is gradually replacing traditional means for broadcasting. At the same time, players from the telecom industry is seeking to create a new, standardized architectural framework for delivering all kinds of multimedia services over IP to end users; the IP Multimedia Subsystem (IMS).

This thesis is about video on demand, one of the more popular services enabled by IPTV. The thesis starts out by introducing the reader to IMS and IPTV and presents the current work in the area of IMS-based IPTV, done by the TISPAN committee of the ETSI.

The author then takes an explorative approach in investigating how a signaling schema for an IMS-based VOD service could look like, based on TISPAN’s existing work. The service is subject to an extra requirement; it should support session continuity, meaning it should be possible to resume the streaming of a video where the user left off, possibly on a different device. The investigation shows that it is possible to combine SIP and RTSP in several ways to get the desired behaviour.

The second part of the results consists of a proof of technology-implementation of the signaling schema that is the output from the first part. The implemented service runs on an IPTV set-top box on the client side, and a regular PC on the server side. The service uses open source software to a great extent and is fairly portable. A sample VOD session using the implemented system is presented along with full message contents.

The thesis concludes with a summary of the results and a discussion on what has been left out from the implementation and possibly subject to further studies. Finally, there is a brief summary on the recent developments within the field of IMS-based IPTV.

(8)

(9)

Acknowledgments

A number of people have been involved in this thesis project. These people, who have contributed in one way or the other to the end result, are: Karl Anders-son, Henrik CarlsAnders-son, Åsa Detterfeldt, Rickard von Essen, Robert Forchheimer, Tobias Gustafsson, Peter Johansson, Lars Wallström, Anders Weiland and Stefan Östergaard. The author wishes to take the opportunity and thank all of you!

(10)

(11)

Introduction

This first chapter serves to provide some background to this final thesis project. Properties of suitable readers1 _{are presented, as are the problem scope of the} thesis. Finally, an overview to remainder of the thesis is presented.

1.1 Intended audience and prerequisites

This thesis could be of interest to people working within the telecommunications or IPTV sectors. It can also be of interest to anyone interested in learning how IP-based media services can be delivered by using off-the-shelf Internet Engineering Task Force (IETF) protocols in a larger architectural context, the IMS.

In order to accomplish a focused text, it is assumed that the reader is already familiar with IP networks and some common network protocols. Although the IMS has been developed for about a decade now (and continues being so), it is still relatively unknown outside the telecommunications world; many people working with computer networks haven’t heard about it.

Therefore, an overview of the IP Multimedia Subsystem (IMS) is included within this thesis. Even so, engineers with previous experience of the IMS will benefit the most from reading it, since the complexity of the framework is not to be underestimated. Previous Video on Demand (VOD) knowledge is optional; previous Real Time Streaming Protocol (RTSP) knowledge helps but isn’t a re-quirement. It is helpful to have some basic knowledge about software systems in order to assimilate the part where the implementation is detailed (Chapter 6).

1.2 Actors involved

A large part of this project was carried out by the author in the premises of Attentec AB. Attentec AB is a consultant business which offer consulting services

1_{Properties here being limited to technical prerequisites.}

(18)

2 Introduction within the area of IMS2_{. In addition, Motorola AB produces Internet Protocol} TV (IPTV) set-top boxes and have contributed by lending Attentec AB a set-top box; this set-top box acts as user equipment in the project’s implementation part.

1.3 Problem definition

This thesis aims to

• investigate what work has been done so far in the area of IMS-based VOD. • investigate how a signaling schema for an IMS-based VOD service supporting

“session continuity” could look like, based on existing work.

• implement an IMS-compatible VOD service which is based on Session Ini-tiation Protocol (SIP) and RTSP and is deployable in a system where a Motorola Set-top box (STB) acts as the user equipment.

The first problem is solved by investigating if there are standards (or drafts that are likely to become standards) that deals with IMS-based VOD. Further, the parts of the most suitable current work that are related to this thesis are described.

For the second problem, an exploratory approach is taken. The requirements set by the standards are analyzed and possible solutions discussed, the result being signaling schemas suggestions that satisfy the requirements.

The solution to the third problem will be based on the solution of the second. One of the more important parts in solving this last problem is to prioritize and decide what will be left out, since implementing a complete system is a far too large undertaking.

1.4 Contents and reading advice

The remainder of this thesis is intended to be read sequentially. Parts of it can be skimmed or be read out-of-order, depending on how familiar the reader is with IPTV and IMS and what parts he/she is interested in. It is, however, the author’s recommendation that chapters 4-6 be read in-order. The following is an overview of the remaining chapters:

Chapter 2 explains the basics of IPTV. Its usefulness and the different services available are covered, with emphasis on VOD. The basic parts of a session continuity-supporting, IMS-based VOD service is explained.

Chapter 3 gives a brief overview of IMS – its history, the most fundamental network nodes and some basic concepts are covered. In addition, the chapter contains signaling flows for some common procedures.

2

Attentec offers systems development services in general, with IMS being one of their focus areas.

(19)

1.4 Contents and reading advice 3 Chapter 4 provides the reader with an overview of the work carried out so far

by the Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN) group of the European Telecommunica-tions Standards Institute (ETSI) in the area of IMS-based VOD. Architecture and high-level signaling flows are provided.

Chapter 5 builds on chapter 4 and discusses how a more detailed signaling schema could look like, based on SIP and RTSP. This is the first part of the VOD service that is the result of this thesis.

Chapter 6 deals with the second part of the service – the implementation. The chapter contains descriptions of how nodes were realized and what limitations the implementation has. Finally, the system is taken for a test run.

Chapter 7 concludes the thesis with a summary of the results and a discussion on possible refinements. Also, a few words are said about more recent devel-opments in the field that took place after the bulk of this thesis was written. Appendix A contains the contents of SIP and RTSP messages produced during

a test run of the implemented service.

(20)

(21)

Chapter 2

IPTV and VOD

IPTV is not a standard by itself like the Digital Video Broadcasting (DVB) family of standards for delivering digital TV, but merely an acronym used for TV services delivered via the Internet Protocol (IP).

2.1 IPTV Services

The two arguably most attractive IPTV services are:

Broadcast (BC) is the equivalent of traditional TV. The user can “tune in” to a channel and see what is being broadcasted on that channel for the moment. An Electronic Program Guide (EPG) can be presented to the user to aid in channel selection.

VOD allows the user to stream content at the time of her choosing. VOD could be described as a modern version of going to the video store and renting a video. The VOD service presents the user with a list of videos on her TV set. After a choice has been made, the video is streamed to the user’s STB and the video stream can be controlled (play, pause, forward, rewind etc.) in a way similar to controlling the playback of a regular VHS video tape.

2.2 Advantages of IPTV

Some of the advantages of IPTV over traditional Digital TV are (depending on implementation):

• Infrastructure for providing Internet access can also be used for the delivery of TV services. DVB standards, on the other hand, require TV antennas (DVB-T), satellite dishes (DVB-S) or coaxial cables (DVB-C).

• The ability of bidirectional communication; the user cannot only be the receiver of information, but also the originator. This enables interactive TV

(22)

6 IPTV and VOD services. Although there are ways of achieving bidirectional communication with DVB (e.g. DVB-RCT), it requires a different path to be taken for the user-originating traffic, while IP-based networks are practically always bidirectional.

• The possibility of providing true VOD. This is possible since each subscriber has a dedicated information channel that can be used for transporting indi-vidual video streams. Interactivity is, of course, also an enabler – what good would VOD be if the user could not choose content? It should be said that an experience close to VOD can be achieved using traditional broadcasting if the STB has Personal Video Recorder (PVR) functionality. The video offering then consists of a comparatively small set of videos (compared to true VOD) and each video is periodically broadcasted on the same channel (or one of a small set of channels). Since the user records the desired video, possibly while viewing an earlier section of it, she can control the stream and thus have an experience similar to VOD.

2.3 Traffic flows for IPTV services

The two major IPTV services, broadcast and VOD, work in fundamentally dif-ferent ways with regards to data transportation. A less common type of service is Near Video on Demand (NVOD), which can be seen as a mix of the broadcast and VOD services.

2.3.1 Broadcast

Since broadcasting means that a smaller, fixed set of channels are transmitted and all content starts at a fixed time, multicast can be used by the service provider as the delivery method of IP packets. When the viewer makes a channel selection using her remote control, the viewer’s set-top box then joins a multicast group that contains said channel. Using multicast instead of traditional unicast for this service reduces the bandwidth requirements of the level 3-devices used to deliver the data, especially those closest to the originating node.

2.3.2 VOD

For VOD, the situation is a bit different however. Allowing each individual user to view VOD content at the time of her choosing requires unicast streams. This means that network nodes needs to be able to throughput more data than for the regular broadcasting service, assuming that the number of unique [user, stream, start time] combinations surpass the number of number of TV channels that is multicasted. One way of reducing the load on core network nodes is to place caching media servers closer to the customers’ equipment. These caching servers can then store the most frequently/recently requested videos to take some load off the core network.

(23)

2.4 A VOD service supporting session continuity 7

2.3.3 NVOD

Finally, there exists a service called NVOD, which can conceptually be placed somewhere between BC and VOD. This service is commonly used for Pay-per-view (PPV) purposes and means that a set of movies are multicasted at regular time intervals. That is, a specific movie is multicasted in parallel, with each instance having a different start time. This implies that for a 2 hour movie and an interval of 20 minutes, 6 instances are continuously multicasted in parallel1_.

The advantage over real VOD is that it is cheaper in terms of bandwidth. The main drawbacks are that

• the viewers can not start watching instantly.

• the user’s STB would need to have PVR functionality to store the received stream for the user to be able to rewind2_.

• fast-forwarding would not be possible at all.

2.4 A VOD service supporting session continuity

2.4.1 Overview of service functionality

From a user perspective, an IMS-based VOD service supporting session continuity should typically allow a user to select, order and view videos using an IMS-enabled device. The user should be able to pause, resume, rewind and fast forward the video. As for the session continuity, the user should be able to continue viewing a movie on another device. This should work in a seamless way; the user should be able to start using the service on the second device causing streaming of the same video to continue from where the user left off. The second device could be of a different type than the first one, utilizing a different access technology and with different computational resources, bandwidth capacity and display resolution.

An overview of the requirements posed on a session continuity-capable VOD service such as the one described above is presented in the following sections in the form of the activities that needs to be performed in order to deliver the ser-vice successfully. A high-level presentation of the procedures that make up these activities is then presented in Chapter 4. This high-level model of the procedures will then be refined in Chapter 5. The basic activities are shown in Figure 2.1.

2.4.2 VOD service initialization

The user must register with the IMS network in order to use its services. IMS registration includes authentication and basic authorization to use IMS services. In addition to IMS registration, a VOD service attachment will have to be performed to complete the VOD service initialization. Upon completion of the initialization,

1

Note that while these instances could be transported in 6 different multicast groups, several of them could also be grouped together into the same multicast group.

(24)

8 IPTV and VOD

VoD service initialization

Content selection

Session initiation

Stream delivery & control

Session termination

Figure 2.1. Activities in a typical VOD scenario.

the UE will have a VOD catalog and is ready to let the user make a content selection.

2.4.3 Content selection

For any on-demand service, the user must be able to view content offerings and make a selection. The content offerings might be tailored for a certain user or, more likely, a group of users. For example, High Definition (HD) material may be a premium service available only to customers having subscribed to such pre-mium service. Another example is that of making rated movies available only to subscribers entitled to such content.

2.4.4 Session initiation

In order to start streaming the selected content, the user must somehow indicate that it wants to view a certain video. There are several ways for accomplishing this. However, content selection must be communicated in some way to the VOD application server in order to enable video delivery and charging. If the selected video has been partly viewed earlier, the streaming server must continue streaming where the user left off in order to support session continuity. Also, the operator might want to disallow the scenario where several videos are streamed simultane-ously using the same subscription. Session initiation must then be rejected if the user already has an active session (perhaps using a different UE). Alternatively, the first session must be terminated before the initiation of the new session is completed.

(25)

2.4 A VOD service supporting session continuity 9

2.4.5 Stream delivery and control

The user must be able to control the delivery of the video. Play, pause, fast forward and rewind are features users have come to expect, although some operators might choose to allow only play/pause. There must be a way of guaranteeing a certain bandwidth for assuring the quality the user expects (Quality of Service (QoS)). Guaranteeing a bandwidth is a problem with packet switched networks that needs special attention. Traditional, circuit-switched networks are usually much more predictable, excluding cases where air interfaces and mobility are involved.

2.4.6 Session modification

If conditions change during an active session (e.g. the available bandwidth de-creases, perhaps as a result of user movement in case the UE is a mobile phone or WLAN connected laptop) there might be a need for changing session parameters to ensure a streaming experience free from interruptions.

2.4.7 Session termination

Ending the session properly, both as a result of an error and upon the user request-ing it, is a must. The termination of a session causes session related information such as the offset of the currently active stream to be stored permanently in an operator-controlled database in order to support session continuity.

(26)

(27)

Chapter 3

IMS

This chapter explains the basics of IMS architecture as well as the core concepts and some common procedures. Readers with no prior experience of IMS, but who are nevertheless familiar with networking concepts and protocols, should be able to follow the remainder of the thesis after absorbing this chapter.

3.1 IMS Features

Simply put, IMS is a framework for delivering IP-based multimedia services to end users. The framework specifies network nodes (or functions as they are called), as well as interfaces (or reference points) between nodes that work together to accomplish its task.

To enable network messages to be sent between different nodes, IMS stan-dardize the identification and authentication of end users as well as how messages should be routed between end-users and the operators network and between nodes within the operators network. It also specifies routing between different IMS net-works. This includes roaming functionality.

Another area which is covered by the specifications is charging. The delivery of multimedia services is composed of traffic data and signaling data (often SIP messages). All signaling messages sent traverse network nodes that interface the operator’s billing system. This opportunity of fine-grained billing (as opposed to charging for the transfer of bits and bytes only) is of course a fundamental part in pitching the IMS to telecom operators.

One important aspect of the IMS is its access independence. While it was originally conceived to be a solution for 3rd generation mobile telephony only, access through WLAN was added to the specifications later on, as was access through fixed line networks.

Since the transition to IP based networks will be gradual within the telephony world, backwards compatibility is important and because of the legacy, the IMS comes with network nodes that interwork with Circuit Switched (CS) networks such as the Public Switched Telephone Network (PSTN).

(28)

12 IMS When work began with IMS, IPv6 was chosen as the network layer protocol. However, as it turned out, IPv6 adoption was slower than anticipated and in 2004 a specification [4] was released that described how IPv4 or a combination of IPv4 and IPv6 could be used for the UE and core network nodes.

Finally, it should be said that IMS does not aim to standardize the services themselves, but rather the means needed to deliver multimedia services to end users and charge them for it. Or, put differently, 3GPP seeks to standardize service capabilities.

3.2 Standardization

The 3rd Generation Partnership Project (3GPP) is a collaborative effort between telecommunication standardization institutes across the world. The 3GPP is re-sponsible for standardization of the IMS. Other standards originating from the 3GPP include Universal Mobile Telecommunications System (UMTS), High Speed Packet Access (HSPA) and Long Term Evolution (LTE). 3GPP organizes its work in releases. Each release is composed of a set of standards documents. The stan-dards are open and all documents are available [15] free of charge at their website. IMS was first introduced in 3GPP release 5, which arrived in 2002. As of early 2009, release 8 is almost finished and work with release 9 has already begun. This thesis will in general refer to release 8 documents.

3GPP documents are classified as being Technical Reports (TRs) or Technical Specifications (TSs). While the specifications forms part of the actual standard, the reports can be seen as informational. Furthermore, the Technical Specifications are classified using a stage notation, described by 3GPP [14] as follows:

• Stage 1refers to the service description from a service-user’s point of view. • Stage 2 is a logical analysis, breaking the problem down into functional

elements and the information flows amongst them.

• Stage 3 is the concrete implementation of the protocols between physical elements onto which the functional elements have been mapped.

3.3 3GPP and the IETF

In order to achieve a better integration with current Internet standards and avoid reinventing the wheel, the 3GPP uses existing IETF protocols or extends said pro-tocols to fit their needs. The documents released by IETF are called Request for Comments (RFC)1 _{and they are available [25] free of charge. The 3GPP/IETF} collaboration is formally documented in an RFC [44]. Some RFCs of special im-portance to IMS are shown in Table 3.12_.

1

Not all RFCs were intended to become standards, and even those that were must go through a formal process further described in [31]

(29)

3.4 Architecture overview 13

RFC Title

3261 SIP: Session Initiation Protocol 4566 : Session Description Protocol 3588 Diameter Base Protocol

2401 Security Architecture for the Internet Protocol 791 Internet Protocol

2460 Internet Protocol, Version 6 (IPv6) Specification

Table 3.1. RFCs of special importance to IMS

Furthermore, some RFCs have sprung into existence merely to satisfy the needs of the IMS, an example being RFC 3455 [36] which specifies some of the IMS-specific SIP headers called P-headers (private headers).

3.4 Architecture overview

This section will describe a subset of the functions and reference points of those present in the IMS; the purpose of this section is to give the reader the IMS basics required for understanding the remainder of this thesis. In addition, an overview of the core protocols used in the IMS will be given. A more detailed description of the IMS architecture can be found in [9].

UE MRFC SIP AS S-CSCF I-CSCF P-CSCF Mw Mw Gm Mw ISC Sh Cx Cx MRFP Mr Mp Mb HSS

(30)

14 IMS

3.4.1 Functions

3GPP has chosen to standardize functions, which can be seen as logical nodes. Multiple functions can thus be combined in a single physical network node and, likewise, a single function can be split across several physical nodes for increased performance (load balancing) and/or redundancy. For example, a Home Sub-scriber Server (HSS) database could be split across several physical nodes to pro-vide redundancy.

User Equipment (UE)

The UE is the user’s IMS enabled device. It can be a cellphone, an IPTV STB, a PC or any other IP capable device. Such a device must provide a means of identifying itself to the IMS network (see Section 3.5.1) and, of course, support any other protocols required by the IMS. A SIP stack is a fundamental requirement. The P-CSCF is the UE’s single point of contact to the IMS core network. Proxy Call Session Control Function (P-CSCF)

As stated, all SIP signaling that is destined for the UE or originates from it, must traverse the CSCF appointed to the UE during its registration. The P-CSCF is discovered by the UE either automatically when given an IP address or as a separate procedure using, for example, Dynamic Host Configuration Protocol (DHCP). In SIP terms, the P-CSCF acts as a SIP proxy as defined by [43]. The P-CSCF is responsible for forwarding

• SIP messages sent to the UE.

• SIP REGISTER requests to the correct I-CSCF.

• all other SIP messages sent from the UE to the S-CSCF assigned to it. In addition, the P-CSCF should

• maintain an IPsec [38] security association with the UE 3_. • compress/decompress data sent to/received from the UE 4_. Interrogating Call Session Control Function (I-CSCF)

The I-CSCF is another SIP signaling node. In addition to SIP, it speaks Diameter [32] with the HSS. It is responsible for mainly two things:

• selecting an S-CSCF suitable for assignment to a registering UE. The I-CSCF contacts the HSS to retrieve user information which is used to perform this selection.

3

IPsec is not used if “early IMS security” [6] is being used.

(31)

3.4 Architecture overview 15 • acting as an entry point to the operator’s IMS network for SIP messages

originating from nodes outside the network. When the I-CSCF receives such message, it asks the HSS for the S-CSCF that has been assigned to the user the message is destined for and forwards the message to this S-CSCF. Serving Call Session Control Function (S-CSCF)

The S-CSCF acts both as a SIP proxy and a SIP registrar, depending on the context. Like the I-CSCF, it is connected to the HSS. Each UE has an S-CSCF allocated to it. Although the I-CSCF is responsible for selecting a candidate, the S-CSCF is the node that actually decides if it should serve the registering UE. The proxy responsibilities of the S-CSCF includes the forwarding of messages

• originating from one of the users it serves to an I-CSCF of the terminating user’s network or, if the destination is within the operator’s own domain, to the correct S-CSCF.

• destined for one of the UE it serves to the correct P-CSCF.

• to a Border Gateway Control Function (BGCF) if the call is to be routed to the PSTN.

Other important tasks of the S-CSCF are

• authentication of users; the S-CSCF retrieves one or more authentication vectors from the HSS and uses them to issue a challenge to the UE that is registering. If the UE responds successfully to the challenge, the UE has been authenticated and the S-CSCF tells the HSS that from now on, the S-CSCF serves said UE.

• evaluation of Initial Filter Criteria (IFC) that is retrieved from the HSS; this evaluation may result in the forwarding of a SIP message to an Application Server (AS).

Home Subscriber Server (HSS)

The HSS is the primary database in the IMS. It is connected to the I-CSCF, S-CSCF and can also be connected to application servers. It is for the IMS what the Home Location Register (HLR) is for the Global System for Mobile communications (GSM). The data stored by the HSS function includes

• shared secrets; for the purpose of user authentication, each UE shares a secret with the IMS core network. The core network’s secrets are stored by the HSS.

• all subscriber related information such as user profile and addressing infor-mation.

(32)

16 IMS For more details on the role of the HSS and the exact information stored there, see [11] and [13]. IMS networks containing many users can store the user data across multiple HSS. To know what HSS to query, the entities connected to the HSS are then connected to an Subscription Locator Function (SLF), which they can ask (via Diameter) for the Home Subscriber Server that is responsible for the user that the original Diameter request relates to.

Application Server (AS)

The application server hosts and executes services offered to users. The application server in the IMS can either be a native SIP AS or a server that enables interwork-ing with Customised Applications for Mobile networks Enhanced Logic (CAMEL) or Open Service Architecture (OSA) services. Only SIP AS will be considered in this thesis and the term “application server” or “AS” should thus be interpreted as “SIP Application Server”. The AS

• is contacted by the S-CSCF if the IFC (Section 3.5.2) indicates that the SIP request should be forwarded to the relevant AS.

• can belong to the operator itself or a third party.

• may interface the HSS through a Diameter interface if the operator of the HSS allows it.

Media Resource Function (MRF)

MRF is a collective name for two functions; a control plane function known as Media Resoruce Function Controller (MRFC), and a media plane function, the Media Resource Function Processor (MRFP). The MRFC can instruct the MRFP to perform operations on media traffic, such as transcoding, recording, streaming, mixing etc. Multimedia conferences and text-to-speech are two applications which can utilize the features of the MRF.

3.4.2 Reference points

A listing of the reference points between the core functions detailed above is shown in Table 3.2.

3.5 Concepts

3.5.1 Identification

Entities using the IMS must be able to identify themselves. The means for identi-fying users of IMS networks and services provided to those users are described in this section.

(33)

3.5 Concepts 17

Ref. point Functions Protocol

Gm UE, P-CSCF SIP Mw S-CSCF, I-CSCF, P-CSCF SIP ISC S-CSCF, AS SIP Cx S-CSCF/I-CSCF, HSS Diameter Sh AS, HSS Diameter Mr S-CSCF, MRFC SIP Mp MRFC, MRFP H.248 [39]

Mb UE, MRFP Traffic-dependant (e.g. RTP)

Table 3.2. Reference points between core functions.

User identification - private and public user identities

A subscription can be identified uniquely by its operator using a private iden-tity. This identity is only used for Authentication, Authorization and Accounting (AAA) purposes and is not used for session initiation or routing purposes. The identity is stored in an IP Multimedia Services Identity Module (ISIM) applica-tion residing on the UE. The private identity take the form of a Network Access Identifier (NAI) as defined in [29]. A valid NAI is

eric@operator.net

With each private identity, one or more public identities can be associated. These are the ones used for initiating sessions and routing messages and thus the only type of identity the end-user has to be aware of; the public identity is the one that the user hands out to people they wish to communicate with. Associating multiple public identities to a private identity enables a user to have a single subscription yet being reached through different identities, depending on the context. One could, for example, have one identity for work purposes and another for private use. The public identity take the form of a SIP or SIPS URI as defined in [37] or a TEL URI as defined in [45]. A valid SIP URI is

sip:theodore@acme.com

One or several public identities together are associated with a service profile [8]. This profile contains a set of IFC and service authorization information among other things. With 3GPP Release 6, the relation between public and private identities became a many-to-many relation; different UE with different private identities can register the same public identity with the network. This enables a user’s S-CSCF to select one of several devices to route incoming calls to depending on the devices’ different capabilities. 3GPP also found it flexible to be able to have multiple private user identities per subscription. Private identities are also called IP Multimedia Private Identity (IMPI) and public identities are called IP Multimedia Public Identity (IMPU). The relationship between the entities related to user identification are shown with cardinalities in Figure 3.2.

(34)

18 IMS Subscription IMPI 1 IMPI 2 IMPU 1 IMPU 2 IMPU 3 Service Profile 1 Service Profile 2

one-to-many many-to-many many-to-one

Figure 3.2. User identification entities and cardinalities.

Service identification - public service identities

Services residing on application servers are identified using Public Service Identitys (PSIs). They are used to route messages to the correct application server much in the same way as IMPUs are used to route messages to the correct UE. As with IMPUs They take the form of a SIP or TEL URI.

Communication services and applications

UE and AS can act as communicating endpoints in the IMS and to route mes-sages to the correct application within the device, a combination of an IMS Communication Service Identifier (ICSI) and/or an IMS Application Reference Identifier (IARI) can be used, as shown in Figure 3.3.

SIP message UE/AS Communication service 1 Application 1 Application 2 Communication service 2 ICSI 1 IARI 1 IARI 2 ICSI 2 IARI 2

Figure 3.3. Dispatching an incoming SIP message using ICSI and IARI.

(35)

3.6 Signaling examples 19 IARI. If no IARI exists, the message is routed to the default application for the service identified by the ICSI. If neither IARI nor ICSI exist, there can be only one IMS application on the device.

3.5.2 Initial Filter Criteria

As previously mentioned, zero or more IFC [8] may be associated with a service profile. These decide how the S-CSCF should route incoming SIP requests, specif-ically if they should be routed to an applications server (and which one) or not. The criteria are ordered logically by a priority number associated with each of them; the S-CSCF will consider a criteria with a lower priority number before it considers one with a higher number. In addition to its priority number, the most important properties of an IFC are the application server associated with it and the optional trigger point.

The trigger point is a boolean expression that decides if the IFC matches or not. The expression may depend on the values of a number of parameters related to the incoming message, such as

• SIP method • request URI • header values

If the IFC (expression) matches, the incoming message is forwarded to the IFC’s application server; if it does not, the next IFC, if any, is evaluated. The absence of a trigger point means that any message matches the IFC and the message will thus be forwarded to the application server unconditionally.

3.5.3 Home network and visited network

Roaming is possible in IMS, much thanks to the I-CSCF, which acts as an inter-face towards other IMS networks. As have been said, a P-CSCF and an S-CSCF is associated with each UE. The P-CSCF can be located in the user’s operator’s network (the home network) or in another network (a visited network), depending on the UE’s location. The S-CSCF is, however, always located in the home net-work. Application servers must be reached through this S-CSCF, but the servers themselves can be provided both by the user’s operator as well as by a 3rd party.

3.6 Signaling examples

The SIP signaling in IMS can be quite complex since IMS itself is a complex archi-tecture. The reader may find examples on the Internet [28] of what messages are sent during common scenarios such as UE registration and peer-to-peer sessions.

One particular scenario that is relevant for this thesis is when a UE needs to initiate a session towards an AS. Messages sent and nodes involved in this scenario are shown in Figure 3.4. In this case the session is set up, a message is

(36)

20 IMS sent from the UE to the AS5 _{and the session is then terminated. The pictured} scenario assumes that the UE is already registered with the IMS network. More information about how different nodes react to incoming messages can be found in the 3GPP specifications [7]. UE P-CSCF S-CSCF INVITE AS INVITE INVITE 200 OK 200 OK 200 OK ACK ACK ACK MESSAGE MESSAGE MESSAGE 200 OK 200 OK 200 OK BYE BYE BYE 200 OK 200 OK 200 OK Evaluation of IFC

Figure 3.4. Message flows for a simple UE-to-AS session.

5

The purpose of the session isn’t clear from the sequence diagram by itself, but if the AS sent the contents of the MESSAGE message to a group of subscribers, the diagram could for example illustrate a twitter-like service.

(37)

Chapter 4

IPTV in Next Generation

Networks

TISPAN is a standards body within ETSI. Its purpose is to standardize what they refer to as Next Generation Networks. While the definition of NGN is somewhat vague, it is in essence referring to the IP based networks that will replace tra-ditional telecommunication networks. While 3GPP focuses on mobile networks and services, TISPAN focuses mainly on the fixed-line equivalents. The two groups’ work is closely related; TISPAN’s work extends 3GPP’s IMS and there-fore, TISPAN documents often refer to 3GPP documents. TISPAN’s specifications includes proposals for how IPTV services should be delivered using IMS-based net-works as well.

4.1 Use of IMS in NGN

TISPAN provides two alternatives for incorporating IPTV in next generation net-works. One of these paths build on existing IMS functions [5], while the other is an NGN specific solution [10]. The IMS-based alternative will be used exclusively in this thesis as a basis for design and implementation of a VOD service.

In this architecture, IMS contributes to the IPTV architecture with a set of functions relating to session control. In TISPAN nomenclature, these functions are known as “NGN IMS” or “Core IMS”, of which the latter will be used in this thesis. The functions included in the Core IMS are [1]:

• P-CSCF, I-CSCF, S-CSCF and MRFC as described in Section 3.4.1. • BGCF and Media Gateway Control Function (MGCF) which provide

inter-working with CS networks (that is, call routing between IMS networks and non-IMS networks along with the required protocol conversion).

The two latter functions are not within the scope of this all-IP thesis and will not be considered further. The remainder of this chapter will summarize

(38)

22 IPTV in Next Generation Networks UE MCF SCF S-CSCF I-CSCF P-CSCF Mw Mw Gm Mw ISC Sh Cx Cx MDF y2 Mp Xd UPSF SDF Sh ISC Xc ? SSF Xa

Figure 4.1. Simplified NGN/IMS IPTV architecture.

those parts of [5] that relates to VOD; the two other IPTV services that the specification describes — broadcast (“regular TV”) and Network Personal Video Recorder (NPVR) services — are not considered here.

4.2 IPTV Architecture

Several functions and reference points relevant in the IMS are still relevant in TISPAN’s IMS-based IPTV-architecture. However, there are some differences. Some names of functions and reference points have been changed due to slight differences in their purpose. More importantly, TISPAN has extended 3GPP’s IMS specification with new functions and interfaces that are lacking in the IMS documents but that are important for IPTV.

This section presents the most important differences between IMS entities and their NGN counterparts with regards to IPTV. Figure 4.1 shows a simplified view of TISPAN’s NGN/IMS architecture for IPTV services.

4.2.1 UPSF — TISPAN’s HSS

In NGN, user related information is not saved in an HSS, but rather in a User Pro-file Server Function (UPSF). Both interface application servers via the Sh/Diameter interface and CSCFs via the Cx/Diameter interface, and for all purposes relevant to this thesis, the UPSF and the HSS are equivalent. Thus, information relating

(39)

4.2 IPTV Architecture 23 UE MCF S-CSCF P-CSCF Mw Gm y2 Xp Xd Xc MDF UE MRFC S-CSCF P-CSCF Mw Gm Mr Mp Mb MRFP MRF MF

Figure 4.2. IMS Media Resource Function (left) and NGN Media Function (right).

to the HSS in Section 3.4.1 applies to the UPSF as well. As with IMS, an SLF may be used when multiple UPSFs exist.

4.2.2 The MF — an IPTV adapted MRF

Although the MRFC and MRFP together provides the means for transcoding, mixing and streaming media (MRFP) and the control thereof (MRFC), the inten-tion of the MRF in the IMS seems to be that of enabling multimedia conferences, rather than enabling IPTV services.

Therefore, TISPAN has introduced new functions in their IPTV architecture. These functions are the Media Control Function (MCF) and the Media Delivery Function (MDF) and together they form what is called the Media Function (MF). Figure 4.2 shows how the MRF and the MF corresponds to each other and how they interface other functions.

While the purposes of the Xp, y2 and Xd reference points are the same as those of Mp, Mr and Mb, respectively, the NGN architecture acknowledges the need for a direct connection between the UE and the MRFC/MCF. This connection is realized using the Xc reference point.

Xc enables the user to control the streaming media, while the streaming media itself is delivered using the Xd interface. Typically, RTSP is used for stream control over Xc and RTP/RTCP are used for the media delivery over Xd.

4.2.3 SCF

The Service Control Function (SCF) is the main SIP application server. Duties include

(40)

24 IPTV in Next Generation Networks • credit control and generation of charging information.

• MCF (and possibly MDF) selection.

4.2.4 SSF

The Service Selection Function (SSF) provides the user (UE) with a list of available services. It communicates directly with the UE over the Xa interface, although the particular protocol and message contents used for the interface is not specified in the draft.

4.2.5 SDF

TISPAN decided to distribute IPTV responsibilities over two SIP application servers. The purpose of the Service Discovery Functions (SDFs) is to provide the UE with an address of an SSF. This may be a very simple task if the same SSF is used for all user types. However, the operator might want to personalize content offerings depending on the type of user. This can be achieved by

• letting the SDF categorize the user by means of the Sh interface and provide an address of an SSF matching the user’s type, or

• sending an URI of a generic SSF to the UE and letting the client application on the UE filter the content offerings locally.

4.3 VOD using NGN/IMS

Figure 4.3 shows how VOD is related to other IPTV services considered in [5]. Content on Demand (COD) is simply a more generic, but less commonly used term for VOD and VOD-like services. NPVR is a service that enables the user to record and store video in the network. Since the specification covers multiple IPTV services, the SCF, MCF and MDF are prefixed differently depending on which service they deliver. For VOD, the service-specific functions will be a VOD-SCF, a VOD-MCF and a VOD-MDF. Since only VOD is considered here, “SCF”, “MCF” and “MDF” will be used, respectively, to refer to these entities for the sake of brevity. Of course, a VOD-capable application on the UE is necessary as well.

4.3.1 IPTV user profile

TISPAN’s NGN/IMS IPTV architecture assumes that each IPTV user is allocated an IMPU. This IMPU is then mapped to an IPTV user profile containing IPTV-specific settings for the user. Figure 4.4 shows the contents of a possible IPTV user profile. The profile contains

(41)

4.3 VOD using NGN/IMS 25

IPTV Service

Broadcast CoD NPVR

VoD

Figure 4.3. NGN IPTV services.

• A list of UE’s with accompanying capabilities (display resolution, bandwidth etc.)

• Service related settings (for VOD, this data include what categories of rated content the user should be allowed to access, such as PG-13, R etc.) The IPTV user profile can be stored in one of several locations: • In the SCF application server.

• In a standalone application server communicating with the SCF.

• In the UPSF as transparent data using the Diameter commands User-Data-Request (UDR) (for reading) and Profile-Update-User-Data-Request (PUR) (for writ-ing).

If the service provider (responsible for providing the SCF and the MF entities) is not the same as the operator of the IMS network (responsible for the IMS Core functions), the two first alternatives are most likely to be deployed.

4.3.2 IPTV service action data

This category of data includes information that is dependant on actions the user has taken. For VOD, this information includes

• A list of movies the user has purchased.

• A list of movies the user has rented and their respective expiration date. • Offset of each purchased/rented movie, to enable session continuity. Figure 4.5 shows a possible IPTV service action data record.

The options for storing the IPTV service action data are the same as those for storing the IPTV user profile.

(42)

26 IPTV in Next Generation Networks

IPTV user profile

General settings VOD settings

UE settings

UE 1 UE 2

User ID: bob@biloxi.com

Preferred language: English Allowed content: all

ID: private23613@realm ID: private76788@realm

Resolution: QVGA

Bandwidth: 384 kbps

Resolution: WUXGA

Bandwidth: 10 Mbps

Figure 4.4. IPTV user profile.

4.3.3 Service and session portability

Two important components of a true nomadic VOD service are service and session portability. Service portability refers to the possibility of accessing a service from different devices across using different access networks. True service portability also requires roaming, i.e. not only allowing different access methods for differ-ent user equipmdiffer-ent, but also allowing the UE and to connect through IMS core networks managed by different operators.

Session portability is the feature allowing a user to end the viewing of a video mid-session and then continue watching from the same position using another UE. This implies that the current time (offset) in the movie needs to be saved in the network when terminating the first session, allowing the MF to begin streaming the movie from the saved offset when the movie is played on the second user equipment.

(43)

IPTV service action data

Purchased movies Rented movies Movie 1

User ID: alice@atlanta.com

ID: 14655564 Offset: 00:08:26 Movie 2 ID: 12525711 Offset: 00:00:00 Movie 3 ID: 78932416 Offset: 02:11:17 Expires: 2012-06-28

Figure 4.5. IPTV service action data record.

4.3.4 Signaling flows

A typical Video on Demand-session starts with service initialization, followed by session initiation, stream control and delivery. A session is possibly modified along the way. It concludes with a session termination. This section presents a high-level description of these steps.

VOD service initialization

The first procedure is VOD service initialization, consisting of the steps depicted in Figure 4.6.

At startup, the UE’s first step is to perform a network attachment. This involves communicating with the Network Attachment Subsystem (NASS). Two important parts of the network attachment is

1. obtaining an IP address. 2. receiving a P-CSCF address.

(44)

28 IPTV in Next Generation Networks

UE NASS Core IMS SDF SSF

Network attachment IMS registration VoD service attachment VoD catalog retrieval

Figure 4.6. Initialization steps.

An IP address can be dynamically obtained via Point-to-Point Protocol (PPP) or DHCP, as described in [12], while P-CSCF address awareness can be obtained in one of several ways:

1. The UE can be preconfigured with a P-CSCF address.

2. The UE can receive the P-CSCF address from the NASS as a part of network attachment.

In either way, if the P-CSCF address obtained is a Fully Qualified Domain Name (FQDN) rather than an IP address, the UE will need to obtain a DNS server IP-address from the NASS (or be preconfigured with one) to be able to resolve the IP address of the P-CSCF.

Following network attachment comes IMS registration. Upon successful regis-tration, the UE has been authenticated and authorized to communicate with other user equipment in the IMS network as well as with application servers.

The next step is to actually initialize the VOD service. This is done via a VOD service attachment procedure1_{, which comes in two different versions:}

• Pull mode VOD service attachment. • Push mode VOD service attachment.

As expected, pull mode implies that the service attachment is initiated by the UE, while push mode indicates that the SDF acts as the initiator. The push mode can be slightly more effective signaling wise, since it does not call for another complete UE — SDF — UE roundtrip (the SDF can obtain UE status via the S-CSCF). However, if the UE registers with the IMS only to use some other non-IPTV service, an unnecessary SSF selection will be performed and VOD service information will be sent to the UE, although it will never be used. Pull and push modes are shown in Figure 4.7 and Figure 4.8, respectively.

(45)

UE Core IMS UPSF SDF

VoD service attachment request

SDF retrieves IPTV user profile

SDF performs SSF selection

VoD service attachment information VoD service

attachment information

VoD service attachment request

Figure 4.7. Service attachment using pull mode.

SDF becomes aware of UE (de)registration SDF retrieves IPTV user profile

SDF performs SSF selection

VoD service attachment information VoD service

attachment information

(46)

30 IPTV in Next Generation Networks UE Core IMS SCF MF Session initiation request Session initiation request Session initiation request Session initiation response Session initiation response Session initiation response

Content control channel and delivery channel setup

Content control and delivery

Figure 4.9. Session initiation.

After receiving the VOD service information, being an SSF address along with any additional information needed to formulate a request for a VOD catalog, the UE contacts the SSF directly to obtain this catalog. The SSF then returns the requested data, and the UE can present the information to the user in order to let the user make a selection and initiate a session.

Session initiation

Session initiation always takes place with the UE being the initiator. The basic signal flow of session initiation is shown in Figure 4.9. The session initiation traverse the Core IMS, which routes the request to the correct SCF using IFC from the UPSF. The SCF takes care of authorization and selects a suitable MCF to act as the other end-point of media control (the UE being the first) during the session. The MCF in turn, is responsible for selecting a MDF. Upon receiving a session initiation response indicating success, the Core IMS interacts with the Resource and Admission Control Subsystem (RACS) (not shown here) to ensure that a proper amount of bandwidth is reserved for the session.

Session modification

During an active session, session parameters may be renegotiated. If transmission conditions change, this might be required to ensure a good user experience. This session modification can be initiated by the UE as well as the MF. The basic signal flow for an UE-initiated session modification is shown in Figure 4.10. MF-initiated session modification works analogously.

(47)

4.3 VOD using NGN/IMS 31 UE Core IMS SCF MCF Session modification request Service authorization Session modification response Session modification response Session modification request Session modification request Session modification response

Figure 4.10. Session modification.

Session termination

The session can be terminated by the UE (Figure 4.11), the SCF (Figure 4.12) or the MCF (Figure 4.13). The reason for an SCF-initiated session termination might be that another UE having registered the same public identity is requesting session initiation. This simply means that the user wishes to resume viewing on another device. Transport resources are released as soon as the session termination request reaches the Core IMS through communication between the P-CSCF and the RACS.

(48)

32 IPTV in Next Generation Networks UE Core IMS SCF MF Session termination request Session termination request Session termination request Session termination response Session termination response Session termination response

Figure 4.11. UE-initiated session termination.

UE Core IMS SCF MF Session termination request Session termination response Session termination response Session termination response Session termination request Session termination request

Figure 4.12. SCF-initiated session termination.

UE Core IMS SCF MF Session termination response Session termination request Session termination request Session termination request Session termination

response _{Session termination}

response

(49)

Chapter 5

Design of a signaling schema

for IMS/NGN-based VOD

In this chapter, the high-level procedures presented in Section 4.3.4 will be consid-ered and studied at a more detailed level. This new level of detail includes concrete protocols and deciding what types of messages that are suitable. Some protocols are already implied by the reference points used in [5] and their definition within IMS. The relevant protocols and their responsibilities are shown in Table 5.1.

All of these protocols are IETF protocols and as such, the specifications are freely available as RFCs. The signaling schema presented in this chapter will ex-tend [5] by showing how SIP and RTSP can be used to be build a VOD service as described by the high-level procedures of that specification. The chapter starts off with VOD service initialization. Then, sessions are investigated and how respon-sibility should be distributed between SIP and RTSP, before some brief notes on other areas not investigated in detail here concludes the chapter.

Protocol Main RFC Function(s)

SIP 3261 Session initiation, modification and

tear-down, IMS registration and VOD service at-tachment

SDP 4566 Communicating media/session information

RTSP 2326 Stream control

RTP/RTCP 3550 Stream delivery and delivery reports

Diameter 3588 UPSF (database) interaction

Table 5.1. IETF protocols and their use in an IMS/NGN VOD service

(50)

34 Design of a signaling schema for IMS/NGN-based VOD

5.1 VOD service initialization

Network attachment and IMS registration should take place as described in [12] and [2], respectively. However, service attachment and catalog retrieval needs to be investigated.

5.1.1 Push mode VOD service attachment

The SDF needs to become aware of the newly registered user and send SSF-related information to the new user. Since the Gm, Mx1_{and ISC interfaces used for} UE-SSF communication are all SIP interfaces, the problem boils down to selecting suitable SIP method(s) and proper ways to embed the necessary information in message headers and/or bodies.

For notifying the SDF of the new user, there is only one appropriate solution; a third-party registration, as described in [7]:

... the S-CSCF shall send a third-party REGISTER request, as described in sub-clause 5.4.1.7, to each AS that matches the Filter Criteria of the service profile from the HSS for the REGISTER event ...

This procedure means that SIP REGISTER requests are sent to third par-ties by the S-CSCF upon successful registration. A successful registration has occurred when the S-CSCF has responded to a REGISTER request with a 200 OK response. A third party registration is sent to each AS that matches the IFC for the REGISTER event.

At a first glance, there seems to be two methods that looks like suitable al-ternatives for sending the actual service attachment information; INFO [34] and MESSAGE [33]. However, the INFO method should only be used for in-session signaling and is thus not suitable, since the UE and the SDF do not participate in a session. The MESSAGE method is a more attractive option, since it is dialog-free, that is, it can be sent as a stand-alone request/response transaction. The only objection against using it is its original intended purpose; the exchange of messages between users. It is, however, the best alternative unless SIP itself is to be extended with additional methods, something we will try to avoid as far as possible.

A push mode VOD service attachment using third-party registration and the MESSAGE method is shown in Figure 5.1.

The actual service attachment information is enclosed in the MESSAGE SIP request as the message’s body. We will not speculate much in what the format of this information will be. However, this much can be said: it will probably be an XML-based format, and the information will contain, among other things, one or more SSF addresses.

1

The reader is encouraged to remember that Mx is the reference point between the three CSCF:s that form the functional block referred to as ”Core IMS“.

(51)

5.1 VOD service initialization 35

IMS user profile retrieval REGISTER 401 Unauthorized REGISTER REGISTER 200 OK MESSAGE 200 OK IPTV user profile retrieval Evaluation of IFC MESSAGE 200 OK

Figure 5.1. Push mode VOD service attachment.

5.1.2 Pull mode VOD service attachment

In pull mode, the UE is responsible for initiating the transfer of VOD service attachment information. The INFO method is discarded for the same reason as in the push case. One way would be for the UE to send a MESSAGE request and receive the service attachment information in the response. However, [33] clearly states that “A 2xx response to a MESSAGE request MUST NOT contain a body”. Using MESSAGE thus implies that two round-trips are needed — one where the UE acts as User Agent Client (UAC) and indicates its desire to receive service attachment information using a first MESSAGE request and another where the SDF, this time acting as UAC, sends the information in another MESSAGE request. This scenario is illustrated in Figure 5.2.

This solution looks like a typical SUBSCRIBE-NOTIFY [41] scenario. When using SUBSCRIBE-NOTIFY, you additionally have a good way of announcing changes to service attachment information; it is a simple matter of sending an-other NOTIFY to the UE. Using SUBSCRIBE and NOTIFY requires a new event package to be defined that states, among other things:

• The value of the Event header for NOTIFY and SUBSCRIBE messages. • The format of the NOTIFY request’s body.

(52)

36 Design of a signaling schema for IMS/NGN-based VOD

IMS user profile retrieval REGISTER 401 Unauthorized REGISTER 200 OK 200 OK MESSAGE IPTV user profile retrieval Evaluation of IFC MESSAGE 200 OK Evaluation of IFC MESSAGE 200 OK MESSAGE 200 OK

Figure 5.2. Pull mode VOD service attachment using MESSAGE.

Choices for event package parameters are out of the scope of this thesis; we simply state that a new event package needs to be registered with the Internet Assigned Numbers Authority (IANA) [20]. A pull solution using these SIP meth-ods is shown in Figure 5.3 (the registration part is omitted this time for the sake of brevity).

5.1.3 Catalog retrieval

The protocol used for the Xa reference point is not mentioned in [5]. The author believes that it is not, however, unlikely that this will be HTTP-based, similar to the Ut reference point specified in [11]. The actual catalog information will probably be attached as an XML-based body to the HTTP response. The catalog retrieval using the HTTP request method GET [35] is shown in Figure 5.4.

(53)

5.2 Handling sessions and streaming 37

200 OK SUBSCRIBE IPTV user profile retrieval NOTIFY 200 OK Evaluation of IFC SUBSCRIBE 200 OK NOTIFY 200 OK ...

Figure 5.3. Pull mode VOD service attachment using SUBSCRIBE/NOTIFY

UE SSF

GET

200 OK

Figure 5.4. Catalog retrieval using HTTP/GET.

5.2 Handling sessions and streaming

Procedures for initiating and terminating VOD sessions are discussed in this sec-tion, as are ways of controlling the video stream and ways of delivering the actual data. The latter task is reasonably straight-forward, while the others are more delicate.

5.2.1 Protocols

For stream delivery over IP networks, Real-time Transport Protocol (RTP) on top of User Datagram Protocol (UDP) is commonly used and it suffices here as well.

An IMS-based VOD Service Supporting Session Continuation

Institutionen för systemteknik

Department of Electrical Engineering

Examensarbete

An IMS-based VOD Service Supporting Session

Continuation

An IMS-based VOD Service Supporting Session

Continuation

Examensarbete utfört i Informationskodning

vid Tekniska högskolan i Linköping

av

Abstract

Acknowledgments

Contents

List of Tables

List of Figures

Chapter 1

Introduction

1.1

Intended audience and prerequisites

1.2

Actors involved

1.3

Problem definition

1.4

Contents and reading advice

Chapter 2

IPTV and VOD

2.1

IPTV Services

2.2

Advantages of IPTV

2.3

Traffic flows for IPTV services

2.3.1

Broadcast

2.3.2

VOD

2.3.3

NVOD

2.4

A VOD service supporting session continuity

2.4.1

Overview of service functionality

2.4.2

VOD service initialization

2.4.3

Content selection

2.4.4

Session initiation

2.4.5

Stream delivery and control

2.4.6

Session modification

2.4.7

Session termination

Chapter 3

IMS

3.1

IMS Features

3.2

Standardization

3.3

3GPP and the IETF

3.4

Architecture overview

3.4.1

Functions

3.4.2

Reference points

3.5

Concepts

3.5.1

Identification

3.5.2

Initial Filter Criteria

3.5.3

Home network and visited network

3.6

Signaling examples