You are on page 1of 7

Deployment of an Internet Protocol Television Network

Engr. Muhammad Zafar Iqbal


Communication & Networks Research Lab, PSATRI, King Saud University, Riyadh, Saudi Arabia Key Words: TSTV (Time Shift TV), TVOD (TV on demand), ONU (Optical Network Unit). 1. Abstract

This paper is a recollection of personal experiences of working in the design and deployment of an IPTV network and may be useful for professionals and operators who are actively considering IPTV for extending their service offerings. This paper intends to fall under the category of Applied Studies as mentioned in [ICCT Brochure, 2009]. Internet Protocol Television is an important tool under active consideration of many telecom operators for survival in the competitive environment of post deregulation era. The driving factor behind IPTV is vast deployment of Internet Protocol and its extension beyond originally intended data communication application into real time voice and video applications. The telecom operators working in monopolistic environments are experiencing pains of eroding traditional voice revenue streams and are eagerly looking for alternates to add value to their service bouquet. Pakistan Telecommunication Company is one such company. After enjoying working in a monopolistic environment for several decades, it started to face tough competition mainly due to proliferation of cellular networks. Therefore in a major strategic move, it decided to add IPTV in its service offerings. Internet Protocol Television delivery mechanism is a highly integrated network, composed of several segments such as the Headend, transmission network, IP Core, Middle ware, Access technologies (BRAS/ DSLAMs), copper plant and the Customer Premises Equipment. This paper is an effort to describe the working of a complete IPTV service delivery network while explaining the functioning of its contributing components. Key Words: TSTV (Time Shift TV), TVOD (TV on demand), ONU(Optical Network Unit). 2. Introduction

The Figure1 gives an overview of how an IPTV network would look like. The subsequent sections will describe their individual working as well as contribution to the whole solution. This IPTV solution is commercially available in Pakistan since one year. The end product can be found by the name of Smart TV on the company website [PTCL, 2009]. The total solution is composed of various existing and new segments. Some are new and others are incumbent but optimized or upgraded to cater for the new service. The figure shows a layered architecture. At the top lies the management layer containing Operational Subsystem (OSS) and Business Support System (BSS) which is an interface for subscriber and other management platforms. Middleware and content distribution network is the segment where TV signals received through the headend are processed to the desired format and several servers are maintained to support various solution service such VoD, Electronic Program Guide or STB upgrade. IP bearer network along with access and aggregation network supports transportation of the service from centralized Middleware and Content Management platforms to far off places throughout the country. ADSL, the technology that realizes the transportation of high speed data to the customer in the last mile is an important part of Access and Aggregation layer. In the lowest layer, lies the Home network that consists of the modem, Set Top Box installed at the customers premises. Various network segments converge to provide service to this terminal part. 3. Head End

This is where the contents are received and processed for injection into subsequent network segments. Main components of Headend are Satellite Dishes, Receivers, Encoders and LAN Switches. The channels received

through Satellite dishes are digitized and encoded with MPEG-4 before being assigned a multicast IGMP group. A customer who switches to view one of these channels actually becomes a part on one of its IGMP groups. There are only two Headend that complement each other by feeding IP network channels from different satellite foot prints besides working as DR site for each other in case of overlapping foot prints. The Headend is also connected to the Middleware which is the facility where subscriber management takes place. Figure 2 shows the interconnection of various Headend components and their role in the network. An important design consideration that effects dimensioning of entire subsequent network is the bandwidth occupied by each channel. Network elements such as the optical interface type/numbers are dependent on this factor. In this case bandwidth per channel was reserved at 2.5Mbps. This means that for 100 channels, 250Mbps is required throughout the network beyond Headend. Processing capacity, bandwidth and interfaces on switches, routers, ADMs are dimensioned according to this. The treatment of the channels in the Headend depends on them being censored and/or time shifted or not. Uncensored/ non-time shifted channels are directly sent to the Access network while censorable channels are sent through censoring equipment in the Headend and time shifted ones are recorded in designated hard disks on temporary basis. Customers who wish can rewind a live channel up to 60 minutes. 4. Middle Ware and Content Delivery Platform

Figure 3 shows interconnection of IPTV Middle ware and content delivery network. Functions of these networks are as following: 1. 2. 3. 4. 5. Conditional Access to IPTV broadcast and Video on Demand contents. Hosting Central Electronic Program Guide (EPG) servers. Hosting Central Video on Demand Content Library. Hosting Electronic program guide upgrade server that automatically upgrades Customer Premises equipments with software upgrade and services. Interfaces with Operational Subsystems and Network Management Platforms for Subscriber and network management respectively.

