The new multimedia applications


Quality of Service (QOS)

Over the years new multimedia applications are appearing over the Internet, demanding particular QoS requirements, such as bandwidth, delay, jitter, packet loss and reliability, which must be taken into account when selecting paths. Different QoS architectures, such as DiffServ and IntServ, are proposed to meet these QoS requirements. A key aspect in these QoS architectures is the routing process, i.e., how routes are computed, selected and established.

Traditional IP routing algorithms, which are based on the best-effort transmission model, select routes according to the shortest path routing. These algorithms select the path that optimizes the sum of a single value, such as hop count or delay along the selected path. This routing model is not suitable in a QoS environment. When a certain guarantee is required for sending a particular traffic flow, routing algorithms must add some QoS attributes to the path selection process. Unlike shortest path based routing algorithms, QoS routing algorithms select that route which more precisely meets multiple QoS requirements. Basically, the main goal of QoS routing is to find a route for a particular traffic flow with certain QoS requirements conforming to the QoS cost parameters, which specify the available resources in the network (i.e., conforming to the network resources that can be used to support the incoming traffic request). These QoS requirements may be bottleneck requirements, such as bandwidth, or additive requirements, such as end-to-end delay, in which case the QoS routing process looks for that path that guarantees a minimum available bandwidth or an end-to-end delay bound respectively. In order to perform this route evaluation and selection, the link state databases are extended to include information on available resources, and are often referred to as Traffic Engineering Databases (TED). In addition to QoS guarantees, there are some other widely sought solutions to common networking challenges that can be perfectly synthesized with the above mentioned goals: optimisation of network utilization, load distribution, the number of paths successfully routed, etc. There is currently a concerted effort in the networking community to achieve all of these objectives. In addition to these algorithms there are other works in the literature aiming at addressing special important sub-problems in QoS routing, such as QoS routing in the context of bandwidth and delay, which is not NP-complete. Even if the end-to-end connection could be established satisfactorily, it is unlikely that all the remaining components are going to have excess capacity. Traffic always expands to fill the excess. So how can the traffic cross the Internet without suffering delays?

Content Delivery Networks (CDNs) mean that files no longer have to be served right across the Internet. Instead, content is delivered from servers placed at the edge of the Internet in your local point-of-presence. This edge serving makes for a much better viewing experience, without all the problems that packet loss and delays can cause as clips transit the Internet routers.

(A basic content delivery diagram)

As the bottlenecks are removed and the performance of streaming improves, more companies will want to use rich media, so the traffic will grow and congestion will increase. The improvements will have to continue at a pace to keep up with ever-increasing demand; it is just like building a highway network - traffic expands to meet the capacity and is regulated only by congestion.

The H.264 error-resilience

The IEEE 802.11 family of specifications simplify the access to private networks and the Internet by developing wireless interfaces that effectively use the free electromagnetic spectrum available in most countries, providing high bandwidth at a very low cost. It was the DCF mode available in the 802.11b standard that has pushed forward the generalized use of wireless ad-hoc networks. These networks, called MANETs (Mobile Ad-hoc Networks) have intricacies that make them different from what can be expected in other networks, such as IP LANs, WANs and even cellular networks. Hence performance of H.264 in error prone environments, is exceptional in regards all previous codecs.

Error-resilience mechanism on H.264

In H.264 there was a back to basics approach, were a simple design using well known blockcoding schemes was used. In the design of this codec, the Video Coding Layer was separated from the Network Adaptation Layer in order to enable a modular development of each of its components. Due to its general purposed nature there is a need to include mechanisms that are able to get good performance in error prone environments such as wireless networks or the Internet. H.264 makes available error resilience mechanisms both on the encoder and on the decoder side. In the encoder we can find several parameters that can be tuned so that a trade-off between compression rate and error resilience can be made targeting different type of problems found in heterogeneous environments.

Most commonly used methods for error-resilience:

  • Insertion of intra-coded pictures
  • The Macroblock Line Intra Update
  • Use of slices
  • Flexible Macroblock Ordering (FMO)
  • Rate Distortion Optimization

(To start off with the research part first we will discuss and analyze some of the previous work done in this area and then introduce new proposed algorithm.)

An Adaptive Cross-layer Mapping Algorithm

To support the varying Quality-of-Service (QoS) requirements of emerging applications, a new standard IEEE 802.11e [1] has been specified. This algorithm is supposed to adapt itself according to the requirement of network usage. The 802.11e standard defines four access categories (ACs) that have different transmission priorities. The transmission priority is the probability of successfully earning the chance to transmit when individual ACs are competing to access the wireless channel; the higher the transmission priority, the better is the opportunity to transmit.

MPEG-4 video structure

