ITU Centres of Excellence for Europe

NGN SERVICES VoIP AND IPTV

Module 3: IPTV architectures and implementation

MODULE 3: IPTV architectures and implementation

Contents
IPTV architectures and implementation ................................................................1 3 Introduction ........................................................................................................3 3.1 IPTV functional architecture ............................................................................3 3.2 Signaling architecture for IPTV .....................................................................12 3.3 SIP-based IPTV Service Discovery...............................................................17 3.4 IMS based IPTV............................................................................................25 3.5 IPTV security aspects ...................................................................................36 3.6 IPTV over DSL and FTTH .............................................................................41 3.7 IPTV over wireless and mobile networks ......................................................48 3.8 Reference list ................................................................................................55

3 Introduction
IPTV is defined as multimedia services over broadband IP-based networks, managed to support the required level of quality of service (QoS) / quality of experience (QoE), security, interactivity and reliability. This kind of NGN should be the best tool supporting the reliable and secure delivery of multimedia contents including video, which is a very crucial issue for IPTV services. As the IPTV service requires not only the broadband multimedia streaming but also the security and reliability with a certain level of quality, there are certain limitations to support those capabilities in current best effort based IP network such as the Internet. Therefore, NGN with adjustment for IPTV characteristics would be suitable way to provide new emerging services over heterogeneous networking environment. In this sense, IPTV will have the principal role of accelerating deployment and business of NGN. IPTV services over manageable broadband link from a provider will be the ultimate goal of the broadband revolution using NGN.

3.1 IPTV functional architecture

ITU-T defines the NGN as a packet-based network able to provide telecommunication services and able to make use of multiple broadband, QoSenabled transport technologies, in which service-related functions are independent from underlying transport-related technologies. It enables unfettered access for users to networks, competing service providers and/or services of their choice. It supports generalized mobility which will allow consistent and ubiquitous provision of services to users. On the other hand, ITU-T defines IPTV service as multimedia services such as television/video/audio/graphics/data delivered over IP-based networks managed to support the required level of QoS/QoE, security, interactivity and reliability. In order to introduce IPTV functional architecture, the content value chain, domain model and several types of IPTV services will be explained. IPTV Content Value Chain: The value chain considering life cycle of contents should be the most important fundamental framework to identify IPTV services. Top part of Fig.1 shows an IPTV Content Value Chain Model taking into consideration broadcast services and on-demand services: - Content Production: producing and editing the actual content (movies, drama series, sports events, news reports etc.) - Content Aggregation: bundling content into catalogue offers and bouquets, ready for delivery - Content Delivery: transporting the aggregated contents to the consumer - Content Reconstitution: converting the content into a format suitable for rendering on the end-user device(s). Each role in the value chain has historically been bound to a type of stakeholder or technical component. Content Production, for example, is linked to production firms and to the production teams of TV stations.

Figure 1 - Content value chain and IPTV domains

Figure 2 - IPTV domains Domain Model for IPTV Services: Lower part of Fig. 1 and Fig. 2 show the domain and content value chain that are involved in the provision of IPTV services. Four domains of IPTV service provisioning are defined as follows: - Content Provider: The entity that owns or is licensed to sell content or content assets. - Service Provider: An operator that provides telecommunication services to customers and other users either on a tariff or contract basis. A service provider may or may not operate a network. A service provider can optionally be a customer of another service provider.

Typically, the service provider acquires or licenses content from content providers and packages this into a service that is consumed by the end-user. - Network Provider: The organization that maintains and operates the network components required for IPTV functionality. A network provider can optionally also act as service provider. - End-user: A human being, organization, or telecommunications system that accesses the network in order to communicate via the services provided by the network. There are several reference points (RPs) between logical domains: - RP 1: logical reference point between end-user and network provider (user to network RP). - RP 2: logical reference point between network provider and service provider (transport and control RP). - RP 3: logical reference point between service provider and content provider (content provider RP). - RP 4: logical reference point between end user and service provider (service platform RP). - RP 5: logical reference point between network provider and content provider. - RP 6: logical reference point between end-user and content provider. A direct logical information flow may be set up for rights management, protection, etc. Types of IPTV Services: IPTV services are classified as the follows: - Broadcast type services: comprise a one-way transmission of content from one point (the source) to two or more points (the receivers), whereas the end-user has no control over the content or timing of what he receives, apart from the ability to select a particular channel. - On-demand type service: is content prepared and delivered by the content provider for retrieval, which is received and stored by the service provider. If necessary, trans-coding can be performed to accommodate the storage device characteristics. The end-user can then select and retrieve such contents from this storage at any time, according to the constraints provided by the content protection metadata. - Other type services: include advertising service, public interest service, teleservices, portal services, hosting services, IPTV interactive service, presence services, time-shifting and place-shifting service, session mobility service, supplementary content, etc. Overall Functional Architecture for IPTV: In this section, IPTV architectures are introduced. The functional architecture for IPTV considers the principal functional groups for IPTV. These functional groups provide a more detailed breakdown of the IPTV domains. The functional groups in the architecture are derived by grouping related functions. Fig. 3 shows an overview of the IPTV functional architecture. The following gives a description of each functional group. The related functions in each functional group are further decomposed as shown in details in Fig. 4.

Figure 3 - IPTV architectural overview - End-User Functions: perform mediation between the end-user and the IPTV infrastructure. - Application Functions: enable the End-User Functions to select and purchase a content item. - Content Delivery Functions: facilitate the delivery of content from the Application Functions to the End-User Functions using the capabilities of the Network Functions. - Service Control Functions: provide the functions to request and release network and service resources required to support the IPTV services. - Management Functions: perform overall system management, status monitoring and configuration. - Content Provider Functions: provided by the entity that owns or is licensed to sell content or content assets (i.e., owner of the content, metadata, and usage rights). - Network Functions: provide IP layer connectivity between the IPTV service components and the End-User functions.

Figure 4 - Detailed IPTV functional architecture IPTV Terminal Functions (ITF): The ITF are responsible for collecting control commands from the end-user, and interacting with the Application Functions to obtain service information (e.g., electronic program guide (EPG)), content licenses, and keys for decryption. They interact with the Content Delivery Functions to receive the IPTV services. They also provide the capability for content reception, decryption, and decoding. - Application Client Functions: exchange information with the Application Functions to support IPTV and other interactive applications. Service and Application Discovery & Selection Client Functional Block: provides for the end users discovery and selection of IPTV services and applications. On-Demand Client Functional Block: interacts with the On-Demand Application Functional Block to perform session management, service authorization, presentation of the content metadata, and execution of the service logic for the On-Demand application. Linear TV Client Functional Block: interacts with the Linear TV Application Functional Block to perform session management, service authorization, presentation of the content metadata, and execution of the service logic for the Linear TV application.

Other Client Functional Blocks: interact with the Other Application Functional Blocks for the delivery and presentation of additional IPTV services and their content, e.g., games, distant learning etc. - Service and Content Protection (SCP) Client Functions: interact with the server side SCP functions to provide Service Protection and Content Protection and verifies the usage rights and decrypts the content. Content Protection Client Functional Block: performs integrity checking, usage rights verification and content decryption. Service Protection Client Functional Block: performs the authentication and authorization of access to services and, optionally, protection of the services using methods such as encryption. - Content Delivery Client Functions: receive and control the delivery of the content from the Content Delivery and Storage Functions. After receiving the content, the Content Delivery Client Functions may use the SCP Client Functions to decrypt and decode the content, and can also optionally support playback control. Multicast Content Delivery Client Functional Block: receives the content from the Multicast Delivery Functional Block within the Content Delivery & Storage Functions. This functional block communicates with the Multicast Control Point Functional Block for the selection of the multicast stream. Unicast Content Delivery Client Functional Block: receives the content from the Unicast Delivery Functional Block within the Content Delivery & Storage Functions. Error Recovery Client Functional Block (option): performs error recovery on the content streams in conjunction with the Error Recovery Functional Block within the Content Delivery Functions. - Control Client Functional Block: allows the ITF to initiate service requests to IPTV Service Control Functional Block, in order to prepare for the connection to the Content Delivery Functions. Home Network Functions (HNF): The HNF provide the connectivity between the external network and each IPTV terminal device. All data, content, and control traffic must pass through the Home Network Functions in order to enter or exit the end-users IPTV terminal device. It serves as the gateway between the IPTV Terminal Functions and the Network Functions. - Delivery Network Gateway Functional Block: provides IP connectivity between the external network and the IPTV terminal device. It manages the IP connectivity, obtaining IP address(s) and configuration for the HNF and IPTV terminal devices. Service & Content Protection (SCP) Functions: controls the protection of the services and content. - Content Protection Functional Block: controls the protection of the content and is responsible for the management of the content rights and the keys used to encrypt and decrypt the content.

- Service Protection Functional Block: controls the protection of services. Service protection includes authentication and authorization of access to services and the protection of the services using methods such as encryption. Application Profile Functional Block: stores the profiles for the IPTV applications. The application profile may be located either within Service User Profile Functional Block or within IAF depending on implementation. Application Provisioning Functional Block: adds or withdraws applications and manages the life-cycle of IPTV applications. Content Preparation Functions: prepare and combine the content such as VoD programs, TV channel streams, metadata, EPG data, as delivered by the Content Provider Functions, into the required delivery format. - Content Management Functional Block: manages the life-cycle of the content in compliance with commercial agreements with the content owner. This management function may be triggered by request from the IPTV Application Functions. The Content Management Functional Block directs the Content Processing Functional Block to process the content, e.g. to perform packaging, scheduling or re-coding. - Metadata Processing Functional Block: obtains, manages and processes the program related metadata from the metadata sources, via the Content Aggregation Functional Block, and provides it to the IPTV Applications Functions. The metadata may include title, brief introduction and content tracing information (such as watermark) etc. from the Content Provider, as well as price, time schedule etc, from the Service Provider. - Content Aggregation Functional Block: aggregates content and metadata delivered by the Content Provider Functions. - Content Processing Functional Block: includes re-coding and other functions such as packaging, ad-insertion into streams, format conversion, resolution conversion, editing, etc. - Content Encryption Functional Block: encrypts the content. IPTV Service Control Functional Block: provides the functions to handle service initiation, modification and termination requests, perform service access control, establish and maintain the network and system resources required to support the IPTV services requested by the ITF. - Provides registration, authentication and authorization functions for the EndUser Functions. - Processes request from IPTV Applications and forwards it to the Content Delivery Functions in order that the Content Delivery Functions select the most appropriate Content Delivery & Storage Functions, for delivering content to the End-User Functions. - Requests the Content Delivery Functions or Application Functions to get charging information.

