A Testbed Environment for Validation of End-to-End QoS Provision for

A Testbed Environment for Validation of End-to-End QoS Provision for the Content Delivery Chain over Heterogeneous Systems1 C. Skianis, G. Xilouris, G. Kormentzas, A. Kourtis National Centre for Scientific Research ‘Demokritos’ Institute of Informatics & Telecommunications 15310 Aghia Paraskevi Attikis, POB 60228, Athens, Greece email: {kourtis; skianis; xilouris; gkorm}@iit.demokritos.gr Abstract

The content delivery chain encompasses content creation, delivery and consumption. To support this, the content has to be identified, described, generated, delivered, managed and protected. Furthermore, content/services of different format will be distributed over heterogeneous networks and delivered on a variety of user terminals. The scarce resource of bandwidth needs to be dynamically managed and the QoS should remain within predefined limits, accepted by the end users. This will enable the provision of network and terminal resources on demand to form user communities, where the content can be created, protected and shared, always with the agreed/contracted quality, reliability and flexibility. It is therefore imperative to develop an integrated solution that is able to manage the functionality of various entities in the digital information distribution chain, from content/service generation to user terminals, using heterogeneous networks, comprised of wired (IP based core network) and wireless (DVB, WLAN, UMTS) segments, and based on the end-to-end QoS approach. The aim of this work is to propose and to build a suitable testbed environment where such a solution, namely the approach of ENTHRONE (End-to-End QoS through Integrated Management of Content, Networks and Terminals), can be tested and demonstrated. In this respect, an operational networking infrastructure is outlined which can be used as a test bed to demonstrate, in real conditions, the functionalities and the performance of ENTHRONE approach to E2E QoS provisioning.

1. Introduction Today, the telecom and IT market is facing a peculiar problem: although the technology has evolved and the infrastructure for both the core and the access networks are in place and there are services available to be used, the Network Operators (NOs) and Service Providers (SPs) tend to be disappointed because revenues of their investments are very low. Consumers are not willing to subscribe to the existing services/applications and new attractive applications are not massively available yet. The provisioning of new applications/content to the market still follow slow rates and the main reason is due to end-end QoS delivery issues. There is considerable effort within the IST on the end-to-end QoS issue. AQUILA (c.f., [1]) considers dynamic E2E QoS provisioning in IP networks, implementing prototypes of a QoS architecture for a carrier grade DiffServ (c.f., [2]) core network. The project supports a wide range of applications by providing a QoS toolkit API, targeting at IP Core and IP Access network infrastructures. TEQUILA (c.f., [3]) develops architectures, algorithms and protocols for negotiation, monitoring and enforcement of Service Level Specifications (SLS) between service providers and their customers and between peer providers in the Internet. A functional model for a complete solution to intra-domain traffic engineering to meet contracted SLSs in a cost effective manner is envisaged and is validated through both simulation and/or testbed experimentation. Several access technologies alongside the IP core and the IP access are the considered network infrastructures. In MESCAL (c.f., [4]) the focal point is on the specification and validation of scalable, incremental solutions for flexible provisioning of interdomain QoS across the Internet. In CADENUS (c.f., [5]) an integrated solution for the creation, configuration and provisioning of end-user services with QoS guarantees in Premium IP networks is proposed. CADENUS supports structuring a set of core functional blocks at the user - provider interface. Service creation and configuration is performed in a dynamic way through the appropriate linking of user related service components (authorisation, registration, etc.) to network related service components (QoS control, accounting, 1

This work has been performed in the framework of the IST IP Project IST-2003-507637/ENTHRONE, which is partly funded by the European Union.

P89/1

etc.). Dealing with the end to end QoS issue, ENTHRONE (End-to-End QoS through Integrated Management of Content, Networks and Terminals) adopts a business model in which Content Providers (CPs) and Content Consumers (or end users) are considered as one entity, while NOs and SPs are other entities. In this approach, every end-user can potentially be a CP, but can also consume content. This new entity (proposed and supported by MPEG-21 framework [6]) will be responsible only for the generation of the content and will focus only on the business aspect of the service. A second entity (i.e., NOs) is responsible for engineering the network and for the provisioning of networking resources, required for service/content delivery. An overlaying Integrated Management System (IMS) allows NOs to monitor, control and manage the network resources based on specific policies derived from the requested QoS and the capabilities of each network. In this context, it can be created a networking environment, which achieves provisioning and maintaining of an end-to-end agreed QoS through heterogeneous networks, owned by different NOs. Further information on the adopted concept can be found in [7], [8] and [9]. This environment is comprised of wired (IP based core network) and wireless (DVB, WLAN, UMTS) segments. An interesting terrestrial networking implementation, also considered in this work, is the utilization of DVB-T as a downlink channel for the provision of IP services to single end-users, i.e. users that are equipped with a DVB-T compliant receiver modules (c.f., [10]). The aim of this work is to propose and to build a suitable testbed environment where such a solution, namely the approach of ENTHRONE (End-to-End QoS through Integrated Management of Content, Networks and Terminals) can be tested and demonstrated. In this respect, an operational networking infrastructure is outlined which can be used as a test bed to demonstrate, in real conditions, out of a set of suitable service scenarios, the functionalities and the performance of ENTHRONE approach to E2E QoS provisioning. In Section 2 the ENTHRONE demonstrator architecture is presented. Section 3 introduces scenarios on provisioning broadcast/multicast and content on demand followed by a description in Section 4. Concluding remarks are found in Section 5.