The MPEG-4 standard defines three types of video frames for the compressed video stream, including I (Intra-coded) frame, P (Predictive-coded) frame, and B (Bi-directionally predictive-coded) frame. The MPEG I frame is encoded independently and decoded by itself. Thus, the I frame is just a frame coded as a still image, without any relationship to any previous or successive frames. The P frame is encoded using prediction from the preceding I or P frame in the video sequence. Thus the P frame requires the information of the most recent I frame or P frame for encoding and decoding. The B frame is encoded using predictions from the preceding and succeeding I or P frames. According to the coding relation, in MPEG-4 video stream the most important video type is the I frame, with the P frame being more important than B frame.

The video sequence can be decomposed into smaller units, GOP (Group Of Picture), similar to a deterministic periodic sequence of frames (as shown in Figure 1). A GOP pattern is characterized by two parameters, G (N, M): N is the I-to-I frame distance and M is the I-to-P frame distance. For example, G (9, 3) means that the GOP includes one I frame, two P frames, and six B frames. Similarly, the second I frame in the figure marks the beginning of the next GOP. The arrows indicate that the B frames and P frames decoded are dependent on the preceding or succeeding I or P frames.

Static Mapping

To support QoS transmission of video over a wireless network, a cross-layer design architecture has been proposed. As shown below, the researchers proposed a mapping algorithm, based on the traffic specification of IEEE 802.11e EDCA, and encoded H.264 video data is allocated into different precedence AC queues according to the video coding significance. However, the mapping is static and not adaptive. When the network load is light, the video data which is mapped to lower priority AC will result in unnecessary transmission delays and packet losses. on the other hand if MPEG-4 video streams are transmitted as the traffic for the mapping algorithm proposed , the I frame will always be mapped to AC[2], while the P frame will be mapped to AC[1] and the B frame will be mapped to AC[0]. If the AC[2] queue is empty (which means the video traffic load is light) such a static mapping algorithm will result in unnecessary transmission delays as well as high packet loss if AC[1] and AC[0] are almost full at the same time.

Dynamic Mapping

This is a proposed adaptive cross-layer mapping algorithm for improving the MPEG-4 video transmission quality over an IEEE 802.11e wireless network. In the proposed cross-layer approach, MPEG-4 video packets are dynamically mapped to the appropriate AC based on both the significance of the video data and the network traffic load. By exploiting the cross-layer mapping approach, we could prioritize the transmission of essential video data and improves the queue space utilization.

To guarantee the quality of delivered video the proposed mapping algorithm dynamically allocates the video to the most appropriated AC at the MAC layer according to both the significance of video type and the network traffic load.

Furthermore, to support dynamic adaptation to changes in network traffic loads, we use the MAC queue length as an indication of the current network traffic load. According to the IEEE 802.11e specification, when transmitted over an IEEE 802.11e wireless network, MPEG-4 video packets are placed in AC2 category which has better opportunity to access the channel than lower priority ACs. The tradeoff is, when the video stream increases, this queue rapidly jams and drops occur. For this reason, the proposed mapping algorithm re-arrange most recently received video packets into other available lower priority queues, while the AC2 queue is getting filled. We adopted two parameters, threshold_low and threshold_high, to predicatively avoid the upcoming congestion by performing queue management in advance. The integrated function to introduce these two parameters in the algorithm is in the following expression:

In this function, the original predefined downward mapping probability of each type of video frame, Prob_TYPE, will be adjusted according to the current queue length and threshold values, and about the result is a new downward mapping probability, Prob_New. When a video data frame arrives:

The proposed adaptive cross-layer mapping algorithm

In the mapping algorithm shown above, when a video packet arrives, first the queue length of AC2 is checked and compared against a set of threshold values, threshold_high and threshold_low. If the queue length is lower than the lower threshold value, threshold_low (light load), the video data is mapped to AC[2] (no matter what type of video data is being transferred). But if the queue length is greater than the upper threshold value, threshold_high (heavy video traffic load) the video data is directly mapped to lower priority queues, AC[1] or AC[0]. However, while the queue length of AC[2] falls within threshold_high and threshold_low, the mapping decision is determined based on both the mapping probability (prob_TYPE) and the current buffering size condition of the queue as given by formula (1). Hence, the video data packet will be mapped to AC[2], AC[1] or AC[0] according to the calculated downward mapping probability. By exploiting such a priority scheme and queue length management strategy, the transmissions prioritized and the drop rate of video minimized, along with efficient utilization of network resources.

Simulation topology

To evaluate the performance of our proposed cross-layer mapping algorithm, authors have conducted simulations using a widely adopted network simulator NS-2, and integrated with EvalVid. The results of the proposed mapping algorithm are compared with the results derived from IEEE 802.11e EDCA [1] and the static mapping algorithm in [2].

