cross layer design to achieve QOS

7/28/2019 cross layer design to achieve QOS

1/22

CROSS LAYER DESIGN IN HETEROGENEOUS NETWORK FOR QOS SUPPORT

DEPARTMENT OF COMPUTER SCIENCE BEC, BAGALKOT Page 1

1. INTRODUCTION

Cross-Layer design has been the focus of several recent research efforts. Due to the highly

variable nature of the links used in wireless communication systems and the resource-poor nature of

the wireless mobile devices, there have been multiple research efforts to improve the performance of

the protocol stack by allowing cross-layer interaction in wireless systems. Cross-layer interaction

means allowing communication of a layer with any other possibly non-adjacent layer in the protocol

stack. Several issues related to the cross-layer design paradigm need to be addressed before it can

achieve its promises. One of these issues is to have a well defined framework that manages the

interaction between the different layers of the protocol stack, such that the modularity of the stack is

preserved while still achieving the flexibility and adaptability which cross-layer design promises.

This seminar addresses this issue by proposing a cross-layer coordination framework for next

generation wireless systems. The proposed framework enables the interaction between non-adjacent

layers in a systematic organized way while preserving the modularity of each layer. We believe that

the existence of such a framework will ease the development of cross-layer design schemes.

Figure : OSI Protocol Stack


2/22


3/22



Bandwidth limitation and fluctuations:

It is known that the throughput of a wireless channel may be reduced due to multipath fading,

co-channel interference, and noise disturbances. The capacity of a wireless channel may fluctuate

with the changing distance between the base station and the mobile host. In the meanwhile, the

network provides best-effort service and it does not provide Quos (Quality of Service) guarantee for

services. Specifically, network conditions and characteristics such as bandwidth, packet loss ratio,

delay, and delay jitter vary from time to time. Considering the bandwidth fluctuation, it is important

to estimate the available bandwidth dynamically. Throughput calculation, bandwidth probing,

packet pair are several popular techniques for bandwidth measurement .

Considering the bandwidth limitation, especially for wireless channel, it is essential to

improve the bandwidth utilization. It is known RTP/UDP/IP and TCP/IP have the problem of the

large header overhead on bandwidth-limited links. Header compression has been proven to be

efficient for using those protocols. Unfortunately, existing header compression schemes do not work

well on noisy links, especially the one with high bit error rate and long roundtrip time.

Low performances for traditional transport-layer protocols:

It is known that traditional transport layer protocol assumes congestion in the network to be

the primary cause for packet losses and unusual delay. It will decrease the transmitting rate in the

case of packet lost. Unfortunately, packets are lost in wireless channel due to channel error rather

than congestion, thereby resulting in an unnecessary reduction in end-to-end throughput. For wireless

network itself, both the high BER and frequently occurred fading make packet loss ratio very high

during a TCP/UDP connection. Many works have been made to overcome the drawbacks of

transport protocols over wireless networks.

Different Quos requirements for different types of data:

In general, different kinds of media have different characteristics. Real-time media such as

video or audio is delay sensitive but capable of tolerating certain degree of errors. Non-real-time

media such as Web data is less delay sensitive but requires reliable transmission. Consequently,

unequal error control and priority-based scheduling schemes are needed for different types of media.

Cross layer communication framework helps different kinds of protocols to communicate

with each other without knowing the protocol or system architecture specification. It maintains a

parameter repository to manage the data format that these layers accept or produce. Cross layer


4/22



manager manages and co-ordinates the communication among different protocols by sending and

receiving the event messages between different types of protocols. The below figures such a cross

layer framework representation where the cross layer manages the communication between different

types of protocols by sending and receiving the event messages and using the state variables.

Figure : cross layer design for different transmission protocols

While the standard TCP/IP stack has worked well for wired links, it suffers from badperformance when used over wireless links. When compared with wired links, wireless links in

general have lower bandwidths available, higher transmission delays, and higher BERs, and suffer

from channel fading. There is not much that can be done at the protocol stack level to work around

the first two problems, and users learn to live with these limitations. Unfortunately, transport

protocols suffer severely from the consequences of the last two problems. Again, the widely used

TCP protocol is the primary example of this situation. On one hand, erroneous datagrams are

automatically dropped by the link layer, while TCP always interprets losses as a congestion signal.