Some of Middleware and Content Management Platform elements such as Conditional Access Servers run on clusters of mission critical servers. 6. IP Bearer Network

It is the advancement in this part of the network that realizes IPTV. As evident from Figure 4, OSPF, PIM-SM and BGP are key protocols. OSPF is used for usual application of advertising IP pools and routing information among various areas defined to organize traffic. While PIM-SM is used to extend Multicast channels right from the Head-end to Anycast-RPs on the IP network Edges before being fed into the Access and aggregation network. BGP is used to advertize AS pools to other AS domains. 7. Access and Aggregation Network

This is another important segment of total IPTV solution. Please refer to Figure 5. BRAS (Broadband Remote Access Server) stand on its border and interfaces with the IP bearer network. It is the convergence point for a number of DSLAM (Digital Subscriber Line Access Module). BRAS and DSLAMs are connected through a SDH based fiber optic transmission network. DSLAM is the first convergence point in the network where subscribers of a specific area terminate. A DSLAM and its customers are connected through the copper plant. Capability of a DSLAM to support a certain bandwidth on the copper plant is determined by the standard on which it is built. The network under study had DSLAMs supporting ADSL2+ standard which had higher copper reach length and bandwidth. A DSLAM should support IGMP proxy function to pull Multicast traffic from upstream network elements. The SDH transmission network should be able to support Multicast traffic in order to reserve resource. The nature of multicast traffic as compared to Uni-cast is conservation of bandwidth as the traffic goes in only one direction and one-to-many distribution is achieved through replication and forwarding in the intermediate nodes rather than having a separate stream between source and destinations. Besides DSLAMs,

PTCL also used Optical Network Units (ONUs) in the aggregation network. ONUs are deployed further into customer neighborhoods according to fiber to the neighborhood (FTTN) concept as compared to DSALMs that are installed inside the Local Exchanges. IGMP snooping was activated in the last ADM before an ONU ring to compensate for the lack of bandwidth in transmission network of FTTN rings. Terminal Presentation Functions: This consists of devices that comprise Customer Premises Equipment. The copper line coming from the DSLAM installed in the local exchange is terminated into ADSL modem which feed an Ethernet interface to the Set Top Box or STB. STB contains a smart card for authorization and obtaining services from the middleware components. STB further feeds the TV or other viewing device in use of the customer. 8. Functional Description

In this section an overview of how this network works to deliver IPTV service to its subscribers, is given: The Figure 6 shows the flow of various services through the network segments described separately in the above text. The IPTV services being offered can be classified as BTV (Broadcast TV channels), TSTV (Time Shift TV) and VOD. Different layers are mentioned in the figure to accommodate for scaling. Initially all traffics can be handled by central media center and central headend. But as the network grows, regional media centers are established to achieve scaling. This can be seen from the sequence of Figures 6 A, B, C. BTV or Multicast traffic channels identified by its IGMP group can be streamed directly from the Headend to DSLAM which has IGMP proxy support enabled. Similarly Unicast VoD streams can be fed to interested customers from Central Media Center or Middleware and Content Delivery platform without engaging any intermediate content management. However, for large networks spanning over large geographical areas like the whole country, intermediate content management servers have to be established to achieve scaling. In this scenario, regional IPTV nodes were established in each provincial capital. These were used to provide Electronic Program Guide, VoD and TSTV services to the customers of its jurisdiction. This arrangement eased burden on the central servers and conserved bandwidth on national IP backbone. 9. Service Flow (Broadcast Channels /BTV)

In this section two major processes relating to Broadcast Channels are described. These are publishing a Multicast channel, Subscribing to programs and accessing a program. 9.1 Publishing a Multicast Channel: Please refer to figure 7 and Acronyms to understand subsequent text. 1. A metadata of a channel is created which contains the IP multicast address and port number of program stream in CIS. 2. CIS creates instruction for creating BTV channel in the MDN. 3. MDN records instruction and creates a BTV channel. 4. MDN further instructs adding the channel to specified MS. 5. CIS obtains URL for the channel from MDN 6. CIS advise scrambling of the channel through CAS 7. CAS obliges and receives stream from the live source, scrambles it and sends it to IPTV delivery network i.e. IP multicast network 8. A program is added to the list of channels in CIS 9. The channel is bound with proper name and subject in the CIS. This binding information is available to subscriber in the EPG to select the channel if he wished to view. 10. The channel is activated in the CIS.