Service User Profile Functional Block: used for storing service profiles and generating responses to queries for service profiles. It also performs basic data management and maintenance functions. Content Distribution & Location Control Functions: control the Content Delivery & Storage Functions to optimize content distribution, selection and deliver content to the IPTV Terminal Functions. - Distribution Control Functional Block: coordinates the delivery & storage resources and establishes the optimal distribution policy for distributing file content and live stream content from Content Preparation Functions to Content Delivery & Storage Functions. It is also responsible for distributing file content among the Content Delivery & Storage Functions. - Location Control Functional Block: used to process the request from IPTV Service Control Functional Block or IPTV Application Functions to select a suitable Content Delivery & Storage Functions which can provide the required content. Then the selected Content Delivery & Storage Functions can deliver the content to the Content Delivery Client Functions. The IPTV Service Control Functional Block or IPTV Application Functions then request the identified Content Delivery & Storage Functions to allocate resources for content delivery. Content Delivery & Storage Functions: store and cache the content from Content Preparation Functions, and transfer the content data among peers. - Content Delivery Control Functional Block: handles control functions on Content Delivery & Storage Functions, such as control of the media resources, and handling of video cassette recording (VCR) commands. - Unicast Delivery Functional Block: responsible for streaming and delivering content streams to the Content Delivery Client Functions via the Network Functions based on the use of the unicast protocol and mechanisms. - Multicast Delivery Functional Block: responsible for streaming and delivering content streams to the Content Delivery Client Functions via the Network Functions based on the use of the multicast protocol and mechanisms. - Cache & Storage Functional Block: responsible for caching the content, e.g. in order to support time-shifted linear TV. It is also responsible for storing the file content, e.g., in order to support VoD or other file-based IPTV services. - Distribution Functional Block: receives the content from the Content Preparation Function. It distributes the content, which include live streams or files, residing among the separate instances of Content Delivery & Storage Functions. - Error Recovery Functional Block (option): serves to improve reliability in case that the IPTV Network Functions cannot provide sufficient QoS. Network Functions: The Network Functions are shared across all services delivered by IP to an End-User Functions. The Network Functions provide the IP layer connectivity in order to support IPTV Services. - Authentication & IP Allocation Functional Block: provides the functions to authenticate the Delivery Network Gateway Functional Block which connects to

the Network Functions, as well as allocation of IP address to the IPTV Terminal Functions. - Resource Control Functional Block: provides control of the resources which are allocated for the delivery of the IPTV services through the Access Network, Edge and Core Transport Functions. - Access Network Functions: (1) aggregate and forward the IPTV traffic sent by the End-User Functions into the edge of the core network and (2) forward the IPTV traffic from the edge of the core network towards the End-User Functions. - Edge Functions: forward the IPTV traffic aggregated by the Access Network Functions towards the core network, and also forward the IPTV traffic from the core network to the End-User Functions. - Core Transport Functions: forward IPTV traffic throughout the core network. - Multicast Transport Functions Multicast Control Point Functional Block: is responsible for the selection of the individual multicast streams to be delivered, over the access network, to the IPTV End-User Functions. Multicast Replication Functional Block: is responsible for replicating multicast streams from a Multicast Delivery Functional Block to all the instances of the Multicast Control Point Functional Blocks. - Unicast Transport Functions: transport unicast content streams from the Unicast Delivery Functional Block to the End-User Functions. Management Functions: The Management Functions manage overall system status monitoring, and configuration. This set of functions may be deployed in a centralized or distributed manner. These functions are required for each of the main functional groups: - Application Management Functional Block - Content Delivery Management Functional Block - Service Control Management Functional Block - End User Device Management Functional Block - Transport Management Functional Block Content Provider Functions: The Content Provider Functions provide a number of different types of sources to the Content Preparation Functions. The physical interfaces and content formats may be different depending on the type of the sources. It may include functions for access control based on rating of the content. - Content Protection Metadata sources: the usage rules and rights for protected IPTV content. - Metadata sources: an entity that provides content provider metadata associated with the IPTV content. - Content sources: an entity that provides IPTV content.

3.2 Signaling architecture for IPTV

The most common service signaling architecture of IPTV system is based only on SIP for both the session and media control. Within an IMS based IPTV environment, this model for service control plays a major role on advanced service capabilities by introducing the set of Trick Functions to the user. There is a clear advantage on this model when compared to hybrid models of SIP in combination with the RTSP (Realtime Streaming Protocol) for both the signaling and media control: the simplicity of integration of the IPTV services with other session oriented services based on SIP, for example, VoIP. Another advantage is the reuse of functions and attributes already available on SIP and SDP (Session Description Protocol) to implement the media control functions, avoiding the design of extensions to SIP. As Table 1 shows, the SIP protocol also has fewer stages than the RTSP protocol as well as the hybrid SIP-RTSP protocol. This optimization is especially important for environments where packet loss rates are high and bandwidth is limited, as it minimizes the need of retransmission of packets and number of signaling stages. Table 1 Comparison between RTSP and SIP messages

Figure 5 shows the SIP Signaling Structure used on the IPTV architecture.

Figure 5 - SIP signaling overview

The main sections in the signaling structure are: session establishment, session control, session quality and session tear-down. The various signaling messages can be see in Figure 6.

Figure 6 - Server and client SIP message protocol Session Establishment As the name implies, this section is responsible for session setup. The general procedure of the protocol is similar to the one used in VoIP applications. The signaling messages transmitted during session setup are depicted in Figure 7. The IPTV Client sends an SIP INVITE message to the IPTV service, which is forwarded by the core IMS CSCF to the IPTV AS (see Figure 7). This SIP INVITE message contains the SDP initial session parameters, such as frame rates and codecs to be used, as well as the URI of the selected content. This URI corresponds to a multimedia content, such as a file located in a video repository or a live multimedia transmission. The IPTV AS replies with a SIP 180 Trying response and checks whether the resource is available and if session

parameters can be sustained. If so, the IPTV AS proceeds with the reservation of the resources and sends a SIP 200 OK message to inform the IPTV Client that the session is established and the RTP flow is started. In case the resource is unavailable (due to a wrong resource identifier, deleted content or unsupported codec), the server sends one of the SIP 400 failure responses and the session is finished with a SIP BYE message.

Figure 7 - SIP messages exchanged during session setup Session Control Session control allows the server to change session attributes without impacting the state of the SIP dialog between the client and server. This is accomplished with SIP UPDATE messages. When issued from the server side, an UPDATE allows the callee (client) to update session attributes (such as available encoding options). From the client side it implements Trick Functions to update the state of the media being received (such as playing or paused). The SIP Update should contain a SDP message. The content of the session Control UPDATE message is shown in Figure 8. Session Control can be accomplished during or after the session establishment phase. For a PAUSE the client sends a SIP UPDATE message with the attribute a=inactive for the RTP/AVP streams. The server attempts to apply the requested updates to the session parameters and, if successful, responds to the client with a SIP 200 OK message. If the parameters cannot be applied, the server replies with a non-200 SIP message, such as 415 Unsupported Media Type or 420 Bad Extension messages. To resume the session the client sends another SIP UPDATE message with the attribute a=recvonly for the RTP/AVP streams.

Figure 8 - SIP messages transferred during a session pause Session Quality Update The IPTV AS does not monitor the session quality, instead this function is delegated to the IPTV Client. The dynamic QoS adaptation is signaled by the IPTV Client using the standard SIP UPDATE messages. Figure 9 depicts a quality change during a session. The Quality UPDATE message is sent from the IPTV Client with a SDP quality attribute a=quality:xx, the quality values range from 0 to 10. The IPTV AS interprets the SIP message and proceeds to adapt the multimedia stream by reducing the target bit-rate, without interrupting the ongoing session. There is a visual impact when the stream is updated, but the session is not compromised. This method was based on the QoS negotiation for IPTV using SIP.

Figure 9 - SIP messages transferred during a session quality update

Session Teardown The session tear-down is a two stage procedure. The requesting party, which can be either the client or server, sends a SIP BYE message that is accepted or rejected by the other party. If the receiving party decides to end the session, all of its resources dedicated to the session should be terminated. The content of the session Tear-down BYE message is shown in Figure 10.

Figure 10 - SIP session termination procedure on client request On the requesting side, after receiving the BYE response, all resources dedicated to the session should also terminate. If the BYE response is rejected, the originating party should retry to end the session by sending another BYE message.

3.3 SIP-based IPTV Service Discovery

