Dynamic bandwidth allocation for efficient support of concurrent digital TV and IP multicast services in DVB-T networks

Computer Communications 29 (2006) 741–756 www.elsevier.com/locate/comcom

Dynamic bandwidth allocation for efficient support of concurrent digital TV and IP multicast services in DVB-T networks* D. Negrua,*, A. Mehaouaa, Y. Hadjadj-aoula, C. Berthelotb b

a CNRSpPRiSM Laboratory, University of Versailles 45, av. des Etats Unis, 78035 Versailles, France Thales Broadcast and Multimedia, 1, rue de l’Hautil, zone des outries, 78700 Conflans sainte Honorine, France

Abstract Convergence of digital video broadcasting networks, from one hand, and IP wireless networks, from the other hand, represents undoubtedly the main evolution in next generation of services combining digital television and interactive Internet applications. This crossindustry synergy is jointly driven by the growing number of mobile devices willing to access the Internet and the large-scale and low-cost deployment of broadband terrestrial digital broadcasting infrastructures (DVB-T). In this paper, we describe a novel dynamic bandwidth allocation algorithm, called iDBMS, for the provisioning of concurrent IP multicast and Digital TV services over a new type of broadband wireless metropolitan area networks that utilises the DVB-T stream in regenerative configurations for creating a multi-service capable infrastructure in the UHF/VHF band. This fast DVB-T metropolitan backbone will permit the seamless inter-connection of multitechnological access networks (i.e. WiFi, xDSL, PSTN, .) at a regional level by means of a shared broadband DVB-T downlink and pointto-point physical return channels. IP over DVB optimization, asymmetric wireless channels and resource allocation are addressed in this paper. Implementation and performance evaluation of the proposed resource management algorithm iDBMS is also presented in the largescale context of the IST European project ATHENA. q 2005 Elsevier B.V. All rights reserved. Keywords: IP; DVB; QoS; Resource management

1. Introduction Next generation networks will undoubtedly consist of the synergy between heterogeneous networking technologies, coming from either the broadcasting/telecom side and the Internet domain. Interoperation of digital video broadcasting standards and Internet protocols based services represents one main evolution in next generation of new services for digital television. Concerning broadcasting standards, Digital Video Broadcasting (DVB) [1] is expected to be the prominent television broadcast standard for next decades, as well

* This work is partially supported by the 6th EU Framework Program for Research and Development 2003–2007, within the IST-ATHENA project (www.ist-athena.org). * Corresponding author. Tel.: C33 139254059; fax: C33 139254057. E-mail addresses: [email protected] (D. Negru), [email protected] (A. Mehaoua), [email protected] (Y. Hadjadj-aoul), [email protected] (C. Berthelot).

0140-3664/$ - see front matter q 2005 Elsevier B.V. All rights reserved. doi:10.1016/j.comcom.2005.07.017

through a satellite-based technology (DVB-S), as in terrestrial television (DVB-T), or cable (DVB-C). The DVB technology provides a relatively high bandwidth data channel (around 1.8 Gbps) but, as a matter of fact, it is based on uni-directionality, thus neglecting interactivity. From the Internet world, IPv4 and IPv6 are the protocols standards. One of the main characteristics of this technology is its bidirectionality, permitting full interactivity to users. Combining the two standards is a task that has been handled in numerous ways, and, today, results are taking form in IP over DVB encapsulation processes, such as MultiProtocol Encapsulation (MPE) and UltraLightweight Encapsulation (ULE) protocols. However, the trend now is to deploy QoSenabled IP/DVB inter-working environments dedicated to the highly requested multimedia services. Indeed, for many years now, there has been a sensational growing interest in multimedia networking, due to the emergence of efficient audio/video encoding techniques and the proliferation of enhanced audiovisual services. The demand for these kinds of applications has been increasing rapidly. Major advances in communication and network technologies have made multimedia services technically

742

D. Negru et al. / Computer Communications 29 (2006) 741–756

and economically feasible in any type of environment. Digital TV and multicast IP represent the best processes for delivering multimedia content, respectively, through broadcast and Internet-based networks. In this context, the universal multimedia access (UMA) concept is no longer unfeasible, and is instead gaining interest from Service Providers in order to enlarge their potential audiences (market), and hence increasing their revenues. The combined IP/DVB architecture may as well be envisaged for critical applications where no network infrastructure is available. In order to efficiently combine IP and DVB technology, we need to find an architecture in which those two technologies can coexist and inter-work together. However, the differences between those two technologies reside principally in the uni-directionality of DVB networks. Thus, the goal is to create a DVB-based architectural environment in which one or several powerful return channel(s) will be accessible, permitting the throughput or the access of IP services, which by nature need bi-directionality. This DVB environment should be able to efficiently transit IP packets, with the required QoS, as well as to deliver them to its users, those being accessible through any kind of access technology (UMTS, WLAN, xDSL, etc.). In this paper, we present an innovative concept of broadband wireless metropolitan networking area that interconnects various heterogeneous access networks including WLANs, UMTS UTRAN, fixed IP, xDSL, and DVB-T. These interconnected networks actually represent the Service Provider/Content Provider premises, backbone IP and DVB-T network, and end-user access networks, this way constituting a complete end-to-end service provisioning chain. The downlink is provided by a broadband DVB-T stream over the well known UHF frequencies that can deliver a huge bandwidth up to 1.8 Gbps; the downlink conveys the digital TV streams received from the TV studios along with all IP data traffic emanating from each single uplink of the different connected access networks. We believe that this concept reasonably represents many of forthcoming broadband wireless networks for DTV and IP services provisioning. Within the context of such an environment, we propose a support for Quality of Service by efficiently managing the bandwidth between IP data and DTV flows at two levels. Known approaches, such as the Opportunistic Data Insertion (ODI), give priority to DTV flows and assign the residual bandwidth (if any) to IP, with no concern about the IP demand. Our solution is more interactive and fair; it is based on two bandwidth management systems, respectively, for DTV and IP, which perform specific improving tasks on the corresponding flows according to the QoS needs of each other. It permits an optimal use of the total bandwidth by dynamically adjusting it to the requirements of the services. Concerning the management of DTV services, we enhance the bandwidth reallocation process between flows

not only by considering PIDs priorities, but also thanks to a dynamic re-transcoding phase. For IP data, we distinguish two types of services: Real-time multicast IP and the other Best Effort traffic. We activate a classifying process and launch an elastic-proportional scheduling mechanism based on the service differentiation and the changing allocated bandwidth. The reminder of this paper is as follows. Section 1 is devoted to the background and related works on IP over DVB and the description of the IP Opportunistic Data Insertion protocol. In Section 2, we describe the proposed interactive Dynamic Bandwidth Management System (iDBMS). Section 3 presents some experimental results evaluating the performance of the system in the context of the large-scale ATHENA testbed. Finally, conclusion is provided in Section 4.