2. ENTHRONE demonstrator architecture The aim of this demonstrator is to show some basic features of the ENTHRONE concept, in a laboratory environment. In this respect, an operational networking infrastructure will be developed, which can be used as a test bed to demonstrate, the functionalities and performance of the suggested solution.

2.1. Technical description of the demonstration environment The adopted network configuration is able to address the most significant issues of the concept. Two basic network types, IP and DVB, are included in the core network (c.f., [11]) with DVB-T, GPRS/UMTS and WLAN considered as access network.

Figure 1: A simple network configuration of the demonstrator Figure 1 depicts an indicative network configuration. Two CPs (CP1 and CP2) are connected to the corresponding NOs (NO1 and NO2). The two NOs are connected to NO3, which in turn is connected to NO4. An alternative route between NO1 and NO4 is also anticipated. The access network is comprised of a DVB-T and a GPRS (or UMTS) network, in co-operation. The link between NO2 and NO3 includes a DVB-T link, in order to demonstrate the use of DVB technology as a core network segment.

P89/2

The DVB-T based network is implemented through a DVB encapsulator and multiplexer, along with a COFDM modulator and a low power UHF amplifier. The WLAN access network is based on IEEE 802.11x technology. An Access Point (AP) serves as an interface between the wired core and the CC terminals. Also, a Station Adapter (SA) is to interface the WLAN radio link to the terminal device (e.g. a laptop) of the CC. At the CC site two types of terminals are considered: a TV set along with a set top box and a PC properly equipped with the corresponding interfaces to connect to both the DVB-T and the GPRS (or UMTS network). Based on the final network configuration, the location of the CCs and the CPs and the requirements of the content to be provided, the appropriate traffic engineering will be applied, in order to define the suitable SLSs (‘provider SLSs’ named pSLS) between adjacent NOs. SLSs between NOs, namely pSLS, are distinguished from signaling messages related to CCs, namely cSLSs, also depicted, that are used on service request (c.f., [8]). Regarding SLSs the forward cascade model is adopted where any pSLS between two NOs has to respect also pSLSs from previous NOs in the communication chain. Taking Figure 1 as an example, pSLS1 and pSLS2 are initially defined and then when it comes to pSLS3 and pSLS4 they should also consider pSLS1 and pSLS2. The established pSLSs are translated to appropriate DiffServ parameters and applied to the underlying networks. Quality monitors such as Network and Perceived Quality Meters (NQM and PQM) are included in the NO sites to test and evaluate interconnections with network management subsystems. Moreover, additional experimentation will consider pSLS renegotiation scenarios using appropriate signaling protocols. Additional features such as IP traffic switching from GPRS to DVB-T access networks can be demonstrated, according to specific criteria, e.g. when content requires higher bit rate than GPRS supports. Finally, the platform will support additional scenarios of QoS degradation occurrences testing and validating the reaction of the system.