Thus, the TCP congestion control algorithm decreases (usually by half) the congestion window and

enters the congestion avoidance state, where the congestion window grows linearly. The net result is

a significant reduction in effective performance, which the user does not understand, knowing the

advertised bandwidth of the network interface card. On the other hand, wireless links often

experience channel fading effects, consisting of fluctuation of the channel capacity over time. We

can distinguish between slow and fast fading according to its duration, which is usually related to the

speed of a mobile node's movement. Although fast channel fading has little impact on the

performance of TCP, when slow channel fading occurs several consecutive TCP packets are


5/22



dropped. Thus, TCP congestion control will inevitably and quickly lower the congestion window to

its minimum value. Unfortunately, due to the multiplicative decrease additive increase property

of congestion avoidance the congestion window is very slow to return to its original value therefore

fading occurred. Once more, the net result is a decrease .in effective throughput and, consequently,

underutilization of resources.

The future of mobile communication is heading towards ubiquitous Next Generation (NGN)

heterogeneous or 4G Networks. The 4G networks are intended to cater to seamless and fast handover

between applications to be used anywhere, at any time, using different access technologies. There is

an increased demand for faster, seamless and cheaper multimedia delivery over the wireless Internet.

The Next Generation wireless Networks will have an all IP-based architecture to support this

heterogeneity. Currently, the foundation of these heterogeneous networks is based on a strict layered

architecture referred to as the Open Systems Interconnect (OSI) Protocol stack. However, this OSI

Protocol stack presents various bottlenecks to the performance of real-time applications over the

Internet. Consequently, a different approach, called Cross Layer Design has been introduced to

optimize the performance of the Quality of Service (QOS) of these applications. This seminar

discusses the basic OSI protocol stack and its need for modification.

Cross-Layer design has been the focus of several recent research efforts. Due to the highly

variable nature of the links used in wireless communication systems and the resource-poor nature of

the wireless mobile devices, there have been multiple research efforts to improve the performance of

the protocol stack by allowing cross-layer interaction in wireless systems. Cross-layer interaction

means allowing communication of a layer with any other possibly non-adjacent layer in the protocol

stack. Several issues related to the cross-layer design paradigm need to be addressed before it can

achieve its promises. One of these issues is to have a well defined framework that manages the

interaction between the different layers of the protocol stack, such that the modularity of the stack is

preserved while still achieving the flexibility and adaptability which cross-layer design promises.

This seminar addresses this issue by proposing a cross-layer coordination framework for next

generation wireless systems. The proposed framework enables the interaction between non-adjacent

layers in a systematic organized way while preserving the modularity of each layer. We believe that

the existence of such a framework will ease the development of cross-layer design schemes.


6/22



3. KEY CHALLENGES

3.1 Real Time Application Requirements

Real-time applications have strict Qos constraints on bandwidth, delay and jitter. Although

the OSI protocol has been in existence for over 20 years, advancing technology and use of multiple

applications on the same protocol stack has led to increased bottlenecks in the performance of the

protocol model. Some of the bottlenecks experienced are: increased energy consumption,

unnecessary encapsulation and decapsulation, increased jitter and delay, unnecessary

retransmissions, reduced throughput and inability to meet different Quos requirements of different

applications running on same protocol. This seminar discusses the implementation of the cross layer

architecture to help speed up communication and provisioning of Quos requirements between the

layers of the OSI protocol stack. It proposes an extension to the design of the existing internet OSI

architecture that allows interaction between non-adjacent layers of the protocol stack. In particular, it

focuses on end-to-end user delay, prioritization and per-user throughput for a VoIP application.

3.2 Cross Layer Design Architecture

Figure : overview of cross layer coordination framework

Cross layer clients are added to each layer of the protocol stack to enable interaction with the

server (Manager). Parameters that characterize each individual layer are relayed to the client which

in turn communicates across the other layers through the cross layer server. When an event occurs

through the signaling scheme, a request is made to the server for particular information. The server in

turn relays relevant information to the particular layer making the request. This way, information can

be transferred across non-adjacent layers through the cross layer server.


7/22



Figure : Details of cross-layer coordination framework

In order to fully address all aspects of the framework, the following issues have to be

discussed in detail.

A. Cross-layer Client (to be added to each layer of the traditional protocol stack to enable thecross-layer coordination operation)