2. Background and related works The convergence of IP and DVB networks is gaining more and more interests for the provisioning of large-scale multimedia services at a very low-cost. This section gives an overview of the ETSI DVB architecture and analyses the different approaches for transporting IP packets into DVB streams in an optimal way, stressing on the most important ones, the standardized MPE and the emerging IETF Ultra Lightweight Encapsulation (ULE). Then, it focuses on the QoS aspects of such a network interoperation, by describing the Opportunistic Data Insertion method. 2.1. IP over DVB Digital Video Broadcasting (DVB) is based on MPEG-2 transport stream in which data is transmitted in fixed size packets (188 bytes). Fig. 1 presents the MPEG transport stream packet and header structures. The packet is constituted of a header of 4 bytes followed by a payload of 184 bytes. † The PID: Packet Identifier is used to identify all packets carrying the same component (one PID per audio, one PID per video) or signalisation traffic (reserved PIDs). † Although, there is neither source address nor destination address in the header, MPEG-2 TS network devices use the PID to switch the streams when required. Using the specific DVB signalling traffic (i.e. special tables carried into stream with specific PID numbers), the DVB network devices are appropriately configured, so that they are able to forward the entering streams without ambiguities Using the TS packet header fields, it is possible, to a certain extent, to signal the transported data structure (delimitation, priority, padding, etc.), so that the upper layer PDU transport may be accommodated. There are many data broadcast specifications that are intended to be malleable in

D. Negru et al. / Computer Communications 29 (2006) 741–756

743

MPEG-2 Transport Stream

Transport Stream Packet (188 bytes) Header (4 bytes) [Adaptation Header]

Payload (184 bytes)

PID continuity_counter (4 bits) adaptation_field_control (2 bits) transport_scrambling_control (2 bits) PID (13 bits) transport_priority (1 bit) payload_unit_start_indicator (1bit) transport_error_indicator (1 bit) sync_byte (8 bits) Fig. 1. Transport stream packet and header structure.

order to provide the information required by a particular service. These specifications can be found in [2]. There exist several ways of incorporating IP over MPEG2/DVB streams. The most important ones are the following. 2.1.1. Data piping In this encapsulation mode, the IP fragments are directly packed in the payload of TS packets. The payload of a transport packet can contain only one IP packet (or fragment). This kind of encapsulation is mainly used when higher layer data is not packetized (packetization is irrelevant to the DVB broadcast). The data piping is rarely used for IP streams due to IP packets delimitation problems and bandwidth wasting. 2.1.2. PES encapsulation data streaming This protocol uses ‘PES’ (Program Elementary Stream) encapsulation of IP packets (or fragments). Only one IP fragment is carried in each PES (i.e. packet packing is not IP payload

IP header

allowed). Organization of PES into transport packets complies with the ISO/IEC 13818-1 (MPEG-2 system) standard. The PES encapsulation offers many advantages by allowing a larger IP traffic signalisation using the PES containers header. It is worth mentioning that both Data Piping and PES Encapsulation assume that a fragmentation mechanism is deployed at the IP layer (MTU), forcing the IP generated packets to have a limited size (e.g. 368 bytes). 2.1.3. Multi-protocol encapsulation (MPE) The Multi-Protocol Encapsulation framework [4] is the more widespread IP over DVB encapsulation protocol. This protocol has the advantage of being highly flexible. Within MPE, the multiplexer encapsulates a single IP packet into a single MPEG-2 section regardless the IP packet size. The figure below (Fig. 2) summarizes the general IP MultiProtocol Encapsulation operations: The MPE encapsulation is able to convey the entire MAC frame including the IP packet. This improvement involves IP header

IP payload

MPE section Header

M A . . . . . . . C @

TS header TS payload

TS header TS payload

MPE section Payload IP header

IP payload

TS header TS payload

TS header TS payload

M A . . . . . . . C @

TS header TS payload

Fig. 2. Multi protocol encapsulation.

MPE section Payload IP header

IP payload

. . . .. . . . .. . .

744

D. Negru et al. / Computer Communications 29 (2006) 741–756

a complexity reduction at the receiver size since the receptor devices can discard frames at the MAC level, instead of processing all the IP packets. Additionally, the MPE gives the possibility to pack two different MPE sections (IP packets) parts into the same TS packet. This functionality considerably reduces the overhead while being fully compliant with DVB-SI DAT standard. The MAC address management is clearly important to provide seamless IP services across DVB networks. Still, the MPE standard (DVB-SI-DAT) 360 does not describe how to manage MAC addresses. In our context, we tackle this issue through the use of an IP-MAC mapping table (limited to 65,000 entries) at each gateway. Thus, the mapping table is dynamically updated using the well known IP mechanisms (ICMP, ARP/RARP). Each entry in the table has the following format: Destination IP address

Sub network mask

MAC address

178.3.1.1

255.255.255.0

00-00-A2-83-4D-B8

If the destination IP address is a ‘multicast’ IP address, the MAC address is deduced according to the description supplied in RFC 1112 [3]. Otherwise, the MAC address is the broadcast MAC address to ensure that the IP frame is received. 2.1.4. Ultra lightweight encapsulation (ULE) In January 2004, the IETF set up the IPDVB Working Group that aims at developing new protocols and architectures to enable better deployment of IP over MPEG-2 transport stream and provide easier interoperability with IP networks. Specific properties of this subnetwork technology include link-layer support for unicast and multicast, large numbers of down-stream receivers, and efficiency of transmission. The working group will recognize the existing Multi-Protocol Encapsulation (MPE) as the ‘de-facto’ IP over DVB standard encapsulation, so that any alternative encapsulation should co-exist with MPE. Nevertheless, a new encapsulation method known as ‘Ultra Lightweight Encapsulation’ (ULE) is currently under development by the IPDVB IETF WG [5].The aim of ULE is to progressively replace MPE due to (1) the overhead considerations, and (2) to introduce more evolving mechanisms for multicast management, IPv6 encapsulation, auto-configuration, etc. The principle of the ULE encapsulation is based on PDUs (Protocols Data Unit). They represent packets from different network protocols (IP datagram’s, Ethernet Frame, LLC/snap frames, etc.). These PDUs are processed by the encapsulator (by adding header and CRC trailer) and finally inserted in SNDUs (SubNetwork Data Unit). These SNDUs are then fragmented and encapsulated in the TS packet payload. The IETF on-going work on ULE encapsulation emphasizes on header extension, FEC support, and encryption functionalities.

