International Journal of Computers, Communications & Control Vol. I (2006), No. 3, pp. 61-69 Bringing IPTV to the Market through Differentiated Service Provisioning Cathryn Peoples, Petre Dini, Sally McClean, Gerard Parr, Michaela Black Abstract: The world of telecommunications continues to provide radical technologies. Offering the benefits of a superior television experience at reduced long-term costs, IPTV is the newest offering. Deployments, however, are slow to be rolled out; the hardware and software support necessary is not uniformly available. This paper examines the challenges in providing IPTV services and the limitations in developments to overcome these challenges. Subsequently, a proposal is made which attempts to help solve the challenge of fulfilling real-time multimedia transmissions through provisioning for differentiated services. Initial implementations in Opnet are documented, and the paper concludes with an outline of future work. Keywords: Transport layer, real-time communication, QoS, multimedia protocols, reconfigurable stacks, Opnet simulation. 1 Introduction It is anticipated that IPTV will be enthusiastically accepted [1] [2; cited by 4] by early adopters, those with a passion for technology. However, while the desire for rich multimedia-based information grows, it is necessary to remove any service impairments to maximise the possibilities of widespread attraction. IPTV, with its high bandwidth and strict Quality of Service (QoS) requirements, will currently not operate to a satisfactory quality in many networks throughout the world. Investments and improvements are therefore required. The potential for IPTV to become a killer application will depend on such developments. Without an efficient and reliable service, demand for it cannot grow. As with previous Internet applications with widespread demand, it is anticipated that IPTV will have a similar appeal. The race is now on to make the necessary hardware and software upgrades to ensure an end-user experience of quality. 2 IPTV A report by Accenture [3] revealed that there is a lack of consumer awareness on the definition of IPTV. For those who claim to understand, some exhibited widely varying interpretations. In the context of this paper, it is our (the authors’) understanding that IPTV describes the transmission of traditional television over an IP network. In addition, IPTV seeks to further build upon the user experience. The intention is to enable a customised and interactive service [4] [5]. It will be possible to search for on- demand viewing, obtain access to exclusive content, and succumb to product recommendation. To attract initial customers, it is not thought imperative to provide a service which is fully reliable or which exceeds the current viewing experience. In the early stages, IPTV is likely to be used as a supplement to the traditional television service, adopted by those with a passion for new technologies. However, to ensure longevity, it is necessary to provide a service which exceeds the current experience. This demands a service which is uninterrupted, reliable, and ideally offers cost advantages. In addition, availability through minimal operational efforts is advantageous in terms of encouraging widespread appeal. Copyright c© 2006 by CCC Publications 62 Cathryn Peoples, Petre Dini, Sally McClean, Gerard Parr, Michaela Black 2.1 Challenges of Transmitting IPTV There are numerous challenges to providing IPTV. Voice and video are applications with stringent QoS requirements, demanding an end-to-end delay of less than 100 milliseconds and a bit error rate (BER) of less than 10−6. In addition, they require minimal variation on the amount of end-to-end delay; jitter has a negative effect on the ability to stream the service smoothly. Indeed, the accumulation of a sufficient amount can render the communication useless [6]. Ensuring high levels of QoS is difficult, especially given the increasing popularity of the Internet and resulting pressure on restricted resources. In addition, increased roll-out of wireless links creates connections with notoriously error-prone links. Rejaie et al (1999) [7] have the opinion that, "the quality of delivered service to real-time operations is neither controllable nor predictable." While this fact may have been true in 1999, developments are ongoing to remove the occurrence of such limited network performance. The ability to achieve certainty in the reliability and quality of transmissions is required. Customers purchase Internet packages according to different levels of QoS, which guarantee that they will receive a certain level of performance. Therefore, the ability to ensure the quality of a real-time service is required. 3 Multimedia Protocols Numerous multimedia protocols have been designed in recent years to meet the challenges involved in achieving real-time communication. In addition to considering those developed specifically for mul- timedia transmissions, protocols with rate-based control mechanisms are also applicable to multimedia transmissions. Flow control is an important attribute where applications require a steady rate of through- put and where reliability is required. Window-based flow control, as in the case of TCP [8], is inap- propriate for multimedia applications. Variable file sizes result in transportation through the network at different rates. Setting a retransmission time-out which does not match the time-out appropriate to the media can increase jitter, and hence QoS. In addition, rate-based transport protocols are considered to be more reliable than window-based approaches. The design of the window-based approach is highly constrained in terms of window-size and retransmission time-out, and any changes in the external envi- ronment will cause the protocol to fail. Rate-based approaches, in contrast, adapt based on real-time, and not pre-defined, information. The Broadband Application Transport System (BATS) [9] was proposed in 1994 as a rate-based transport protocol. Supporting four classes of service, provisions are made for a variety of applica- tion requirements. While ensuring throughput of Class A applications (those which are time-sensitive, connection-oriented, and which require a constant bit rate) by blocking all subsequent communications, there is a limitation of this approach in terms of coping ability when there is more than one Class A trans- mission. As all connections are blocked when a Class A application is transmitting to ensure sufficient bandwidth, the implication is that a second Class A transmission must wait until the first has completed. This approach, therefore, has significant limitations. RT-Ring [10] was developed in 2002 to transmit multimedia in real-time. It offers three qualities of service and a fairness control mechanism which provisions for traffic with both real-time and non real-time requirements. However, a limitation also exists with this approach. The principle behind this protocol is that a non-satisfied station (one which has not achieved its real-time transmission) can maintain priority until it is satisfied. What happens, however, if there are multiple stations with the same priority? In large-scale deployments, this approach is likely to be unsuitable. The Rate Adaptation Protocol (RAP) [7] was created to provide QoS for multimedia applications by adapting the quality of a flow of data. Quality is adapted by using layered encoding, and simultaneously delivering a number of layers which can fit inside the available bandwidth. However, despite the benefits of bandwidth-provisioning, doubts exist regarding the direct provisions made for the transmission of Bringing IPTV to the Market through Differentiated Service Provisioning 63 real-time traffic. Each packet is acknowledged and losses are detected by missing ACKs. Lost data is not retransmitted, but the information is used to update the rate at which traffic flows. In addition, RAP incorporates a feature of adapting the rate of flow depending on the feedback delay. Adjusting the rate of flow does not seem like a suitable response to take for video applications, where such actions will result in varying amounts of network jitter. The Rate Control Scheme (RCS) is designed for environments with high error rates and high bandwidth- delay products. It uses dummy packets to perform congestion control and an AMID algorithm to adjust its transmission rate. A flaw exists in this protocol in relation to its approach to flow and congestion con- trol. Due to the protocol’s inability to perform retransmissions, if congestion occurs between a dummy packet being received at the source and the actual transmission being sent, the data will be lost without the ability to be recovered. In addition, it appears as though this protocol could cause the application to experience variable jitter. If a dummy packet is not received, the transmission will cease at least until the period when the next dummy segment is to be sent. Providing sufficient bandwidth exists, the transmis- sion will continue. However, a gap in the transmission will have been introduced, and bringing with it jitter. A QoS-Guaranteed Transport System (QTS) [11] provides differentiated QoS based on the needs of the application. A bandwidth allocator determines the rate at which data is transported through the network, and the transport protocol module performs rate-based congestion control at a rate which has been determined by the bandwidth allocator. As with BATS, the limitation is that there is no mechanism to cope with multiple applications having the same QoS requirements. It therefore seems difficult to ensure that applications will receive the required QoS. The main criticism of the current protocols which have been developed for multimedia applications is that they do not take network resource information into account when making protocol choices. While the QoS requirements of the application are important, there are benefits in also incorporating network information. In this way, the available resources can be maximised for all applications and not only those with Class A (in BATS [9] language) requirements. 3.1 Reliable Transportation from the Application or Transport Layer? It is appropriate at this stage to discuss the location of transportation reliability within the protocol stack. Provisions for transmission reliability are increasingly being incorporated within the application layer. The Real-Time Protocol (RTP) [12] is one such example, used in the application layer of the OSI (Open Systems Interconnection) [13] protocol stack for the transmission of applications with real-time requirements. CFDP [14], the CCSDS [15] File Delivery Protocol developed by the Delay Tolerant Net- work Research Group (DTNRG) [16], is another example, deployed within the CCSDS protocol stack [17]. Flow and error control functions are combined within the application layer in an attempt to com- press the layered approach to solving the communication problem as introduced by the ISO (International Standards Organisation) [18]. However, it is the opinion of the authors that it makes greater sense to re- tain the traditional layered approach to solving the communication problem, and have each layer solve an individually complex problem. This explains why the protocols under investigation are located within the transport, and not the application, layer. 4 Reconfigurable Protocol Stacks The concept of reconfigurable protocol stacks has long been under investigation [19] [20] [21], and it is believed that there are significant performance improvements to be achieved in the real-time mul- timedia transmission challenge through development of this technique. There are obvious benefits to operating a reconfigurable protocol stack in 21st Century networks due to increasing pressures on re- sources and the need to provide quality of service. A dynamic network architecture allows exactly 64 Cathryn Peoples, Petre Dini, Sally McClean, Gerard Parr, Michaela Black the right combination of protocols to be chosen for each application. However, reconfigurable protocol stacks remain to be deployed in networks today. An obvious concern which arises from the consideration of reconfigurable protocol stacks is the risk of increasing processing time when choosing the optimum stack configuration. There is also the risk that, in incorporating multiple choices into the stack, memory increases, and hence hardware costs, will be required. There are several approaches to incorporating reconfigurability into the protocol stack. One approach is to empower the message with the intelligence to decide the path through the stack and the functions necessary in relation to the requirements of the packet [22] [23]. Another approach is to group the functions specific to an application at all layers [24] [25]. While there may be multiple functions within each layer, only one from each will be relevant to an application and the grouping will be determined in advance. The final approach investigated is to build a middleware layer into the stack, which makes provisions for allowing adaptability [26] [27]. The approaches presented are diverse and thorough, and yet many more exist in addition to those examined here [28] [29] [30]. However, each has certain features with specific application for various environments and applications. As with the multimedia protocols, the main criticism is that the majority of the proposed reconfigurable protocol stacks do not take environmental information into account when making protocol choices, but rely on the needs of the application. As transmissions depend heavily on the environmental constraints in the network, it is important that explicit network information is used in the decision-making process. 5 Research Proposal Current transport layer protocols are incapable of achieving the stringent QoS requirements of real- time multimedia applications. They neither possess the capabilities to characterise applications nor adapt performance to maximise the possibility that QoS is achieved. Such functionalities, however, are thought paramount to the achievement of application QoS in tomorrow’s networks. The research proposal incorporates application and environmental information at the top of the stack to influence decisions made in the lower layers. In addition, the functionalities which are available in each layer will be increased. Currently, within the transport layer, either TCP [8] or the User Datagram Protocol (UDP) [31] will be available according to the nature of the application. Each protocol has well- defined and contrasting approaches to communication. However, network conditions can be extremely variable and dynamic. Therefore, my proposal incorporates a greater amount of variability into the transport layer, different protocols being more appropriate to use in different circumstances. The protocol stack will be evaluated on a hop-by-hop basis. Variability of protocol functions will be introduced in terms of connection orientation of the communication, flow control and the rate of flow control, error control, and the retransmission strategy. The proposed protocol stack is shown in Figure 1. Environmental information is passed to the protocol stack via a connecting network diagnostic and management system. The diagnostic system will not be discussed in depth in this paper; this represents future work and may be documented at a later date. Several attributes are passed between the protocol stack and the diagnostic system. This is in keeping with Bashir et al’s (2005) [32] opinion that network performance is typically measured using metrics for throughput, connectivity, end-to-end and round-trip packet delay, and packet loss. Several of these parameters have been selected to combine environmental and application infor- mation. The subsequent result will be used to select the transport protocol. The formula is shown in Equation 1. Result = √√√√ √ BER( √ U D2e2 ∗(Db + Dt ) ) ∗ToS (1) Bringing IPTV to the Market through Differentiated Service Provisioning 65 CONTEXT-AWARE PROTOCOL STACK NETWORK AGENT & FAULT DIAGNOSIS SYSTEM Real-Time Contextual Information Sending and receiving timestamp Source address Destination address IP Traffic Dropped (packets/sec) IP Background Traffic Delay (sec) Jitter (sec) Data Drop Rate (Buffer O’flow) (bps) Data Drop Rate (Retry Threshold Exceeded) (bps) Load (bps) Packet Delay (sec) Packet Delay Variation (sec) TCP Delay (sec) TCP Segment Delay (sec) TCP Retransmission Count Application C1 C2 C3 Network C1 C2 C3 Data Link C1 C2 C3 Bundling Context-Aware Middleware Application Classification BW MC RT P TCP RCS Transport Parsing & Normalisation Real-Time Analysis Fault Identification Fault Diagnosis Action B1 B2 … Bx Physical C1 C2 C3 QTS RTP RAP UDP Multi-Hop Backbone Data Collectors Figure 1: Proposed Protocol Stack and Network Management Function Combination o f Application and Environmental In f ormation Where: U Link Utilisation De2e End-to-End Delay Db Data Drop (Buffer Overflow) Dt Data Drop (Retry Threshold Exceeded) BER Bit Error Rate ToS Type of Service The Type of Service (ToS) attributes refers to the QoS required by an application. The scale being used is 0 - Best Effort Application, 3 - Excellent Effort, and 6 - Interactive Voice. The QoS therefore increases in parallel with the ToS value. As an example of how this protocol stack will be used, it is the intention that where the link is under-performing (i.e. low link utilisation, high end-to-end delay, high number of data drops, and high BERs), the transport protocol deployed is one with a reduced amount of overhead. The rationale behind this approach is that, where the network is operating in a manner which is sub-optimal, a protocol with less control overhead should be used to maximise the opportunity that some of the data transmitted will be received (taking into account that IPTV is an application which can cope with some data loss). If a protocol with more stringent error-control requirements was used in such an environment, there is a greater opportunity that the data will not be received due to an inability to cope with data loss. It should also be noted that, while it is shown in the stack that the complete protocols are deployed at each hop when the conditions are evaluated, it is the intention that the separate functionalities of each protocol can be called. For example, it may be decided that the four classes of service from BATS should 66 Cathryn Peoples, Petre Dini, Sally McClean, Gerard Parr, Michaela Black be deployed alongside the QTS error-control scheme (error-control only for loss-sensitive applications). It is the intention to call the current multimedia protocol functions to maximise their potential and the success of the transmission, given the application requirements and the environmental constraints. The calling of individual error, flow, and retransmission strategies will depend on individual formulaic con- ditions designed. 6 Implementation Implementation of the research proposal has partially occurred. The functionality being documented in this paper is the integration of adaptability in terms of the connection-orientation of the commu- nication. Within Opnet [33], this has involved integrating environmental information, which has not previously been provisioned for. The environmental information and the evaluation criteria discussed in Section 5 have been inserted into the application layer. Defined within the Function Block, the changes are subsequently called from the process model states when spawning the application profiles. Dependencies between the layers have also been provisioned for. This has involved integrating the changes made in the application layer within the subsequent modules called. Opnet uses a global data structure from which it determines the transport protocol being used for any application. It is referred to several times in the initiation of a communication for the purpose of populating data structures with the transport protocol. One of the functions of this implementation was therefore to remove all reliances on the global transport protocol service, and to ensure that all references were instead made to the intelli- gently calculated protocol. Changes were required in the tpal layer and the process models generated by the spawning of the application process, the video_calling_manager and gna_profile_mgr models. After the tpal layer, the transport protocol module and the lower layers of the stack are called. As the changes are being made to the choice of transport protocol, all changes must therefore be made before this layer. Figure 2 shows the dependencies between the process modules, and the span of changes required to achieve implementation at the client. The changes implemented in a top-down fashion between the application and tpal layers have ensured developments at the client. Developments must now be made in a bottom-up approach between the same layers to allow incorporation of the same changes at the server. 7 Conclusions and Future Work The research proposal has been thoroughly investigated and it is believed that the proposed scheme can have a realistic existence in future networks. Reconfigurable protocol stacks have been widely in- vestigated in the literature, but remain to be deployed. Given the dynamism of network conditions, it seems sensible to incorporate flexibility into the protocol stack. Conditions in the external environment are pivotal in enabling the transport protocol’s operation, and hence the fulfilment of the application’s requirements. Therefore, its incorporation into the decision-making process is thought fundamental to providing future service differentiation. It is the challenge to design one which is technically and com- mercially feasible. This research has been conducted during a four-month Internship with Cisco Systems in Silicon Valley. The protocol stack developments discussed in this paper are also simultaneously being developed for a PhD research project. This Internship has allowed research to occur specifically on the transmission of multimedia, although the applicability of all application types to this proposal will be considered for the final project. This period has seen the initiation of the task of delving into Opnet’s code to modify how functions are performed at present. Future work will involve incorporating the other techniques with an adaptable status. These include flow control, error control, and the retransmission strategy. Bringing IPTV to the Market through Differentiated Service Provisioning 67 destroy_profile spawn_profile svc_compl arrival client_closed rtrv_complete close open remote_ profile wait start init gna_clsvr_mgr ace gna_profile_mgr init idle spawn end close gna_video_calling_mgr open connect end idle receive send_ close send tpal_v3 pre_init init wait req reg error_ trap open gna_profile_spawn app_pk_to_tpal_send Figure 2: Data Flows from Application to Tpal Layers References [1] Multimedia Research Group, "IP TV Global Forecast - 2006 - 2009: Semiannual IP TV Global Forecast", March 2006. [2] Gartner Group, "IPTV Prediction", Gartner Group Research Report, Winter 2005. [3] Zadeh, A; Douglass, G, K; Dogra, R; "Communications and High Tech: "Infinite Possibilities" Television?", Accenture, May 2006. Available at: http://www.accenture.com/Global/Research_and_Insights/Outlook/By_Issue/Y2006/ InfiniteTelevi- sion.htm [4] Shin, D, H; "Potential User Factors Driving Adoption of IPTV. What are Customers Expecting from IPTV?", Technological Forecasting and Social Change, 2006. [5] Harris, A; "White Paper of Enabling IPTV: What Carriers Need to Know to Succeed", May 2005, IDC. Available at: http://www.emc.com/analyst/pdf/IDC_IPTV_WhitePaper_Jun_9_05.pdf 68 Cathryn Peoples, Petre Dini, Sally McClean, Gerard Parr, Michaela Black [6] Chan, S-P; Kok, C-W; Wong, A, K; "Multimedia Streaming Gateway with Jitter Detection", IEEE Transactions on Multimedia, Volume 7, Number 3, June 2005, Pages 585 - 592. [7] Rejaie, R; Handley, M; Estrin, D; "RAP: An End-to-End Rate-Based Congestion Control Mechanism for RealTime Streams in the Internet", Proceedings of the Eighteenth Annual Joint Conference of the IEEE Computer and Communications Societies, Volume 3, 21 - 25 March 1999, Pages 1337 - 1345. [8] Postel, J; "Transmission Control Protocol", Request for Comments 793, September 1981. [9] Yuang, M, C; Liu, J, C; Shay, C, L; "BATS: A High-Performance Transport System for Broadband Applications", IEEE Proceedings of the 19th Conference on Local Computer Networks, 2 - 5 October 1994, Pages 448 - 455. [10] Conti, M; Donatiello, L; Furini, M; "Design and Analysis of RT-Ring: A Protocol for Support- ing Real-Time Communications", IEEE Transactions on Industrial Electronics, Volume 49, Issue 6, December 2002, Pages 1214 - 1226. [11] Yuang, M, C; Liu, J, C; "QTS: A QoS-Guaranteed Transport System for Broadband Multimedia Communications", IEEE Transactions on Industrial Electronics, Volume 45, Number 1, February 1998, Pages 69 - 77. [12] Schulzrinne, H; Casner, S; Frederick, R; Jacobson, V; "RTP: A Transport Protocol for Real-Time Applications", Network Working Group, Request for Comments 3550, July 2003. [13] International Organisation for Standardisation, "Open Systems Interconnection - Ba- sic Reference Model: The Basic Model", ISO/IEC 7498-1: 1994, Available at: http://isotec.iso.org/livelink/livelink/fetch/2000/2489/ lttf_Home/PubliclyAvailableStandards.htm [14] Consultative Committee for Space Data Systems, "CCSDS File Delivery Protocol (CFDP): Rec- ommendation for Space Data System Standards", Blue Book, October 2002. [15] Consultative Committee for Space Data Systems, Available at: www.ccsds.org [16] Delay Tolerant Network Research Group. Available at: www.dtnrg.org [17] Consultative Committee for Space Data Systems; "Overview of Space Link Protocols", CCSDS 130.0-G-1, Green Book, June 2001. [18] International Standards Organisation, Available at: www.iso.org [19] Curran, K; Parr, G; "The Use of Dynamically Reconfigurable Protocol Stacks for Streaming Mul- timedia to Mobile Devices", Proceedings of the 8th International Conference on Communication Systems, 25 - 28 November 2002, Volume 2, Pages 947 - 951. [20] Johnny, T, F; "Adaptive Protocol Suite for Next Generation Wireless Internet", Proceedings of the IEEE 2005 International Conference on Personal Wireless Communications, 23 - 25 January 2005, Pages 509 - 513. [21] Akyildiz, I; Altunbasak, Y; Fekri, F; Sivakumar, R; "AdaptNet: An Adaptive Protocol Suite for the Next-Generation Wireless Internet", IEEE Communications Magazine, March 2004, Pages 128 - 136. [22] O’Malley, S, W; Paterson, L, L; "A Dynamic Network Architecture", ACM Transactions on Com- puter Systems, Volume 10, Number 2, May 1992, Pages 110 - 143. Bringing IPTV to the Market through Differentiated Service Provisioning 69 [23] Schöler, T; Müller-Schloer, C; "Design, Implementation and Validation of a Generic and Reconfig- urable Protocol Stack Framework for Mobile Terminals", Proceedings of the IEEE 24th International Conference on Distributed Computing Systems Workshops, 2004. [24] Haas, Z; "A Protocol Structure for High-Speed Communication over Broadband ISDN", IEEE Net- work Magazine, January 1991, Pages 64 - 70. [25] Zitterbart, M; Stiller, B; Tantawy, A, N; "A Model for Flexible High-Performance Communication Subsystems", IEEE Journal on Selected Areas in Communications, Volume 11, Number 4, May 1993, Pages 507 - 518. [26] Curran, K; Parr, G; "The Use of Dynamically Reconfigurable Protocol Stacks for Streaming Mul- timedia to Mobile Devices", Proceedings of the 8th International Conference on Communication Systems, 25 - 28 November 2002, Volume 2, Pages 947 - 951. [27] Zhang, C, H; Chin, T, K; Koh, K, Y; Ong, G, M; Suthon, S; Peng, C, H; Pung, H, K; "Octo- pus: An Adaptive Group Communication Environment for Multimedia Application", The IEEE 10th International Conference on Networks, 27 - 30 August 2002, Pages 145 - 150. [28] Akyildiz, I; Altunbasak, Y; Fekri, F; Sivakumar, R; "AdaptNet: An Adaptive Protocol Suite for the Next-Generation Wireless Internet", IEEE Communications Magazine, March 2004, Pages 128 - 136. [29] An, L; Pung, H, K; Zhou, L; "Design and Implementation of a Dynamic Protocol Framework", Computer Communications 29, 2006, Pages 1309 - 1315. [30] Guan, S-U; Lim, S-S, "Modeling Adaptable Multimedia and Self-Modifying Protocol Exceution", Future Generation Computer Systems 20, 2004, Pages 123 - 143. [31] Postel, J, "User Datagram Protocol", Request for Comments 768, August 1980. [32] Bashir, O; Parish, D; Sandford, M; Phillips, I; "Optimising Data Processing in Network Perfor- mance Monitoring Systems", Proceedings of the IEE Communications, Volume 152, Issue 5, 7 Oc- tober 2005, Pages 633 - 642. [33] Opnet, Available at: www.opnet.com Cathryn Peoples, Gerard Parr, Sally McClean, Michaela Black University of Ulster School of Computing and Information Engineering Coleraine, Northern Ireland BT52 1SA E-mail: {si.mcclean,gp.parr,mm.blackg}@ulster.ac.uk Petre Dini Cisco 170 West Tasman Drive San Jose, CA 95134 USA E-mail: pdini@cisco.com