B. Cross-Layer ServerC. Signaling Scheme (Event Messages)D. Adaptation Algorithms (reside in the cross-layer client)

Breaking the cross-layer framework into these four main blocks makes it easier to handle each

required aspect of the framework independently and focus on its solution.


8/22



A. The Cross-Layer Client

The cross-layer client is the part which is added to each layer of the protocol stack to

facilitate the cross-layer coordination functionality. The client communicates with other clients in

other layers through the cross-layer server to achieve the required functionality. The cross-layer

client consists of two major parts, namely:

a. The Adaptation ModuleThe adaptation module could be divided into three main parts:

The adaptation algorithm itself. This is the logic and the implementation which solves acertain problem. It receives events from the server and sends events to it and can change the

state variables of the layer it resides in.

It communicates events to other layers through the server. The conversion of the receivedparameters from other layers into the form that the algorithm needs to operate on.

The parameters from other layers which might be necessary for the proper operation of thealgorithm.

b. Abstracted Layer StateEach layer in the protocol stack could be viewed as a set of parameters. Depending on

the value of these parameters, one can determine the overall state of the layer and determine

its behavior (i.e. each layer could be abstracted in a set of parameters).

B. The Cross-Layer Server

The cross-layer server resides outside the protocol stack to facilitate the cross-layer

coordination functionality. It could be viewed as a service or part of the operating system. The cross

layer server consists of two major modules, namely:

a. Control ModuleThe Control Module is divided into two parts:

1. The Action Module which takes the actions towards other layers, i.e. sends events to themin the form of Event Messages, or takes internal actions in response to a certain event

received from a client.


9/22



2. The Event Management Module which manages concurrent events and schedules whichevent to be handled first in the case of several events occurring at the same time. This form of

scheduling should be easy and not time consuming; otherwise it will affect the performance

of the system.

b. Parameter Management ModuleThis Module consists of the Parameter Repository which is responsible for saving the

parameters (abstracted state) of each layer in a suitable form for the other layers to access easily.

C . Signaling Scheme (Event Messages)As mentioned previously, the communication between different non-adjacent layers in the

protocol stack happens through the cross-layer server. When an initiating layer wants to send a

certain event to another target layer, the client of the initiating layer sends this event to the server,

which forwards it to the target layer. The event message should be expressive enough to carry the

necessary information from one layer to another. Different events could achieve different tasks, for

example an event could be used to inform the server of a change of a parameter and report its new

value. Another event could be used to request a certain parameter value from the server. The server

could send events to the clients to request a certain action to be performed or request from the client

a certain parameter value. An event is transmitted from a client to the server via an Event Message.

An Event Message could contain one event or several events with or without associated

parameters. Each event should have a priority to facilitate scheduling it among other events. Event

parameters are optional (i.e. there could be an event without a parameter). Events should be encoded

in a TLV (Type, Length, and Value) to facilitate the existence of several events per message.

3.3 What the Cross-Layer Designer needs to Specify

In order to utilize the proposed framework, the cross-layer protocol designer needs to specify

following parts in the cross-layer framework:

1. The adaptation algorithm which will be implemented inside the client of a certain layer orseveral layers of the protocol stack.

2. The necessary events, their numbers, types, their parameters and the associated action witheach event, which will be sent from a client to the server and vice versa.


10/22



3. A priority policy for differentiating between different events in case they are all present at thesame time at the server side. This policy should define which one to execute first when

several events of different types are present

3.4 Cross layer design for voice and video applications.

Cross layer can be used for the bandwidth hungry application like voice, video or multimedia

transmission where the jitter, delay many condition decide the Quos.

A. VOICE OVER INTERNET PROTOCOLVoIP is an interactive voice application that facilitates routing of voice conversations over the

internet or any other internet protocol (IP)-based protocol. These protocols carry telephony signals as

data packets. They are reduced in data rate using speech data compression techniques and

encapsulated in a data stream over the Internet protocol. VoIP is location independent. Only an

Internet connection to the VoIP provider is required.

Cross layer implementation is especially necessary when the channel is congested. This is

when all the nodes are competing for the available bandwidth. As the sending rate-per-node

increases, the available bandwidth in the channel decreases and congestion occurs. This design

consists of an IEEE 802.11bWLAN network supporting various VoIP applications using a UDP/IP