2.2. QoS and resource management in IP over DVB networks When dealing with IP over DVB networks, the QoS resource management mainly consists of the allocation of the available bandwidth between IP data and DVB services. This is achieved inside a specific module before the multiplexing process. The bandwidth is managed at two different levels. First, DTV services are inserted in the output transport stream according to the rules defined in the configuration of the DVB equipment. DTV services can fill the whole bandwidth or can be restricted to a defined bandwidth. Then, IP data are inserted in the residual bandwidth. This method is called Opportunistic Data Insertion (ODI) [6]. Furthermore, it is possible to require a guaranteed minimum bandwidth for IP data. Indeed, we can use a strict constraint for the bandwidth management of digital TV services in order to limit their maximum bandwidth into a slice of the total bandwidth. DTV services always have the priority on IP but they can be forced into a slice of the transport stream rate. It is possible to manage many independent slices of bandwidth, through PIDs. For each PID, a bandwidth is allocated in the available output bandwidth according to the following parameters: † Guaranteed bit rate: It is the bandwidth reserved for the PID. This bandwidth is guaranteed only if the residual bandwidth sis big enough. † Bit rate upper limit: It is the maximum bit-rate the PID can use. Indeed, a PID that needs more bandwidth than its guaranteed bit-rate can overflow in the other slices that are under used. For an optimal functioning (the guaranteed bit-rates are respected for every PID), the sum of the guaranteed bit rates must be smaller than the residual bandwidth. Considering a strict constraint for the bandwidth management of digital TV services is set, the remaining bandwidth can be used for IP data. Digital TV broadcasters are constrained to the bandwidth reserved for DTV services. IP data providers use the residual bandwidth in opportunistic data insertion mode (ODI) with a guarantee of results. Indeed, the residual bandwidth is always greater than the ‘total bandwidth– bandwidth reserved for DTV services’. However, this bandwidth reserved for DTV services is most of the time static and changes rarely (i.e. when a channel does not emit anymore). Therefore, with this method, we do not really take advantage of the variable nature of the flows. They are VBR-coded and they are being processed as if they were constant. The spare bandwidth is not actually exploited each time it could. The following figure (Fig. 3) gives an example of the IP data insertion in a DVB-T transport stream including digital TV services. The bitrate of the transport stream is 24 Mbps

D. Negru et al. / Computer Communications 29 (2006) 741–756

745

Rate (Mbps) 25

1.

transmission bitrate 20

bitrate of input DTV services

15 10

1

2

3

4

5

6

2.

5 0

Time (s)

Rate (Mbps)

3.

10 8 6 4

bitrate of IP data input stream1

2 0

Time (s)

4. 5.

Ra te (Mbps) 10 8 6 4

bitrate of IP data input stream2

2 0

Time (s)

6.

Rate (Mbps ) 25 transmission bitrate 20 bitrate of output DTV services 15 10 5

bitrate of IP data output stream2

DTV services input bitrate = 15 Mbps IP data input stream 1 = 2 Mbps IP data input stream 2 = 4 Mbps DTV + IP1 + IP2 = 15 + 2 + 4 = 21 Mbps, less than the transmission bitrate. Nothing to do. The bitrate of IP data input stream 1 increases from 2 Mbps to 4 Mbps DTV + IP1 + IP2 = 15 + 4 + 4 = 23 Mbps, less than the transmission bitrate. Nothing to do. The bitrate of IP data input stream 1 increases from 4 Mbps to 6 Mbps DTV + IP1 + IP2 = 15 + 6 + 4 = 25 Mbps more than the transmission bitrate. DTV services bitrate is less than its constraint. DTV services bitrate cannot be decreased. IP2 bitrate is equal to its constraint. IP2 bitrate cannot be decreased. IP1 bitrate is more than its constraint. IP1 bitrate can be decreased to 5 Mbps. Case 2 The bitrate of DTV services increases from 15 Mbps to 17 Mbps DTV + IP1 + IP2 = 17 + 4 + 4 = 25 Mbps more than the transmission bitrate. DTV services bitrate is less than its constraint. DTV services bitrate cannot be decreased. IP2 bitrate is equal to its constraint. IP2 bitrate cannot be decreased. IP1 bitrate is more than its constraint. IP1 bitrate can be decreased to 3 Mbps. The bitrate of DTV services increases from 17 Mbps to 21 Mbps DTV + IP1 + IP2 = 21 + 4 + 4 = 29 Mbps more than the transmission bitrate. DTV services bitrate is more than its constraint. DTV services are removed. Now, DTV + IP1 + IP2 = 0 + 4 + 4 = 8 Mbps less than the transmission bitrate. Nothing to do.

bitrate of IP data output stream1

0 Time (s)

Fig. 3. IP Opportunistic data insertion in a DVB-T transport stream including DTV services.

while digital TV services bandwidth is limited to 18 Mbps. The remaining bandwidth, at least 6 Mbps, is divided into 2 IP data streams. The guaranteed bitrate of IP data stream 1 is 2 Mbps while the guaranteed bitrate of IP data stream 2 is 4 Mbps. Concerning the management of resources and QoS in IP networks, the Class Based Queuing (CBQ) ??? is the more widespread technique dealing with multiple DiffServ traffic classes. Generally, CBQ is used in a router to make separate allocations of link bandwidth to different classes of traffic as defined at the router. For example, different classes could be constructed for TCP

and UDP traffic, or for traffic from different institutions or different ISPs, or for unicast and multicast traffic. Or all of these distinctions could be made in a hierarchical link-sharing structure. With CBQ, each class gets at least its allocated bandwidth, given sufficient demand, and gets to use more than its allocated bandwidth if extra bandwidth is available. However, each class gets additional bandwidth only if other classes’ queues are empty, which do not allow an instantaneous response to transient bursts in other queues. Class-based weighted fair queueing (CBWFQ) is another priority-based packet scheduling technique; it

746

D. Negru et al. / Computer Communications 29 (2006) 741–756

extends the standard WFQ functionality to provide support for user-defined traffic classes. For CBWFQ, we can define traffic classes based on match criteria including protocols, access control lists (ACLs), and input interfaces. Each traffic class is characterized by bandwidth, weight, and maximum packet limit. The bandwidth assigned to a class is the guaranteed bandwidth delivered to the class during congestion. The packet dropping may be achieved using a tail drop policy or any advanced AQM technique ???. Still, this technique provides rather probabilistic guarantees to each traffic class according to its weight. That is, it does not allow queues dynamics trends to dynamically give transmission opportunities regardless the queue occupancy. In this paper, we focus on providing strict QoS guarantees for multicast multimedia IP traffics while maximizing the overall goodput achieved by the system. Assigning fixed shares for both real-time and best effort traffics would not be effective since those traffics are likely to fluctuate over the time, so the attributed bandwidth remains mostly unfilled completely. Although, traffic classes may borrow additional bandwidth to accommodate the transient traffic bursts, this depends upon the emptiness of the other queues.

