«End-to-End QoS Provision over Heterogeneous IP and non IP Broadband Wired and Wireless Network Environments A dissertation submitted in satisfaction ...»
Authors in [?] discuss details of the mapping of the traﬃc classes oﬀered by UMTS and the RCL architecture, which is a prototypical implementation of the next-generation Internet. The existence of the traﬃc classes aims at the diﬀerentiation of user traﬃc in order to provide the individual QoS guarantees required by diﬀerent types of applications. In order to achieve the desired end-to-end performance, the traﬃc classes must be appropriately associated at the point where the two networks converge. The authors propose not only the association of the traﬃc classes of one network to those of the other, but also a possible methodology to appropriately transform the QoS service attributes. The simulations performed in this context proved that the proposed mapping achieves the end-to-end service requirements, which are, in a few words, delay sensitivity and minimal packet loss for the conversational and streaming classes, and diﬀerentiation based on priorities for the interactive and background classes of UMTS. These results have been accomplished even though the traﬃc classes of the RCL architecture are not in full compliance with those of UMTS, especially for delay-insensitive traﬃc classes. However, this situation is pragmatic, since in a real scenario the traﬃc classes of the external IP network will not be deﬁned according to the traﬃc classes of UMTS.
In this chapter there is a review available solutions which address the problem of end-to-end quality of service for multimedia streaming applications over heterogeneous networks, including wireless and wired network domains. In particular, it describes advanced QoS-enabled multimedia streaming techniques from the application perspective. These include layered video coding, packet prioritization and packetization, semantic description and QoS proﬁling of each stream, and addressed the generic areas of content adaptation and context awareness in an end-to-end system context. Following this, it describes a number of available network technologies that have support to class based quality of service from the network perspective, including the IntServ and DiﬀServ models, Multiprotocol Label Switching and UMTS. Finally, it provides a review of selected techniques that combine application and network layer QoS mechanisms in order to provide the desirable end-to-end quality of service. This research area is highly active because the demands of emerging applications in the ﬁeld of real-time multimedia streaming are increased and because of the wide use of mobile networks.
Many topics/issues are still open in this area, like quality of service and mobility, terminal equipment heterogeneity and intellectual property management and protection. Despite this, it concludes that for QoS-enabled multimedia streaming, the user and network heterogeneity requires highly scalable video coding, prioritized packetization, wherever possible, and ﬂexible QoS enabled delivery techniques to smoothly and transparently interoperate.
3.1 Introduction This chapter discusses a heterogeneous cluster of networks comprising of two IP and one DVB domains. The developed testbed encompasses DiﬀServ technology in the IP domain and bandwidth management over MPEG-2 Transport Stream in the DVB domain. The IP domains are realized with PCs running Linux Operating System acting as border and core routers. These Linux-based routers are employing DiﬀServ capabilities implemented through open source software. The DVB domain is realized through commercial equipment patched with the ability to discriminate the DiﬀServ traﬃc aggregates and apply bandwidth management.
The major goal of these experiments is to demonstrate that the common operation of IP DiﬀServ, DVB BM mechanisms and scalable MPEG-4 FGS prioritized video streaming oﬀer quality gains for continuous media applications.
This chapter is organized as follows: Section 3.2 discusses in detail a linuxbased heterogeneous IP/DVB testbed for MPEG-4 FGS video streaming traﬃc delivery experimentation. The testbed conﬁguration details for the media delivery experimental studies and the results of these studies are discussed in Sections
3.3 and ?? respectively. Finally, Section ?? draws conclusions and discusses directions for further work and improvements.
3.2 Proposed Arrhitecture
3.2 depicts the implemented heterogeneous IP/DVB testbed for MPEG-4 FGS media delivery experimentation studies. The testbed includes two IP autonomous systems interconnected via a DVB MPEG-2 autonomous system, acting as a trunk network.
The implementation of both IP and DVB autonomous systems is mainly based on open source software. The choice of open source software enables the conﬁguration of the testbed according to the needs and the speciﬁc requirements of the experimental studies that are carried out. The major goal of these experiments is to demonstrate that the common operation of IP DiﬀServ, DVB BM mechanisms and scalable MPEG-4 FGS prioritized video streaming oﬀer quality gains for continuous media applications. The next three subsections discuss implementation details of DiﬀServ, BM mechanisms and MPEG-4 FGS coding and packetization approaches, respectively.
3.2.1 IP Domain - DiﬀServ Implementation The DiﬀServ  framework aims to provide service diﬀerentiation within backbone IP networks. DiﬀServ technology enables the deployment of IP traﬃc discrimination in a scalable manner, by providing QoS guarantees only for aggregated traﬃc classes rather than for speciﬁc ﬂows. Essentially, when entering a network, packets are placed into a broad service group by a classiﬁcation mechanism that reads the DiﬀServ Code Point (DSCP) in the IP packet header and the source and destination address. The advantage of such a mechanism is that several diﬀerent traﬃc streams can be aggregated to a small number of Behavior Aggregates (BA), thereby simplifying processing and associated storing and forwarding processes at the routers. Furthermore, there is no need for signaling and the traﬃc diﬀerentiation is obtained on a packet-by-packet basis.
Diﬀerentiated Services model as proposed by IETF support two diﬀerent services: (1) the Expedited Forwarding (EF) that supports low loss and delay/jitter, and (2) the Assured Forwarding (AF) that provides better QoS than the best eﬀort, but without guarantee. For streaming video applications, in which the encoding and decoding process is more resilient to packet loss and delay variations, besides Premium Service, the Assured Service can be employed. Note that MPEG-4 FGS originally assumes guaranteed delivery to Base Layer (BL) and leaves the Enhancement Layer (EL) to the mercy of best eﬀort service of Internet.
The international literature presents a number of DiﬀServ implementations
 . However, most of them are poorly documented and/or quite outdated.