2.2. Targeted services for the demonstrator environment This demonstration targets two general types of services to be provided, namely • Category 1. Services whose distribution is initiated by a CP, mainly a Business CP (BCP), such as • TV services (Broadcasted or multicasted), with content provided to the (human) user in real time • Distribution of content files (audiovisual or any other type), pushed by the BCP to the terminal of CCs., with content provided in due time (e.g., after the downloading is finished). • Category 2. Services whose distribution is initiated by the CCs. • This category of services mainly refers to the viewing of AV content in real time on demand by the CC (e.g., VoD).

3. Scenarios for on demand provision of broadcast, multicast and content The objective of the scenarios presented in the remainder of this section is to demonstrate the provision of two basic categories of services over heterogeneous networks that support the ENTHRONE concept. The data and control planes of the adopted network architecture are depicted in Figure 2. A high level E2E QoS ENTHRONE Networking Architecture is also given in Figure 3. The architecture is purposely selected based both on simplicity and on completeness. It includes both types of networks IP and DVB in the core network. In the access network, DVB-T, GPRS/UMTS, WLAN and ISDN are anticipated in several configurations. Several important features of the proposed ENTHRONE solution are considered such as DiffServ support, existence of Policy Enforced Points (PEP) and Policy Decision Points (PDP), the ability to enforce DiffServ QoS policies, establishment of SLAs/SLSs, IPv6 support, NQMs and PQMs, traffic diversity in interactive broadcasting (c.f., [7], [8], [9]).

P89/3

Figure 2: General network architecture for the scenario of on demand provisioning of broadcast/multicast and content Routing / Biling / QoS / Security

Routing / Biling/ QoS/ Se curity

Routing / Biling / QoS/ Security

PDP Data and Policy Repository

LDAP

IMS user Agent

PDP

IMS

Customer SLA

Customer SLA

EQoS SLS (pSLA)

EQoS SLS (pSLA)

EQoS RA EQoS RM

PDP

EQoS RA EQoS RM

Service Plane

IMS user Agent

PDP

Inter Domain Management Plane Customer SLA

Customer SLA PS CO

C O PS

P/ NM /S

/S N M P/ ...

Intra Domain Management Plane

...

ePEP

ePEP cPEP

cPEP

Control Plane

cPEP

Core

Content Edge

Acce ss netw ork

Server

Domain A

Edge Edge

ePEP

ePEP

ePEP ePEP

Edge

Core

Management Plane

Core

Edge

Acce ss netw ork

Edge

Domain C

Domain B

End User Terminal

Data Plane

Figure 3: High-level E2E QoS ENTHRONE Networking Architecture Figure 4 presents, in a more detail, the actual network configuration to be implemented. It consists of two IP network domains (Domain A, Domain C), a DVB domain (Domain B) and an UMTS/GPRS domain. The IP networks are realized through Linux PC routers. The Linux PC routers run the latest stable operating system kernel release 2.4 and are configured to support DiffServ technology. The DVB network comprises of two nodes that have the same functionality and architecture. The main functionalities that are supported in these nodes are: • Mapping of the DSCP field of the IP packets. • Encapsulation of the IP packets to Transport Stream Packets (IP/MPEG2 GW). • De-encapsulation of IP packets from TS packets (MPEG2/IP GW). • Bandwidth management. Each node uses a certain frequency to broadcast data both to the users and to the other node with some CCs using the UMTS/GPRS network domain as return channel to send request signals.

P89/4