3. iDBMS: interactive dynamic bandwidth management system for support of digital TV and IP multicast services Our objective in this work is to ensure strict quality of service guarantees for Digital TV and multicast IP services while maximizing the overall goodput of the network. Constant QoS for both single TV program and multicast IP video distribution has to be provided, residual bandwidth being systematically allocated to Best Effort IP traffic (HTTP, FTP, SMTP, etc.). It should be noted that there could be some kinds of priority (drop preference) within the TV bouquet according to a-priori committed SLA (Service Level Agreement) between the Service Provider (owning the TV program) and the Network Operator (owning the network infrastructure). At this point, managing the downlink with reactive mechanisms is a key component to optimize the scarce wireless resources utilization while meeting SLA constraints, which obviously would generate more income to the Network Operator. 3.1. iDBMS QoS and resource management The QoS solution proposed for inter-working IP and DVB is based on continuous bandwidth management and resources allocation. In actual mixed IP and DVB-T broadband access networks, a Bandwidth Manager is deployed to control the Digital TV and IP flows to be broadcasted in the

metropolitan area, according to the Opportunistic Data Insertion (ODI) method. This module is usually statically configured in order to perform a pre-defined bandwidth share between DTV and IP services. It is located before (in the downlink direction) the IP encapsulator and remultiplexer platform used in the Regenerative DVB-T system. The data flow passes through this module before reaching the DVB-T gateway for encapsulation and remultiplexing. In order to fulfill our objective, i.e. maximizing the bandwidth exploitation while meeting the QoS constraints of diverse services, we introduce a new design of an interactive Dynamic Bandwidth Management System (iDBMS) that exploits the DVB re-transcoding process in order to dynamically derive rules for IP traffic scheduling. The iDBMS consists of two entities, namely the DTV Bandwidth Manager and the IP Bandwidth Manager. Both have several interactions with each other in order to reach a proficient share of the bandwidth in a way that meets the QoS bounds and maximizes the wireless channel exploitation by immediately filling the open medium gap left by the DTV programs. An understanding of the DTV re-transcoding process is clearly very important for designing and operating our iDBMS. In the following, we summarize the main bandwidth managing features that may influence the iDBMS design. The iDBMS should analyse each single MPEG-2 TV programs in order to decide to what level the stream can be transcoded while sustaining the final perceived quality withtin certain limits. Thus, every DTV stream in the bouquet may undergo a transcoding process that is intended to eventually assign the resulting DTV bandwidth gain to IP traffic. The iDBMS may as well use streams’ priorities to preserve certain important TV programs from any transcoding. It should be noted that even when no transcoding is enforced, it is worth to achieve DTV streams analysis to figure out the overall bit-rate of the final multiplexed bouquet during the next GOP (Group of Pictures, 12 pictures -500 ms- for an MPEG-2 stream at 24 fps) and, thus, assigning the residual bandwidth to IP flows; the overall bouquet bitrate often fluctuates since it is composed of several VBR video streams. The maximum bandwidth consumption of each single video stream is a priory known (from SLAs). It permits an appropriate dimensioning of the maximum bandwidth reserved for the DTV streams. For instance, if the total downlink bandwidth is of 120 Mbps, we guarantee 20 Mbps for the IP flows, given that the maximum bit-rate of the DTV would be of 100 Mbps (through SLAs). Besides, when the DTV services either do not use all the bandwidth or exploit less than they are allocated, the IP services can take (if needed) the share of the spare bandwidth. Within iDBMS, there are many interactions between IP BM and DTV BM in order to continuously (each 500 ms) re-negotiate the bandwidth allocation strategy.

D. Negru et al. / Computer Communications 29 (2006) 741–756

A a result, the DTV BM takes into consideration the bandwidth needed by the IP services and the DTV streams characteristics (i.e. offered load, priority, transcoding pace, etc.) for reallocating the DTV services’ resources. On the other hand, the IP BM bandwidth request may be only partially satisfied. In this case, the IP BM puts into effect a particular scheduling strategy that maximizes the overall goodput, whilst meeting the QoS exigencies of multimedia IP streams. We call this the Interactive data insertion (IDI) method of the iDBMS. The main advantage that distinguishes IDI is that the transcoding is achieved only after receiving the IP BM bandwidth, which allows an on-demand transcoding at the DTV BM, and hence avoiding useless DTV degradation. The different interactions of the IDI method, along with the iDBMS architecture, are depicted Fig. 4. The Interactive Data Insertion method has several executive steps, described in the following table (Table 1): The dynamic reallocation of the bandwidth between the two BMs, meaning steps (2)–(5) are performed every 500 ms. It represents the time for processing a GOP (Group of Picture) in the MPEG-2 specifications. During this

Interactive Data Insertion (IDI) Algorithm

747

period, the DTV BM keeps the same bandwidth for DTV programs; therefore, it is unnecessary to keep on exchanging bandwidth information between the two BMs for that period of time since the bandwidth share will not change. However, in order to reach a real Quality of Service for the IP data, the IP packets need to be scheduled every time (see Section 3.3). The management of the overall bandwidth is hence achieved inside the iDBMS, and shared between the two BMs thanks to the IDI method. Every 500 ms, the IP BM informs the DTV BM about the bandwidth it needs in order to pass all the IP data it has received. According to this value and knowing its constraints and quality requirements, it performs a re-transcoding phase on all the DTV flows. Afterwards, the DTV BM informs the IP BM about the additional bandwidth it could have earned thanks to the re-transcoding process. According to its new allocated budget, the IP BM performs the accurate scheduling process on the IP flows in order to respect the service differentiation between Real-Time multicast and Best Effort traffic. The full algorithm beneath the IDI method consists of:

748

D. Negru et al. / Computer Communications 29 (2006) 741–756

This algorithm shows the processing of aggregate DTV flows from one side and aggregate IP flows from the other side. The QoS functions for the DTV and the dynamic reallocation of the bandwidth are performed at the beginning and then every 500 ms, while the ones for the IP continuously operate. We will see now in details what the DTV_BM() and IP_BM() functions exactly consist of. IP traffics

MPEG-2DTV streams

1

3

1'

2

DTV BM

IP BM

4

Transcoding process

5

IP Services Scheduling

iDBMS Interative Dynamic Bandwidth Management System

6 Multiplexed DVB Streams Native MPEG-2 DTV & Encapsulated IP traffic

Fig. 4. The iDBMS architecture and the IDI method interactions.

