Dimension Ing Multicast-Enabled Networks for IP-Transported TV Channels

8/6/2019 Dimension Ing Multicast-Enabled Networks for IP-Transported TV Channels

1/16

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

aCNRSpPRiSM Laboratory, University of Versailles 45, av. des Etats Unis, 78035 Versailles, France

bThales Broadcast and Multimedia, 1, rue de lHautil, 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, representsundoubtedly the main evolution in next generation of services combining digital television and interactive Internet applications. This cross-

industry 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 multi-

technological access networks (i.e. WiFi, xDSL, PSTN,.) at a regional level by means of a shared broadband DVB-T downlink and point-

to-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 large-

scale 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 broad-

casting 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

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 bi-

directionality, permitting full interactivity to users. Com-

bining 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 MultiProtocolEncapsulation (MPE) and UltraLightweight Encapsulation

(ULE) protocols. However, the trend now is to deploy QoS-

enabled 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

Computer Communications 29 (2006) 741756

www.elsevier.com/locate/comcom

0140-3664/$ - see front matter q 2005 Elsevier B.V. All rights reserved.

doi:10.1016/j.comcom.2005.07.017

*This work is partially supported by the 6th EU Framework Program

for Research and Development 20032007, 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), Berthelot@thales-

bm.com (C. Berthelot).
http://www.elsevier.com/locate/comcomhttp://www.ist-athena.org/http://www.ist-athena.org/http://www.elsevier.com/locate/comcom


2/16

and economically feasible in any type of environment.

Digital TV and multicast IP represent the best processes for

delivering multimedia content, respectively, through broad-

cast 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 technol-

ogies 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 inter-

connects 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, thisway constituting a complete end-to-end service provision-

ing 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 usethe 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) 741756742


3/16

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 MPEG-

2/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 (orfragment).

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

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 Multi-

Protocol Encapsulation operations:

The MPE encapsulation is able to convey the entire MAC

frame including the IP packet. This improvement involves

IP header IP payload

IPheader IP payload

MPE section PayloadMAC@

. . . . . . .

TSheader TS payload

TSheader TS payload

TSheader TS payload

IPheader IP payload

MPE section Payload

MPE section Header

MAC@

. . . . . . .

IP header IP payload

. . . . . . . . . . . .TSheader TS payload

TSheader TS payload

Fig. 2. Multi protocol encapsulation.

Header (4 bytes) Payload (184 bytes)

MPEG-2Transport Stream

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)

[Adaptation Header]

Transport Stream Packet (188 bytes)

Fig. 1. Transport stream packet and header structure.

D. Negru et al. / Computer Communications 29 (2006) 741756 743


4/16

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 interoper-

ability with IP networks. Specific properties of this sub-network 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 encapsula-

tion, 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 encapsu-

lation is based on PDUs (Protocols Data Unit). They

represent packets from different network protocols

