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/comcom8/6/2019 Dimension Ing Multicast-Enabled Networks for IP-Transported TV Channels
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
8/6/2019 Dimension Ing Multicast-Enabled Networks for IP-Transported TV Channels
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
8/6/2019 Dimension Ing Multicast-Enabled Networks for IP-Transported TV Channels
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
D. Negru et al. / Computer Communications 29 (2006) 741756744
8/6/2019 Dimension Ing Multicast-Enabled Networks for IP-Transported TV Channels
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,
less than the transmission bitrate.
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
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.6. 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 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.
D. Negru et al. / Computer Communications 29 (2006) 741756 745
8/6/2019 Dimension Ing Multicast-Enabled Networks for IP-Transported TV Channels
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.
D. Negru et al. / Computer Communications 29 (2006) 741756746
8/6/2019 Dimension Ing Multicast-Enabled Networks for IP-Transported TV Channels
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
D. Negru et al. / Computer Communications 29 (2006) 741756 747
8/6/2019 Dimension Ing Multicast-Enabled Networks for IP-Transported TV Channels
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.
D. Negru et al. / Computer Communications 29 (2006) 741756748
8/6/2019 Dimension Ing Multicast-Enabled Networks for IP-Transported TV Channels
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
D. Negru et al. / Computer Communications 29 (2006) 741756 749
8/6/2019 Dimension Ing Multicast-Enabled Networks for IP-Transported TV Channels
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.
D. Negru et al. / Computer Communications 29 (2006) 741756750
8/6/2019 Dimension Ing Multicast-Enabled Networks for IP-Transported TV Channels
11/16
8/6/2019 Dimension Ing Multicast-Enabled Networks for IP-Transported TV Channels
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.
D. Negru et al. / Computer Communications 29 (2006) 741756752
8/6/2019 Dimension Ing Multicast-Enabled Networks for IP-Transported TV Channels
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
D. Negru et al. / Computer Communications 29 (2006) 741756 753
8/6/2019 Dimension Ing Multicast-Enabled Networks for IP-Transported TV Channels
14/16
Fig. 9. Bandwidth distribution without iDBMS.
Fig. 8. Snapshot of the iDBMS regulating flows.
D. Negru et al. / Computer Communications 29 (2006) 741756754
8/6/2019 Dimension Ing Multicast-Enabled Networks for IP-Transported TV Channels
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.
D. Negru et al. / Computer Communications 29 (2006) 741756 755
8/6/2019 Dimension Ing Multicast-Enabled Networks for IP-Transported TV Channels
16/16
Top Related