9.2. Accessing a channel Please refer to figure 8 and Acronyms to understand subsequent text. 1. 2. 3. 4. 5. 6. 7. 8. The subscriber selects a channel in the EPG to view and STB send request to EPG server to play it. EPG server checks the authorization status of the requesting party. Upon authorization, EPG server provides the STB with URL of the requested channel. STB requests RRS to provide the channel according to this URL. The RRS redirects the request to a MS. MS provides the channel multicast IP address and port number to STB. STB sends an IGMP join request to the DSLAM. The DSLAM delivers the requested program stream to STB.

10 Issues and concerns In this section some issues observed during deployment and optimization is being presented. 10.1 - VoD Unicast bandwidth issue: As per bandwidth allocation plan a small amount of Unicast bandwidth was allocated in SDH transmission network for the VoD customers of each DSLAM. By Unicast it means that for each VoD content being watched there is a 2.5 Mbps stream from VoD servers up to the customer. This quantity of bandwidth has to be maintained by the IP network as well as underlying transmission network. For transmission network a Unicast bandwidth of 1xVC4 (45Mbps) was reserved for each DSLAM to be shared by all VoD subscribers. One important design consideration for transmission network was overlooked. Consider for example that if the concurrent VoD users of a specific DSLAM reaches 18 and a 19th user also opts for VoD. In this case there is no way for the management layer to detect saturation in transmission layer. Instead it will allow the 19th one to access the service. Once this is done, the behavior of the network becomes unpredictable and this can deprive other working VoD customers off their streams and that too without any notification to the billing servers! 10.2 - IGMP Proxy Issue: As per multicast design, the DSLAMs present in the network have to support IGMP proxy. This means that all multicast channels are required to be transported to this point in the network and any IGMP join request (to view a certain channel) is entertained from the DSLAM without going further upstream. This design consideration became problematic in multivendor environment as not all DSLAMs support IGMP proxy. For example unlike Huawei, Alcatel did not support this feature as a result Multicast was not being pulled into the transmission network of DSLAMs. This problem was tackled in two ways. 1. Adding at-least one Huawei DSLAM into Alcatel DSLAM cluster. This way the Multicast traffic pulled by one Huawei DSLAM was available to all Alcatel DSLAM present in the cluster. 2. Creating a unicast resource from Alcatel DSLAM up to the nearest IGMP proxy server that may be BRAS or a Huawei DSLAM present out of this cluster. 10.3 - IGMP Snooping and ONU Transmission Bandwidth: As mentioned earlier, besides DSLAM, ONUs were also used in the network to deliver IPTV services. However, the transmission network of ONU was deployed before IPTV conception and has limited resource as it could not cater for all 100 channels (250 Mbps of Multicast resource). Since IPTV capable ADSL ports were available in ONUs, a solution was required to utilize them and extend geographical reach-ability of companys IPTV offerings. The solution to this problem was found by activating IGMP snooping in the ADM feeding ONU transmission rings. This feature detects and extends a multicast stream only if the is a customer subscribing to it. Since the ONU transmission ring could spare only 100 Mbps for multicast, therefore by using this solution a total of 40 Multicast IPTV customers could enjoy the service even by switching 40 different channels. However, the 41st customer trying to view the 41st channel would disturb the entire stream. Therefore in a management decision, only 40 customers were allowed per ONU to access IPTV service. This wasted around 50 IPTV ports per ONU but enabled the company to establish its presence meanwhile upgrading its transmission network to accommodate all installed ports.
1.4. - Channel zapping time Zap time is the time it takes for the channel to change from the moment the subscriber presses the button on the remote till the video leaves the display [6]. Total Zap time in IPTV (~1.9-4.8s) is