Figure 4: Actual network configuration to be implemented in this scenario The traffic flow from BCP at domain A to the CC at domain C can be described as follows: • The ingress router of domain A marks the packets with appropriate DSCP bits and forwards them to the second router. • This egress router, based on the DSCP field, forwards the packets to the Domain B. • The first node of the B domain reads the DSCP field information and maintains the QoS properties of the flow. It then encapsulates the packets and transmits the data to the other node. • The corresponding node in domain B receives the TS packets and de-encapsulates the IP packets and forwards them to domain C ingress router. • The ingress router of the C domain reads the DSCP field and forwards the packets to the CC. In order to test the functionality of the whole system, stressed conditions will be created in the network, by inserting non ENTHRONE traffic from the router of domain A in order to congest the link between domain A and B. The system will react, managing that traffic and protecting the EF flows.

4. Scenarios description In this section three indicative candidate service provision scenarios are described, namely: • Provision of TV services, • provision of file downloading services, using push technology, • provision of VoD services.

4.1. Provision of TV services In this scenario, it is assumed that a broadcaster (a BCP according to ENTHRONE terminology) is willing to broadcast TV services to a large number of CCs geographically dispersed, which are equipped with TVs, PCs and mobile terminals. The scenario also anticipates for hybrid CC terminals (DVB-T and UMTS/GPRS). Between the broadcaster and the target CCs there may be a number of networks, IP and DVB based. The access networks may also be of various types (e.g., DVB, IP, UMTS/GPRS). As a result, the broadcaster is assumed to have Digital Item Adaptation (DIA) capabilities, for the adaptation of the content to any format (MPEG-2 or MPEG-4) and over any transport layer (MPEG-2/TS or IP). The NOs are also assumed to have DIA capabilities, if the neighboring network is of different type (DVB or IP). The basic characteristics of this scenario are : • The BCP selects the content to be offered. • Initiates the transmission whenever he wishes. P89/5

• • • •

• •

The transmission is uni-directional and is addressed to a large number of CCs. The CC joins the transmission. The CC can be equipped with TV, PC or mobile terminal. All types of ENTHRONE management systems are considered to be employed. A return channel (although not mandatory in general), will be available to the CC in this scenario, in order to enable the selection of the desired content among those distributed and also to enable the communication of the terminal management subsystem at the CC with the network management subsystem. The CC will receive guaranteed PQoS, independent of the type of terminal. The networks will support DiffServ QoS policies.

4.1.1. Description of the scenario In this scenario, the broadcaster is aware of the network architecture, as he is connected to the ENTHRONE management system, which knows all established SLAs. In addition, he is aware of the market, i.e. the types of CCs that are connected to the various network domains. For example he knows that there are possibly N CCs connected to network X through mobile terminals, M CCs connected to network Y through PCs etc. Based on the above the paths through which traffic will flow (find path) are known. Before initiating the transmission, the network management subsystem receives information on available network resources along the path. If resources (mainly bandwidth) are available and based on the content and the specified quality level, the DIA parameters are set. It is possible to consider DIA performance at the broadcaster’s site or at an appropriate network domain. The QoS policy (marking of packets, traffic excess policy, delay jitter, etc) is applied to the networks sequentially from the broadcaster to the last network. After the commencement of the transmission, measurements from quality meters are fed back to the broadcaster. If measurements show a QoS degradation, the network manager subsystems in the path are activated and PQoS measurements are taken. From these measurements, the network operator that is responsible for degradation is retrieved and remedial actions are taken.

4.1.2. Parameters related to the service scenario In this scenario all network domains (IP and DVB-T) support DiffServ, with packet marked as EF or AF traffic. Marking can be performed either at the BCP site or at the ingress router of the NO to which the BCP is connected. The required adaptation of the digital item is mainly performed at the BCP site. Alternatively, it could be performed at the NOs sites, under certain conditions. Regarding any excess traffic a different treatment is anticipated such as dropping packets or lowering priority from EF to AF. When it comes to NO without DIA capabilities, multiple transmissions will commence at different bit rates, each destined to the appropriate network. The source content will be in MPEG-2 or MPEG-4 format, supported by the network to which the BCP is connected. Typical access networks are considered, namely the IP, DVB-T and UMTS/ GPRS. Regarding alternative core network routes from BCP to CCs all the combinations are to be considered, involving certain cases where DVB is part of the core network.