The IPTV Service Discovery is a mechanism to enable an ITF to discover IPTV Service Providers and IPTV services provided by a specific IPTV Service Provider. The procedures of IPTV Service Discovery consists of the following three steps which are consistent with DVB-IP Service Discovery and the discovery information is based on DVB-IP SD&S records for both managed network and unmanaged network. Step 1) Determination of the IPTV Service Provider Discovery entry points: This procedure is the bootstrap of IPTV Service Discovery, where the ITF finds the entry point(s) of the IPTV Service Provider Discovery functional entity. The mechanisms to determine the entry point(s) can be different between the managed and the unmanaged models. For example, in case of the managed model, the Network Attachment functional entity can provide the IP address to start the IPTV Service Provider Discovery phase. Step 2) IPTV Service Provider Discovery: This is the procedure where the ITF retrieves the information about each IPTV Service Provider. This information is located at the Service Provider Discovery functional entity, addressed by the entry point(s) found as a result of step 1. This information can be provided either as a web page or based on XML data, such as a DVB-IP Service Provider(s) Discovery Record. It includes the names of IPTV Service Provider(s) and related attributes (e.g. a logo image of the IPTV Service Provider, the means to retrieve IPTV Service Discovery information, etc.). This information will be used by the ITF to perform IPTV Service Provider selection. Step 3) IPTV Service Discovery: After selecting one IPTV Service Provider from the list obtained in step 2, this procedure allows the ITF to get information about IPTV Services offered by the selected IPTV Service Provider. This information is located at the Service Discovery functional entity. In this step, the term services includes linear TV, CoD, nPVR, etc. The IPTV Service Discovery information can be provided either as a web page or as an XML record, such as a DVB-IP Offering record with needed extensions (including the start-up URL for DAE (Declarative Application Environment), entry point for the DVB-IP Broadband Content Guide Record and so on). Note that in the case of 1-to-1 relationship between the Service Platform Provider and the IPTV Service Provider, the IPTV Service Provider Discovery phase (Step 2) would return a single record; therefore, in such a deployment, the subscriber does not have to select the Service Provider and Step 1) could directly provide the address of the IPTV Service Discovery functional entity. Note that step 2 and step 3 can be repeated without necessarily performing step 1. When the Service Discovery and Selection Information changes, the IPTV Service Provider Discovery FE or IPTV Service Discovery FE should inform the ITF about this change. The sequence in Figure 11 shows a high level call flow for IPTV Service Discovery followed by call flows for IPTV service access, such as retrieving documents for DAE and retrieving content guide metadata. Each call flow can

include an optional authentication step to avoid unauthorized access to the IPTV services.

Figure 11 - High level steps in Service Discovery and Service Access

IPTV Service Discovery and IPTV Service Access Procedures for Unmanaged Networks This section describes the IPTV Service Discovery and Service Access procedures for unmanaged networks. The minimum set of functional entities needed to access unmanaged IPTV services are the OITF (open ITF) and the WAN Gateway; thus, the IPTV Service Discovery and Service Access procedures for unmanaged network are shown hereafter considering only these entities.

High Level Procedure

Figure 12 - High level steps for Service Discovery and Service Access for unmanaged networks The IPTV Service Discovery and IPTV Service Access procedures for an unmanaged network comprise a number of steps, as shown in Figure 12: 1. Determination of the IPTV Service Provider Discovery entry point 2. IPTV Service Provider Discovery 3. IPTV Service Discovery 4. IPTV Service Access (e.g. Access to the Content Guide via metadata or web page) These steps are described in detail below. 0. Attachment to the network, where the OITF obtains connectivity to the unmanaged network through the WAN Gateway 1. Determination of an IPTV Service Provider Discovery entry point. This is an internal process in the OITF. 2. The OITF initiates the IPTV Service Provider Discovery using this entry point. In this step, the IPTV Service Provider Discovery functional entity provides the list of IPTV Service Providers and information that is used in the next step (e.g. IPTV Service Provider name, IP address, protocols to be used) 3. The OITF initiates the IPTV Service Discovery. In this phase the OITF selects an IPTV Service Provider and obtains the list of IPTV services available from that specific IPTV Service Provider 4. The OITF can select and access an IPTV service, e.g. access the Content Guide. Determination of the IPTV Service Provider Discovery entry points For unmanaged networks, the OITF determines the entry point(s) with the following options. There is no priority order for these options.

 Manual The End User manually enters a URL or an IP address/port. The OITF should provide a means to allow users to enter an entry point easily, e.g. bookmark, or default URL and the means by which this is achieved is OITF vendor dependent. Pre-Configured Optionally, all the necessary information can be pre-configured in the OITF. DHCP Configuration Optionally, the OITF retrieves provider discovery entry points via DHCP configuration parameters. This would be provided by the ISP to which the residential network connects. IPTV Service Provider Discovery The OITF requests the information on the available IPTV service providers from the IPTV Service Provider Discovery functional entity via HTTP(S).

Figure 13 - IPTV Service Provider Discovery for unmanaged networks

IPTV Service Discovery The Service Discovery Record can be delivered via HTTP(S) as XML data (DVBIP SD&S Record) or as a Web Page.

Figure 14 - IPTV Service Discovery for unmanaged networks IPTV Service Access The following figure shows the call flow for obtaining the Content Guide, which is an example of IPTV service access.

Figure 15 - IPTV Service Access for unmanaged networks

IPTV Service Discovery and IPTV Service Access Procedures for the Managed Model This section describes the IPTV Service Discovery and Service Access procedures for managed networks. The minimum set of functional entities needed to access the managed IPTV services are the OITF, the IG (Application Gateway) and the WAN Gateway; moreover, the AG can be introduced as an optional functional entity in some deployment options. The IPTV Service Discovery and Service Access procedures are shown hereafter, starting from a high-level procedure description and then detailing two cases based on two different deployment options. First section shows the case where just the IG is deployed, while second section describes the case where the AG is also deployed together with the IG.
High Level Procedure

Figure 16 - High level steps for Service Discovery and Service Access for managed networks The managed network Service Provider Discovery comprises a number of steps as shown in Figure 16: 0. Attachment to the Service Platform provider (SPP) 1. Discovery of the IG. The OITF is turned on and obtains the entry point for the IPTV Service Provider Discovery from the IG. The determination of the IPTV Service Provider Discovery entry points can be achieved in a number of ways e.g. pre-configuration of the IG or using a specific event package, the service providers discovery request can be forwarded to the appropriate Service Provider Discovery FE. 2. Registration with the SPP (IMS Registration) 3. GBA bootstrapping procedure

4a. IPTV Service Provider Discovery: The OITF initiates the IPTV Service Provider Discovery. The Service Provider Discovery FE provides the list of IPTV Service Providers and information used for the next step (e.g. IPTV Service Providers name, IP address, protocols to be used). 4b. IPTV Service Discovery: The OITF initiates the IPTV Service Discovery. In this step, the OITF selects an IPTV Service Provider and obtains from the Service Discovery FE the list of services available from that specific IPTV Service Provider. 5. The OITF can select and access an IPTV service, e.g., access the Content Guide, via metadata or a web page. In the case where there is a 1-to-1 relationship between the Service Platform Provider and the IPTV Service Provider, the Service Provider Discovery phase will return a single record; therefore, in such a deployment, the subscriber would not select the service provider and the initial response to Service Provider discovery could return the address of the Service Discovery functional entity.
IPTV Service Discovery and Service Access for Residential networks with IG
High Level Step 4a - IPTV Service Provider Discovery

Figure 17 - IPTV Service Provider Discovery for a managed network

The call flow in Figure 17 shows the case where the OITF requests, via the IG and the ASM, information about the available IPTV Service Providers from the Service Provider Discovery FE. Assumptions for this signal flow are that: The IG is registered with the SPP. The SPP has configured the IG. The IG knows the service URI of the IPTV Service Provider Discovery FE. This FEs service URI as well as the protocol to use to access it may be well known within the SPP domain.
IPTV Service Discovery and Service Access for Residential networks with IG and AG
High Level Step 4a - IPTV Service Provider Discovery

Figure 18 - Steps in Service Provider Discovery for a residential network with an AG and IG

3.4 IMS based IPTV

The digital television has been evolving for several years. What started as digital terrestrial or satellite digital television delivery can now, following the recent technology evolution, be delivered over a broad range of fixed or mobile networks. The deployment of the IPTV over different broadband access networks was made possible because of the Increase in the available bandwidth on new types of access networks together with improving media coding algorithms. Most of the major European telecom service operators already start or plan to start providing Triple play type of services which include in one service package of video, voice and data services (like IPTV, Voice and high speed internet access). We could clearly recognize a growing demand for multimedia on mobile devices and several technologies like DVB-H also allow receiving mobile TV channels on enhanced mobile terminals. The increasing number of deployments and potential customers enforce the operators and solution vendors to optimize delivery network architecture, control mechanisms, end devices as well as to enable a simplified usage of enhanced services. We are focusing in this section on the description of one possible approach for the delivery of IPTV services over IMSbased network architecture. The IP multimedia subsystem (IMS) has been introduced by the 3GPP initiative as the architectural subsystem dedicated to control and provide multimedia services over packet based core network within third generation mobile networks. The concept of the Next Generation Networks (NGN) has been evolving for several years and first real standardization activities have been started by ITU-T NGN focus group and ETSI TISPAN which already employ IMS concept to first standard releases within NGN architecture framework. Ongoing standardization attempts to use IMS to support IPTV services within NGN release two specifications. This section explains a new approach to the use of IMS for IPTV application and also shares the experience of the development and evaluation of such IPTV service architecture. IMS BASED IPTV PLATFORM If we would like to somehow specify what should be understood by the IMSbased IPTV platform the following definition is possible: IMS based IPTV platform is service platform architecture which is able to provide IPTV services controlled and handled by IMS core subsystem and delivered independently from underlying IP transport networks. There exist at least three different stages of evolution for IPTV architecture: 1. Non-NGN based IPTV solutions (almost all available solutions on market for now). It is possible to make some interworking with NGN but generally a separate service control and application layer were developed specially for IPTV services (IPTV middleware). 2. NGN based IPTV architecture. It enables interaction and interworking over specified reference point between IPTV application and some existing common NGN components. These components include transport control elements for resource admission and control subsystem (RACS) or the TISPAN network