There are two kinds of scenario in the simulations for evaluating the video transmission performance:

  • Scenario 1: in this case only video stream is transmitted from the video sender node to the video receiver node. In this scenario, the performance evaluation focused on the queue space utilization by witnessing the queue length variation of each AC.
  • Scenario 2: in this case we used light and heavy loading cases, including different loads of voice traffic (64k, in AC [3]), CBR (in AC [1]), and TCP (in AC [0]). Traffic flows were randomly generated and transmitted over the entire simulation environment. In this scenario, we analyzed the received video quality to evaluate the efficacy of our proposed scheme under various network loading conditions.

Simulation Results

In this simulation, we will observe the mapping of video packets in MAC layer. In the simulation, there are three mapping algorithm, including IEEE 802.11e [1], static mapping [2], and dynamic mapping [3].

There are five parameters of the simulation. The first is the choice of mapping algorithm (0: IEEE 802.11e, 1: static mapping, 2: dynamic mapping). The follow four mean the numbers of traffic flows of AC[3], AC[2], AC[1], and AC[0]. In this simulation, we give two video flows to transmit in IEEE 802.11e network without other traffic. Then, a new file (queuelength_choice_0_voice_0_video_2_FTP_0_CBR_0.txt) is created. This file is the trace of the queue length. First field is the time stamp. The next four steps are the queue length of AC [3], AC[2], AC[1], and AC[0]. Then, you can change the mapping algorithm to static and dynamic by setting the parameter of mapping choice. Both the static and dynamic mapping algorithms use three queues (AC[2], AC[1], and AC [0]) to transmit video packet. The dynamic mapping provides better utilization of high priority queue than static mapping.

Part II. Four traffic flows

In order to evaluate performance of different mapping algorithm, we give light load and heavy load in the simulation. In light load, there are 5 voice flows, 1 video flow, and 1 CBR, 1 TCP. In heavy load, there are 1 voice flow, 3 video flows, 1 CBR, and 1 TCP.

Light load

By comparing the traces of sending and receiving, we can find the loss of packet and video frame. Moreover, the video quality is also evaluated by the Decodable Frame Rate (Q). The result shows that the total number of loss video frame is 0. The Decodable Frame Rate is 1.00.

Heavy load (1) ./ns 802_11e.tcl 0 1 3 1 1

(Because all steps are in the same for light and heavy load, we skip the step figures for heavy load.)

The average PSNR and number of frames lost (heavy load)


Above Cross layer architecture for video transmission over IEEE 802.11e WLAN with AEDCA scheme has performed well in evaluation test, IDR delay, IDR loss rate, Partition A delay and its loss rate reduced significantly. Parameters determining data flow rate (latency and throughput) were also noticeably improved. Experimental results showed that proposed architecture performed better over EDCA and AEDCA in improving video quality.

OSPF Based Load Sensitive QoS Routing Algorithm

Here authors have introduced a different algorithm where they will be concentrating on Open Shortest Path First (OSPF) routing scheme.

According to this scheme a better way of implementing QoS routing is to confine the routing change information to the region where QoS has deteriorated. This reduces the protocol overhead and convergence time of the algorithm. In this paper a load sensitive routing (LSR) algorithm based on Dijkstra's shortest path algorithm has been used and tested.

Following are the advantages of LSR algorithm:

  • Better average performance: The LSR algorithm tries to find alternate path to route packets when there is congestion in the OSPF path. Hence, packets get better QoS in terms of delay, jitter and packet loss.
  • Less overhead and scalability: This algorithm does not use flooding mechanism to communicate congestion of a link. Rather the congestion notification is only contained to the neighbours of the node. Thus, it has less overhead and it can scale easily to large networks.
  • Coexistence with OSPF router: It can be implemented easily with an extension to the framework of OSPF standard by creating a new LSA type. Routers running this algorithm can coexist with routers running vanilla OSPF).

  • Loop free property: Since alternate next hop is chosen based on next hop property of OSPF routing, LSR algorithm is loop-free. Hence there is no need for loop detection mechanism.



We model a network consisting of N nodes. A node i is identified by its id Node(i) (0 = i < N). Nodes in a network are connected by physical links along which packets can be transmitted. Node(i) and Node(j) are considered neighbours of each other if there is a physical link between them. The physical link between them is identified by the Link(i, j). Cost of transmitting a packet over Link(i, j) is denoted by Cost(i, j).


A. When Node(i) detects congestion on Link(i, j) it sends Congestion(i, j) message to all its neighbour except Node(j) and setup LSR routing for all destinations for which OSPF next hop is Node(j).

B. When Node(k) receives congestion message Congestion(i, j), it executes the following: (Note that since Congestion message is only sent to neighbouring nodes, this means that Node(k) is a neighbour of Node(i))

B1 Congestion_Notification(i, j)