3.2. Qos management of DTV services The DTV BM has in charge of re-shaping the bandwidth allocated to the digital TV flows, according to different parameters, the most important one being the additional needed bandwidth for IP. An analyzing and a transcoding process are necessary in order to achieve that. First, the different MPEG-2 incoming flows have a Variable Bit-Rate (VBR), which changes every 500 ms (or each I-frame), according to the MPEG-2 specifications. There is only one I-frame per GOP (Group of Picture). Consequently, every 500 ms, we can re-arrange the sharing of the bandwidth between IP and DTV, giving more or less to IP. An analyzer and a transcoder constitute the DTV BM. It receives as an input the DTV channels, each one with its own variable bit-rate. The analyzer first processes an analysis on the aggregation of DTV streams in order to obtain the value of the overall occupying bandwidth (IDTV). Afterwards, it takes into consideration the additional needed bandwidth for IP (Addip), given by the IP BM. According to this parameter, the transcoder tries to re-transcode the DTV flows and to reduce their bit-rates to a lower value (Itrans(DTV)), if needed. Finally, it informs the IP BM about how much optimization the transcoder has been able to perform. Indeed, it might not be able to re-transcode the DTV flows enough to pass all the IP traffic, thus inducing scheduling process at the IP BM side.

D. Negru et al. / Computer Communications 29 (2006) 741–756

749

Table 1 Executive steps of the IDI method Steps

Description

(1) (1) (2) (3) (4) (5) (6)

The DTV inputs: the different MPEG-2 flows (TV1, TV2,.) coming form broadcasters and reaching the DTVBM of the iDBMS The IP inputs: the different IP flows coming from all the CMNs in the broadcasting area and reaching the IP BM of the iDBMS The IP BM informs the DTVBM about the amount of the bandwidth it needs in order to transmit all the IP traffic Giving the IP BM needs and the video bouquest analysis, the DTVBM performs a transcoding (if any) The DTVBM informs the IP BM about the amount of the residual bandwidth after transcoding, which can be used by IP BM According to its newbandwidth budget, the IP BM performs its scgeduling strategy among IP flows The output DTV and IP flows are sent to the re-multiplexer and encapsulator

The re-transcoding phase is strongly related to the value of the Addip. It tries to perform the best transcoding in order to satisfy this value. Three cases can occur: † AddipZ0: there is no need for additional bandwidth for the IP traffic. The already reserved bandwidth is enough. Consequently, there is no use for a re-transcoding, the DTV flows are sent as they are received. † AddipZIDTV–Itrans(DTV): there is a need for additional bandwidth for the IP traffic. The transcoding can and will be achieved so that the residual bandwidth corresponds exactly to the needed bandwidth. † IDTV-Itrans(DTV)!Addip: there is a need for additional bandwidth for the IP traffic. However, even the best transcoding process does not permit to have enough residual bandwidth for the entire required IP one. We transcode for the best and the IP BM has to cope with such value. In order to proceed to the best re-transcoding process and to consider all the characteristics of the different DTV flows, regulations must be made inside the DTV BM between the DTV slices based on PIDs. The BM manages the DTV services bandwidth allocation according to the desired configuration, and up to hundreds of slices of DTV services PIDs. For each slice, a bandwidth is allocated in the available output bandwidth according to the following parameters: † Bandwidth size: It corresponds to the bandwidth reserved for a slice. If the bitrate used by PIDs attached to this slice reaches the bandwidth size, the slice is suspended according to the slice priority, the slice constraint and the slice policy. † Priority: Low or High. Slices with a low priority will be suspended first in case of slice overflow during the remultiplexing process. Priority has no sense with strict constraint. † Constraint: Strict or Loose. With the strict constraint, PIDs attached to a slice will never use more bandwidth than the bandwidth size defined for the slice. With the loose constraint, PIDs attached to a slice can use more bandwidth than the bandwidth size defined for the slice according to the free bandwidth. In case of overflow, packets will be removed according to the smoothing policy.

† Smoothing policy: Drop exceeding packets or Drop slice. With drop exceeding packets smoothing policy, only the exceeding packets attached to the slice are removed from the output transport stream during an overflow. With drop slice smoothing policy, all the packets attached to the slice are removed from the output transport stream during an overflow. Smoothing policy is always set to ‘Drop slice’ with strict constraint. PIDs not defined into a slice are in the default slice. This slice has its priority set to ‘extra high’, uses ‘loose’ constraint with ‘drop exceed packets’ smoothing policy. Its bandwidth is set to the maximum output bitrate. If a PID is shared in several slices with different strategy, this PID is processed according to the most attractive strategy: † ‘Loose’ constraint is most attractive than ‘Strict’. † ‘High’ priority is most attractive than ‘Low’. Consequently, according to the priorities and the constraints, along with the smoothing policy, regulation of the DTV services thanks to PIDs will be performed any time a resource-demanding event occurs, triggering re-transcoding and reallocation of bandwidth. 3.3. Qos management of IP services In the context, where IP and DVB-T flows coexist, we have to create a way to achieve an efficient QoS management of the IP services, taking into consideration that the DTV has the priority over the IP data. An amount of the bandwidth is yet reserved for the IP, though. Thanks to the Interactive Data Insertion method, the bandwidth allocated to the IP services is negotiated between the DTV BM and the IP BM to prevent any bandwidth wasting. Actually, the IP traffic may take profit of additional resources after a ‘short-term’ (500 ms) TV streams analysis and an eventual re-transcoding phase. Therefore, the bandwidth allocated to the IP services changes every 500 ms. The IP BM algorithm needs to conform to this dynamic constraint, by accommodating the Expedited Forwarding multicast streams and using the residual bandwidth for the Best Effort traffic. In such a DVB-T environment, the IP services are classified into two classes of traffic. The classification is achieved using the beforehand subscribed SLA and more

750

D. Negru et al. / Computer Communications 29 (2006) 741–756

specifically service identification attributes at the packet level (e.g. IP DiffServ DSCP field, IPv4 Type of Service, IPv6 Traffic Class and Flow Label, etc.) † Real-time multimedia services, such as IP TV. They have strong constraints of delays and receive the highest priority (priority 1). We classify them as Expedited Forwarding traffic, according to the Diffserv QoS model. † Common web services, such as ftp, http, pop, and other applicative protocols. These types of traffic have hardly some bandwidth availability exigencies; they are assigned the priority 0, and considered as Best Effort traffic.

buffer overflow