transport protocol. It involves interaction between the application, transport and MAC layers of the

protocol stack. This proposed architecture is used to optimize two Quos requirements of real-time

applications. These are: per-user throughput and end-to-end delay.

Cross layer interaction is created between the transport and the MAC layer of the VoIP

application. The application layer relays to the transport layers its specifications (i.e. sending rate and

required throughput). The transport layer directly contacts the MAC layer to relay the VoIP

applications specifics, the type of packets being sent (CBR packets) and its priority status. At the

MAC layer, a procedure is implemented such that if it detects that the sending rate of the priority

application is much greater than the throughput received at the base station, the MAC layer increases

its packet size by a pre-defined set number of bytes. When the sending rate of this application is

much greater than the per-user throughput at the base station, this is an indication that the application

is not being adequately served. It is therefore an indication that the channel is experiencing

congestion. The MAC layer continues to increase the packet size after a set interval within bound


11/22



until the transport layer relays to the MAC layer that the priority nodes throughput is at the required

level. To exemplify the effectiveness of this design, consider a number of applications running over

an 802.11b application using CSMA/CA. Each of the\ applications is waiting and listening for a slot

to transmit its information.

Figure : Cross Layer Interaction between the MAC a Transport Layer.

Consider that each packet has 50 bytes of information. As the application using the cross

layer realizes that the channel is getting congested, the transport layer of the VoIP application alerts

the MAC layer of the need for prioritization to send information with minimal delay. The MAC

layer, on receiving this information, increases its packet size to 100 bytes.

Hence, 100 bytes of VoIP are sent for half the contention period of the other competing

applications. Therefore, more information is sent for half the time. The other applications will have

to wait and listen two contention periods in order to send the same amount of information (50 bytes

per contention period). By increasing the packet size of the application, the MAC layer gives this


12/22



VoIP application increased priority. In addition to this, the CSMA/CA contention period of this

application shows a marked decrease. More bytes of information are being sent to the base station for

a shorter period of time than the applications using the normal OSI protocol layered stack

mechanism. Accordingly, the per-user throughput of the VoIP application is improved despite the

congested nature of the IEEE802.11b WLAN network.

VoIP data travels on a Real-time Transport Protocol (RTP) over User Datagram Protocol

(UDP). VoIP packets are very small with a payload of about 20 to 150 bytes. An RTP/UDP/IP

header is exactly 40 bytes (IP = 20 bytes, UDP = 12 bytes, RTP = 8 bytes). Due to the high relation

between the header size and the payload size, transmission of VoIP is inefficient.

It is important to note, when transferring information using VoIP, the Quality of Service

requirements of the application. The main constraints specified by VoIP are: delay, jitter, packet loss

and throughput.

CARRIER SENSE MULTIPLE ACCESS/COLLISION AVOIDANCE

Link adaption is a technique used to handle the effects caused by the changes in the channel

condition. It is performed at the link or Media Access Control (MAC) layer. This technique is used

to automatically adjust a number of radio/MAC parameters, so that optimal throughput is achieved.

Cross layer signaling can be used to pass the information across the layers. The 802.11b family uses

a MAC layer protocol called Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA).

It is a peer-to peer Ethernet protocol that needs no master station. In CSMA/CA, if a node wants to

transmit, it performs the following sequence

A node desiring to transmit listens to the channel. If the channel is busy (i.e. another node is

transmitting), the node waits until transmission stops and then waits a further contention period (A

contention period is a random period waited after every transmission on every node. It is

approximately 20-50 ms).When it senses that the channel is free for a specified time (called the

Distributed Inter Frame Space (DIFS)), the node is allowed to transmit. The DIFS is the Inter Frame

Space used for a node that is willing to start a new transmission. It is usually 128 microseconds long.

SIMULATION SETUP

Using a Network Simulation tool called NS-2, the topology for the cross layer interaction is

set up. The various layers and their individual protocols are included in the nodes and cross layer


13/22



interaction between the layers is effected as explained below.The basic topology consists of eleven

wired nodes connected to a base station (access point). A base station is a wired gateway between

wired and wireless domains. To measure the throughput at the base station, we attach a wired node to

the base station using a large capacity lossless link. This wired node acts as the sink for the packets