4.2. Provision of file downloading services, using push technology In the case of pushing content to the CCs, a number of files containing either video or other types of content are stored in a server at the BCP site. The files are selected by the BCP to represent as much as possible the CCs preferences. The BCP downloads this content to the CCs terminal, which may be either a PC or a mobile terminal. The User is able to access the content and interact with it after it is completely downloaded to his terminal.

4.2.1. Description of the scenario In some degree, this service is similar to the provision of TV services, but without the stringent bandwidth requirements of a real time video service. Even though the content may be a video file, it can be downloaded to the CC terminal in due time and after the completion of the transmission, the User is able to watch it. In this way, a scenario similar to the one described in the provision of TV services can be applied. Please note that DIA in the case of video content is performed off line, i.e. when the file is prepared and surely before starting the transmission.

P89/6

As a result, BCP is aware of the network configuration, the location and the terminal types of the CCs, involved in the push services. In other words he is aware of the full path(s). Before initiating the transmission, the network manager subsystem is informed on the available network resources along the path. If resources are adequate for the volume of the information (i.e. it does not require too long to download), it sets the appropriate parameters to the multicast software and starts transmission. Moreover, multiple transmissions are performed by the BCP in case network resources allow them (i.e. enough bandwidth available). The content will be provided on a carrousel basis, to allow the downloading of content to CCs that missed the beginning of the transmission. The whole transmission is over IP or IP encapsulated over MPEG-2 TS, to enable CCs connected through a DVB network to access the services.

4.2.2. Parameters related to the described service scenario Due to the nature of the service, the bandwidth required for the push service can be much lower than that of a TV service. However, after the bandwidth has been defined, it has to be respected, otherwise the CC will receive erroneous files and the service will fail for that CC. Therefore, although the bit rate requirements may be relaxed, the packet loss should remain very low. The delay jitter, crucial to TV services, is not important in this scenario. Finally, this type of service is not affected by different delays experienced. Although packet loss can occur due to the physical layer impairments, packets may also be lost in some router queues when marked as low priority and have to compete against heavy traffic of higher priority in the same router. Therefore, a way to ensure safe forwarding of the packets they should be marked accordingly, as EF or AF, in order not to be dropped from any queue. The types of access networks and the core network sequence from BCP to CCs are the same to the aforementioned TV services scenario. Regarding quality, measuring the received bit rate will give appropriate indications.

4.3. Provision of VoD services In this scenario, a number of BCPs host a variety of video files into their servers. The CCs are equipped mainly with PCs or mobile terminals. They are able to access these servers and retrieve the content in real time. Source content is initially stored as high quality MPEG-2 to anticipate for possible CCs that may wish such quality. In addition, the BCP will have adaptation (DIA) capabilities, to bring the content to the requirements of the CCs terminal and comply with the restrictions of intermediate networks. The typical format is anticipated to be MPEG-4 and the communication protocol UDP/RTP/RTSP. In order to achieve the provision of services to a number of CCs, a bank of DIAs is placed in the BCP.

4.3.1. Description of the scenario In this scenario initially the CC enters the portal of the BCP. From a list of offered services he selects the desired one and sends his request. The capabilities of the terminal are retrieved either through a subscription data base or through the terminal manager subsystem. The path between the content and the CC will be discovered, through signaling message exchanges between system entitities. In addition, the network manager subsystem takes information on available network resources along the path. If resources (mainly bandwidth) are available then based on the content and the specified quality level, the DIA parameters are set. As a result, the content is properly adapted at the BCP site and no DIA is required at the NOs. When no adequate resources are available along the path, CC will be offered the content with a lower quality and if accepted DIA will be informed. The CC’s request can be dropped in the cases where he will not accept a lower quality or in the rare case where there is no available bandwidth at all. In preparation of content delivery (adequate resources are available), the QoS policy (marking of packets, traffic excess policy, delay jitter, etc) will be applied to the networks sequentially from the BCP to the CC and the transmission will start. In this scenario measurements from quality meters are fed back to the BCP. If measurements show a QoS degradation, the network manager subsystems in the path are activated and network QoS measurements are taken in order to discover the responsible the network operator and perform suitable remedial actions. An interesting case study occurs when traffic diverts from a GPRS/UMTS network segment to a DVB-T network segment in the case of insufficient network resources to support delivery of the requested content (interactive broadcasting). Finally, admission control is applied to the number of CCs up to the point that there is availability in the