B2 {

B3 Let D = {set of all destination nodes in the routing table RT(k, k) for which Node(i) is theOSPF next hop node};

B4 Let D' = {Node(p) | (Node(p) ? D) and (Node(j) is the OSPF next hop node in the routing table RT(k, i)for destination node Node(p))} /* D' contains all the destinations for which packets * forwarded from Node(k) to Node(i) would go * out on congested link Link(i, j) */

B5 for each node Node(p) ? D' do { /* find all the nodes eligible for LSR forwarding for * destination Node(p) */

B6 R = {set of all neighbouring nodes of Node(k)} - {Node(i)};

B7 Q = {};

B8 For each node Node(q) ? R do {

B9 if ( inequality (8) holds ) { /* substitute p for r, k for p and q for q in (8) */

B10 Q=Q+{Node(q)}; /* Node(q) is an eligible LSR node */

B11 }

B12 } /* end of for each node Node(q) */

B13 while ( Q != {} ) do {

B14 Node(r) = a randomly selected node in the set Q;

B15 If (LSREntry(k, r) == {Node(r), Node(p)}) { /* Node(r) is sending LSR packets destined to Node(p) * to this node Node(k), so do not send packets for * destination Node(p) to Node(r) to avoid looping */

B16 Q = Q - {Node(r)};

B17 } else break;

B18 } /* of while */

B19 if (Q == {}) continue;

B20 Send Reroute Request(i, j, k, p) message to Node(r);

B21 Set the next hop node of Entry(Node(p), k, k) to Node(r);

B22 Set the LSR flag of Entry(Node(p), k, k) to TRUE;

B23 } /* for each node Node(p) */

B24 } /* Congestion_Notification() */

C. When Node(r) receives RerouteRequest(i, j, k, p) from Node(k) it executes the following:

C1 Process_RerouteReq(i, j, k, p)

C2 {

C3 if ( (next hop of Entry(Node(p), r, r) is Node(k) ) &&

C4 (LSR flag of Entry(Node(p), r, r) is TRUE)) { /*Node(r) is temporarily routing packets destined for Node(p) * to Node(k) due to LSR algorithm, a direct loop detected */

C5 if ( Node(r) > Node(k) ) { /* Fall back to OSPF routing */

C6 set next hop of Entry(Node(x), r, r) to OSPF next hop of Entry(Node(x), r, r);

C7 set LSR flag of Entry(Node(x), r, r) to FALSE;

C8 }

C9 }

C10 set LSREntry(r, k) = {Node(k), Node(p)};

C11 } /* Process_RerouteReq() */

D. When Node(i) detects that congestion is over on Link(i, j), then it sends CongestionOver(i, j) to all its neighbours except Node(j).

E. When Node(k) receives CongestionOver(i, j), it does the following:

E1 Process_Congestion_Over(i, j)

E2 {

E3 Let D = {set of all destination nodes in the routing table RT(k, k) for which Node(i) is the OSPF next hop node};

E4 Let D' = {Node(p) | (Node(p) ? D) and (Node(j) is the OSPF next hop node in the routing table RT(k, i) for destination node Node(p))} /* D' contains all the destinations for which packets * forwarded from Node(k) to Node(i) * would go out on congested link Link(i, j) */

E5 for each node Node(p) ? D' do {

E6 if ( LSR flag of Entry(Node(p), k, k) is TRUE ) { /* This entry in RT(k,k) is doing LSR routing, reset it back * to OSPF routing */

E7 Node(r) = next hop node of Entry(Node(p), k, k);

E8 Set next hop node of Entry(Node(p), k, k) equal to OSPF next hop;

E9 Send RerouteOver(i, j, k, p) to Node(r);

E10 } /* if

E11 } /* for */

E12 }

F. When Node(r) receives RerouteOver(i, j, k, p) from Node(k), it deletes entry LSREntry(r, k).

Performance evaluation

In this section, we evaluate the performance of LSR algorithm. We compare performance of LSR algorithm when it uses different methods of calculating LSR coefficients and also against OSPF

Topology of the Simulation Network.

algorithm to route packets and measured various performance parameters. The simulation is written in C and run on a SUN/Solaris environment.


The topology of our simulation is shown in Figure 1. There are ten nodes in the network. Costs of direct paths between nodes are shown in the figure. Cost of the links are assigned using the rule given in [3] as follows.


It is clear from the plot that the average delay for LSR algorithm using LSR_a, LSR_b and LSR_ab coefficients are all much better than that for OSPF. Delay for LSR_ab is the lowest among the LSR method However, delay of LSR_ab method is very close to that of LSR_a method because the number of APs in those two methods are close to each other. As load increases performance of all the LSR methods becomes even better than that of OSPF

In these cases all LSR algorithms perform better than OSPF.

A MAC centric Cross Layer approach for H.264 video streaming