being sent from the wireless nodes to the base station. The wireless nodes represent the different

real-time applications. Each wireless node represents a different user connected to the network using

a specific application.

To show the effect of cross layer architecture on the performance, a specific node is identified

as the priority node. This priority node represents the end-user that requires priority service over

the other users. It is given all the characteristics of a VoIP application. In this node, cross layer

design method is implemented. The rest of the nodes in the network are also given all the

characteristics of real-time applications. However, these non-priority nodes use the ordinary OSI

Protocol stack adjacent layer communication.

Figure : Simulation Topology Setup

An Agent is created at each wireless node. Each node is identified as a UDP Agent since real-time applications are throttled when TCP is used. The traffic is specified to be CBR traffic. The

sending rate and packet size of each of the wireless nodes is then set to the same value. Each node

gets the same initial characteristic. Packets are then sent from each of the eleven wireless nodes to

the base station. This approach is used to ensure that all the nodes are given the same basic

environment and channel conditions. It also ensures that there is no bias on measurement of results.

The aggregate and per-user throughput of each node is measured at the base station and recorded

using trace files in NS-2. The average end-user delay is also recorded.


14/22



Assumptions

A lossless wired link with a very large capacity is used to connect the base station to the

wired node. The assumption is made that the throughput at the base station exactly matches the

throughput at the wired node. The per user throughput, aggregate throughput and end-user delay are

hence measured at the wired node. Also, as the congestion increases, the number of packets lost or

dropped increases too. It is assumed that the number of packets dropped does not adversely affect the

throughput o f any of the nodes.For accuracy of simulation results, eleven nodes are simulated and

tested. However, for ease of presentation of results in this paper, only four nodes have been

represented in the graphs. These include: three randomly chosen non-priority nodes and the sole

priority node.

USECASE

For effective evaluation of the simulation results, they have been divided up into two

different scenarios: before and after congestion. In each scenario, performance of the priority node

that uses cross layer design is compared to other non-priority nodes that use the strictly modular OSI

protocol stack. This helps to nullify any bias to the results.

Per-user Throughput

Scenario 1: Before Congestion

In this scenario, there is no congestion detected in the link. The channel conditions are

capable of supporting all the traffic passing through the link. All the nodes connected to the base

station are able to transmit their packet information with ease. The sending rate of each of the nodes

is set at 10 000 bps (0.01

Mbps).

Figure: Throughput vs. time before saturation


15/22



Figure above shows that all the nodes are able to attain maximum through put within minimal

time of 30 seconds. No node requires or is given priority over the other nodes. The per-user through

put of all the nodes is relatively equal to the sending rate i.e.0.01 Mbps. The low sending rate of each

application ensures that the bandwidth is fairly shared by all the applications. There is also enough

bandwidth left over to cater for other bandwidth hungry applications that may join the network.

Since there is no congestion, the cross layer procedure at the link layer is not necessary and the VoIP

priority application receives the same service as the rest of the nodes.

Scenario 2: High congestion

In this scenario, the sending rate of all the nodes is now set to 0.5 Mbps. The channel is

battling to cater to all the applications and their requirements. The end-to-end delay of the

participating applications increases drastically and the throughput per-user reduces considerably.

Figure: Throughput vs. time after saturation

Figure is a clear illustration of the improved performance of the priority node over the non

priority nodes. It is evident that the priority nodes through put increases to a value of 0.58 Mbps

well above the sending rate of the application. However, the other non-priority nodes are greatly

affected by the high congestion levels. In addition to this, they have to cater for the increased

throughput of the priority node. The through put of the other nodes lowers to an average value of


16/22



0.41 Mbps. However, the congestion does affect the priority node to some extent as its time to reach

maximum throughput increases to a value of 150s.

End-to-end Delay

Scenario 1: Before Congestion

This scenario remains the same as explained above. The sending rate of each node is set to a

value of 10 000 bps (0.01 Mbps). At this rate, all the nodes are freely transmitting their information.

There is enough bandwidth on the link to cater for\ all the nodes simultaneously. The total

bandwidth for all the nodes (0.11 Mbps) is much lower than the total capacity of the link. This is

approximated to be 4.5 Mbps. Figure 7 below shows the end-to-end user delays experienced by both

the priority nodes and non priority nodes collectively.

Figure: Delay vs. time before saturation