Thus, the IP BM manages two queues, one for each class, and designs a specific scheduling mechanism between them two, respecting the dynamically allocated bandwidth. Instead of using the conventional EF non-preemptive priority model for DiffServ QoS, we propose to relax the proportional QoS by enforcing a less stringent priority scheduling. Actually, within the conventional non-preemptive priority discipline, the Best Effort queue is scheduled only if the high priority queue is empty, which is not actually optimal in terms of bandwidth efficiency. The objective is to gain more flexibility, so that we can schedule the BE traffic even when the EF queue is not empty, providing that the EF queue dynamics are controlled (i.e. both end-queued and entering EF traffic can be processed without QoS violation in the next scheduling rounds). To better understand the impact of non-preemptive queue scheduling, Fig. 5 illustrates the evolution of both data and real-time IP queues occupation (i.e. queue occupation histogram) at the IP BM level. The queue level sampling is achieved at constant intervals TDZ10 ms, which roughly concord with the period needed for scheduling 20 IP

packets. At each interval Ti, we give the queues’ lengths as well as the packets to be scheduled (‘grided’ part). In this example, we consider the conventional non-preemptive algorithm that keeps scheduling the real-time packets as the real-time queue is still filled. We observe that at time T3, there is an important BE packets dropping, caused by BE queue overflow. On the other hand, at time T5, both IP queues are almost empty, resulting in transmitting only eight BE packets. Dropped BE packets could have been transmitted when the real-time queue passed through relaxed periods. Indeed, the real-time queue was not stressed during period T4, which means that using an appropriate preemptive packets scheduling strategy could avoid BE traffic burstiness overflows while preventing realtime QoS violations. It appears from the above described example that the transient BE packets bursts, if not handled on time, will cause buffer overflow and lost packets. Although in here, we focus on two traffic classes, we can as well extend the proposal to several queues in case the QoS provisioning offer is fragmented into several service classes (e.g. multimedia, web, off-line multimedia downloading, etc.). Fig. 6 shows the two queues associated, respectively, to real-time and BE IP services. Within the real-time queue, N1 stands for the number of packets in the queue at time T and N 1 for the estimated number of packets in the queue at time TC1,l1 is the packet arrival rate, Gd is the threshold corresponding to the maximum acceptable delay for multimedia applications (i.e. Gd is used to restrict the maximum transit delay, which also confine the jitter experienced by the real-time flows). For those types of services, the delay is much more important that the packet loss. We could afford loosing some packets but we cannot accept a strong delay or high jitter oscillation at the receiver

dropped packets Maximum queue length Γp Γd

T0

T1

T2

T3

T4

T5

Fig. 5. Ip queues occupation histogram: effect of the BE flows burstiness.

T6

D. Negru et al. / Computer Communications 29 (2006) 741–756

Γd

N1

N1

λ1 Real-time (Priority 1) Queue (IP TV) N2

Γp

N2

λ2 Best Effort Priority 0 Queue (IP data) Fig. 6. Real-time and BE services queues.

side. It is therefore, obvious to focus on delays and jitter since the throughput (i.e. loss rate) is already guaranteed through admission control and iDBMS overall resource dimensioning. As long as the number of packets does not approach the Gd threshold, we can keep on filling in the queue buffer. The aggregated real-time traffic fluctuation can be foreseen without difficulties since each single multimedia flow is almost always the same with more or less smooth variations. Fig. 6 also shows the IP data services queue, in which N2 stands for the number of packets in the queue at time T and N 2 for the estimated number of packets in the queue at time TC1, l2 is the packet arrival rate, Gp is the maximum threshold beyond which the arriving packets have high priority of dropping due to overflow situation. For these other types of IP services, the packet loss characteristic is much more important than the delay. For example, the FTP applications do not have stringent delay constraints, but they rather need a minimum bandwidth so that the bit-rate could stabilize according to the TCP behavior. The characterization of such traffic is much more difficult to obtain since the different flows are rarely the same and they usually operate by burst. For instance, the web traffic (http) use in fact a short-lived TCP connection that generate burst traffic during short periods. Therefore, we do not set the threshold for packet losses at the end of the buffer, assuming a large number of packets could instantly arrive. By considering the two IP traffic aggregation classes, with widely different characteristics, we define a new mechanism for efficiently controlling the Quality of Service of IP applications. The priority is given to real-time services, which means that the delay constraint must be respected first. At the same time, we also try not to omit the packet loss constraint for the other IP services. We come out with a novel solution, based on prediction of flows. The usual techniques are ‘deterministic’ in the sense that they consider the priority given to the packets by serving first the queue with the highest priorities without taking care of the other queues or their inherent constraints. Our proposal features a dynamic

751

proportional service differentiation by possibly prompting the scheduling of real-time packets in case of relaxed queue conditions. For example, if the real-time queue is far from reaching the maximum delay threshold (Gd), whereas the other queue is getting saturated by approaching the maximum packet loss threshold (Gp), our mechanism will adapt by serving the packets of the BE queue for a while, until it gets more critical for the highest priority queue. The purpose of this scheme is to absorb as much as possible the transient short-term packet bursts exhibited by the aggregated BE flows. This way, the congestion problems for each queue are anticipated and the constraints are also respected. We call our proposal Elastic-Proportional Service Differentiation (EPSD). The assumptions are: † Gd is fixed according to the maximum delay tolerated by the real-time traffics, while Gp fixed in a way to anticipate the BE queue overflows. † l1%CIP: the incoming packet arrival rate of the real-time flows is always lower than the minimum assured bandwidth capacity for the IP. † The real-time queue must be empty before a new bandwidth allocation cycle between DTV traffic and IP traffic. This allows for preventing any excessive delay when the IP allocated bandwidth drops. We know that: Newip R N1 C N2 C l1 C l2 at a determined time t

(1)

And we need to assure that: Newip R l1 C

N 1 Tremaining

where Tremaining Z DKt

(2)

EPSD is a predictive-based algorithm. It states the procedures to undertake on the next values of the metrics. We can evaluate the next number of packets inside the queues through the following equation:  0  N i KN 00 i N i Z Ni C li f C Ka ðNi KN 0 i Þ C Kb (3) f f is the frequence of scheduling and Ka and Kb are two small regulated constants combined with proportional and derivative adaptations, usually employed in AQM techniques to regulate the traffic in the router queues. Based on the prediction of the number of packets to exist in the queue, EPSD decides of the scheduling process according to the following algorithm: If ðN 2 O Gp Þ If ðN 1 O Gd Þ && ðNewIP O l1 C N 1 =Tremaining Þ Processing(IP_prio_0) Processing(IP_prio_1) If left_space Processing(IP_prio_0) Thus, from formula (1)–(3) results the EPSD algorithm

752

D. Negru et al. / Computer Communications 29 (2006) 741–756

which best satisfies the IP flows different QoS requirements, while still considering the permanent bandwidth reallocation between IP and DTV services.