attachment subsystem (NASS). This approach uses a dedicated IPTV subsystem within NGN to provide all necessary IPTV required functionalities. 3. IMS based IPTV architecture. It specifies IPTV functions supported by the IMS subsystem and employs these functions to allow reused IMS functions and also make service initiation and control based on SIP (Session Initiation Protocol). This section presents one solution achieved with this concept. IPTV services can be divided in three main groups of services (but not limited just for those in future): Broadcast services (BC): live TV and radio channel feeds broadcasted or multicasted over network. Content on demand (CoD): generally unicast services provided on subscriber demand to deliver required content (e.g. movie, song, etc.). Personal video recorder services (PVR) include services which allows recording, pause or time shift capabilities for live content (can be provided by network or by UE). The advantages of IMS based IPTV concept Deploying IMS functionalities to support IPTV services enables more interesting IPTV features as follows: Integrated user registration and authentication (single sign-on) User subscription management Session management, routing, service trigger, numbering Interaction with existing NGN service enablers (presence, messaging, group management, etc.) Roam and nomadic support QoS and bearer control Unified charging and billing The IMS based IPTV can also bring additional advantages such as support for mobility, enabling interaction with existing NGN service enablers, service personalization and media adaptation as well as provide converged applications integrated voice, data, video and mobile services to flexible quadruple play service concept (in the future proof of concept called sometimes also multi-play services). IMS based functional architecture for IPTV services The functional architecture of IMS based IPTV presented in this section contains main functions and reference points defined in TISPAN IMS IPTV concept. The following sections describe the main functions, including the service control function, the media control function and the media delivery function. We enhance the short description from original TISPAN drafts (originally described in TISPAN Work item 2048) and include additional functions descriptions in line with IMS IPTV concept as shown in Figure 19.

Figure 19 - Simplified and adapted IMS IPTV functional architecture In this section we define functional entities for the presented functional architecture and propose new concept of service control for IMS based IPTV. Several enhancements for distributed IPTV media delivery functional elements and new reference points are introduced. All these enhancements are necessary in more realistic environments. In the following subsection we would like to explain main principles of this IPTV functional architecture. The User Equipment communicates with the IPTV Service Control Functions via the Core IMS for the purpose of session management, and may use the Xt (enhanced Ut interface) reference point for the purpose of service profile configuration or interaction with IPTV application server (in this realization it is also used for service discovery and selection functionalities). IPTV application server functions (IASF) use the ISC interface to communicate with the IMS based NGN service control. Multimedia Service Control Function (MSCF) is introduced which should be used as reusable service control element for any multimedia services not just for IPTV services. This additional functional element extend IMS core without special needs to change IMS core functionality or interfaces. MSCF is used for control tasks across distributed media control and delivery architecture. Each UE has at least four interfaces for media control over Xc (originally Xc) and media delivery over Xd (originally Xc) as well as Gm

interface to IMS and Xt interface to IASF. Media Control Functions (MCF) can control Media Delivery Functions (MDF) over Xp reference point that also allows building a really scalable and distributed media delivery infrastructure. External content can be imported from external media sources (e.g. content providers) via Xg external interface for MDF. Multimedia Service Control Functions (MSCF) This function handles IPTV related request and play a role of the service and session control element for all IPTV services. This component is also responsible for interworking with IMS core on the service control layer. The service control function should include all functions required for each IPTV service and therefore should be reusable as specific IPTV application server functions or as separated functional elements depending on implementations (we therefore use separated functional entity called Multimedia Service Control Function - MSCF). General tasks of MSCF: Session initiation and service control for IPTV applications Interaction with IMS core and S-CSCF to perform IPTV requests (receive, validate and perform IPTV service requests from user) Service authorization and validation of user request for selected content based on user profile information Select the relevant IPTV media control/delivery functions Perform Credit control The MSCF could use the IPTV profile in order to customize the user experience. For instance, the list of subscribed channels could be used to filter the list of channels presented to subscriber. IPTV Media Control Function (IMCF) The purpose of this function is to: Selection of MDFs Propagate content to the distribution network. Manage the distribution of assets between media delivery functions and also to the user equipment (whether by streaming them or any other means) Content protection control function (Control licensing policy across IMDF, validate user license for specific content) Apply policy (e.g. according to specific spatial or temporal restriction) of distribution management; Storage management in the distribution and delivery system Mapping content ID and content location in specific IMDF Manage interaction with the UE (e.g. handling of video-recorder commands or IGMP commands) Manage the capture of live events (network PVR and network time shift TV) Collect information of service using statistics collecting and submission; Generate billing information

IPTV Media Delivery Function (IMDF) Originally MDF was responsible just for delivery of media to the user equipment (in IPTV domain, media may be video, voice as well as data). We propose to extend media delivery functionalities to the three following functional elements: Interconnection - IPTV Media Delivery Function (I-IMDF) these functions handles the media import and ingress importation of CoD content and all metadata and service provider as well as receives live streams from IPTV Headend or directly from content provider sources. Serving - IPTV Media Delivery Function (S-IMDF) function handles the processing of content (encoding, content protection processing, transcoding to different formats) and is also responsible for storage of contend and metadata together with propagation content information within IPTV IMS. Primary - IPTV Media Delivery Function (P-IMDF) function is primary contact point which provide also the streaming functionalities for all IPTV services in required quality, format and with specified casting (multi/uni-/broadcasting). Media delivery function can be distributed depending either on the service type (BC, CoD, PVR) or on the mentioned specialized subfunctions. Hence, this function is composed of the following sub-content: Metadata: used to provide user information about asset describing metadata such as SD&S data, EPG, or VoD catalogue. It may provide any type of metadata, given that it is properly standardized. Assets: the CoD-MDF is designed to deliver assets to the user equipments. Those assets were previously propagated by the IMCF to P-/S-IMDFs, according to the availability, popularity and regionalization of the content they compose. IMS core The IMS core is used to forward the complete SIP signaling used in the IMS for session management. The media flows of established sessions like IPTV streams, instead, do not traverse the IMS core. A number of Call Session Control Functions (CSCF) are introduced to establish a multimedia session between subscribers and to prepare delivery of the demanded services according to the session characteristics required by users. Some of CSCFs have interfaces to the Home Subscriber Server (HSS) where the complete information about particular subscribers is stored, like their profiles, policies, subscriptions, preferences, etc. Three types of CSCFs are defined: Proxy-CSCF (P-CSCF) is the first point of contact for the IMS users. The main goal of the P-CSCF are the guarantee of signaling messages between the network and subscriber and resource allocation for media flows by the interaction with TISPAN defined Resource and Admission Control Subsystem (RACS) Serving-CSCF (S-CSCF) is the main control entity within the IMS. It processes registrations from subscribers and stores their current location, is responsible for

subscriber authentication and call management. Subscriber policies stored in the HSS control the operations performed by the S-CSCF for a particular subscriber. Interrogating-CSCF (I-CSCF) queries the HSS to find out the appropriate SCSCF for the subscriber. It can also be used to hide operators network topology from other networks. Converged access aggregation network architecture The main aim of the described IMS based IPTV functional architecture is to provide various IPTV services with personalization and adaptation of service and media independently for any user terminal connected over underlying converged access aggregation network infrastructure. Figure 20 shows network architecture as a basic building block of the Next Generation Network that realizes Fixed & Mobile Convergence (FMC). The main element of the proposed network architecture is the Converged Access Aggregation Network (CAAN). All available access technologies are integrated within a single converged access network domain. Both wired (e.g. optical, DSL) and wireless (e.g. 3G and beyond, WiFi, WiMAX, Mesh) access networks are connected together via a jointly managed transport network. The Access Border Controller (ABC) is the main logical entity of the CAAN. It deploys overarching functions needed to provide mobility, AAA and QoS support within the CAAN. A new functional block placed on every access node, Universal Access Node Function (UANF), is an interface integrating every access technology into the common Ethernet based CAAN core. It supports interaction with the ABC and adapts its mechanisms like QoS reservation to the appropriate access technology of the access node whereon the UANF is installed. An Edge Router builds a single IP domain for all nodes connected to a CAAN and connects it to the IP backbone. Using the CAAN in the transport layer and the IMS in the control layer any type of multimedia services available in the application layer may be provided to mobile users connected to the CAAN. That avails convergence of fixed and mobile access networks since the multimedia services which can be delivered to network subscribers are independent from the terminal and access technology used by the subscriber. The next section describes how the IPTV functionalities reusing IMS signaling can be implemented in the CAAN.

Figure 20 - Converged access aggregation network architecture REALIZATION OF IMS BASED IPTV PLATFORM To proof the concept of the integration of IPTV and IMS platforms on the example of the advanced network architecture presented in Figure 2 we have prototypically elaborated the Click to Multimedia Service to evaluate and demonstrate advantages of the defined IMS based IPTV functionalities. The main particularities of the developed system are as follows: Session management performed in the IMS core and IPTV IMS capable application server Personalization of available services based on IMS user identities Support for both terminal and session mobility of IMS users maintaining IPTV service Accommodation of IPTV QoS parameters to the terminal device used to access IPTV service Personalization of IPTV services The prototypically implemented IMS based IPTV service enables a high level of efficiency and flexibility of service discovery and selection for IMS users. In a typical usage scenario an IMS user authenticates on a web portal using a secure https connection. Multimedia services including IPTV services available for the user according to its preferences and subscriptions are shown on a user-friendly graphical web interface adapted to user preference and capabilities of the terminal display. The logged on user is able to search for a specific service or media, modify its group of interest etc. After selection of the desired service a simple click on the appropriate icon or link is sufficient to initiate the establishment of the multimedia session.

During session establishment based on basic IMS mechanisms the QoS parameters of the selected multimedia service are adapted to the current user terminal in terms of audio and video bitrate and video resolution. During session handovers the QoS parameters are adapted to the new terminal device of the user. This is because a typical MDA with a small display and a not very powerful processor is not able to play back an incoming stream with HDTV quality. The flexible QoS adaptation is very important in the FMC environment where access networks of various access technologies with highly differing constraints are used by a number of terminals with different capabilities. Using implemented Click to Multimedia Service a single click on the selected service is enough to establish the desired multimedia session. Thereby users can access multimedia services using any terminal devices they have on hand. The best possible IPTV service quality in every access network with any terminal device is guaranteed. The possibility of session and terminal handovers enables the highest level of flexibility for mobile users maintaining multimedia services everywhere. Implementation details Generally, an IMS user needs to know the SIP identifier of the corresponding peer to be able to establish a multimedia session to it. Information about SIP identifiers which can be used to generate SIP INVITE messages during session initiation is usually stored in the buddy lists of IMS users. New entries in the list are created either manually or using some automatic mechanisms to exchange contact data between IMS users, like the well known contact sharing in Microsoft Outlook Express. A manual creation of the contact assumes that the user must know the exact SIP identifier of another network user or server that can provide a multimedia service desired by the user. Multimedia content that may be provided to IMS users may be hosted on a number of streaming servers located in the same or different administrative domains. Offering the information about services available for particular users is a big challenge in such network environment since there is no single point of contact that can be used by the user to discover and select an appropriate multimedia service in the network. Every time the user wants to get access to a multimedia content, e.g. to a video data, it has to discover the SIP identifier and the identifier of the content it wants to retrieve from a media streaming server. Only after that the user is able to initiate a session to the selected application server that will trigger the media streaming server to deliver the selected multimedia content to the requiring user. The exact methods which can be used to discover and select a specific content or a particular service are undefined in the current IMS standardization activities. The presented implementation contains simplified service architecture comprising proposed functions presented in Figure 19 to provide IMS based IPTV services in a CAAN shown in Figure 20. The implemented network architecture comprises application servers that provide a flexible and scalable discovery and delivery of multimedia services available for particular IMS users as shown in Figure 21.