P89/7

resources of the networks along the paths.

4.3.2. Parameters related to the described service scenario The AudioVisual content to be provided is stored in files and the BCP hosts the content in servers that has access too. The CC is able at any point to select the desired content, initiating that way the service session. The transmission is bi-directional (a return channel is also required in that case) and is addressed to a limited number of CCs, depending on the network and server resources. The types of access networks and the core network sequence from BCP to CCs remain as indicated in the TV services scenario. DiffServ is also supported by all network domains (IP and DVB-T). Upon starting content delivery, the IP packets of the BCP are marked as AF at the border router of the first network (if allowed) or at the BCP site. Finally, it should be noted that network “delay” is important in VoD services due to the existence of control functions (play, pause, stop, rewind, etc).

5. Conclusions This work proposed a suitable testbed environment where ENTHRONE integrated solution that is able to manage the functionality of various entities in the digital information distribution chain, from content/service generation to user terminals, using heterogeneous networks and based on the end-to-end QoS approach can be validated. Future work involves the implementation and the exhaustive experimentation regarding all aspects of content delivery in a highly diversified networking environment.

6. References [1] AQUILA, “Adaptive Resource Control for QoS Adaptive Resource Control for QoS Using an IP Using an IP-based Layered Architecture based Layered Architecture”, IST-1999-10077 [2] Z., Wang, “Internet QoS: Architectures and Mechanisms for Quality of Service”, Morgan Kaufmann Publishers, 2001. [3] TEQUILA, “Traffic Engineering for Quality of Service in the Internet, at Large Scale”, IST-1999-11253 [4] MESCAL, “Management of End-to-end Quality of ServiceAcross the Internet at Large”, IST-2001-37961 [5] CADENUS, “Creation and Deployment of End-User Services in Premium IP Networks”, IST-1999-11017 [6] ISO/IEC, “MPEG-21 Multimedia Framework Part 1: Vision, Technologies and Strategy”, TR 21000-1. [7] C. Skianis, G. Kormentzas, A. Kourtis, G. Xilouris, A. Mehaoua, T. Ahmed, D. Negru, E. Borcoci, E. LeDoeuff, “ENTHRONE Perspective for E2E QoS”, 13th IST Mobile and Wireless Communications Summit, Lyon, France, 27-30 June 2004. [8] T. Ahmed, A. Mehaoua1, H. Asgari, G. Kormentzas, E. Borcoci, T. Kourtis, S. Eccles, ‘End-to-End Quality of Service Provisioning Through an Integrated Network Management System’, in NGNM ’04 under Networking 2004, Athens Greece. [9] A. Kourtis, C. Skianis, G. Kormentzas, G. Xilouris, D. Negru, A. Mehaoua, T. Ahmed, E. Borcoci, H. Asgari, S. Eccles, E. LeDoeuff, “Provisioning of End to End QoS in Diverse Environments: The ENTHRONE View”, Special Session on Transition to digital terrestrial television in UHF (DVB-T) στο 8th WSEAS International Conference on Communications, Athens, Greece, 12-15 July 2004. [10] E. Pallis, G. Xilouris, G, Gardikis, A. Kourtis, C. Mantakas, “The New Interconnecting Television: An alternative approach to next generation broadband networking”, in Proc. ConTEL 2003, Zagreb, Croatia, pp. 709-712. [11] E. Pallis, G. Xilouris, G. Gardikis, A. Kourtis, "The use of a DVB-T platform as an IP backbone for interconnection of LANs", in Proc. 6th WSEAS CSCC Multiconference, Rethymnon, Crete, July 2002, pp. 64-67.

P89/8