In this paper, authors have focused their efforts on H.264 video standard over wireless. Here a new ARQ scheme for H.264 video streaming over wireless networks is proposed. This new ARQ uses the information passed from H.264 encoder in order to achieve unequal error protection of video contents at the link layer. Basically, what it does is it assigns deadlines to packets according to the individual importance of each video packet and drops those that exceed their deadlines so on and so forth thus making it another viable approach.

H.264/AVC architecture is composed of two layers: a Video Coding Layer (VCL) and a Network Abstraction Layer (NAL). The later one has been designed in order to provide simple and efficient conveyance for a broad range of network transport protocols, such as RTP (Real Time Protocol), as well as for storage media, like ISO MP4 and MMS. The fundamental processing unit of the network abstraction layer is the NALU (NAL Unit). The NALU could contain video parameters or video data. In the latter case, each NALU will encapsulates a video data unit named slice, which is basically a given number of Macro-Blocs associated to a video picture samples. The second layer which is Video Coding Layer, is the core compression engine. Compared to MPEG-4, H.264/AVC standard can maintain acceptable video quality with up to a 50% reduction in file size, making by this way H.264/AVCideally suitable for video transmission in a bandwidth limited networks (light load & heavy load). In particular, when considering wireless networks.

Performance evaluation

In order to evaluate the performance of suggested architecture the video sequence is encoded with the H.264/AVC video coding reference software, namely JM , After that, the encoded stream is parsed and the obtained, trace file is used as input to the UMTS/HSDPA simulator. Using the output file of the UMTS/HSDPA simulator, we generate a list of missing IP packets. All the NALUs transported in missing IP packets are removed from the received video stream. The obtained distorted video stream is then decoded and the video quality of the obtained sequence is measured using the PSNR (Peak Signal to Noise Ratio) metric averaged over all frames in the sequence.

Here a UMTS/HSDPA network is simulated with EURANE extension to NS-2 simulator. EURANE models the UTRAN in detail, whereas the nodes SGSN and GGSN are just regular ns-2 nodes used to route IP packets from the Internet to the UTRAN and introduce some delays. In particular, in EURANE all the functions of the RLC (Radio Link Control Protocol) and MAC-hs (MAC in HSDPA) layers are implemented. There are per-flow queues in the RNC and a credit-based algorithm flow control between Node B and RNC. The MAC layer implements the HSDPA scheduler and other functionalities like HARQ. The underlying physical layer is modelled in detail and this model is used to compute a Channel Quality Indicator (CQI) which is feedback from UEs to the base station. Our solution is implemented on the RLC.

We are making a single-cell environment, in which 4 User Equipments (UEs) connect to the Node B via a High Speed Downlink Shared Channel (HS-DSCH). The Node B is connected to the RNC, which itself is connected to the Internet via the 3G-SGSN and 3G-GGSN of the cellular system's core network. The UEs establish a data connection with a host in the Internet. In order to alleviate the impact of scheduling algorithms, all UEs are moving on circles at a distance d from the node B, where d varies from 200 to 800 meters. In order to obtain valid statistical results, all results shown in this section are the average of 10 simulations runs.

This mechanism, refereed as CA-ARQ (for Content- aware ARQ), is compared to three other mechanisms:

  • Fixed deadline mechanism, in which all packets in the video stream are given the same importance and deadline values. In this mechanism, FMO is not used;
  • Fixed deadline with FMO mechanism, in which all packets in the video stream are given the same importance and deadline values and the FMO dispersed scheme is enabled;
  • GOP-based deadline mechanism, in which all packets in the same frame Xn are given the same importance. Moreover, FMO is not used for this mechanism.

(PSNR video quality with T = 1000 ms: Quality is considered as poor if PSNR is under 25 dB)

(PSNR video quality per frame for UE distance from Node B of 450 meters: peaks in CA-ARQ curve are relating to I frames)

(Packet loss ratio per slice group and position in the GoP with distance from Node B of 600 meters)

In the figure below , two original frames and their respective decoded frames using the Fixed deadline and CA-ARQ mechanisms have been illustrated, respectively. The error pattern used in the two mechanisms is the same.

We can see that using the Fixed deadline, the impact of error is a large area and that the error concealment mechanism fails to bring up the video quality. However, using CA-ARQ the MBs losses is reduced and visually it is clear that the video quality is better.


In this paper authors proposed and analyzed a new MAC level content-aware ARQ scheme for video streaming over wireless links. The proposed scheme assesses the importance of each packet using the FMO tool, which is a new error robustness tool of H.264 video encoding standard. Temporal values are then given to video packets in respect of their importance. Simulations showed that their content aware ARQ mechanism achieves unequal error protection and outperforms all simulated mechanisms.

Novel Architecture for reliable H.26L video transmission over IEEE 802.11e

In this proposal, researchers established an association between the TC and the H.26L stream based on the NALU's NRI field.

Network Abstraction Layer