Figure 21 - IMS based network architecture for delivery of multimedia services The application server (AS) with service discovery and selection (SD&S) functions is used to provide service information for IMS users. It has associations to a number of media service control servers (MSCF) via the ISC interface so that it can collect information about media content available from media delivery servers achievable through these MSCF servers. This interface is also used to connect the AS to the IMS core so that it understands SIP based signaling from IMS users. The AS supports also Sh interface to the Home Subscriber Server (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 may be created for a particular IMS user considering its preferences and subscriptions. Thereby the personalization, policy-based service discovery and value added multimedia services may be integrated and deployed using this SD&S scheme. Media discovery information can be provided to users in form of multimedia web

pages using a secure https connection on the Xt interface. The IPTV application server is therefore a single point of contact for IMS users for service discovery and can be seen as a key element to select and to initiate multimedia services available for registered IMS users. A step-by-step overview of the service discovery, service selection and further session establishment performed in a typical usage scenario using the described scheme is presented in Figure 22.

Figure 22 - Discovery and selection of the IPTV service and establishment of an IPTV session The IPTV application server is realized as a usual web portal. The GUI of the portal consists of a graphically adapted links to the multimedia services available for the IMS user. The IMS users use secure https connections to access the GUI provided by the IMS Application Server (AS). Hence, the https protocol is used on the Xt interface in the presented implementation. During the logon stage the user credentials received via the Xt interface are compared with user data required via the Sh interface from the HSS. The information about subscribed services of the user is also required via this interface and is then available to the AS that filters its database with the information about all available services and

builds a web page with only links to services available for the logged on user. The preferences of the user stored in the HSS are considered to build the page according to the policies defined for every particular user or for groups of IMS users. As result, personalization of the content offering is realized where both user subscriptions and preferences are considered. IMS user can then navigate on the built page and decide about the multimedia service it wants to initiate. To select the desired multimedia service the user can simply click onto the appropriate link or icon leading to the informing the user about selected multimedia session via the Xt interface. After that the IMS user can either automatically or manually initiate the selected IPTV session using IMS enhanced SIP signaling. Any type of multimedia sessions may be established using this method. Thereby there is no need to know, notice or store any identifiers of the content or streaming server providing this content. The IMS client that was developed during implementation exchanges session related data in the background that is transparent for the IMS user. That allows a fast and simplified service selection and establishment of multimedia sessions to the desired multimedia content. During IMS defined session establishment via the Gm interface the IMS client is able to inform the Server deploying Multimedia Service Control Functions (MSCF) the capabilities of the user terminal so that appropriate QoS parameters for the multimedia stream can be selected. After selection of appropriate QoS parameters the MSCF informs the Media Delivery Server (contains media control and media delivery functionalities) via the Y2 interface to stream data of the selected multimedia content to the requesting user via the Xd interface. The implementation uses RTP and RTSP protocols on this interface. Using RTSP protocol the user may also control data delivery in the case the user requires Content on Demand It can be paused, played faster or slower, etc. The RTSP protocol is then used for media control that take place on the Xc interface between the user and media streaming server.

3.5 IPTV security aspects

This section defines the IPTV security aspects represented by a general security architecture, a content protection architecture and service protection architecture. The IPTV security architecture described below assumes and is intended to be used in the context of the IPTV Functional Domains and IPTV Functional Architecture Framework, respectively. General Security Architecture A general security architecture for IPTV is depicted in Figure 22 below. This general architecture is divided into two primary areas: one considered in-scope for the purpose of interoperability, and another considered to be out-of-scope, where the first encompasses End-User, Network Provider, and Service Provider domains, and where the second encompasses the Content Provider domain. All security aspects within the Content Provider domain, and between Content Providers and Service Providers is considered to be out-of-scope, and, instead, subject to private agreements between the stakeholders operating in these domains. Although the Content Provider and the interconnect between the Content and Service Provider domains are considered out-of-scope in the present context, for the purpose of completeness, the Content Provider domain is nevertheless included in the figures and descriptions that follow.

Application Server Functions Application Client Functions SCP Client Functions Media Client Functions Control Client Functions

Application Profile Functions

Content & Metadata Sources

Service Control Functions Service Profile Functions Content Preparation Functions Rights & Key Management Functions

Content Provider Access

Delivery Network Gateway Functions

Access Network Functions

Out of scope

Figure 22 - IPTV General Security Architecture

The general security architecture is divided roughly into four areas of functionality as follows: Content Provider Functions Although technically out-of-scope, it is assumed that content provider(s) will provision access to content for those service providers that have established relationship(s) with the content provider(s). In some cases, a content provider may themselves serve as a service provider, in which case this relationship is considered to be internal. In providing access to content for service providers, a content provider may use standard or private mechanisms to control and enable access to content; however, such mechanisms are usually subject solely to private agreement. Service and Content Protection Functions The role of service and content protection functions play a central role in the IPTV general security architecture. In particular, service protection functions enable protection of the service infrastructure as well as controlling access to services and the content contained therein, while content protection functions enable controlling the use of services and content according to licensed uses. In general, a service provider is obligated by license(s) with content providers to make content available only under certain conditions of use, such as for one-time viewing but no recording, one-time recording with multiple viewing, one-time recording with transfer of recording rights, etc. The primary purpose of the service and content protection function is to provide technical mechanisms to allow a service provider to satisfy such obligations in an objectively verifiable manner. The primary purpose of service protection is to prevent unauthorized access to information considered to be confidential by entities in various domains: service, network, terminal device, and end-user (subscriber). A secondary purpose of the service protection aspects of the service and content protection function is to protect the service infrastructure from damage due to both intentional and accidental misuse or access. Network Functions Security functions that pertain to the network domain are focused on authenticating and authorizing access to the network(s) through which IPTV services are or will be delivered. A secondary function is to protect the integrity of the network itself: physically, electronically, and operationally (e.g., by detecting and thwarting denial of service attacks on the access or bearer network). End User Functions Aspects of security that apply to the end-user (subscriber) include protection of the integrity of the IPTV terminal device operating on subscriber premises as well as protection of end-user privacy. In some circumstances, a gateway between an IPTV terminal device and a delivery network may be considered to be in the end-user domain and subject to end-user security measures. Finally, in those cases where content is received by an IPTV terminal device and subsequently redistributed to other devices, the maintenance and integrity of

content protection rules may apply, which results in overlap between end-user security aspects and content security aspects. Content Protection Architecture A content protection architecture for IPTV is depicted in Figure 23 below. The primary function of the content protection architecture is to delineate the flow and processing of information pertaining to content usage rights and information required to manage and facilitate such rights. Ultimately, rights of content use originate with content provider(s); however, such rights may be modified (e.g., narrowed, or perhaps even widened) by service provider(s) according to their agreements with content providers and their operational and business policies. From an operational and typical legal perspective, an end-users access and use of content is with the service provider, and not a content provider.

Figure 23 - IPTV Content Protection Architecture

An end-user may not, in fact, perceive their access to content is a through a relationship with a service provider; rather, they may misperceive this relationship as one with a content provider. This is not an unlikely circumstance, particularly since content is more often branded by the content provider than by the service provider. At any given time, a service provider may or may not include some type of branding mark that effectively notifies the end-user of their role, for example, a station mark (bug) or logo superimposed into a video stream. Notwithstanding the presence of such a mark, an end-user may fail to notice or realize that their legal relationship (if one exists) is with the service provider. The content protection architecture showed here focuses primarily on two functional areas: Service and Content Protection Functions Content and its associated rights are collected from content providers, aggregated, and processed for delivery to the end-user, where the overall process is managed by an IPTV Application Server using stored Application Profile data that describes an end-users rights and related conditions. Content, rights, and keys (used to grant access to and use of content) are organized into a form appropriate for the specific IPTV application, for example, linear television viewing. Rights and key information are delivered to an SCP Client functional entity in the terminal device, content is then processed to (optionally) insert content tracing (e.g., watermarking) metadata and then is then encrypted prior to delivery. In the context of the IPTV Content Protection Architecture (as opposed to the subsequently described IPTV Service Protection Architecture), the focus is primarily on the management, processing, and delivery of rights and key information as opposed to the encryption of this information or the content subject to these rights. End-User Functions The IPTV Terminal Device, operating in the End-User domain, is responsible for enforcing content usage rules ascribed to rights information (also known as content protection metadata). An SCP Client functional entity interprets content rights and keys obtained from the IPTV Application Server and then acts on the interpretation to control how the content is processed and exposed to the enduser, either through integrated presentation devices (such as a display or audio rendering system) or through physical interconnects to external devices. In those cases where the IPTV Terminal Device transmits protected content to an external device (such as a display or another device), the content usage rules may be translated in form, and the content to which such usage rules apply may be further processed to insert client-side content tracing information (e.g., watermarks) or re-encrypt content to effect downstream access control. Service Protection Architecture A service protection architecture for IPTV is depicted in Figure 24 below. The primary functions of the service protection architecture include: Authentication and Authorization

For managed services involving protected content, it is typically the case that the end-user (subscriber) must be authenticated and, subsequent to successful authentication, authorized to access service(s) and the content contained therein. Depending upon circumstances, authentication and authorization functions may be performed separately on the IPTV terminal device and the enduser(s). In other cases, additional devices in end-user premises, such as a delivery network gateway and other end-user devices may require authentication before service access is authorized. The combination of authentication and authorization can be considered to effect positive access control on the terminal device and end-user for purposes of service and content acquisition prior to use. Control Signaling and Content Interchange Encryption In order to limit acquisition and access of services and content, both control message information and content itself is encrypted (scrambled). Different (strength) levels of encryption may be applied to the various control signaling and content interchange paths in accordance with the requirements of a concrete IPTV system or service providers.

Figure 24 - IPTV Service Protection Architecture

3.6 IPTV over DSL and FTTH

The delivery of Internet protocol TV (IPTV) using DSL is an emerging and exciting technology that offers new business opportunities to service providers. ADSL2+ and VDSL2 data rates make it possible to easily integrate voice, video and data services over a single telephone line, commonly denominated tripleplay services. With all these technological developments, it is now practical and economical to simultaneously provide multiple standard and high-definition television channels (SDTV and HDTV) to the residential user. The term IPTV usually includes a broad range of programs or TV channels provided by one or multiple service providers. Additionally, it might include some specialized programming like concerts, special events and movies, provided only when requested by the user; i.e., video on demand (VoD). Like every other evolving technology, there are multiple approaches for the delivery of IPTV across the core network and its transmission to the customer premises over an ADSL2+ connection. In general, video service providers first perform the coding and compression of the video signal typically using MPEG-2, MPEG-4 or WM9/VC-1 (it is at this stage that a trade-off between quality and required bandwidth occurs). Then, the video content is ready to be distributed by streaming IP packets using the user-datagram protocol (UDP), which is the preferred method of IP packet delivery when offering video due to its low latency. Once at its final destination, the subscribers house, the video stream is decoded by a set-top box (STB) and played on the TV (Figure 25). This subsection discusses the basic properties that define video over ADSL2+ streaming, the measurement principles behind IPTV quality of service (QoS).

Figure 25 - Typical IPTV-over-DSL network

Quality of IPTV On any ADSL-based deployment, the quality of the consumers video is not just a function of the network bandwidth (ADSL2+/ADSL) or the data stream, as there are a number of parameters that contribute to the customers perception of good vs. bad quality. As the video stream arrives to the settop box and ultimately the television, it has gone through various protocol layers (e.g., physical ADSL layer, ATM layer, IP layer, transport layer, etc.). It is the interaction between these layers and the effect of external influences that affect the quality of the video perceived by the consumer; this is often referred to as quality of experience (QoE). Some of the parameters that influence the customers QoE include image pixelization and tiling, picture blurring and edge distortion, as well as audio dropouts and channel-change latency (also known as zap time). A typical IPTV configuration from the digital subscriber line access multiplexer (DSLAM) to the customer premises is shown in Figure 26. As shown, the video stream is delivered using ADSL2+ from the IPbased DSLAM to the users ADSL2+ broadband router. The router, while supporting voice and Internet service, passes the video stream to the STB for decoding. The STB converts the video stream into required signals for displaying on the consumers TV.

Figure 26 - Typical IPTV configuration Factors Affecting Service Encoding and Compression The quality of the video being distributed across the network can be affected right at the source; i.e., at the video head end. The encoding and compression

process usually creates a trade-off between the quality of the video and the desired compression level. In addition, depending on the encoding and compression technique used, the amount of video information per IP packet will vary. Therefore, an IP packet loss can represent a single unnoticeable missing point of the video sequence or a large period of degraded, pixilated (Figure 27) or unavailable image.

Figure 27 - Pixelated image Jitter A typical IP packet carrying MPEG-2 video-streaming data consists of seven MPEG transport stream packets, each containing 184 bytes of payload and 4 bytes of header. This results in 1316 bytes, plus the packet overhead 8 bytes for the UDP header, 20 bytes for the IP header, 14 bytes for the Ethernet header and 10 bytes for ATM overhead for a total frame size of 1368 bytes (Figure 28).

Figure 28 - Frame for MPEG-2 Video Jitter is defined as a short-term variation in the packet arrival time, typically caused by network or server congestion. If the Ethernet frames arrive at the STB

at a rate that is slower or faster, as determined by the network conditions, buffering is required to help smooth out the variations. Based on the size of the buffer, there are delivery conditions that can make the buffer overflow or underflow, which results in a degradation of the perceived video. Similarly, knowing the characteristics of a specific STB, the service provider might be able to characterize the maximum jitter supported by the IPTV network before noticing a considerable video degradation. This value will be a decisive factor when analyzing the video QoS at the customer premises. Limited Bandwidth The total amount of video-stream data that can be sent is limited ultimately by the customers actual ADSL/ADSL2+ rate. Core IP infrastructure is usually based on optical networks with a low level of congestion; therefore, bandwidth limitations are commonly located only within the access network or the customers home network. When traffic levels hit the maximum bandwidth available, packets are discarded, leading to video quality degradation. ADSL2+ rates may be temporarily affected by external factors, which in turn can generate pixelization of the image. Another situation might occur when, in addition to the IPTV service, a high amount of data is downloaded simultaneously to a PC and the traffic priorities have not been assigned correctly by the service provider; in these cases, video streaming packets are lost. A less common but important case is when video is streamed in variable-rate mode, in which considerable changes in the video sequences lead to an increase in the bandwidth requirement. This can generate packet loss and hence quality degradation. Bandwidth limitation is one of the main factors to be evaluated during the network design stage.

Figure 29 Edge distortion

Packet Loss Loss of IP packets may occur for multiple reasons bandwidth limitations, network congestion, failed links, and transmission errors. Packet loss usually presents a bursty behavior, commonly related to periods of network congestion. Depending on the type of transport protocol used for the video streaming, a packet loss will have different impact on the quality of the perceived video. When UDP is used, the lost packets will directly affect the image, as the information cannot be recovered and the image will simply be corrupt or unavailable. When using TCP, a packet loss will generate a retransmission, which can produce a buffer underflow and, consequently, a possible frozen image.

IPTV over optical networks Passive optical network (PON) has proven to be the lowest-cost fiber-to-thehome (FTTH) network for triple-play services. For video, service providers have realized the need to provide Internet protocol television (IPTV) as opposed to cable TV (CATV) overlay on their PON not only for a richer and more competitive video offering, but also for driving down costs. Although gigabit PON's (GPON's) (International Telecommunication Union Telecommunication Standardization Sector [ITU-T] G.984) most famous feature is its downstream rate, is it fast enough to support high definition (HD) TV or multiple stream of standard definition (SD) TV over IP? Can it meet the bandwidth demand in a multipledwelling unit (MDU) application? Is GPON the right PON technology choice to make now? The primary driver for GPON is the expected consumer bandwidth demand for IP-based SDTV and particularly HDTV services. Reports indicate that nearly 60 percent of all homes in the United States will have HDTV sets by 2012. It then becomes obvious that HDTV content will begin to dominate TV programming shortly thereafter. While an SDTV channel with Moving Pictures Experts Group 2 (MPEG2) encoding requires approximately 3 Mbps of capacity, HDTV needs about 18 Mbps and thus will very quickly consume PON downstream capacity. The question is, how fast must a PON be to support a mix of IPTV content and still provide basic IP services such as voice and high-speed Internet? This question is not simple to answer. It depends on factors such as demographics; take rate; whether traffic transmission is broadcast, multicast, or unicast; and network planning. Without attempting any IPTV traffic modeling, a simple capacity usage model can be created to establish how many subscribers can be supported or are available for basic high-speed Internet and voice services if a given number of IPTV channels are on the PON for a given a mix of SDTV and HDTV content. The model simply sets the mix of IPTV channels on the PON and calculates the corresponding number of subscribers that can be serviced with the remaining bandwidth. For illustrative purposes, GPON at 2,488 Mbps will be compared to the popular Ethernet PON (EPON) of 1.25 Gbps. The assumptions for this simple model are as follows: HDTV channel 18 Mbps SDTV channel 3 Mbps