4. Performance evaluation Within the framework of the IST-funded European project ATHENA [7], the deployment of an inter-working IP/DVB-T environment, has been setup at the premises of the Centre of Technological Research of Crete (CTRC), in Heraklion, Crete. Through this demonstrator, the evaluation of the performances of the proposed iDBMS solution has been achieved. 4.1. The inter-working IP/DVB-T environment The inter-working environment consists of an infrastructure which uses regenerative DVB-T streams for the interconnection of distribution nodes, enabling access to IP services and Digital TV programs in wide areas such as big cities. Such a configuration enables multi-service capability, as regenerative DVB-T creates a single access network physical infrastructure, shared by multiple services (i.e. TV programmes, interactive multimedia services, Internet

applications, etc.). In this approach, the DVB-T stream is used in a backbone topology and thus creates a flexible and powerful IP broadband infrastructure, thus permitting broadband access and interconnection of all local networks. Fig. 7 shows an overall representation of such an environment. The Broadcasting Area is provided with regenerative DVB-T streams by the Central Broadcasting Point (CBP). Cell Main Nodes (CMNs) enable a number of simple users (geographically neighbouring the CMN) to access IP services hosted by the network. Each CMN constitutes the ‘physical interface’ to the common Ethernet backbone of users/citizens of a local network (i.e. IEEE 802.11), customers of a mobile network operator making use of 3G and B3G technology (i.e. UMTS), individual users and service providers [8]. In such configuration, both reverse and forward IP data traffic are encapsulated into the common DVB-T stream, thus improving the flexibility and performance of the network. As a result, the downlink can be roughly seen as a common medium shared by all CMNs within the CBP range. Based on the well known IP mechanisms (e.g. ARP/RARP, DNS) and keeping track of their enrolled user IP addresses, the CMNs forward the IP packets to the local networks behind them. The IP data stemming from the CMNs, consisting of either requests/acknowledgements or of useful data, are forwarded to the CBP to be included in the common

Fig. 7. The IP/DVB-T inter-working environment.

D. Negru et al. / Computer Communications 29 (2006) 741–756

broadcast downlink. This traffic will be conveyed via unidirectional point-to-point wireless links, acting as return channel trunks. The technology adopted for the implementation of the return channel can be any point-to-point wireless data transmission technique, without need for additional link-level procedures, like multiple access schemes or error resilience via retransmissions. The important components of this architecture are the IP to MPEG-2 encapsulator, which is located at the CBP level (and de-encapsulator at CMN level) and the IP routing module at the edge of each CMN. The encapsulation of IP packets into DVB-T flows is achieved through the MultiProtocol Encapsulation (MPE) process. All the modules of this solution are as well IPv4 as IPv6-compliant and can process packets from both versions of the Internet Protocol. Further information on modules description can be found in [7]. The IP users are connected through access networks behind CMNs and DVB-T users (Digital TV viewers) receive their DTV programs directly in their home through a simple set-top box (Fig. 7). Since the presented architecture is overall a broadcasting environment, the most appropriate services to be exploited are the multimedia ones. As shown Fig. 7, TV studios deliver Digital TV content to the CBP which is in charge of broadcasting it through DVB-T technology to the entire area. Broadcasters create the content they want to distribute inside the digital TV bouquet in MPEG-2 VBR-coded format. They make an agreement with the network operator (Service Level Agreement -SLA) for a guaranteed quality. The approximately same service could be offered through IP. Any user behind a CMN could be active and distribute his multimedia content to the network, assuming of course that it has the capabilities. This transmission will be provided through to the multicasting technique. The proposed architecture supports multicast in IPv4 and in IPv6 from all points of view: † Addressing and routing: the CMN routers handle the class D addresses from 224.0.0.0 to 239.255.255.255 for IPv4 and the ones starting with FF in IPv6. They are configured for forwarding multicast packets and for taking care of the multicast routing tables. They understand and replies to requests based on IGMPv3 and MLDv2. Mapping and encapsulation: at the CBP level, the IP-toMPEG2 encapsulator handles multicast packets and encapsulates them inside the DVB-T stream, through the MPE process and according to RFC 1112 for the layer-2 mapping. 4.2. Results analysis For the performance evaluation, we developed a CBP inside the University of Heraklion, as well as 3 CMNs, two inside the University with WLAN access and one in the city center providing a minimal ISDN/PSTN access to citizens.

753

The overall bandwidth exploitable for the measurements was of 16 Mbps. This bandwidth was shared among MPEG2 DTV channels allowed to a maximum of 10 Mbps and IP services, with an assured 6 Mbps. Distinction between IP multicast and the other BE traffic has also been made. A representation of the different flows that are transmitted by the CBP is shown in the snapshot of the IP encapsulator equipment, where the iDBMS module has been implemented (Fig. 8). The three MPEG-2 TV channels, each one of approximately 3.2 Mbps, an IP TV multicast stream, MPEG-1 coded at the bit-rate of 1.7 Mbps, and the BE IP traffic can be visualized. The minimum, current and maximal bit-rates used by each flow are also shown. For the experiments, students had the possibilities to be connected to the WLANs at the University, generating IP traffic randomly. Also, two active users were created behind each CMN delivering three IP multicast videos, MPEG-1 coded at 1.7 Mbps, gathering a total of 5.1 Mbps. The remaining assured bandwidth, 0.9 Mbps, is given to BE IP traffic. Therefore, the measurements were made according to these characteristics: † † † † † †

Maximum bandwidth rate for DTV channel: 10 Mbps Minimum assured bandwidth rate for IP: 6 Mbps 3 DTV channels transmitted: 9.6 Mbps 3 IP multicast streams transmitted: 5.1 Mbps Assured bandwidth rate for BE IP: 0.9 Mbps BE IP traffic transmitted randomly

In order to overpass the whole bandwidth capacity and see how our mechanism reacts, we intentionally fill the network with BE IP packets by bursts. We made 20 times the measurements on bandwidths. Each measurement corresponds to a period of 90 s, during which we send burst BE IP packets (of 2 Mbps) for 5 s every 30 s. The following figures show the mean bandwidth distribution between aggregated DTV, aggregated multicast IP and BE IP, resulting from these experiments. Fig. 9 shows the bandwidth share with no iDBMS implemented; the allocation is not optimal at all and the DTV flows always have an unused bandwidth reserved for them, which is lost. Also, at some points where burst packets are sent, the real-time IP multicast traffic might be dropped whereas the BE IP traffic may pass. This is due to the fact that no priority-based scheduling is settled. Fig. 10 represents the bandwidth share with the presence of the iDBMS, along with the IDI algorithm implemented. We can observe the optimal occupancy and reallocation of the bandwidth. Only BE IP packets are dropped when congestion occurs. The priority-based scheduling process permits the efficient throughput of the real-time multicast IP flows. For these measurements, the EPSD scheduling process for the IP traffic was not present within the equipment, its implementation not being operational yet. Only a simple priority-based mechanism, assigning the highest priority to IP multicast packets, was established. That’s the reason why