The Network Abstraction Layer of JVT video, defines the interface between the video codec itself and the outside world. It operates on Network Abstraction Layer Units (NALUs) which gives support for the packet-based approach of most existing networks.

Parameter Set Concept

One of the key problems of robust video transmission in packet loss environments results from the layered nature of all current video coding standards. Information in the slice/picture/GOP (Group of pictures)/sequence headers is necessary for the reconstruction of the whole slice/picture/GOP/sequence, but traditionally coded only once at the start of each Slice/picture/GOP/sequence in order to save bits. A loss of a packet containing a header renders all following packets containing data that rely on the lost header useless. Therefore, a fundamentally new approach was taken in H.26L/JVT video.

IEEE 802.11e and its enhancements

The need for a better access mechanism with an aim of providing service differentiation has led task group E of the IEEE 802.11, working group come up an extension to the IEEE 802.11 standard called 802.11e. The QoS support is realized with the introduction of Traffic Categories (TCs).

Network architecture

The network architecture used is shown in Figure below, to simulate a unicast service provided by the server attached to the node server. The server sends H.26L stream to the client attached to node Client. Here authors have included three ftp data traffics over TCP (with no Ack) to overload the wireless network.

( The network architecture)

Proposal of a reliable transport of H.26L video stream over IEEE 802.11

Commonly, H.26L uses hierarchical coding for resolving scalability and heterogeneity issues. Based on the idea that coding will be in quality hierarchy form, where the lowest layer of hierarchy contains the minimum information for intelligibility. Succeeding layers of the hierarchy adds increasing quality to the scheme.

To distinguish between the traffic categories, we will use different CW and AIFS. These values are chosen according to traffic category's priority.

(Architecture concepts)


(Parameter set information packets loss)

The traffic used here is a simulated multimedia H.26L traffic. In our simulation, the H.26L video stream was obtained by using three elementary streams, plus a stream which represents the Parameter set information Parameter set information was generated according to CBR (Constant Bit rate) traffic.

In addition, three video streams were generated which corresponds to:

  1. The first stream is thH.26L base layer video stream, it offers minimum QoS,
  2. The second stream is the H.26L enhanced layer 1 stream, it improve minimum QoS to offer medium QoS,
  3. The last stream is the H.26L enhanced layer 2 stream, it improve the two precedent streams to propose maximum QoS illustrates the packets loss percentage of the base layer stream (minimum QoS).

From above we can notice that the two mechanisms give practically the same packet loss percentage. In fact, the mean packets loss is about 8% for the two mechanisms. We can see that DCF gives a better performance then EDCF, this is due to the fact that DCF makes no difference between the different streams Contrariwise, in EDCF this stream have less priority then the base layer stream, and Parameter set information. The Fig. 9 presents the end-to-end delays of the base layer stream, it is clearly seen that EDCF outperforms DCF, where the mean packets delay is roughly 0.35 s with DCF, and only about 0.25 s when using EDCF marking algorithm. The Fig. 10, illustrates the end-to-end delay of the two enhanced layer stream, we also notice that EDCF have harmful performance then DCF, this is due to the same raisons cited for the packets loss.


In this paper, authors presented a novel approach for a reliable transport of the H.26L video over wireless channels, by combining the H.26L's hierarchy encoded stream and the new proposition of the IEEE 802.11e group. The simulations have shown that the proposed scheme achieves considerable improvement than DCF, particularly on minimizing packet loss of sensitive video data (as to know Parameter set information). Further, a significant reduction of the end-to-end packet transfer delay is obtained. The proposed marking scheme better takes into account the characteristics of the hierarchic encoding of the H.26L and, the differentiation mechanism given by the IEEE 802.11e network.

(So far we have analysed a lot of different algorithms and seen different results, where each one exceeds the boundaries hence now we will be testing a new mechanism all together and show its results under heavy load and light load environment.)

Adaptive 2-stage Cross-Layer architecture for scalable video transmission in wireless network

Adaptive 2-stage Cross-Layer FEC mechanism