GPON downstream rate 2,488 Mbps 92 percent efficiency = 2,289 Mbps EPON downstream rate 1,250 Mbps 72 percent efficiency = 900 Mbps (for an explanation of how these efficiency percentages were derived, see Table 1 in "GPON vs. EPON: A Cost Comparison," Lightwave, September 2005, page 27.) High-speed Internet = 100 Mbps per subscriber with 20:1 oversubscription Voice over IP (VoIP) will not be considered, since the most bandwidth used per channel is only 100 kbps and has a negligible effect on the outcome. The results of the model as seen in Figure 30 illustrate how drastically the number of subscribers supported drops when HDTV content increasesparticularly with EPON. For example, with 45 SDTV and five HDTV channels on the PON, EPON can service up to 135 subscribers with high-speed Internet, while GPON can support up to 413. However, as the video content goes to 100 percent HDTV with 50 video channels on the PON, EPON's downstream capacity is exhausted while GPON can still guarantee high-speed Internet service to 278 subscribers.

Figure 30 - The More HDTV Streams There Are, the Fewer Subscribers Can Enjoy High-Speed Internet Access. GPON Provides Greater Overall Bandwidth than EPON; Therefore, It Can Support a Greater Number of Subscribers with Combined HDTV/Internet Service Offerings Using this example in an MDU application with a split ratio of 1:32, GPON can support basic high-speed Internet service and voice to 32 optical network units (ONUs) supporting eight subscribers each (i.e., 278 32). Statistically, the number of subscribers can be even higher and will depend on the technical and business practices of the service provider. However, it is anticipated that there will be many more TV channels to the home because of multiple picture-in-picture viewing for sporting events, digital video recorders (DVRs), and content going to more than one TV set per home. Even in a single-family unit (SFU) network with a split ratio of 1:32, EPON will be stretched to guarantee basic high-speed Internet service in an HDTV-rich PON. Fundamentally, it is GPON's efficient 2,488-Mbps downstream transport that is