In this context, I implemented our own version running over Linux OS with kernel version 2.6.11 . Our implementation follows the generic architecture of Figure 3.2.1. Speciﬁcally, according to a set of ﬁlters, the incoming packets are separated into a number of classes, where each one of them maintains its own queuing/scheduling discipline for serving its packets, as well as its own policing scheme for controlling the amount of its packets.
The implemented DiﬀServ mechanism is incorporated into the two IP autonomous systems of the heterogeneous IP/DVB testbed. Each autonomous system consists of three PCs (at least PIII CPU with 512MBytes of RAM) running Linux OS (kernel version 2.6.11) with iproute2 package and tc utility support.
Each IP domain includes two edge routers and one core router. The supported BAs are EF, AF1x and BE. The Hierarchical Token Bucket (HTB) packet scheduler with three leaf classes is used for the realization of the supported BAs. In particular, a pFIFO queuing discipline is adopted for the EF BA. Three GRED virtual queues with diﬀerent drop percentages are implemented for the AF1x BA.
The BE BA is served through a RED queuing discipline. This setting is depicted
in Figure 3.2.1. The maximum bandwidth allocated at the parent HTB class is 13Mbps shared among the BAs. Each leaf class can borrow excess bandwidth from another leaf class.
The conﬁguration of the GRED virtual queues requires the adjustment of the following parameters: AvgQmin which is the maximum average queue size after which all packets get dropped, BS, which is the percentage of the bandwidth share, L, which is the desired latency, BW, which is the total link bandwidth, AvgQmax which is the minimum average queue length after which packets get dropped, AvgP kt which is the average packet size, B, which is the burst value in number of packets and Qlimit which is the actual queue length never to be exceeded.
The AvgP kt size is 1024 bytes. The percentage of the Bandwidth Share (BS) is 33%. The desired Latency L is either equal to 100ms for all AF1x BAs, or 100ms for AF11, 200ms for AF12 and 500ms for AF13 BA. The remaining parameters are calculated based on the following formulas 3.1-3.4 and the corresponding
results are given in 3.1:
3.2.2 DVB Domain - BM Implementation The bandwidth reallocation among the IP virtual channels of a DVB MPEG-2 TS  uplink is based on a set of predeﬁned priority policies. In this work three priority policies are implemented, namely: (1) Static guaranteed - This policy guarantees a static bandwidth to each virtual channel. A guaranteed bit rate value has to be speciﬁed so that the actual bit rate is guaranteed up to this boundary value. The unused bandwidth (guaranteed bit rate - instant bit rate) is reserved and cannot be allocated to other virtual channels. (2) Dynamic guaranteed - This policy guarantees a dynamic bandwidth to each virtual channel. A guaranteed bit rate value has to be speciﬁed so that the actual bit rate is guaranteed up to this boundary value. On the contrary to the static guaranteed policy, the unused bandwidth (guaranteed bit rate - instant bit rate) is not lost, but can
be allocated to other virtual channels. (3) Best eﬀort - This conventional policy allocates bit rate to various virtual channels based on the available bandwidth.
Two full uplink/downlink conﬁgurations comprise the DVB domain. The uplink involves an encapsulator, a multiplexer and a DVB modulator. The downlink is realized via a DVB/IP gateway, which is a standard PC running Linux operating system equipped with a standard Ethernet controller and a DVB PCI card capable of demodulating the DVB signal and de-encapsulating the IP packets.
The DVB domain employs the implemented priority policies in order to preserve BAs deﬁned in the IP domains. The binding among BAs and the corresponding
priority policies is given in Table II:
Note that in order to deal with the IP to MPEG-2 encapsulation overheads, the total link bandwidth is 14 Mbps, which is 1 Mbps bigger than the IP domains one. While AF1x BAs and BE BA can borrow bandwidth beyond the guaranteed, the EF BA is statically allocated a maximum value and therefore cannot borrow unused bandwidth.
3.2.3 MPEG-4 FGS video coding and transmission
MPEG-4 FGS scalable video coding constitutes a new video coding technology that increases the ﬂexibility of video streaming. Similar to the conventional scalable encoding, the video is encoded into a Base Layer (BL) and one or more (ELs). For MPEG-4 FGS, the EL can be eﬃcient truncated in order to adapt transmission rate according to underlying network conditions. This feature can be used by the video servers to adapt the streamed video to the available bandwidth in real-time (without requiring any computationally demanding re-encoding). In addition, the ﬁne granularity property can be exploited by the intermediate network nodes (including base stations, in case of wireless networks) in order to adapt the video stream to the currently available downstream bandwidth. In contrast to conventional scalable methods, the complete reception of the EL for successful decoding is not required . The received part can be decoded, increasing the overall video quality according to the rate-distortion curve of the EL as described in  .
The most widely used scheme, in order to packetize MPEG-4 video streams, is ﬁxed-length packetization, where video packets of similar length are formed. The packet size of video stream is also related to eﬃciency and error resiliency because a smaller packet size for example requires a higher overhead but has a better performance in error prone networks. By evaluating the expected loss impact of each packet to the end-to-end video quality, by assign priority to each packet according to its importance in video sequence. With assigned priorities, the packets are sent to underlying network and receive diﬀerent forwarding treatments.
3.3 Testbed Conﬁguration
Eight YUV QCIF 4:2:0 color video sequences consisting of 300 to 2000 frames and coded at 25 frames per second are used as video sources. Each group of pictures is structured as IBBPBBPBB. and contains 25 frames, with maximum UDP packet size of 1000 bytes (payload only). The Microsoft MPEG-4 FGS encoder/decoder is used for encoding YUV sequences. A number of background ﬂows is transmitted in the network, in order to lead the DiﬀServ/DVB system in congestion. The background traﬃc is always running and is assigned to the BE BA. The latter BA has always the following characteristics: Poisson distribution with 1472 bytes packet size and constant rate of 8 Mbps. Correspondingly, EF BA is generated at 3Mbps rate and each AF1x BA at 2Mbps rate. The assigned bandwidth to AF1x BA is equally segmented to support three-drop percentages, which are 2% for AF11, 4% for AF12 and 6% for AF13.