754

D. Negru et al. / Computer Communications 29 (2006) 741–756

Fig. 8. Snapshot of the iDBMS regulating flows.

Fig. 9. Bandwidth distribution without iDBMS.

D. Negru et al. / Computer Communications 29 (2006) 741–756

755

Fig. 10. Bandwidth distribution with the iDBMS.

the bandwidth allocated to IP multicast has a constant shape. Further results of experimentations on these bases can be found in [9].

5. Conclusion In this paper, we have preseted a novel QoS-enabled broadband wireless metropolitan network architecture for the seamless support of large-scale Digital TV and IP multimedia services to fixed and mobile terminals. This fast implementing and low-cost infrastructure creates a unique broadband virtual and common IP backbone (i.e. of a maximum 1,5 Gbps in case of ???, which is provided by all DVB-T streams in UHF, besides being present and available at every point of an entire region of 25 kms radius. This common IP backbone interconnects all users/citizens of the entire region, and enables them to access the provided services (i.e. HDTV-MPEG4, multicast IP services, e-mail, IPTV, datacasts, etc.) via the corresponding Cell Main Node (CMN). In this promising networking architecture, we improve the overall bandwidth usage at several levels. First, we propose an interactive bandwidth allocation system called iDBMS between DTV and IP services in order to take advantage of DTV offered load fluctuations, with an eventual additional transcoding action, to transmit more IP traffic. This iDBMS, along with the Interactive Data Insertion algorithm, perform

these actions. On the other hand, if the IP traffic is already accommodated by existing resources, we maximize the DTV perceived quality by avoiding the systematic transcoding of traditional data insertion schemes. Furthermore, the dynamic amount of bandwidth allocated each time to IP traffic is optimally managed. Actually, the proportional (relative) QoS differentiation between the two service classes is elastic, thereby absorbing the Best Effort traffic bursts while still conforming to Real-Time services exigencies. The presented QoS provisioning scheme (EPSD) achieves numerous performance gains over the conventional static approaches. In addition to maximizing the overall achieved goodput in the downlink, our proposal still meets the QoS constraints. Future works will consist of expanding the QoSprovisioning mechanism to all the network entities. The centralised approach of the iDBMS (at the Central Broadcasting Point) will be distributed to Cell Main Nodes throughout the Broadcasting Area, in order to inform and prevent in advance from IP packets discarding. The purpose will be to manage the overall DVB-T backbone resources through service level agreement between CMNs and the CBP. This way, all the traffic generated at a given CMN (multimedia and best effort) will have to conform to an earlier committed contract that explicitly specifies the allowed amount of data load. It is actually preferable to drop packets (using appropriate shaping mechanisms) at CMN level in order to achieve fairness between CMNs.

756

D. Negru et al. / Computer Communications 29 (2006) 741–756

References [1] ETSI: Digital Video Broadcasting (DVB); DVB specification for data broadcasting, European Standard EN 301 192 V1.4.1 (200406). [2] ETSI: Digital Video Broadcasting (DVB); Implementation guidelines for Data Broadcasting, European Standard ETSI TR 101 202 V1.2.1 (2003-01). [3] S. Deering, Host Extensions for IP Multicasting, RFC 1112, August 1989. [4] G. Fairhurst, H.D. Clausen, B. Collini-Nocker, H. Linder, A framework for transmission of IP datagrams over MPEG-2 networks, Internet Draft, draft-fair-ipdvb-req-05.txt, work in progress, May 2004. [5] Gorry Fairhurst, B. Collini-Nocker, Ultra Lightweight Encapsulation (ULE) for transmission of IP datagrams over MPEG-2/DVB networks, Internet Draft, draft-fair-ipdvb-ule-03.txt, work in progress, November 2004. [6] Thales Broadcast and Multimedia, Optimux, Patent number EP1249954, October 2003. [7] ATHENA Technical Annex: ATHENA Digital Switchover: Developing Infrastructures for Broadband Access, FP6-507312, August 2003. [8] G. Gardikis, E. Pallis, A. Kourtis, Beyond 3G: A multi-services broadband wireless network with bandwidth optimization, International Symposium 3rd Generation Infrastructure and Services, Athens, Greece, pp. 176-179, July 2001. [9] ATHENA consortium, ATHENA Deliverable D12.1, Evaluation and Measurements Performances, FP6-507312.

Daniel Negru received his MSc degree in computer science, specialized in networking and multimedia from the University of Pierre and Marie Curie, Paris 6, France. He is currently working toward a PhD degree in the CNRS-PRiSM Laboratory, at the University of Versailles, in the area of multimedia communication, mobility and convergence of Next Generation IP and Broadcasting Networks. His research interests include IPv6 Mobility and QoS, mobile multimedia services, bandwidth adaptation of multimedia services in hybrid IP/DVB networks.

Ahmed Mehaoua received his PhD degree in computer science in 1997 from the University of Versailles, France. From 1995 to 1998, he was an associate researcher in Telecommunications and Distributed Systems at the Computer Science Research Institute of Montreal, Canada. He was involved in several research projects on ATM network management and digital video Communications. In 1998, he joined the Centre for Communication Systems Research at the University of Cambridge (UK) as a research fellow, and the University of Versailles, France, as an assistant professor. His primary research interests are Multimedia traffic management and congestion control issues in wired and wireless broadband networks.

Yassine Hadjadj-Aoul graduated from the Department of Computer Engineering of the University of Es-Senia, Oran, Algeria, in 1999, specialized in Networking. He obtained his Master of Science degree in multimedia networking from the University of Versailles, where he is currently working towards the PhD degree, in the CNRS-PRiSM Laboratory, in the area of multimedia communication, and congestion control in TCP/IP networks. His research interests include Active Queue Management, QoS provisioning and dynamic bandwidth allocation for multimedia services in IP networks.

Christophe Berthelot received his engineering degree from INSA Rennes in 1994. From 1995 to 1998 he worked for BA Systemes in application development for automated guided vehicles. In 1998, he joined Thales Broadcast and Multimedia NMS. From 1998 to 2001 he worked in MPEG-2 real time analyser product line. In 2001, he joined the Broadcast TV system service where he is managing the development of multiplexer, scrambler and audio/video processing products. His research interests are based on enhanced multimedia services for broadcasting networks and IP over DVB QoS support.