the enabler for IPTV delivery with sufficient capacity for HDTV, even for an MDU PON. Ultimately, for a unified, low-cost network, all services will converge to IP delivered via Ethernet. The question is: how do you get there while supporting current legacy services? The answer in the optical access network is GPON. Only GPON enables service providers to migrate their legacy time division multiplexing (TDM) and asynchronous transfer mode (ATM) technology to 100 percent Ethernet. Conversely, with EPON as the optical access technology, the decision is immediate all services must be Ethernet. Even with TDM circuit emulation service (CES), GPON still offers significantly better transmission performance over EPON because of its PON level quality of service (QoS) capabilities2. As with broadband PON (BPON), the comprehensive nature of the ITU-T G.984 GPON standard provides the means for industry-wide interoperability of optical components, chips, and equipment. The global success of digital subscriber line (DSL) can be attributed to interoperability because it enabled low-cost, highvolume commodity customer-premises equipment, which in turn has allowed service providers to deliver low-cost services. In 2006, there have been four GPON interoperability events with a total of 19 equipment vendors from around the globe demonstrating Internet and IPTV services. EPON, on the other hand, has been limited to service provider interoperability initiatives and not any national let alone global initiatives. GPON is more than just a faster PON for IPTV. It is an ITU-T PON technology that has demonstrated its maturity through interoperability. As a result, leading service providers around the world have selected GPON is its fiber access technology for the future. This has led to the leading equipment and chip vendors investing in GPON technology to drive down cost for mass deployment, as was the case for DSL.

3.7 IPTV over wireless and mobile networks

IPTV over WiMAX Worldwide Interoperability for Microwave Access (WiMAX) technology is based on IEEE 802.16 2004 and 802.16e 2005 standards for fixed and mobile wireless access in metropolitan area networks (MAN). It can deliver data rates of 70Mbps, cover ranges in excess of 30km, and it can provide secure delivery of content and support mobile users at vehicular speeds. WiMAX medium access control (MAC) layer supports real time poling services (rtPS) that ensures required bandwidth and minimum latencies for video services through quality of service (QoS). It uses orthogonal frequency division multiplexing (OFDM) and orthogonal frequency division multiple access (OFDMA) physical layer (PHY) that are resilient to multipath fading channels. Moreover, it uses adaptive modulation schemes and forward error correction (FEC) to increase service quality. Since WiMAX PHY supports varying frame sizes and scalable bandwidth, WiMAX is an ideal choice for IPTV applications. WiMAX is considered as an all IP access network and offers transparency for packet based core networks. Additionally, WiMAX radios are designed not to add any impairment to the content delivery. Hence, WiMAX base stations (BSs), subscriber and mobile stations (SSs/MSs) are ideally suited for the delivery of IP based services; (triple play) VoIP, IPTV, internet multimedia over wireless MAN. This makes WiMAX a superior choice over conventional cable, DSL, and satellite solutions. WiMAX access networks will offer the much desired ubiquity for the content. Eventually, WiMAX deployments will deliver IPTV to rural and underserved regions with high degree of video and audio quality at affordable prices. This section, presents a system deployment model for IPTV services over WiMAX. Functional block diagram of an IPTV application is illustrated in Fig. 31. Video servers/encoders store audio/video (A/V) content which are encoded and compressed from live and pre-recorded programs. Video servers/encoders are either centralized or distributed in core networks.

Figure 31 System model for IPTV over WiMAX

Fig. 32 shows the protocol stack for IPTV transmission. A/V content from the source is formatted, compressed (mostly using MPEG-2 encoding and compression standard) and is encapsulated as real time transport protocol (RTP). This payload is transported as either user datagram protocol (UDP) or transmission control protocol (TCP) datagram which in turn becomes the payload for internet protocol (IP). The IP payload is encapsulated as Ethernet 802.3 and 10/100/1G Bass-T traffic that travels over the core networks. WiMAX BS that sits at the edge of the core network receives the 802.3 packets and the BS MAC decapsulates Ethernet headers and encapsulates the IP payload as 802.16 MAC PDUs and then into PHY PDUs. The 802.16 PHY prepares these PDUs for wireless air-link by performing FEC, symbol mapping and OFDM modulation. The radio transceiver radiates these signals through antennas to SSs and MSs within the cell. The reversed process through said layers delivers A/V content to IPTV ready STB, PCs. One of the drawbacks of packet based transmission is the overheads associated with each layer. As a result, the payload capacity is greatly reduced. IPTV transmission requires higher payload capacity, therefore, it poses a challenge in providing maximum service. The user datagram protocol (UDP), transmission control protocol (TCP) and internet protocol (IP) with associated overheads are part of WiMAX payload. Note that IEEE 802.16 MAC and PHY adds its own overheads.

Figure 32 Protocol Stack for IPTV Transmission over WiMAX IPTV over WiFi The current popular wireless home networks use the wireless technologies specified in the IEEE 802.11 standards. The IEEE 802.11 working groups specify a series of wireless communication technologies and medium access control (MAC) protocols that keep the advancement of wireless local area networks (WLANs). Some important standards include the IEEE 802.11b standard

specifying the operation of up to 11 Mbps data rate on the 2.4 GHz wireless channel, the IEEE 802.11g standard enhancing the operation to 54 Mbps data rate on the 2.4 GHz wireless channel, the IEEE 802.11e standard specifying the enhanced distributed channel access (EDCA) to provide quality of service (QoS) support to the IEEE 802.11 WLANs, and the recently standardized IEEE 802.11n standard enhancing the operation to 100 Mbps data rate. With these constant efforts of enhancements, the IEEE 802.11 WLANs have prepared themselves not only to provide wireless Internet access for best effort (BE) traffic, but also to deal with future network applications with high demand in bandwidth and QoS such as multimedia-rich applications. As we witness the advancements in WLANs in the last decade, we also see increasing demand of high quality media from the traditional low-resolution media to the current DVD quality media, the emerging HDTV quality media and the potential new arrival of 3D TV media. IPTV, in which video content is digitized and sent to individual receivers as IP packets, is adopted for most recent media development. IPTV media can be accessed on multi-purpose devices instead of traditional TV devices with some dedicated functions. The content of IPTV can be personalized and accessed from locations where Internet connectivity is available. The current popular coding schemes for IPTV include H.264 advanced video coding (AVC), H.264 medium grained scalability coding (MGS), and H.264 scalable video coding (SVC). The rapid evolution of IPTV media in recent years has prompted the urgency in the investigation of the WLAN support. The investigation of the WLAN support for IPTV media is especially important for the IEEE 802.11 WLAN due to its employment of contention-based operation for both channel access and QoS support. The mechanism of the contention-based operation in IEEE 802.11 WLAN gives rise to uncertainties in the efficiency of channel access and effectiveness of QoS support. The tremendous growing of the IEEE 802.11 WLANs deployed in the home environment in recent years has encouraged the use of IP networks for various traditional and new network applications, such as networking of home appliances, home security, and also IPTV. There are, however, challenges in using a single common wireless home network for home network applications with increasing demands in bandwidth and QoS requirements. The shared wireless channel architecture in WLANs introduces a bottleneck in the network and the employment of contention-based MAC protocol poses uncertainty in the efficiency of the WLANs. These problems have amplifying effect especially in multimedia applications such as IPTV as they demand high and steady bandwidth to provide adequate operations. Anticipating the increasing demand for personal entertainment in the home environment, IPTV will be the next key application in wireless home networks. Fig. 33 illustrates a scenario of IPTV streaming over wireless home networks. Factoring the potential application of personal entertainment in wireless home networks, we consider a scenario of simultaneous IPTV streams in the wireless home network environment, where different IPTV traffic packets are transmitted by unicast to different users. It is believed that the IPTV service that offers

personalized entertainment is likely to rely on unicast transmission heavily, which is different from the traditional broadcast of TV contents. Additionally, the considered wireless home network also carries some amount of BE traffic generated by other network applications. All IPTV users are equipped with a wireless settop box to communicate with a media server on the Internet via the access point (AP) over the wireless home network. In this setup, the AP acts as a relay that forwards the received IPTV streams to all IPTV users over a wireless link. Given the robust first mile access network and high speed connectivity between the Internet and a wireless home network, it is expected that streaming of IPTV will find transmission bottleneck at the wireless link within the wireless home network. We assume that the AP enjoys a 100BASET connectivity to the Internet. The presented scenario considers various wireless technologies that offer 11 Mbps, 54 Mbps and 100 Mbps physical data rates, with the IEEE 802.11e EDCA QoS implementation.

Figure 33 A scenario example of IPTV over WiFi The IPTV transmission process can be described as follows. An IPTV user tunes to a particular program where the set-top box makes a request accordingly to the

media server. The media server then starts to stream the IPTV traffic over the Internet and the wireless home network to the IPTV user. The IPTV traffic is packetized using RTP/UDP/IP protocols. The IPTV traffic is typically encoded with a pattern of one I frame followed by many P frames or B frames to form a group of picture (GoP). Each frame is encoded and packetized into one video packet in the application layer which may be subjected to fragmentation in the lower layers. At the receiver side, each frame is decoded from received packets. In the event of a packet loss, not only the frame within the lost video packet is lost, but also the subsequent frames that rely on the lost video frame to decode in the same GoP are considered lost. A lost frame is then replaced by the previously decoded frame for error concealment. IPTV over cellular networks In case of cellular networks, if there is no multicast stream, service provider will interrogate network provider weather the VoD content is highly requested or not. If its not highly requested content, it is delivered by unicast transmission without any delay through the dedicated channel. If its highly requested content, MBMS (Multimedia Broadcast Multicast Service) of LTE starts multi-channel multicast transmission algorithm. Multicast transmission can use multicast address to forward content to the end user; hence user can receive the VoD. In a multicast network, users requesting the same data can be logically grouped as a multicast group (MGroup). For example, all subscribers watching the same TV channel in the MGroup, the total number of MGroups in the network is equal with TV channels. However, subscribers are distributed at different locations and experience different fading and path-loss due to time-varying wireless channels, it remains challenging to provide satisfactory multicast services to all subscribers. Upon completion of the above step, the service provider provides the content access information and then the end-user can receive the video. In other words, the multichannel multicast address is used to forward the content to the end user. In this multicast algorithm showed in Figure 34, service provider checks weather multicast stream exists or not, for the VoD contents requested by customer. If the multicast stream exists, server will send an address of multicast group to the user, thus he can join to the multicast stream.