(IP datagrams, 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 themultiplexing 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



5/16

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 institutionsor 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

1. 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.2. The bitrate of IP data input stream 1 increases

from 2 Mbps to 4 Mbps

DTV + IP1 + IP2 = 15 + 4 + 4 = 23 Mbps,


Nothing to do.3. 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.

4. Case 2

5. The bitrate of DTV services increases from 15

Mbps to 17 Mbps

DTV + IP1 + IP2 = 17 + 4 + 4 = 25 Mbps


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.6. The bitrate of DTV services increases from 17

Mbps to 21 Mbps DTV + IP1 + IP2 = 21 + 4 + 4 = 29 Mbps


DTV services bitrate is more than its constraint.

DTV services are removed.Now, DTV + IP1 + IP2 = 0 + 4 + 4 = 8 Mbps


Nothing to do.

bitrate of input DTV services

transmission bitrate

Time (s)

1 2 3 4 5 6

Rate (Mbps)

5

10

15

20

25

0

bitrate of IP data input stream1

Time (s)

Rate (Mbps)

2

4

6

8

10

0

bitrate of IP data input stream2

Time (s)

Rate (Mbps)

2

4

6

8

10

0

bitrate of output DTV services

transmission bitrate

Time (s)

Rate (Mbps )

5

10

15

20

25

0 bitrate of IP data output stream1

bitrate of IP data output stream2

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



6/16

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 guaranteedbandwidth 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 IPservices 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 gen-

erate 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 re-

multiplexer platform used in the Regenerative DVB-T

system. The data flow passes through this module beforereaching the DVB-T gateway for encapsulation and re-

multiplexing.

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 exploita-

tion 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 DTVbandwidth 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.



7/16

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, trans-

coding 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 thatmaximizes 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 thetwo 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

period, the DTV BM keeps the same bandwidth for DTV

programs; therefore, it is unnecessary to keep on exchan-

ging 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 respectthe service differentiation between Real-Time multicast

and Best Effort traffic. The full algorithm beneath the IDI

method consists of:

Interactive Data Insertion (IDI) Algorithm



8/16

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.

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 toobtain 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.

iDBMSInterative Dynamic Bandwidth Management System

IP BMDTV BM

Multiplexed DVB StreamsNative MPEG-2 DTV & Encapsulated IP traffic

IP trafficsMPEG-2DTV streams

IP Services

Scheduling

53

1'1

2

4

6

Transcodingprocess

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



9/16

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.

AddipZIDTVItrans(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 re-

multiplexing 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 ofthe DTV services thanks to PIDs will be performed any time

a resource-demanding event occurs, triggering re-transcod-

ing 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 manage-

ment 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 accom-

modating 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

Table 1

Executive steps of the IDI method

Steps Description

(1) The DTV inputs: the different MPEG-2 flows (TV1, TV2,.) coming form broadcasters and reaching the DTVBM of the iDBMS

(1) The IP inputs: the different IP flows coming from all the CMNs in the broadcasting area and reaching the IP BM of the iDBMS

(2) The IP BM informs the DTVBM about the amount of the bandwidth it needs in order to transmit all the IP traffic

(3) Giving the IP BM needs and the video bouquest analysis, the DTVBM performs a transcoding (if any)

(4) The DTVBM informs the IP BM about the amount of the residual bandwidth after transcoding, which can be used by IP BM

(5) According to its newbandwidth budget, the IP BM performs its scgeduling strategy among IP flows

(6) The output DTV and IP flows are sent to the re-multiplexer and encapsulator



10/16

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.

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 priorityscheduling. Actually, within the conventional non-preemp-

tive 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 occupationhistogram) 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 IPqueues 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 real-

time 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 theproposal 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, N1stands for the number of packets in the queue at time TandN1 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 ofservices, 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

bufferoverflow

T0 T1 T2 T5T4T3 T6

Maximumqueue length

droppedpackets

d

p

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



11/16


12/16

which best satisfies the IP flows different QoS requirements,

while still considering the permanent bandwidth re-

allocation 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 infrastruc-

ture which uses regenerative DVB-T streams for theinterconnection 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 broad-

band 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 MainNodes (CMNs) enable a number of simple users (geographi-

cally 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 B3Gtechnology (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 onthe 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.



13/16

broadcast downlink. This traffic will be conveyed via

unidirectional point-to-point wireless links, acting as return

channel trunks. The technology adopted for the implemen-

tation 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 Multi-

Protocol 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, assumingof 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-to-

MPEG2 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.

The overall bandwidth exploitable for the measurements

was of 16 Mbps. This bandwidth was shared among MPEG-

2 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 encapsulatorequipment, where the iDB MS m odule 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 measurementcorresponds 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 con-

gestion 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. Thats the reason why



14/16

Fig. 9. Bandwidth distribution without iDBMS.

Fig. 8. Snapshot of the iDBMS regulating flows.



15/16

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, IP-

TV, 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 band-

width 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 QoS-

provisioning mechanism to all the network entities. The

centralised approach of the iDBMS (at the Central

Broadcasting Point) will be distributed to Cell MainNodes 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) w ill 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.

Fig. 10. Bandwidth distribution with the iDBMS.



16/16

Date post:	07-Apr-2018
Category:	Documents
Upload:	ahmed-teejay
View:	225 times
Download:	0 times

Dimension Ing Multicast-Enabled Networks for IP-Transported TV Channels

Documents