comparatively more than other competing technologies such as Cable TV (~1s), Off-Air (~1-3s), MPEG2 over QAM (1.2-3s), MPEG2 over QPSK (2-4s), MPEG2 over IP Multicast (1.5-3s) and deployment under study H.264 over IP Multicast (1.7-4s). The delay is accumulated in functions distributed over various segments of the total solution such as Access Network (IGMP transaction in DSLAM and STB, FEC/Interleave) and Core Network (Multicast mechanism and channel replication location). Even more delay is caused during stream acquisition is events concerning PSI, Conditional Access to decrypted channel and getting MPEG key frame. Improving zap time requires focus on various areas of total picture besides intelligent network design. For further exploration of the issue please refer to [7], [8] and [9]. 11. Standard Organizations: As the network under consideration was being optimized after deployment, various standard organizations were finalizing first set of their respective standard documents. In coming years these will be put to test in the industry and might generate some interesting case studies. A brief overview of bodies more relevant to IPTV is given below. 11.1 ETSI/TISPAN: It is a European standard body that mainly focuses on fixed NGN solutions. It first dealt with IPTV as part of NGN Release 2 [10]. Various versions under Release2 define requirements on part of the network layer to support IPTV and service layer to integrate NGN and IPTV. IPTV architecture as well as its support in IMS was also discussed under the same Release. Some standard components of release 2 such as Service Layer and Architecture were further evolved in the recently announced Release 8. 11.2 Open IPTV Forum: It is an industrial forum comprising of Telcos, leading vendors and entertainment and content industry representatives with aim to define an open, end to end specification for IPTV based upon existing technologies and open standards that could help to streamline and accelerate deployments of IPTV technologies and help to maximize the benefits of IPTV for consumers, network operators, content providers, service providers, consumer electronics manufacturers and home and network infrastructure providers. So far two releases have been issued, the latest one defining a functional architecture of IPTV network. Comparatively speaking, Open IPTV Forum is more complex as many functions in TSPAN have been broken down. 11.3 ITU-T: ITU-T is another Standard body that works under umbrella of UN. It has been a major proponent of telecom standards in the pre-internet era although left behind by more dynamic IETF that has been the key in designing the internet as it stands today. Its approach towards IPTV is somewhat similar to ETSI/TISPAN in terms of NGN and IMS. A Focus group FG IPTV is dedicated for the task. 12. Conclusion In the absence of a tested standard based total IPTV delivery solution, telecom operators have to rely on the designing expertise of vendor and integrators who tailor solutions using existing technologies and considering customer environments. Such a customer specific design approach usually lacks rigorous critical analysis that a standard technology faces and this leads to overlooking some aspects that surface very late. A compilation of such observations is presented in the section 11. The success of such deployments will vary from one another depending on the expertise of the chosen integrator or vendor and the presence of vigilant professionals in the operators ranks who would engage in discussions concerning the minutest of design details. Such deployments even if successful might have a shorter life in consideration of prevailing trends in Multimedia service standards (IMS) and consumer behaviors (YouTube, Skype etc). Two scenarios compete for the future of telecom industry. The future telecom operators might become total Multimedia Service Providers based on mature standards such as IMS or FMC or they may become bandwidth providing companies with Multimedia service intelligence shifted to the third party applications and their customers. Such Services might be an amalgamation or convergence of presently available communication and web streaming applications such as Skype, Google Talk, You-tube and Google Video etc. A telecom operator considering adding IPTV to its service offering should take these factors into account while chalking out a long term business strategy.

Ahoo.com 13. References [1] Page 7, Brochure, STS international conference 2010. [2] www.ptcl.com.pk [3] Wes Simpson, Howard Greenfield, 2007, IPTV and Internet Video: New Markets in Television Broadcasting, Focal Press, USA. [4] Chris Hell-berg, Dylan Greene, Truman Boyes, Broadband Network Architectures, Designing and Deploying Triple Play Services.. Prentice Hall 2007. [5] IPTV Guide, Delivering Audio and Video over Broadband, William Cooper, Graham Lovelace. Informitv 2006 [6] FG IPTV-C-0505, ITI-T Focus Group for IPTV, 2007 ITI-T Focus Group for IPTV, 2007 [8] IPTV CHALLENGES AND METRICS, EXFO Electro-Optical Engineering Inc. 2008 [9] IPTV TESTING OVER DSL, EXFO Electro-Optical Engineering Inc. 2008 [10] NGN Releases 2, ETSI, 2008 [11] Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Requirements for network transport capabilities to support IPTV services, Doc. Nb. TS 181 014 Ver. 2.0.0 Ref. DTS/TISPAN-01042-NGN-R2, ITU-T, 2008 [12] Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Service Layer Requirements to integrate NGN services and IPTV Doc. Nb. TS 181 016 Ver. 2.0.0 Ref. DTS/TISPAN-01044-NGN-R2,ITU-T, 2008 [13] Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Service Layer Requirements to integrate NGN Services and IPTV Doc. Nb. TS 181 016 Ver. 3.3.1 Ref. RTS/TISPAN-01059-NGN-R3,ITU-T, 2009 [14] Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); IPTV Architecture; IPTV functions supported by the IMS subsystem Doc. Nb. TS 182 027 Ver. 2.0.0 Ref. DTS/TISPAN-02048-NGN-R2,ITU-T, 2008 [15] Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); IPTV Architecture; Dedicated subsystem for IPTV functions Doc. Nb. TS 182 028 Ver. 2.0.0 Ref. DTS/TISPAN-02049-NGN-R2, ,ITU-T, 2008 [16] Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); NGN integrated IPTV subsystem Architecture Doc. Nb. TS 182 028 Ver. 3.3.1 Ref. RTS/TISPAN-02074-NGNR3, ,ITU-T, 2009
F G I P T V C  ,

You might also like