Figure 34 Service procedure for IPTV VoD service over cellular networks

Here, we look at a multi-channel multicast algorithm which allocates the content (segments) packets into several channels of cellular network, including MBMS as shown in Figure 35. The multicast broadcast transmission is performed through the MBMS of LTE by adding only 1 additional functional entity: MBMS controller. Multicast is a bandwidth conserving technology that allows an E-UTRAN to send packets (video segments in this case) to a subset of all SSs as a group transmission.

Figure 35 IPTV cellular network architecture An MBMS session refers to a logical connection, established between an MS and the MBMS controller, by which the MBMS video is delivered to the users. An MS identifies each session by the tuple id of a channel identifier, named as a logical channel ID, and a MBMS data ID. The MBMS creates and maintains session information. It also transmits the packets from the content chopper. The content chopping mechanism is added in order to efficiently deliver the multicast VoD contents. Since 3GPP LTE with MBMS defined criteria only for PHY and MAC layer, we need a model for the end-to-end transmission over LTE as shown in below Figure 36.

Figure 36 End-to-end IPTV MBMS solution over LTE After MBMS content division function finished dividing video into segments, these will be converted to the MBS packets by MBMS session management/transmission function. Then those packets will be transmitted to the BS. LTE - MBMS can support in either constructing PHY/MAC layer with OFDMA to transmit a mix of unicast and multicast service or upper layer with content copper. Then BS starts to map the segmented contents to dedicated channel id for transmission over LTE PHY/MAC, next LTE PHY layer handles burst scheduling and OFDMA data for each mac/pdu. UE need to have enough storage (greater than 10Gb) to buffer the streaming and downloading whole content, channel switcher, standard decoder. With signaling information of multicasting from MBMS of LTE through the base station like eNodeB, mobile subscriber starts to receive the multicast stream and select channels via logical channel switcher. Next, the channel switcher determines channel id according to the requested content and indicates. LTE PHY/MAC will decode only those MBMS MAC PDUs associated with the selected channel id. After receiving the first segment from the channel, S1, it also receives other related segments from the rest of the channels simultaneously while MS watches S1. Finally user application decrypts and reconstructs the content packets according to standard H.264/AVC video decoding. After MS receives all the segments, the segments ordering will be performed by FLUTE of MBMS. Because of transmission environment, the segment order might be changed.

3.8 Reference list

[1] ITU-T Recommendation Y.2001, General overview of NGN, December 2004. [2] ITU-T TD 40 (IPTV-GSI), Initial version of proposed draft Recommendation Y.iptvreq, IPTV service requirements, January 2008. [3] ITU-T SG 13 [4] ITU-T TD 592 (WP3/13), The draft Recommendation Y.NGN-R2-Reqts, Requirements and capabilities for ITU-T NGN release 2, January 2008. [5] ITU-T IPTV-GSI [6] ITU-T TD 32 (IPTV-GSI), Draft Recommendation: IPTV architecture, January 2008. [7] Jihye Lyu, Shinjee Pyo, Jeongyeon Lim, Munchurl Kim, Sunhwan Lim, Sangki Kim, Design of open APIs for personalized IPTV service, Proc. the 9th International Conference on Advance Communication Technology, vol.1, pp.305-310, February 2007. [8] Markus Hofman, Leland R. Beaumont, Open pluggable edge services, an architecture for networked content services, IEEE Internet Computing, vol.11, pp.67-73, January 2007. [9] Sunghan Kim, S. Y. Lee, Web technology and standardization for Web 2.0 based IPTV service, Proc. the 10th International Conference on Advance Communication Technology, vol.3, pp.1751-1754, February 2008. [10] ITU-T Recommendation Y.2012, Functional requirements and architecture of the NGN, September 2006. [11] ITU-T Recommendation Y.2000SerSup1, NGN release 1 scope, July 2006. [12] ITU-T Recommendation Y.2201, NGN release 1 requirements, April 2007. [13] ITU-T Recommendation Y.2011, General principles and general reference model for next generation networks, October 2004. [14] ITU-T Recommendation Y.2014, Network attachment control functions in next generation networks, consented at January 2008. [15] ITU-T Recommendation Y.2111, Resource and admission control functions in next generation networks, September, 2006. [16] Open IPTV Forum Working Draft 20, Open IPTV forum functional architecture V 1.0, September 2007. [17] ATIS-0800002, IPTV architecture requirements, ATIS-IPTV Interoperability Forum, April 2006. [18] ATIS-0800003, IPTV architecture roadmap, ATIS-IPTV Interoperability Forum, August 2006. [19] ATIS-0800007, IPTV high level architecture, ATIS-IPTV Interoperability Forum, March 2007. [20] ITU-T TD 3 (IPTV-GSI), FG-IPTV deliverable: IPTV service scenarios, work in progress, January 2008.

[21] Cisco, The evolving IPTV service architecture, White Paper, C11-409311-00, May 2007. [22] ITU-T Recommendation Y.2021, IMS for next generation networks, September 2006. [23] A. Cuevas, J.I. Moreno,P. Vidales, H. Einsiedler. The IMS service platform: a solution for next-generation network operators to be more than bit pipes, IEEE Communications Magazine. Vol: 44 (8). ISSN: 0163-6804 [24] Draft ETSI TS 182 027 V0.0.9 (2007-04), Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); IPTV Architecture; IPTV functions supported by the IMS subsystem, ETSI Technical Specification Draft, 2007 [25] WG2TD11 WI2048 Proposal for IMS based IPTV serviceand media control, TISPAN technical draft, ad-hoc IPTV TISPAN IPTV meeting, Madrid, 16 to 19 April 2007 [26] M. Siebert, B. Xu, M. Grigat, E. Weis, N. Bayer, D. Sivchenko et al. ScaleNet Converged Networks of the future. it Information Technology of Informatics and Information Technology 48 5/2006. October 2006, Oldenbourg Wissenschaftsverlag, ISSN 1611-2776, pp. 253-263. [27] ScaleNet - The scalable and converged multi-access operators network from tomorrow. [28] WiMAX Forum, Available online: http://www.wimaxforum.org [29] IEEE Standard for Local and metropolitan area networks Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems. [30] Xilinx Virtex 4 FPGAs, Available online: http://www.xilinx.com/products/ silicon_solutions/fpgas/virtex/virtex4/index.htm. [31] Zhou, J. and Chen, J. and Zhao, J. and Wang, J. and Kang, W., Design of a High Performance RF Transceiver for WiMax Basestation, Microwave Conference Proceedings, 2005. APMC 2005. Asia-PacificConference Proceedings, vol. 5, 2005. [31] Balvinder Bisla, Roger Eline,and Luiz M. Franca-Neto, RF System and Circuit Challenges for WiMAX, Intel Technology Journal, Vol. 8, Issue 3, pp. 189-200, 2004. [31] Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Higher-speed Physical Layer Extension in the 2.4 GHz Band, IEEE Std. 802.11b, 2000. [33] IEEE 802.11g-2003: Further Higher Data Rate Extension in the 2.4 GHz Band, IEEE Std. 802.11g, Sep 2007. [34] Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications Amendment 8: Medium Access Control (MAC) Quality of Service Enhancements, IEEE Std. 802.11e, 2005. [35] IEEE 802.11n-2009: Amendment 5: Enhancements for Higher Throughput, IEEE Std. 802.11n, Oct 2009. [36] N. Nasser, Service adaptability in multimedia wireless networks, IEEE Transactions on Multimedia, vol. 11, no. 4, pp. 786792, 2009.

[37] J. Hu, S. Choudhury, and J. Gibson, Video capacity of WLANs with a multiuser perceptual quality constraint, IEEE Transactions on Multimedia, vol. 10, no. 8, pp. 14651478, 2008. [38] K. Ahmad and A. Begen, IPTV and video networks in the 2015 timeframe: The evolution to medianets, Communications Magazine, IEEE, vol. 47, no. 12, pp. 6874, 2009. [39] C. Foh, M. Zukerman, and J. Tantra, A markovian framework for performance evaluation of IEEE 802.11, IEEE Transactions on Wireless Communications, vol. 6, no. 4, pp. 12761265, 2007. [40] I. Gerhardt and B. L. Nelson, Transforming renewal processes for simulation of nonstationary arrival processes, INFORMS Journal on Computing, vol. 21, no. 4, pp. 630640, 2009. [41] Y. Xiao, X. Du, J. Zhang, and F. Hu, Internet protocol television (IPTV): the killer application for the next-generation Internet, IEEE Communications Magazine, vol. 45, no. 11, pp. 126134, 2007. [42] I. Djama and T. Ahmed, A cross-layer interworking of DVB-T and WLAN for mobile IPTV service delivery, IEEE Transactions on Broadcasting, vol. 53, no. 1 Part 2, pp. 382390, 2007. [43] Q. Du and X. Zhang, Statistical QoS provisionings for wireless unicast/multicast of layered video streams, in INFOCOM, 2009, pp.477485. [44] E. Shihab, F.Wan, L. Cai, A. Gulliver, and N. Tin, Performance analysis of IPTV traffic in home networks, in IEEE Global Telecommunications Conference, 2007, pp. 53415345. [45] E. Shihab, L. Cai, F. Wan, A. Gulliver, and N. Tin, Wireless mesh networks for inhome IPTV distribution, IEEE NETWORK, vol. 22, no. 1, pp. 5257, 2008. [46] L. D. and J. Pan, Performance Evaluation of Video Streaming over Multi-Hop Wireless Local Area Networks, IEEE Transactions on Wireless Communications, vol. 9, no. 1, pp. 338347, 2010.