Fig above shows that the end-user delay for\ the priority node is relatively the same as the

average delay for the non-priority nodes. This is due to the fact that there is no contention for

bandwidth so all the nodes are transmitting data at the designated sending rate.

Scenario 2: After Congestion

In this scenario, the nodes are all competing for the available bandwidth. The sending rate ofeach node is set to a high value of 0.5 Mbps. The overall capacity of all the nodes is much greater


17/22



than the total capacity of the link. As contention for this bandwidth increases, the priority node states

its need for prioritization above the other nodes.

Figure : Delay vs. time with congestion

Fig. above shows that the end to end delay increases for the non-priority nodes. However, the

end-user delay for the priority node remains below 200 milliseconds according to the required QoS

requirements for end-to end delay stated in Table I above. This is an indication that the cross layer

approach suggested here is effective in areas of high congestion. There is a marked reduction in end-

user delay.

B. VIDEO APPLICATIONSThe following figures show the event messages and the flow chart to explain the

video communication using the cross layer design framework.

This section illustrates how the framework is used in the case of the transmission of video

over a wireless channel using cross layer operation. Seminar discuses a transmission scheme for real

time video over wireless which utilizes cross-layer interaction between the physical layer and the

video application layer. In their proposal, the physical layer determines the number of bits that it can

transmit each coherence period. This Information is supplied to the video application which adapts

its transmission based on that number to achieve the best performance.


18/22



Figure : Event message structure

Figure : Adaptation algorithm for video application


19/22



The technique makes use of combined Progressive Group of Pictures (PGOP) and

Fine Grained Scalable (FGS) video to adapt the video transmission to the wireless channel. The FGS

video is a two layered scheme comprising a base layer (BL) and an enhancement layer (EL). With

the PGOP scheme, the BL rate can be maintained close to a predetermined constant. The BL

guarantees an acceptable video quality. The EL can be received even partially. The reception of

additional EL bits can only increase the video quality. FGS is used in the proposal due to its

flexibility of arbitrary bit rate truncation at the EL . This is utilized as an advantage to adapt to the

fluctuating channel capacity. In the proposed cross-layer solution for rate control, the encoder does

not vary the transmission rate every coherence period. The encoder provides all the frame bits in a

buffer in a continuous fashion for the packetization process to truncate.

The packetization process will choose the maximal number of bits to transmit based on the

feedback from the physical layer in each coherence period and will truncate the remaining bits. The

packetizer does not have to know the semantics of the data that needs to be truncated as arbitrary

truncation of FGS video is possible. The packetizer selects only the necessary bits from the

beginning of the buffer and truncates the rest. The packetizer chooses only the transportable number

of bits minus the lower layer packet overhead (headers of lower layers) of the layers below it. The

total number of bits available at the physical layer for transport after including packetization would

be the exact number of transportable bits for that coherence period. This scheme provides real-time

rate adaptation for every coherence period.

We use this application as an example of how our cross-layer framework could be used to

allow cross-layer coordination. The requirement in this case is that the client of the physical layer

needs to inform the client of the video application the number of bits which it can transmit during

each coherence period. This corresponds to an event that the physical layer needs to send to the video

application via the cross-layer framework. This event is transported in an Event Message which

would be in the form shown in Figure . The message carries one event which is the number of bits

that the channel state allows to be transmitted during the next coherence period denoted by X. The

event priority is high, since if the video application does not receive this number it will not be able to

construct the video packet in the correct form. There could be a default value which is the minimum

value which corresponds to only accommodate the BL bits. The cross-layer server upon receiving

this message from the physical layer client determines its event type. The management module in the

server then decides to forward the event to the video application. Thus another message from the

server to the client of the video application is needed. This message has the same type and format as


20/22



the one between the physical layer client and the cross-layer server. The client in the video

application receives this event and starts performing the adaptation algorithm which is shown in

Figure. The operation of the algorithm is very simple, the algorithm drops a number of bits from the

buffer filled by the video encoder so that the remaining number of bits is equal to the number

supplied by the physical layer minus the overhead of lower layer protocols (RTP, UDP, IP and Link

layer headers). Note that the demonstration of the adaptation algorithm does not take into account the

occurrence of an error that prevents the event from reaching the video application. Several strategies

could be used to solve this issue, for example sending the BL bits only or sending the same number