As technologies are rapidly changing in this fast moving world of digitally enhanced communication and data services over wireless networks, service providers have to overcome diverse challenges in design and pattern of cross layer architecture to make it feasible and future oriented. These requirements are hard to overcome due to limitations which are imposed by burst packet loss, channel fluctuation and limited QoS support on wireless networks as well as bandwidth-intense, loss-tolerant and delay-sensitive characteristics of the video streaming. Therefore adding to the advancements of increasing demand of high quality data transmission, here we have introduced a new mechanism which we combine the properties to different mechanism and make it an improved version of Forward Error Correction (FEC) mechanism, Which according to our study is much better in delivering rich content media at very low cost and is easy to implement in a network. The FEC scheme overcomes the issue of packet loss by introducing redundant data that consume additional network resources. Traditionally, the FEC function is implemented on the application layer the redundancy rate is either static or controlled by application-layer programs hence the conventional FEC approaches, however, may not effectively recover lost packets, since they fail to capture the real-time network conditions and to adjust the redundancy rates accordingly. Dynamically manipulate the redundancy rate. The FEC scheme has been adopted to overcome packet errors/losses and to improve the quality of video delivery. This functionality gets realized by adding error-correcting information to the original data. The FEC is usually performed at the byte level and at the packet level. The byte-level FEC recovers bit errors in one packet, and functions on the physical layer of WLANs. To accomplish the goal, introduced in this study is an Adaptive Cross-layer FEC mechanism (ACFEC), which is to enhance the quality of video streaming over 802.11 Wireless Local Areas Networks (WLANs). In this research we are proposing an adaptive two-stage FEC scheme with an enhanced MAC protocol. The reasons we choose to study FEC is because a wireless network is usually multihop and multiple re-transmissions and it would result in unpredictable delay and jitter at the application layer, therefore in this mechanism We enhance the MAC/PHY layers to efficiently support multimedia flows by using both header CRC and FEC. We Are also modifying the protocol stack so that it should not drop the errors instead it should deliver them to the application layer.

Proposed Cross-Layer Architecture

Unlike other proposed architectures our proposed FEC mechanism is implemented at the application layer Whenever a packet is passed down to the next protocol layer, a header associated with that layer is added In this stack, UDP and IP provide source and destination IP addresses and port numbers of the communication pair to ensure correct delivery. Packets are dropped at the IP layer due to congestion or route disruption. On the other hand MAC/PHY protocols support adjacent host communications and have to deal with bit errors. Any bit error within a packet could result in the whole packet being dropped, even though the errors could be corrected in the application layer. To efficiently support multimedia applications, we slightly modify the protocol stack so that it can deliver packets with errors to the application layer by turning off CRC checksum function in the MAC/PHY layers. ). By accurately detecting packet losses and adjusting the redundancy rates accordingly, the number of FEC packets increases or decreases to meet the need of the receiver and to overcome the packet losses.

In stage 1, packet level FEC is added to the application layer packets to correct packet drops and in stage 2 a small amount of bit level FEC is added to recover bit errors from the MAC/PHY layers. At the receiver side, we first process the bit-level FEC; the bit errors from the MAC/PHY layers can be recovered. Then we pass the bit stream to the stage 1 FEC decoder for further correction. The 802.11 MAC layer defines two medium access coordination functions, basic distributed coordination function (DCF) and optional point coordination function (PCF). Since DCF can be used both in ad hoc and infrastructure modes while PCF can only work on infrastructure mode, we will focus on DCF mode in this paper. DCF is a distributed medium access scheme based on the most popular Carrier Sensing Multiple Access with Collision Avoidance (CSMA/CA) protocol. The current MAC mechanism of 802.11 LAN uses stop-wait ARQ (SW-ARQ) to transmit a packet. If a packet arrives at a node with an empty queue and the medium has been found idle for an interval of longer than a distributed inter frame space (DIFS), the node can transmit the frame immediately, and the successful transmission of the packet is confirmed by an ACK packet. Therefore, both the packet itself and the feedback ACK must be successfully transmitted.

The header part of each protocol layer is crucial, because if header has some errors in it, usually the whole packet is useless. We use header CRC and header FEC to enhance the MAC/PHY layers to efficiently support multimedia delivery. We slightly modified the 802.11 MAC/PHY layer packet CRC mechanisms to check if there is something wrong within the header part as shown in Figure below. The packet is dropped if the header CRC fails.

Even if a BCH code is applied to each packet payload, the curve with payload FEC still drops at high bit-error rate. This is because the whole packet is being dropped due to header FEC decode failure. Bit level in packet FEC protection cannot correct packet losses. Thus, we need to have a scheme to correct both bit errors and packet drops. We propose a two-stage FEC scheme to solve the problem as shown in Figure below.

In stage 1, packet level FEC is added across application layer packets to correct packet drops due to congestion or route disruption. We use RS codes for stage 1 FEC.

In stage 2, FEC is processed within each application packet, and a very small amount of bit-level FEC is added to recover any bit errors from the MAC/PHY layers. We use BCH codes for stage 2 FEC.

Here we are going to compare the protection performance of our proposed schemes with traditional application layer FEC scheme to check the residual packet error rate. The proposed two-stage FEC scheme significantly outperforms the conventional 802.11 Scalable video coding and FEC design. The wireless channel is time varying, error prone, and usually bandwidth constrained. A distinct characteristic of wireless communications is its large variation in bandwidth and packet loss rate compared with the conventional fixed-bit-rate video or multi-layer approach that only supports a discrete number of bit stream layers, scalable video coding is more suitable for wireless communications, since a scalable video bit stream can be almost continuously tailored to the time-varying channel characteristics. In this research, we use the fully scalable coder MC-EZBC10 to evaluate our proposed adaptive 2-stage FEC scheme, in conjunction with an enhanced MAC protocol.