of bits as the last packet, or having a weighted average of the sizes of several previously transmitted

packets.

In this case no policy is required for determining how this event should be handled in the case

of the existence of other events at the same time. An example of such a policy would be if the

physical layer sends the event fading_start, which indicates that a sudden fade has occurred in the

wireless channel, meaning that the channel is inaccessible, in this case it should be forwarded to the

video application which should in turn drop the packet it was constructing. The abstracted layer state

of the video application contains the encoding rate that the video is using and the number of bits in

the BL and EL and any additional information for example the encoding algorithm used.

The parameter repository in the cross-layer server in this case will be used to store the base

rate of the BL at which the video application is sending and the maximum rate corresponding to BL

+ EL. It also is used to store the values that the physical layer reported for the previous coherence

periods.

4.FURURE SCOPE

In this seminar we have presented an overview of recent advances in the area of cross-layer

design. We identified an essential issue that we believe is crucial to the success of the cross-layer

design scheme. This issue is the existence of an organized framework which defines how the non-

adjacent layers communicate.

Future work includes investigating the impact of implementing several other cross-layer

adaptation algorithms under the same framework and qualitatively assessing the performance of the

framework and applications under such operation.


21/22



5. CONCLUSIONS

The results above reveal that this proposed Cross Layer architecture is indeed an effective

means of reducing the end-to-end delay experienced by giving priority to a VoIP or video or

multimedia application over the non-priority applications on request and reducing its contention

period. Reduction of this contention period facilitates a reduction in overall end-to-end delay

between the source and of the application. In addition, this design method is effective in increasing

the per-user throughput of the application. As more bytes per packet are transmitted during the

allocated transmission time, the overall per-user throughput of the prioritized application increases

greatly.

The effectiveness of this design is more evident during periods of high congestion when all

the applications are struggling to utilize the available bandwidth of the channel. In the event that all

the nodes: priority and non-priority used this proposed design, the overall throughput would be

increased and end-to-end delay per user decreased due to the increase in packet size and reduction of

contention period for each application. Cross Layer architecture is therefore a more effective and

easier means of provisioning Qos requirements to real-time applications.

REFERENCES

1. Qian Zhang, Fan Yang, and Wenwu Zhu, Cross-Layer Quos Support for MultimediaDelivery over Wireless Internet EURASIP Journal on Applied SignalProcessing. Volume

2005 , pp 207219, January 2005

2. ustavo Carneiro, Jose Ruela, and Manuel Ricardo, Cross Layer Design in 4G WirelessTerminals, IEEE Wireless Communications, Volume: 11, Issue 2, pp 7-13, Apr 2004.

3. James F. Kurose, Keith W. Ross Computer Networking. A top down approach featuring theInternet 3rd Edition 2005

4. Deeya Shakti Nursimloo, A two layered mobility support architecture: Fast Mobile IPv6 andSession Initiation Protocol, Masters thesis, University of Cape Town, 2006.

5. http://www.zytrax.com/tech/wireless/802_mac.htm - Retrieved on April 28, 20096. Karim M. El Defrawy, Magda S. El Zarki, and Mohamed M. Khai ry, Proposal for a Cross-

LayerCoordination Framework for Next Generation Wireless Systems, Proceedings of the

2006 international conference on Wireless communications and mobile computing, pp. 141-

146, Vancourver, 2006.

7. http://sss-mag.com/pdf/802_11tut.pdf Retrieved on 30 June, 2009


22/22


DEPARTMENT OF COMPUTER SCIENCE BEC BAGALKOT Page 22

8. Arulsaravana Jeyaraj, Liang Cheng, Magda El Zarki. Proposal for a Cross Layer scheme forReal Time Wireless Video. In preparation, April, 2006.

9. Carneiro, G.; Ruela, J.; Ricardo, M. Cross-Layer Design in 4G Wireless Terminals. IEEEWireless Communications Magazine. Volume 11, Issue 2, Apr. 2004 Page(s):713.

10.Haitao Zheng. Optimizing wireless multimedia transmissions through cross layer design.IEEE Proceedings of International Conference on Multimedia and Expo, 2003(ICME '03).

Volume 1, 6-9 July 2003 Page(s):I - 185-8 Vol.1.

cross layer design to achieve QOS

Documents