MC-EZBC coding

MC-EZBC is a highly scalable motion-compensated subband/wavelet video coder with high compression performance, rivalling that of the unsalable coding standard H.264. It produces embedded bit streams supporting a full range of scalabilities. In this version of the coder, neighbouring frames are decomposed using a motion-compensated Haar filter bank to produce the temporal low frequency bands (solid lines) and temporal high frequency bands (dashed lines) at the next lower level. This process is repeated until we obtain the MC average of all 16 frames in the GOP, which is at the bottom of the temporal pyramid. Video data in this case has five temporal scalability layers, going from full frame rate down to LLLL-level at 1/16 of full frame rate. Temporal subbands are then subject to spatial subband/wavelet analysis and encoded using a version of the EZBC coding algorithm, details of which are given in.10 The bit stream sequence is organized in an embedded fashion. Each GOP coding unit consists of independent bit streams {QMV, QY UV}, where QMV denotes the bit stream for the motion fields and QY UV for the subband coefficients of colour components Y, U, and V of the video. The motion vector code stream is embedded in frame rate. The remaining bit stream is fully embedded in quality/bit-rate, spatial resolution, and frame rate. Such a scalable bit stream is especially suitable for mid-stream adaptation and can be adapted to different frame rates, SNRs, and resolution according users' requirements. For simplicity, we only consider SNR or bitrate scalability in this paper. Scaling in term of quality is obtained by stopping the extraction process at any point in the bit stream. To achieve a certain bitrate, we simply stop extracting bits when that bitrate is reached.

FEC design

Since the wireless channel is time varying, the effective video bit rate correctly received at the receiver side is a random variable. The 802.11 wireless LAN MAC layer uses SW-ARQ to ensure packet delivery. Therefore, a sender can easily estimate its sending rate based on the ACKs. A video system is time sensitive, so excessively delayed packets are useless. The advantage of the scalable encoded bit stream is that it can be chopped at any point to match very well with the bandwidth varying channel: the more bits the receiver gets, the better the video quality. In this paper, we use MD-FEC11 as stage 1 FEC to protect the MC-EZBC video bit stream.

FEC Adaptation

To efficiently protect packets from losses and to match the available sending rate, adaptation is needed for FEC design. The FEC codes cannot only correct errors, but also detect errors. The receiver estimates the loss behaviour of the channel and feeds back the result to the sender. Two types of loss information are sent back to the sender. The packet loss information is fed back regarding stage 1 FEC design for each GOP. This loss information does not include packet drops due to FEC correction failure. Since bit errors in the packet can dramatically affect the application layer loss rate, stage 2 bit-level FEC uses a Step-Increase-Step-Decrease (SISD) method.


The NS-2 simulator

To evaluate the performance of our proposed scheme in terms of effective application layer throughput and video PSNR, we perform several simulations to compare our two-stage FEC plus enhanced MAC protocol with the conventional 802.11 based method. The network simulator ns-2 wireless module is used to evaluate the proposed FEC mechanism, and to compare it with the static FEC mechanism and the RED-FEC mechanism. The static FEC mechanism generates a fixed number of redundant packets for each source data block. In order to correctly simulate the RED-FEC mechanism in NS-2; we have referred to "NS-2 Adaptive FEC Tool" and RED-FEC Mechanism for Video Transmission.

(FEC Packets on Light Load)

(FEC Packets on Heavy Load)

(PSNR on Light Load)

(PSNR on Heavy Load)

(Light Load at a 0.206 Loss Rate)

(Heavy Load at a 0.206 Loss Rate)


In this study, we have proposed an Adaptive 2-stage Cross-Layer FEC mechanism to enhance the quality of video streaming over 802.11 Wireless Local Area Networks fewer than two different conditions i.e. light load and heavy load and as we can see from the results that our mechanism outperformed in both the environment irrespective of totally different scenario. Thought our most study is said to be concentrated on light load traffic as it requires better QOS than heavy load, but we can say that this mechanism can be used at various platforms, irrespective of nature and requirement. Our proposed FEC mechanism leverages the functionalities of different layers. The Automatic Repeat request (ARQ) function is applied on the MAC layer to detect lost packets. Through cooperation with the UDP protocol, the redundancy rates are adaptively controlled based on the loss information. The experimental results demonstrate that our FEC mechanism adaptively controls the redundancy rates to overcome channel fluctuations, and achieves, under various network conditions, a higher recovery than other conventional methods, while generating a much less volume of redundant traffic.

Please be aware that the free essay that you were just reading was not written by us. This essay, and all of the others available to view on the website, were provided to us by students in exchange for services that we offer. This relationship helps our students to get an even better deal while also contributing to the biggest free essay resource in the UK!