Rate Adapt ns2 Code + Power Adapt

9/12/2017 https://translate.googleusercontent.
com/translate_f
UNIVERSITY OF PATRAS
POLYTECHNIC SCHOOL
DEPARTMENT OF COMPUTER ENGINEERING
B& HELOR'S THESIS
A CINFORMATICS

IN THE CONTEXT OF
M.SC. (SFC)
"COMPUTER SCIENCE AND TECHNOLOGY"
"A DAPTIVE C ROSS - L AYER A LGORITHMS FOR M ULTIMEDIA

T RANSMISSION OF DATA AND MANAGEMENT OF
ENERGY WIRELESS NETWORKS "

VASSILIS PAPAPANAGIOTOU
A. M 613
IMPOSE A PROFESSOR BEINGS:
Christos Bouras, Professor

THREE-MEMBER COMMITTEE:
Emmanuel Varvarigos, Professor
Konstantinos Berberidis, Professor
Christos Bouras, Professor
PATRA 20 10
SUMMARY
https://translate.googleusercontent.com/translate_f 1/92
9/12/2017 https://translate.googleusercontent.com/translate_f
The complexity of networks has led to the separation of network architectures levels (layers).
Traditional approaches focus on wired networks and try to separately optimize the network level as
in the physical, medium access (MAC), the routing layer and the transport layer. This approach
reduces the complexity and makes things more manageable and architectures more flexible and
upgradeable but may also lead to embodiments suboptimal (suboptimal designs). With this level
approach, communication takes place between two adjacent levels without taking into account the
specific features of multimedia applications. Although this level approach was the fundamental
factor for the development of network and web wired networks, it seems to place restrictions on
the adaptability of multimedia applications and wireless networks. Therefore, a careful approach to
communication between nonadjacent levels (cross - layer approach), where selected communication
and interactivity between the levels permitted, can have performance advantages without reverses
the successful separation of the levels has led the networks in their current evolution.
In this diploma and profile fontai power management techniques for transmitting multimedia data
to wireless networks using the TFRC protocol and considering the feedback (feedback) for the
received video quality trying to adjust the transmit power intelligently. The purpose of these
algorithms is to use the feeback of the Protocol TFRC and thus achieve a balance between power
consumption and the received video quality. Two adjustment mechanisms are proposed, each with
its own advantages. Both offer significant improvements when used, taking into account both
power consumption and video quality. Also, the issue of simulating the transmission of multimedia
data in wireless networks is examined, and the proposed algorithms are compared and evaluated.
EXECUTIVE SUMMARY
Networking complexity has led to the modularization of network architecture in layers. Traditional
approaches focus on wired networks and try to individually optimize each network layer, such as
physical, medium, routing and transport layer. This approach reduces complexity and makes issues
more manageable and architectures more flexible and upgradeable, but it may lead to suboptimal
designs. Under this layered approach, communication takes place between two adjacent layers
without taking into account the specific characteristics of multimedia applications. Although this
layered approach has been the fundamental factor for the growth of the wired networks and the
World Wide Web it seems to pose constrain t s when attempting to adapt protocol's behavior to
multimedia applications characteristics and to wireless network conditions. Therefore, a careful
cross-layer approach, where the selected communication and interaction between layers is allowed,
can have performance advantages without negating the successful layer separation that has guided
network design so far.
In this thesis, we describe power management adaptation techniques for wireless video
transmission using the TFRC protocol that take into account feedback about the received video
quality and try to intelligently adapt transmitting power accordingly. The purpose of the
mechanisms is to use TFRC feedback and thus achieve a beneficial balance between power
consumption and received video quality. There are two power adaptation mechanisms proposed,
each with its own advantages. They both offer significant improvements when used both in terms
of power consumption and received video quality. The topic of simulation of multimedia
transmission over wireless networks is also examined and used to compare and evaluate the
proposed adaptation management techniques.

PROLOGUE
By finishing this diploma thesis, I would like to thank the people who helped me that they could
not have been done without their help.
First of all, I would like to extend my warm thanks to Professor Christos Bouras (Professor of
Computer Engineering and Informatics at the University of Patras) for overseeing the work, his
valuable advice and his support to complete the present work, but also about the possibility that I
was able to deal with such an interesting subject.
Similarly, I want to thank Prof. Emmanuel Calibrator Varvarigos and Professor Konstantino
Mpermperidi, for the price they made me to be members of the Triennial Commission of Inquiry.
I would also like to extend my special thanks to Dr. Costas Stamos, Dr. Vangelis Kapoulas and
Ioannis Zououdis not only because their help has been catalytic in my diploma work but also in
their support throughout my collaboration with Research Unit 6 of the Research Academic
Institute of Computer Technology.
In addition, I would like to thank all of my colleagues at the Telematics and New Services
Laboratory of the Department of Chemistry and Research Unit 6 of the Institute of Computer
Technology for the pleasant and harmonious climate of cooperation.
In closing, I would like to thank my family without their mental and physical help and their full
support whenever needed, it would not be possible to complete my graduate studies.

Patras, August 20 10
Basil G. Papapanagiotou
In my family
CONTENTS
SUMMARY
EXECUTIVE SUMMARY
PROLOGUE
CONTENTS
PICTURE LIST
LIST OF TABLES
ACRONYMS
CHAPTER 1: INTRODUCTION
CHAPTER 2: CROSS-LAYER ARCHITECTURES ON WIRELESS NETWORKS
REQUIRE FOR CROSS-LAYERED ARCHITECTURES IN WIRELESS NETWORKS

2.1.1 WIRELESS AND WIRED TRANSMISSION FEATURES
2.1.2 NETWORK ARCHITECTURE
2.1.2.1 PROTOCOLS HIERARCHY

2.1.2.2 THE OSI REFERENCE MODEL
2.1.2.3 THE TCP / IP REFERENCE MODEL
2.1.2.4 CROSS-LAYERED ARCHITECTURE DESIGN PROBLEMS

2.1.2.5 REQUIREMENT FOR RATE-ADAPTIVE TRANSMISSIONS
2.1.3 EXISTING CROSS-LAYER ARCHITECTURES
2.1.3.1 INTRODUCTION
2.1.3.2 CROSS-LAYER ON PHYSICAL-MAC-ROUTING
2.1.4 TFRC PROTOCOL
CHAPTER 3: VIDEO DELIVERY AND SIMULATION TOOLS
3.1 INTRODUCTION
3.2 BINARY FILE ENCODING IN TRACEFILE
3.2.1 UNCOMPRESSED FILE
3.2.2 TYPES OF MPEG FRAMES
3.3 INTRODUCTION H .264

3.4 H.264 ENCODING MECHANISM
3.5 H.264 ON WIRELESS NETWORKS
3.6 TRANSMISSION USING THE H.264 STANDARD
CHAPTER 4: ENERGY MANAGEMENT ALGORITHMS FOR DATA TRANSMISSION USING THE TFRC
PROTOCOL
4.1 DESCRIPTION OF THE PROBLEM

4.2 DESCRIPTION OF THE MIMD MECHANISM
4.2.1 ELEMENTS OF THE MECHANISM
4.2.2 THE MIMD ALGORITHM
4.3 THE BINARY ALGORITHM
4.4 IMPLEMENTATION OF THE MECHANISMS
4.4.1 VIDEO RATING
CHAPTER 5: EXPERIMENTS
5.1 TESTBED
5.2 ASSESSMENT SCENARIOS
5.3 EXPERIMENTS
CHAPTER 6: CONCLUSIONS
CHAPTER 7: FUTURE WORK
CHAPTER 8: BIBLIOGRAPHY
CHAPTER 9: ANNEX
9.1 PLATFORM INSTALLATION AND DEVICE ANALYSIS

9.2 USING A MECHANISM AND EVALUATING VIDEO
9.3 IMPLEMENTATION OF THE MIMD MECHANISM
9.4 IMPLEMENTING THE BINARY MECHANISM:
9.5 PHYSICAL CHANGES (WIRELESS)
9.6 CHANGES TO THE TFRC PROTOCOL L

9.7 TFRC MOTION CREATION SCENARIOS
9.8 TOPOLOGY SCENARIOS
LIST IMAGES
Figure 1. Objective from which cross-layer architectures emerge
Figure 2. Levels, protocols and interfaces
Figure 3. The ISO OSI reference model
Figure 4. Comparison of OSI with TCP
Figure 5. Evolution of multimedia applications over networks
Figure 6. Video MPEG-4 structure.
Figure 7. Frame transmission in conjunction with an adaptive algorithm
Figure 8. Video coding mechanism based on H.264 standard
Figure 9. Video decoding mechanism based on the H.264 standard
Figure 10. H.264 Architecture Levels
Figure 11. Example video transmission using the H .264
Figure 12. Recommended cross-layer design for MIMD and Binary
Figure 13. Packet loss control and power adjustment mechanism
Figure 14. Finite automatic for the sender's proposed mechanism.
Figure 15. Topology of Mechanism
Figure 16. Overall video transmission process in the simulator.
Figure 17. Script 1: 2 nodes fixed
Figure 18. Script 2: 2 nodes, 1 fixed, 1 spacing
Figure 19. Scenario 3: 2 nodes, 1 fixed, 1 approaching and then removing
Figure 20. Script 4: 2 nodes, 1 fixed, 1 is approaching
Figure 21. Script 5: 2 nodes, 1 fixed, 1 approaching and then moving away
Figure 22. Scenario 6: 2 nodes, 1 fixed, 1 is removed and stopped
Figure 23. Scenario 7: 2 nodes, 1 fixed, 1 approaches and stops
Figure 24. Scenario 8: 2 nodes, 1 fixed, 1 moves randomly
Figure 25. Hybrid network
ACRONYMS
LIST TABLES
Table 1. Matching PSNR with MOS
Table 2. Scenario results
Table 3. Assignment of PSNR to MOS values
ACRONYMS
English terms
ACM Adaptive Coding and Modulation
ARQ Automatic Rep eat re-Quest
A VC Advanced Scalable Coding
FGS Fine Granularity Scalability
GoF Group of Frames
GoP Group of Pictures
IP Internet Protocol
CPU Computer Processing Unit
MOS Mean Opinion Square
MPEG Moving Picture Experts Group
NS2 Network Simulator 2
PSM Pipe-to-Soil Monitor
PSNR Peak Signal-to-Noise Ratio
RTT Round Trip Time
QoS Quality of Service
SNR Signal-to-Noise Ratio
SVC Scalable Video Coding
TCP Transfer Control Protocol
TFRC TCP Friendly Rate Control
UDP User Datagram Protocol
WWW World Wide Web
IMPORT
CHAPTER 1: IMPORT
Adaptive Cross - Layer Algorithms for Multimedia Data Transmission and Power Management on
Wireless Networks.

IMPORT
IMPORT
The TCP / IP model is observed to function effectively for wired transmission networks still do
not appear to exhibit the same efficiency to wireless applications. Thus, there is a requirement to
improve the existing model and to develop and implement smarter algorithms that will exploit the
particular features of wireless transmission and in particular the transmission of multimedia data.
The thesis studied the available templates available for cross - layer architectures in wireless
networks and present down tests and measurements in ns -2.30. The optimization possibilities a
well studied and presented and a new mechanism of exploitation cross - layer architecture that
improves the final quality of the transmitted video having in mind the minimum possible
consumption of energy from the node transmits (usually the base station).
In more detail, various issues related to the effective are presented transmission of encoded video
(such as H.264) via wireless s connection using the protocol TFRC (TCP Friendly Rate Control).
It proposed a new mechanism which uses cross - layer architectures for adapting the energy with
which a packet is transmitted according to the feedback information received by the sender by the
recipient on the state of the network connection having the aim of improving its metric
transmission and consequently the user experience without it it also involves high energy
consumption. The device was tested through simulations using the NS simulator 2. Comparing the
received video using the mechanism to that obtained without the mechanism we concluded that
there is significant improvement in video quality.
In chapter 2, we study the cross - layer architectures in wireless networks. Analyzes the basic
principles of network architectures and presents the fundamentals of cross - layer architectures.
Also lists the existing cross - layer architectures as well as different.
In chapter 3, the special structure of the video being transmitted, which is used to turn it into
tracefile for transmitting and further presents the new model H .264 and the potential for
multimedia transmission especially in wireless networks and using cross - layer architectures
between Application levels and MAC.
In section 4 we describe the main problem of diplomatic, i.e. it takes control of the transmitted
packet energy. Also shown being the j power management algorithms are implemented in the
context of improving the existing architecture of TFRC over wireless networks.
Chapter 5 details the experiments made using tert-term mechanisms, topologies used and the
general conditions for the transmission.
Chapter 6 presents the conclusions of this diploma thesis.
Chapter 7 presents some open issues that may be the subject of future studies in this area as well
and is a brief description of hybrid networks.
Chapter 8 presents the literature and websites mentioned in this thesis. References to bibliography
and websites are incorporated into the text in square brackets ([]).
Finally, in Chapter 9 is the Appendix which includes several useful script and mechanisms
developed during the preparation of this diploma thesis.
PUBLICATIONS P E CONFERENCES
[1] "Video Transmission over TFRC using cross- layer power mana gement", 1 7 th International
Conference on Software Telecommunications and Computer Nerworks, Hvar - Split , Croatia, C.
Christos Bouras, Vaggelis Kapoulas, Apostolos Gkamas, Kostas Stamos, Vassilis
Papapanagiotou, Zaoudis Giannis 24-26 September 2009.
Summary
This paper presents issues related to the efficient transmission of encoded video (such as H.264)
to wireless connections using the protocol TFRC. It proposes a new mechanism using cross -
layer approaches to adjust the power of the sender, and feedback information levels on the state
of the wireless connection from the receiver to transmission statistics are improved and
therefore a better user experience without unnecessary power consumption. The device was
tested using simulations on the ns network 2. Compared to the video transmission without the
mechanism, we notice that it has benefits in the quality of the video.
[2] "Efficient Power Management Adaptation for Video Transmission over TFRC", The Sixth Ad
vanced International Conference on Telecommunications AICT 2010, Christos Bouras,
Vassilis Papapanagiotou, Kostas Stamos and Giannis Zaoudis May 9 - 15, 2010 - Barcelona,
Spain
Summary
In this publication, a power management device for wireless video transmission using TFRC
protocol and take into account the received video quality and tries to intelligently adjust its
transmitted power. The mechanism is to use the feedback messages of TFRC in order to achieve
a beneficial balance between power consumption and video quality obtained. This mechanism is
compared by simulations and a plurality of scenarios with another power management
mechanism and transmission without power management.
PUBLICATIONS IN JOURNALS (JOURNALS)
[1] "Power Management Adaptation Techniques for Video Transmission over TFRC",
International Journal of Network Management, John Wiley & Sons, Ltd, Christos Bouras,
Vassilis Papapanagiotou, Kostas Stamos and Giannis Zaoudi s (to appear)
Summary
In this paper, described adjustment and power management devices for wireless video
transmission using TFRC Protocol, taking into account feedback information from the received
video quality and smart trying to adjust the transmission power. The purpose of the mechanisms
is to use the feedback information (feedback reports) of TFRC and thus strike a balance between
power consumption and quality. Two adjustment mechanisms are proposed, each with its own
advantages. Both offer significant improvements when used in terms of power consumption and
the received video. Simulation is used to compare and evaluate our approach.
CHAPTERS IN BOOKS
[1] The TFRC protocol and its usage for wireless video transmission, Advanced Communication
Protocol Technologies: Solutions, Methods and Applications, Christos Bouras, Vassilis
Papapanagiotou, Kostas Stamos and Giannis Zaoudis (to appear)
Summary
The theme of this chapter is to present protocol TFRC (TCP - Friendly Rate Control) in the area
of wireless video transmission and the possible use of power management mechanisms in cross -
layer. Presented the main features of the functions TFRC together with the suitability of the
TFRC for video transmission. In chapter discusses related work and efficient video transmission
mechanisms TFRC that have been proposed. These mechanisms using cross - layer approaches
adjusting the level of the sender transmit power and feedback information from the TFRC
which relate to the status of the wireless connection from the receiver to improve transmission
statistics and thus user experience without unnecessary power consumption.
OTHER PUBLICATIONS (OTHER SFC)
[1] Extending QoS support from Layer 3 to Layer 2, 15th International Conference on
Telecommunications, St. Petersburg, Russia, C. Bouras, V. Kapoulas, V. Papapanagiotou, L.
Poulopoulos, D.Primpas, K.Stamos 16 - 19 June 2008
Summary
the nd
This paper presents some of the results from Esma QoS implementation in 2 level
Ethernet and IP networks. IP networks traditionally provide quality Service Level 3. However,
since there is a very large existing network infrastructure operating at level 2, the current
networks could benefit from the quality of service activation level 2 (L 2 QoS) and cooperation
in the service quality 2 3. ,
2 3
.
[2] Layer 2 Quality of Service Architecture, Telecommunic ations, IN-TECH , Bouras C., V. Kapoulas,
V. Papapanagiotou, L. Poulopoulos, D. Primpas, K. Stamos, 2009
Summary
In this chapter we discuss methods of QoS activation level 2 ( L 2 QoS ) and methods of
cooperation with the QoS level 3. Initially discussed the problem of integration ( integration ) of
the quality of service methods at level 2 with these Level 3 . the following is how the
implemented QoS level 2 to GRNET network and how it works with the level 3 also shows part
of the tool that takes over to automatically activate the service and quality on the 2 levels and
certifies that there is a problem in the network (such as inadequate resources etc.).
Adaptive Cross - Layer Algorithms for Multimedia Data Transmission and Power Management in
Wireless Networks.

VIDEO TRANSMISSION AND GEAR EXOMOIOSIS
CHAPTER 2: CROSS - LAY ER THE
ARCHITECTURAL WIRELESS NETWORKS
CROSS - LAYER THE ARCHITECTURAL
The head AIO this makes an introduction to cross - layer architectures. It starts with a brief
introduction to why we use cross - layer architectures especially in wireless networks and continues
with various embodiments of such architectures in several protocols ( TCP , UDP , etc.) . A
theoretical approach to cross - Layer architectures can be found in [1] .
Requirement for Cross - la yer architectures in wireless networks
The complexity of networks has led to the separation architecture network levels. Traditional
approaches focus on wired networks and is an effort to optimize separately each network layer as
the natural, the level of access and the routing level and transport. This approach reduces
complexity and makes the issues of network design easier in terms of management and makes the
architecture more flexible and easily upgradeable, but can lead to non-optimal designs. Within this
very - flat approach communication between two neighboring levels is performed
without taking into account the particular multimedia applications. Although this too - flat
approach was the key factor for the development of wired networks and the World Wide Web ,
seem to pose limitations in trying to adapt the behavior of the protocol in the characteristics of
multimedia applications and the specific conditions of wireless networks . Therefore a careful
approach cross - Layer , wherein the communication and interaction between some layers, may
have some advantages without invalidating the successful separation of the architecture of a
network which has led networks at this high level is selectively permitted. More information on the
cross - layer architecture can be found in [1] . This chapter presents in detail some architectures
analyzing the protocols and mechanisms used.
Figure 1 . Target from which the resulting cross - layer architectures
2.1.1 Features Wireless and Wire Transfer

The wireless transmission differs in an important way from the wired communication and this is
due to the fact that the concept of association is not so stable and may vary depending on the
traffic between the communication nodes, intermediate interference and transmitting
communication node attributes, and especially the transmission power. Although increasing the
transmission power associated with a strongest signal and consequently improved transmission
characteristics in many scenarios wireless transmission is desired to reduced power consumption.
This tradeoff has been investigated by several researchers in their studies of the amendments to the
protocol TCP [2] , [3] , [4] , to achieve reduced power consumption in conjunction with high data
rate . The wireless transmission standards such as IEEE 802.11 determine power saving
mechanisms [5] , but studies have shown that mechanisms such as PSM and others impose
significant delays cost regarding efficiency [6] , [7] , [8] , [ 9] . In addition an important issue for the
performance of wireless networks is the accurate determination of cause that packets are lost. The
packet loss in wired networks occur mainly due to congestion on the route between the sender and
the recipient, while wireless networks are packet losses are the result of damaged packages mainly
due to low signal to noise ratio ( SNR ) , the fading of the multipath transmission and because
interference from neighboring transmissions . A second and very important difference between
wired and wireless networks is the movement of nodes. The movement of nodes in wireless
networks introduces a number of additional obstacles to the transmission of multimedia data. The
weakening of the channel and the time shift between two base stations are the most important
factors causing packet loss as well as introduce additional delays when a mobile user moves from
one access point to another.
2.1.2 Network Architecture

2.1.2.1 Hierarchy protocols
W e have many researchers have focused on optimizing various topics in wireless ad - hoc using
cross - layer architecture, where a particular infrastructure is not considered, but it would be little
mention in the architecture of networks traditionally used. Historically the first computer networks
were designed primarily due to the material and only secondarily examined the software. This
strategy no longer performs as nowadays the network software is highly structured.
To reduce their design complexity, most networks are organized as a stack levels, the levels built
one above another. The plurality of levels, the name of each layer, the contents of each level, and
the functionality of each plane differ from network to network. The goal of each level is to offer
some services to higher levels, "hiding" from the other levels the implementation details of service.
In a sense, each level is a kind of virtual machine providing services at the highest level. Between
each pair of adjacent levels is an interface that defines the basic functions and services which have
the lower level to the upper level.
Figure 2 . Layers, protocols and interfaces

, OSI TCP / IP .
OSI ,

.
TCP / IP ,
, .
2.1.2.2 OSI
ISO OSI OSI

( Open Systems Interconnection ) ,
. OSI
:
( physical layer ) ,
.
The level data transmission link ( data Link Layer ) which deals with the transformation of a
transmission service raw data in a line which appear in the network layer that does not have the
risk of localized transmission errors.
The network layer ( network layer ) , which controls the operation of the - network and
determined how the routing of packets from source to destination.
The transport plane ( transport This Layer ), whose basic function is to receive data from the
upper level to cleave if necessary in smaller units, to transfer them to the network layer, and
ensures that all parts arrive correctly at the other end. Additionally all this must be done in an
efficient manner so as to isolate the upper levels of the inevitable technological changes resulting
in material used.
The session layer ( session layer ) allows different machine users to establish conversations (
sessions ) between them.
The level of presentation in contrast to the lower levels mainly engaged in the transport bit ,
deals with the syntax and semantics of the information transmitted.
T the application layer contains a variety of protocols that are often requested by users such as
HTTP .
Figure 3 . The reference model ISO OSI
2.1.2.3 T reference model TCP / IP
This model provides an interconnection capacity of many networks transparently. In relations

important to model OSI has fewer levels of all three upper layers of the model OSI form a single
layer in the TCP / IP , the application level. The model TCP / IP has four levels which are
presented below :
The internet layer ( internet layer ) has as its main task to allow hosts and introduce their
packages on any network and they can travel independently to their destination, which can
be located on a different network.
The transport layer ( transport layer ) is designed to allow peer entities on the source and
destination hosts and chat, just
The application layer ( application layer ) which has replaced conversation levels,
presentation of model OSI and contains all upper layer protocols.
The level of interconnection between service computer and network that is not defined and
varies from computer to computer and from network to network although the objective is to
allow the host computer to connect to the network using some protocol so it can send
packets IP
TCP / IP OSI .
.

TCP / IP ,
.
4 . OSI TCP
2.1.2.4 cross - layer

cross - layer . :
(
QoS ) 802.11 e .
,
.
2.1.2.5 rate-adaptive

IP . ,
streaming ( Video - on - Demand )
.
streaming
.
,

.
.

. PDA
,
. ,
.
Video - on - demand ,

. ,

,
.
5 .
2.1.3 cross-layer
2.1.3.1

ad - hoc cross - layer ,
. .
2.1.3.2 Cross-layer Physical-Mac-Routing
[10]
physical Mac routing ad - hoc

. [11]

ARQ ( Automatic Repeat Request )
FEC ( Forward Error Co rrection ) RLP ( Radio Link Protocol ) .
[1] cross - layer
( APP ) , MAC
( PHY ) .
cross - layer -
- ( top - down ) , -- ( bottom - up ) , ---

( application centric ) --- MAC ( MAC centric ) .
cross - layer
( QoS ) .
[12] .
, ,
( uplink ) (
downlink ) Medium Access Control ( MAC )
. [13]

cross - layer .
[14] 802. 16 ( WiMAX ) ,

.
( ACM )
( SNR ) . ,

MAC .
tradeoff .
, cross - layer
[15] .

ad - hoc .
O
(1) MAC , .
cross - layer ,

cross - layer .
2.1.4 TFRC
[16] , TFRC
unicast best - effort .
, TCP ,

TCP ,
.
, MPEG -2 3
( frames ) ( I - frames , P - frames , B - frames ). o bit rate
frames , I - frame
P - frame bit .

, .
bit rate .
. TFRC
( oscillatory )
( statistical multiplexing ). ' ,

( RTT ) .
RTT
RTT . R _ sqmean
:
if no feedback has been received before

R_sqmean = sqrt(R_sample);
else
R_sqmean = q2*R_sqmean + (1-q2)*sqrt(R_sample);
' R _ sqmean
RTT. q 2 q , 0.9
[19] .
, , .
X _ inst :
X_inst = X * R_sqmean / sqrt(R_sample);
sqrt ( R _ sample ) R _ sqmean

.
. TFRC
TCP
1480 bytes .
TFRC
TCP .
TCP . ' ( bottelenecks )
( bps ) ( packets / sec )
.
, TFRC TCP
friendly TFRC feedback reports
.
TFRC
,
. TFRC TCP

streaming . TFRC ,
.
DCCP [38]
.

slow start ( Congestion Avoidance ).
slow start
report ,

RTT . ,
.
TCP .
:
X = min ( TCP throughput, 2*receiving rate
cross - layer ,
feedback
TFRC .
.
RTT ,
.

RTT ,
. ( RTT )
reports
RTT RTT
. ,
RTT .
To timestamp . t _ recvdata .
i , t _
recdata = ts _ i . timestamp
RTT , timestamps
.

, feedback report . t _ delay .

feeback report . X_recv.
, p .

TFRC . ,
.

cross - layer
802.11.
Cross - Layer
.

VIDEO
3: VIDEO

VIDEO
3.1

,
.
binary tracefile
evalvid .
MPEG -4
.
3.2 Binary tracefile
The MPEG-4 video coding, as defined by ISO / IEC's Moving Picture E Xperts Group , is a
standard for compressing and decompressing the digital video in order to distribute and transmit
over within a limited bandwidth. The standard suite of MPEG -4 includes 23 parts describing
different aspects of multimedia compression and transmission. The file that is used akiyo . cif and
belongs to the suite of MPEG -4. To encode the binary file to tracefile should know the video
structure described below.
3.2.1 Non archive

The raw video consists of a series of digital photographs , each of which consists of a grid pixel
which should encode. The grid in this video is 352 x 288 pixel . Each pixel ( pixel ) is represented
by three values of one byte ( bytes ) into RGB format , which allows the presentation 256 intensities
of each color . Uncompressed the above provides a bit - stream that it is impractical to store
process and distributed to computers through modern network equipment because of their size.
The following example shows the calculation of the size of a CIF RGB video which lasts one
minute.

3 colors 1 bytes / color ( 352 288 pixels ) 25 fps 60 se conds / minute = 435 MB / minute

A more efficient alternative is to store the video in YUV format . This format creates the human
perception of color better. Stores the information for brightness and "chromaticity" at different
levels. In this way because the brightness is more easily perceived by the human eye in relation to
the "chromaticity" so the second stored with equally great precision is not required. The size
reduction introduced by the use of the YUV format is not enough to generate a bit - stream which
has sufficient size for transmission over existing networks. For this reason, the compression used is
that shown below.
3.2.2 Types of frames of MPEG

By the use of MPEG compression image no raw video is not sent maintaining the original
structure. Features The series of images or frames ( frames ) are kept in groups of images ( Groups
of Pictures ) as shown in Figure 6 . Structure MPEG -4 video. The frames are encoded then within
the GoP in various ways. There are normally three types of frames in an MPEG gop :

i. Frames formula I : Internally coded frames ( Int ra - coded frames ) which are encoded as
single frames such as in JPEG format . They contain references to any other frames and
have a relatively large size.
ii. Frames of formula P : Predictive coded frames of which are encoded as the difference of
two panels I which belong to the same gop . Their size is usually smaller than that of I
frames .
iii. Type frames Breakfast : Bidirectional frames ( Bi - directional coded frames ) are frames
in which the information on the bidirectional differential frames are created by combining
the I and P frames . Usually it is sufficiently smaller than the size of the P frame .
The remarkable what the above structure, in terms of service quality, is that I - frames are
important for the quality of the video relative to the P - frames , which in turn is greater than the
B - frames . Now if an I - frame is lost during transmission due to noise on the channel or for
some other reason, the loss in the video quality will be high but still smart decoders can create a
useful image if at least reach the recipient the GoP . The number of packets required to transfer
a frame depends on the ratio size; frame by transfer unit size, called Maximum Transfer Unit (
MTU ) .

Figure 6 . Structure MPEG -4 video.
tracefile
frame tracefile . frame
GoP frames GoP .

MPEG -4 10 H .264

.
3.3 H.264
AVC Advanced Video
Coding ITU - T Recommendation H .264 ISO / IEC 14496 ( MPEG -4 )
10
MPEG -4
.
.
1. frame .
2. frame .
i. I B B P B B Group
of Picture ( GOP ) MPEG -4
I - frame
P - frame B - frame
B - frame Bidirectional frame frame
.
frame .
7 . frame
ii. I
- frame

frame .
iii. ,
.
3.4 H.264
The mode of operation mechanism has to do with the way the video layout. Each video as we know
consists of frames (frames) which in this model consist of the respective slices which in turn consist
of smaller macro blocks that feature internal correlation of any given block with its neighbors,
where each block internally further analyzed in a vector and an agent which individually retain
information such as brightness, etc..
Figure 8 . Video coding mechanism of the Standard H .264
Figure 9 . Video decoding mechanism of the Standard H .264
3.5 H.264 wireless networks

The video transmission over wireless network is always a challenge as it requires high compression
but also design and friendly to the network. Regarding both challenges have been the main
objective of the standard formulation H .264 and implemented several tools which can be used for
improvements in wireless multimedia transmission.
These new tools offer features like hide 'error' tolerance to errors due to the special encoding,
multiple frames ( frames ) report that many mistakes repaired and optimization based on theory rate
- distortion . These new features give the H .264 is very important for transmission over wireless
networks, and it is worth mentioning the way that achieves the above standard which is based on
the architecture shown below.
Figure 10 . Architecture levels of H .264
3.6 Transmission using standard H .264

For a better understanding of how the standard mode listed below a detailed explanation of the
process. As shown by the image becomes the video sample and each frame analyzed to macro The
block which in turn is quantized and used to generate internal prediction mechanism and filtering.
Then becomes the final coding and packaging , which is used for sampling the video and sent to the
end user video.
Figure 11 . Video transmission example using the H .264

Adaptive Cross - Layer Algorithms for Multimedia Data Transmission and Power

Management in Wireless Networks.
ENERGY MANAGEMENT ALGORITHM FOR DATA TRANSMISSION USING THE PROTOCOL TFRC
CHAPTER 4: ALGORITHMS ENERGY

MANAGEMENT FOR DATA TRANSMISSION
USING THE PROTOCOL TFRC
ALGORITHMS ENERGY MANAGEMENT FOR DATA

TRANSMISSION USING PROTOCOL TFRC
This chapter is a description of the mechanism which was developed as part of a diplomatic, ie a
brief theoretical approach and analysis of the technical part .
4.1 DESCRIPTION OF THE PROBLEM

In recent years developed a number of new protocols for multimedia applications at all levels of the
OSI network architecture. The family of protocols MPEG involves encoding and compressing
multimedia data. The MPEG -4 protocol improvements FGS ( Fine granularity Scalability ), AVC (
Advanced Vi deo Coding ) and SVC ( Scalable Video Coding ) provides adaptive video coding ,
taking into account the available bandwidth and should be used by many multimedia applications.
In addition, the congestion control and TCP - friendliness ( TCP - fr iendliness ) create additional
design requirements which are extremely volatile ( " shark teeth " - like ) , for the transmission rates
and is very difficult to achieve by the encoders and decoders video and audio. The congestion
control mechanism of TCP creates high variations in transmission rates, which do not match the
existing video and audio codecs, which require predictable and stable bandwidth allocation.
Therefore, development of protocols such as TFRC can be seen as a step to improve multimedia
transmission. The TFRC aims to achieve equivalent throughput as the UDP , without stifling other
TCP flows. One way to cope with temporary fluctuations in data rates is to use buffers to recipients.
However, an initial pre-loaded to the data buffer more than 8 seconds before the user plays the flow
is not easily accepted by the end user. In addition to video applications in real time big data pre-
loading is not feasible. For multimedia applications, the smooth and stable transmission rates and
low delays are most important features of the guaranteed and in correct order delivery of data
packets .
The objective of the proposed mechanisms is to minimize or eliminate packet losses, since even a
small percentage of packet loss can lead to a significant reduction in the quality of multimedia end-
user and result in a poor user experience. Improvements in both these areas lead to improved
metric multimedia such as PSNR ( Peak Signal to Noise Ratio ) and MOS ( Mean Opinion Square )
Which represent better and more objective end-user experience. At the same time it must make
sure that the energy consumption is bounded only increases when results marked a yxisi the video
quality. As shown in the figure below and the two devices use the same cross - layer design. In
TFRC provided a new interface to be able to take as the transmission power.
Figure 12 . Recommended cross - la yer planning for mechanisms MIMD and Binary
4.2 DESCRIPTION OF THE MECHANISM MIMD
4.2.1 Identification of the facility
The mechanism of cross - layer shown using information provided by the Protocol TFRC is a third
level and a protocol used at the transport layer and acts upon the physical plane in order to adjust
the energy with which the packet is transmitted. The parameters included in each layer include the
transmission power of the physical layer and the information on the packet loss rates at the
transport layer.
The proposed mechanism uses the TFRC sender reports from the receiver to calculate the loss
rate of packets. The algorithm considers only a fixed number of packet losses as based on last 5
receiver reports to better adapt to most new network conditions. Additionally, if the packet loss rate
increases above a predetermined limit then the power is increased by a percentage, but if the packet
loss rate falls below another predetermined limit then the power is reduced by an amount for
effective energy management reasons. Furthermore, the power consumption has a lower limit which
protects the base station by interrupting the transmission, and an upper limit that prevents excessive
power consumption.
4.2.2 The algorithm MIMD
To create the interface proposed mechanism required several modifications to the network
simulator ns -2. First, a module that implements the logic of the proposed mechanism was added to
the simulator. Such a section is summarized in the following paragraph.
The logic followed as follows : Initially, a check of the packet loss rate which we obtained from the
TFRC , The way in which this is done we present below, and if the check shows that exceeds the
limits we set then increase by an amount of energy which is transmitted in each packet. If the check
shows a large reduction of packet loss rate reduces power so as not to waste resources of the node
transmitting. Moreover, an important step for the improvement of resources is the fact that the
mechanism allows to exist and an acceptable range in the loss rate of packets, which after several
measurements observed that does not affect the final quality of the transmitted video. Below the
mechanism shown in a more compact form using pseudocode. The PL symbolizes packet loss as a
percentage v ( packet LOSSES ) and TP denotes transmission power ( transmission power ) while
the A > 1 and 0 <B <1.
Figure 13 . Mechanism of control of packet loss and power adjustment
After extensive experimentation with the values of A , Breakfast and limits reached in the values A
= 1.05, B = 0.05 and Threshold _1 = 0.1 and Threshold _2 = 0.075 parallel led to good values for
the PSNR and a limited power consumption. Prices for Upper _ Bound and Lower _ Bound
discussed in the experimental field.
Then they had to make changes to the track of TFRC to provide the information described above,
the packet loss rate which occurs through a mechanism that is part of TFRC and the feedback made
by the recipient to the node that transmits on packets received. Using the above mechanism was
implemented a new mechanism that allows the packet loss rate at any given time and not on the
total number of packets and which was also incorporated in the module TFRC .
The mechanism end calculates the energy required for the improvement of PSNR and then this
information is transferred to the modified section of the physical layer which has been modified to
be able to increase or decrease the packet transmission power computed the mechanism.
4.3 O algorithm Binary

The second proposed algorithm is the algorithm Binary. The Binary algorithm uses the TFRC
receiver reports to the sender in order to calculate the rate of loss of packets. The algorithm
considers only a fixed number of previous packet loss, so they are more adaptive to the latest
network conditions. This cross-layer mechanism uses information provided by the TFRC protocol
that is layer protocol 4 (transport) and acts at the level 1 (physical layer) to adjust the transmission
power. The parameters involved in each plane include the transmission power in the physical level
(level 1) and the packet loss information to the transport layer.
Figure 14 . Finite automatic for the proposed mechanism of the sender.
The finite automaton illustrated in Figure 13 It is the mechanism used by the video sender through
TFRC. Every time the sender receives a reference TFRC (TFRC report) by the receiver changes its
state according to the state which is the new data. The device having received the first report, if the
packet loss is not satisfactory, defines an area where it will try to reach the optimal effect. The
optimum power is that which produces a desired packet loss rate. After designating the area, the
sender increases the strength of the maximum of this area and sends the next packet TFRC to this
effect (A mode). When the sender receive the next report examines whether there has been
significant improvement.If there has been improving and the packet loss is below a predetermined
threshold switches to state C or else repeats the operations of the condition a. In the state C, the
mechanism raises the power to the average of the specified region and the sender proceeds to state
D. In state D, the algorithm checks whether packet loss criteria are met even if so repeats the state
C. If not, the algorithm moves to state E which makes setback in prior known acceptable value j
schyos. The mechanism remains in state E as the packet loss rate is acceptable and if not returns to
state A. Shown below is a summary of the automatic response:mechanism puts the power to the
average of the specified region and the sender proceeds to state D. In state D, the algorithm checks
whether packet loss criteria are met even if so repeats the state C. If not, the algorithm proceeds to
R which makes condition regression to previous known acceptable power value. The mechanism
remains in state E as the packet loss rate is acceptable and if not returns to state A. Shown below is
a summary of the automatic response:mechanism puts the power to the average of the specified
region and the sender proceeds to state D. In state D, the algorithm checks whether packet loss
criteria are met even if so repeats the state C. If not, the algorithm proceeds to R which makes
condition regression to previous known acceptable power value. The mechanism remains in state E
as the packet loss rate is acceptable and if not returns to state A. Shown below is a summary of the
automatic response:The mechanism remains in state E as the packet loss rate is acceptable and if
not returns to state A. Shown below is a summary of the automatic response:The mechanism
remains in state E as the packet loss rate is acceptable and if not returns to state A. Shown below is
a summary of the automatic response:
Fibrates: Several initialization
A: Expansion of "power range" and application of

the maximum power of the region and finally switch
to B mode.
B: Improve and test constraints. If they kept

switches to C, otherwise the situation A.
C: lowers the consumption of the average of the

specified power range, and switches to state D.
D: If all constraints are satisfied, switches to C,

otherwise goes to E mode.
E: regressing the last permissible power value and

remains there as long as the packet loss is acceptable
otherwise switches to A.
4.4 Implementation mechanisms

The testing and evaluation of new cross - layer architectures in real networks will require large
investments in software development and very often in technical equipment. Moreover, they would
require large equipment for bringing large-scale experiments, with multiple sources and destinations
of different types. Therefore, the tests in real network is too costly for most research institutions, at
least for the early stages of developing a mechanism. The tests in a simulated environment is a more
convenient and economical solution for evaluating new cross - layer architectures. In this thesis the
simulator used is the Network Simulator 2 ( ns -2.30) [17] and was the main tool for simulating
video transmission over wireless channels.
4.4.1 Evaluation video

For the simulation of the transmission of MPEG -4 videos using ns -2 used and another software
package named Evalvid - RA ( rate - adaptive ) [18] , [19] . This tool as its name supports
multimedia transmission which adapts during transport and is based on the creation of some "
tracefile " an MPEG video. A typical " tracefile " provides information on the frame number (
frame ) , Frame type, size, segmentation data and the timing for each frame (frame) of the video.
Transferring media is simulated using the " tracefile " rather than using the actual binary content
multimedia. The simulator maintains its own " tracefile " containing information on the timetable
and the throughput of packets at each node during the simulation. Combining this information and
the real " videofile " tool Evalvid - RA can reconstruct the " videofile " as if it had spread over a
real network. Furthermore, using the Evalvid - Ra total noise introduced can be measured (in dB
PSNR ) as well can be calculated and the "average human opinion ( Mean Opinion Score ) . One
such embodiment is shown in [20] .

EXPERIMENTS
CHAPTER 5: EXPERIMENTS
5.1 Experiments Environment ( Testbed)

For the experiments we used our software Network Simulator 2 ( ns -2.30) [17] as an essential tool
for transmitting multimedia data to simulate wireless networks.
To simulate transmission hotel video MPEG -4 using ns -2 need additional software called Evalvid -
RA ( [19] ) . The Evalvid - RA supports multimedia transmission with adjustable bit rate ( rate -
adaptive transmission ) based on producing a trace file ( trace file ) from a file video MPEG . A
typical trace file provides information on the number of frame , the number of the frame , type of
frame , the size, cutting into pieces ( segments being ) and the timing of each frame of a file hotel
video . The media broadcast is simulated using the trace file rather than the file itself video . The
simulator uses its own trace files that maintain information about the timing and throughput (
throughput ) in each node during the simulation. Combining this information and the original file
video the Evalvid - RA can recreate the file video such as would be obtained from a real network.
Additionally, using the toolbox Evalvid - RA the total noise has been introduced can be measured (
in dB PSNR ) and the MOS ( Mean Opinion Score ) can be measured. An exemplary embodiment
exists in [20] . The process shown schematically in Figure 15 .
It took several changes of network simulator in order to implement the proposed mechanisms.
Initially, they added modules that contain logic mechanisms . Then changes were made in the
module that implements the TFRC to provide information about packet loss mechanism. The
device calculates the strength needed to improve the PSNR and then this information is sent to the
modified module of the physical layer which increases or decreases the power according to the
mechanism.
The topology shown in was used in the experiments Figure 14 . The video broadcast for the
purpose of the experiment is part test suite video called akiyo , can be found in [21] .
Figure 15 . topology Mechanism
The simulation environment consists of three parts as shown in Figure 15 . At the stage of pre-
treatment ( pre - Process ) a record video which is usually in the form of YUV encoded 30 different
MPEG -4 video with quantizer scale values of 2 to 31. The scale 2 gives the best quality. We use
then the encoder video ffmpeg [22] for the creation of files video . In our simulations, all video have
temporal resolution 25 frames / sec and Gop ( Group of Pictures ) IBPBPBPBPBPB size 12 frame
. The size of the frame all files video is 352 x 288 pixels which is also known as the Common
Intermediate Format ( CIF ) . Since all encoded files, they produced 30 different trace files . At the
end of the pretreatment phase, we have 30 m 4 v files with the corresponding trace files their.
Figure 16 . Total video transmission process in the simulator.
Briefly, the file video underwent pretreatment during which produced many records video of
different quality and resolution using the tool ffmpeg and other scripts toolbox of Evalvid - RA .
After production was the trace files and then became emulation through scripts of ns -2 to
assimilate the broadcast video on a wireless network using the protocol TFRC . After the simulation
of the transmission of video in different resolutions, they produced new trace files used to
reconstruct records video as we were sent to a real network.
The third part of the simulation environment consists of reconstructing records video and use
metrics to the new file. The reconstruction of downloaded files video is off - line by comparing the
transmitted video with the trace files download. At this stage are many metrics such as PSNR ,
MOS , jitter , throughput , Delay . Using the above procedure we can make many comparisons
between algorithms and draw conclusions on the effectiveness of each.
5.2 Scenarios assessment

In experiments conducted in ns -2, transferring H.264 video using mulit Protocol TFRC to wireless
links and in particular to a wireless single - hop ad - hoc network. In order to model the various
quality downgrades, a series of experiments were done with different scenarios with mobile and
stationary nodes. After compared the throughput achieved by metrics PSNR , packet loss and
energy consumption. Objective measurements PSNR can be assigned to subjective metrics MOS (
Mean Opinion Score ) using a mapping table such as Table 1 .
PSNR [dB] MOS Deformation
> 37 Excellent (5) no observable
31-37 Good (4) Noticeable but

not annoying
25-31 Moderate (3) slightly annoying
20-25 Poor (2) inconvenient
<20 Bad (1) very annoying
Table 1 . Assigning metrics PSNR to MOS
In mechanism MIMD the Lower _ Bound ranged from 0.02 to 0.04 and it 's Upper _ Bound from
0.06 to 0.1. In experiments 1 and 2 Experiments were performed with different Lower _ Bound and
's Upper _ Bound each time increasing by 0.01 in each experiment. The results are as shown by
Table 2 .
Scenario 1: 2 nodes stable
Scenario 2: two nodes, one fixed, one moving away
Scenario 3: two nodes, one fixed, one approaching and then removed
Scenario 4: two nodes, one fixed, one approaching
Scenario 5: two nodes, one fixed, one approaching removed and xanaplisiazei
Scenario 6: two nodes, one fixed, one removed and then stops
Scenario 7: two nodes, one fixed, one approaching and then stops
Scenario 8: two nodes, one fixed, one moving randomly
Repeat each script three times, once with no power management, once using the mechanism MIMD
and once using the algorithm Binary . The nodes moving at speeds up to 6 m / s in the scenarios.
Then compare the throughput in terms of PSNR , packet loss and power consumption.
5.3 Experiments
Performed 8 above scenarios and became export ratio PSNR to average power in each experiment.
For mobile nodes, speeds ranging from 1 m / s to 6 m / s in steps of 1 m / s and the values shown
below correspond to the average of all experiments. The aim is to maximize this ratio since the
larger the value, the better the performance. Indeed, a large value means more average PSNR or
lower average consumption or both. The method Binary has better results than the MIMD and
scenarios without mechanism.
Normal MIMD Binary
PSNR / PSNR / PSNR /

Scenario Power Power Power
1: 669.2 813.1 790.1
2 666.4 769.4 782.5
3: 662.2 759. 8 798 . 8
4: 676 . 2 798 . 9 814 . 8
5: 671 . 8 800 . 3 789 . 7
6: 666 . 4 769 . 4 782 . 5
7: 669 . 2 813 . 1 790 . 1
8: 919 . 3 902 . 3 968 . 4
Average: 700 . 9 803 . 3 814 . 6
Standard
deviation: 88 . 66 45 . 06 63 . 02
Table 2 . results scenarios
Below are presented graphs for each scenario and shown and the linear approach to elucidate the
behavior of the device under different circumstances. It is worth noting that in many cases as
shown in the process diagrams Binary achieves "Excellent" quality according to conversion metrics
PSNR to MOS and other methods of achieving the very "Good" quality.
Figure 17 . Scenario 1: 2 nodes stable
In the first scenario, and two nodes are fixed so the power requirements do not change.
Nevertheless mechanisms MIMD and Binary offering better reason PSNR / medium power. The
proposed mechanisms are highly adept at exploiting the available power. For a given amount of
transmit power, the mechanism Binary has clear advantage over the MIMD and issuing no
mechanism in relation to the quality achieved (in terms of PSNR ). For example, as shown in the
graph, an average transmission power of about 0.03, all the mechanisms achieve a PSNR about 34 is
considered "Good". But when this average power is doubled, the mechanism MIMD achieves
slightly better results, about 36 while the mechanism Binary achieves PSNR 41 which is considered
'Excellent' quality.
The same remarks apply when a node is removed. This time, the mechanism MIMD also shows a
measurable advantage over the simple approach without mechanism. The method Binary however
converges faster and closer to an optimum power value needed to reduce packet loss and thus
achieves better PSNR at the same average power. This scenario is ideal for MIMD and Binary
because the traffic is monotonously increasing and can find very good trade - off video quality and
energy consumption.
Figure 18 . Scenario 2: two nodes, one fixed, one moving away
Due to the increased proximity of nodes in scenarios 3 and 4, even the simple transmission can
achieve good performance but was unable to compete with the methods MIMD and especially
Binary which adjust the power consumed . The Binary as the most adaptive achieves much better
PSNR even for low average power prices.
Figure 19 . Scenario 3: two nodes, one fixed, one approaching and then removed
Figure 20 . Scenario 4: two nodes, one fixed, one approaching
When a node is approaching naturally achieves better PSNR in all methods. Using too fast power
adjustment methods even better results are achieved. Also, the method of Binary achieves
"Excellent MOS for force of 0.04 or more. In this scenario, the advantage of MIMD compared
with the simple less after the node is approaching and thus requires less power and a simple
mechanism suffices.
In scenarios with more complex movements the bottom line remains the same. The method Binary
shows significant performance increase usually gives excellent results considering the PSNR . H
method MIMD provides intermediate results and the simple transmission suffers both from the
quality of the transmitted image and of power consumed.
Figure 21 .Senario 5: two nodes, one fixed, one approaching and then removed
Figure 22 . Scenario 6: two nodes, one fixed, one removed and stops
Figure 23 . Scenario 7: two nodes, one fixed, one approaching and stops
Where nodes stop moving, methods MIMD and Binary adapted to consume the least possible
energy without sacrificing the quality of the video . Indeed, for the same PSNR , the MIMD and
Binary consume less energy and force the 0.05 Binary method achieves excellent results.
Figure 24 . Scenario 8: two nodes, one fixed, one moving randomly
When a node moves randomly, the results show that all mechanisms tend to show similar behavior
for power values up to 0.04. Above this value method Binary again has big advantage and gives
excellent results. The fact that in this scenario of efficiency gains is not like previous scenarios
explained by the fact that adaptive methods need time to adapt (adjust every time you take a TFRC
report ). The random movements tend to change quickly and it is these assumptions underlying
adaptive behavior. Thus, the adaptive methods ( MIMD , Binary ) They tend to have better
performance in cases where the traffic changes made in longer than TFRC report round trip time .

CONCLUSIONS
CHAPTER 6: CONCLUSIONS

CONCLUSIONS
CONCLUSIONS
We observe that by adding a simple cross - layer mechanism , to energy management in wireless
transmissions using the protocol TFRC , we can significantly improve both the objective quality of
the transmitted video and improve the energy used for transmission. The cost of complexity to
implement the mechanism observed to be quite small and the only thing left for improvement are
fluctuations in prices PSNR . The evaluation and control process proposed in this thesis is suitable
for further experimentation. Using the base of the generated code and the test procedure described
could easily be controlled and many different algorithms are evaluated.
In this thesis we proposed 2 cross - layer mechanisms for power management in wireless TFRC
transmissions that significantly improve the objective quality of the transmitted video and make
better use of available power compared with traditional static approach. The approach of energy
management mechanism MIMD has many benefits in performance compared to the static
approach, although significantly smaller mechanism Binary . Additionally, the mechanism MIMD is
stateless and very easy to implement and are therefore ideal for integration into very small capacity
systems. The method Binary It uses a more complex algorithm that improves the quality of the
transmitted video and power consumption significantly compared with the mechanism MIMD and
simple method without mechanism. The complexity cost of the mechanism Binary is relatively
small as shown by the embodiment of the emulator ns -2.
The cross - layer architectures are of particular interest in the field of video transmission, especially
in combination with the mechanisms provided by the standard H .264 , and could be evaluated
based on the platform created.

FUTURE WORK
CHAPTER 7: FUTURE WORK
FUTURE WORK
Future work that can be done having as a basis the results of this work includes extension of
existing mechanism developed and the automated management and evaluation tools that were
created during the experiments.
The proposed cross - layer mechanism could be improved over a wide range. Some ideas are
presented below :
1. This mechanism could be extended to take into account of the metric PSNR together with
the percentage of packet loss and adjusts the transmission rate, energy and the transmitted
video quality to optimize the perceived quality of the video by the end user.
2. An important extension is to test the device with multiple transmitters and multiple receivers.
3. Using the capabilities of H .264 one can change the video quality to dynamically adjust the
transmission rate according to the available bandwidth.
4. Furthermore, the transmission of multimedia data rates may not be followed by the
respective encoders and decoders. The use of large buffer in order to more smoothly
transition due to rapid changes in transmission rates is not always an option, especially for
multimedia applications with high interactivity such as a videoconference. As a conclusion to
reduce distortion of coding / decoding provides smooth transmission rates while taking into
account the long-term justice on the consumption of available bandwidth.
5. In conclusion to note that the special treatment I - frame (frame) of the video sequence can
lead to significant improvement in video quality, which becomes especially noticeable over a
congested network.
6. Additional work should be done on hybrid networks whose characteristics are given below :
The features of hybrid networks is quite different compared to networks that are exclusively
wireless or wired so that the application cross - layer architecture is not as easy as the improvement
that we want to achieve is different for each network segment.
cross - layer ,

.
proxy
cross - layer
backbone proxy host
and other nodes as a client . Naturally they would enter and other restrictions such as moving from
host to host and several others. A topology of a hybrid network is presented below.
Figure 25 . hybrid network

BIBLIOGRAPHY
CHAPTER 8: BIBLIOGRAPHY

BIBLIOGRAPHY
BIBLIOGRAPHY
[1] "Video Transmission over TFRC using cross-layer power management", 17th International
Conference on Software Telecommunications and Computer Nerworkos, Hvar, Croatia, C.
Christos Bouras, Vaggelis Kapoulas, Apostolos Gkamas, Kostas Stamos, Vassilis
Papapanagiotou, Zaoudis Giannis 24-26 September 2009.
[2] "Efficient Power Management Adaptation for Video Transmission over TFRC", The Sixth
International Conference on Advanced Telecommunications AICT 2010, Christos Bouras,
Vassilis Papapanagiotou, Kostas Stamos and Giannis Zaoudis - Split May 9 - 15, 2010 -
Barcelona, Spain
[3] "Power Management Adaptation Techniques for Video Transmission over TFRC", International
Journal of Network Management, John Wiley & Sons, Ltd (to appear)
[4] M. van der Schaar, D. Sai Shankar N, "Cross-Layer wireless multimedia transmission:
Challenges, Principles and new paradigms", IEEE wireless Communications, Aug. 2005
[5] V. Tsaoussidis, H. Badr, TCP-Probing: Towards an Error Control Schema with Energy and
Throughput Performance Gains 8th IEEE Conference on Network Protocols, Japan ,
November 2000
[6] C. Zhang and V. Tsaoussidis, TCP Real: Improving Real-time Capabilities of TCP over
Heterogeneous Networks 11th IEEE/ACM NOSSDAV , NY , 2001
[7] Christine E. Jones, Krishna M. Sivalingam, Prathima Agrawal, Jyh Cheng Chen. A Survey of
Energy Efficient Network Protocols for Wireless Networks. Wireless Networks. Volume 7,
Issue 4 (Aug. 2001). pp. 343-358
[8] IEEE 802.11 PSM Standard. Power Management for Wireless Networks. Section 11.11.2
[9] Dave Molta. Wi-Fi and the need for more power. Network Computing. December 8, 2005 .
[10] Huan Chen and Cheng-Wei Huang. Power management modeling and optimal policy for
IEEE 802.11 WLAN systems. IEEE Vehicular Technology Conference 2004 .
[11] G. Anastasi, M. Conti, E. Gregori, A. Passarella. A performance study of power-saving

polices for Wi-Fi hotspots. Computer Networks: The International Journal of Computer and
Telecommunications Networking. Volume 45 , Issue 3 (June 2004). pp. 295-318. 2004
[12] T. Simunic, Power Saving Techniques for Wireless LANs, Conference on Design,
Automation and Test in Europe - Volume 3. pp. 96-97. 2005
[13] Bozidar Radunovic, A Cross-Layer Design of Wireless Ad-Hoc Networks, Ph.D. Thesis,
July 2005
[14] Yufeng Shan, Zakhor, A., Cross layer techniques for adaptive video streaming over wireless
networks, IEEE International Conference on Multimedia and Expo, 2002 (ICME '02) ,
Volume: 1, pp 277- 280
[15] Jie Chen , Tiejun Lv , Haitao Zheng Cross-layer design for QoS wireless communications,
2004 International Symposium Circuits and Systems, 2004. ISCAS '04, 23-26 May 2004
Volume: 2, pp. II- 217-20
[16] Xiaojun Lin , Shroff, NB , Srikant, R. ,A tutorial on cross-layer optimization in wireless

networks, Selected Areas in Communications, IEEE Journal, Aug 2006, Volume: 24, Issue: 8
,On page(s): 1452-1463
[17] Li, X. , Wu, X. , Li, W. , Wang, X. , An adaptive cross-layer scheduling algorithm for
multimedia networks, 4th International Conference on Intelligent Information Hiding and
Multimedia Signal Processing, IIH-MSP 2008, art. no. 4604006, pp. 52-55
[18] Warrier, A. , Le, L. , Rhee, I. , Cross-layer optimization made practical, 4th International
Conference on Broadband Communications, Networks, Systems, BroadNets, art. no. 4550507,
pp. 733-742
[19] M. Handley, S. Floyd, J. Pahdye and J. Widmer, TCP Friendly Rate Control (TFRC):
Protocol Specification, RFC 3448, January 2003
[20] http://www.isi.edu/nsnam/ns/
[21] Arne Lie, Jirka Klaue, Evalvid-RA: Trace Driven Simulation of Rate Adaptive MPEG-4
VBR Video, Multimedia Systems, Springer Berlin / Heidelberg , Volume 14, Number 1 /
June, 2008, pp. 33-50
[22] Evalvid-RA, http://www.item.ntnu.no/~arnelie/Evalvid-RA.htm
[23] Torgeir Haukass, Rate Adaptive Video Streaming over Wireless Networks Explained &
Explored, MSc thesis, Norwegian University of Science and Technology, Department of
Telematics
[24] http://media.xiph.org/video/derf/
[25] http://www.ffmpeg.org/
[26] K. Klues, Power Management in Wireless Networks, Report, for Advanced Topics in
Networking: Wireless and Mobile Networking by R. Jain, Wash. Univ. in St. Louis , 2006
[27] http://ru6.cti.gr/ru6/research_ns.php
[28] M. Handley, S. Floyd, J. Pahdye and J. Widmer, TCP Friendly Rate Control (TFRC):
Protocol Specification, RFC 3448, January 2003
[29] Il-Min Hyung Kim and-Myung Kim "An Optimum Power Management Scheme for Wireless
Video Service-In CDMA Systems", IEEE Transactions on Wireless Communications on, Vol.
2, No. 1, January 2003
[30] Nicholas H. Zamora, Jung-Chun Kao, Radu Marculescu, "Distributed Power-Management

Techniques for Wireless Network Video Systems", Design, Automation & Test in Europe
Conference & Exhibition, pp. 1-7, 16-20 April 2007.
[31] ITU-R Recommendations BT.500-11. Methodology for the subjective assessment of the quality
of television pictures (2002)
[32] Klaue, J., Rathke, B., Wolisz, A .: "EvalVid-A framework for video transmission and quality
evaluation." In: Proceedings of the 13th International Conference on Modeling, Techniques
and Tools for Computer Performance Evaluation, Urbana, Illinois (2003)
[33] M. Srivastava "Cross-Layer Design: A Survey and the Road Ahead", IEEE Communications
Magazine, Dec. 2005
[34] S. Shakkottai, TS Rappaport, and PC Karlsson, "Cross-Layer Design for Wireless Networks,"
IEEE Commun. Mag., Vol. 41, no. 10, Oct. 2003, pp. 74-80.
[35] D. Chiu and Raj Jain, "Analysis Research of the education@ecb.europa.eu Increase / Decrease
Algorithms for Congestion Avoidance-In Computer Networks," the Journal of Computer
Networks and ISDN, Vol. 17, No. 1, June 1989, pp. 1-14
[36] J. Zhang, Wu D., S. Ci, H. Wang and A. Katsaggelos, "Power-Aware Mobile Multimedia: al
Survey" the Journal of Communications, Vol. 4, No. 9, October 2009.
[37] Z. Li, F. Zhai, and A. Katsaggelos, "Joint hotel video summarization and transmission
adaptation for Energy-Efficient wireless hotel video streaming," EURASIP the Journal on
Advances-In Signal Processing, 2008.
[38] E. Kohler, M. Handley, S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC
4340, March 2006

ANNEX
CHAPTER 9: APPENDIX
9.1 platform installation and analysis of mechanism

To install the device initially visit the website http : // ru 6. cti . gr / ru 6 / Research _ ns . php
from which you download the package that is in the section Extensions to TFRC code
where are all the script and codes that are essential for the proper functioning of the
mechanism. The automated process is relatively long as you follow properly the first time the
instructions given below :
1. Unzip these files and move to folder
/ns-allinone-2.30/ns-2.30

tcp/ :
tfrc-rateAdjust.cc
tfrc-rateAdjust.h
tfrc-rateAdjust2.cc
tfrc-rateAdjust2.h
rateAdjuster.cc
rateAdjuster.h
rateAdjuster2.cc
rateAdjuster2.h
tfrc-backup.cc
tfrc-backup.h
make Normal . sh make Adjust . sh ,

makeAdjust 2. sh ns -2 .
2. /ns-allinone-2.30/ns-
2.30/mac/
wireless-phy_rateAdjust.cc
wireless-phy_rateAdjust.h
wireless-phy_rateAdjust 2 . cc
wireless-phy_rateAdjust 2 .h
wirelessAdjust.sh
wirelessAdjust2.sh
wirelessNormal.sh
wireless-phy-backup.cc
wireless-phy-backup.h
wirelessAdjust . sh wirelessNormal . sh
.
3. /ns-allinone-2.30/ns-2.30/
makeAdjust .sh
makeAdjust2.sh
makeNormal .sh
4. !!!!! script back -

up (
) :
back - up :
tfrc.cc -> tfrc-mybackup.cc
tfrc.h -> tfrc-mybackup.h
wireless-phy.cc -> wireless-phy-mybackup.cc
wireless-phy.h -> wireless-phy-mybackup.h
5. Now you are ready to use our device, just run the script makeAdjust. sh and mechanism
MIMD fully activated on your system. If you want your original system is sufficient to
run the script makeNormal. sh and restores the original settings. Respectively for the
mechanism Binary, running makeAdjust2.sh
9.2 Using apparatus and video evaluation

In this part of the thesis give detailed mechanism of instructions, which if followed the procedure
described above, can be activated with a single command. At this stage we should start the steps to
make the transmission :
1. Firstly create a folder, which will be your working folder. In this working folder you
store your programs, script simulation and tracefiles arising from the pre-processing.
In our experiments the working folder like this :
" /root/ns-allinone-2.30/ns-2.30/tcl-examples "
2. Now we need to create the files . m 4 v with different qualities. This will create files
which have different requirements on bandwidth. The best quality is set quantization
q = 2 and the lower q = 31. These files will be used by the MP 4 program that
generates files st_ $ 3_Q $ i.txt . We will need these files during preprocessing. The
server selects the next GoP ( Group of Pictures ) from one of these based on network
conditions. We use the script manyQ . sh to create these files. We need to give the
path to the program MP 4 . For the experiments we operate as follows ?
MP4 = / root / ns-allinone-2.30 / ns-2.30 / tcl-examples / MP4
where / root / ns - allinone -2.30 / ns -2.30 / tcl - examples the path for the
folder of work you . Modify this path according to your own system .
CAUTION : If used . exe executable files you need to download the wine for LINUX
the link : http : // www . winehq . org /
Epileon will need the Ffm Peg , which can be found on the link : http : //
ffmpeg . mplayerhq . hu /
End download files yuv the link : http : // trace . eas . asu . edu / yuv /
index . html
After finishing the installation of wine and ffmpeg you should run the following
commands :
./ manyQ . sh 2 31 concat _ cif . yuv
Wherein contact _ cif . yuv is the video in YUV format . We can use the command
cat to combine more than one yuv files :
cat file1.yuv file2.yuv> concat.yuv
This video is encoded by a ffmpeg mpeg4 video. Therefore, now you 30 MPEG 4
video files. The program MP 4 transmits these files and retains traces in the form
st_concat_cif.yuv_Q $ i.txt . We need these traces for both the pretreatment and the
post-operation.
3. Now it is time to execute the simulation scenario . To " one _ hop _ wireless . Tcl " is
a simple script that transmits a sender to a recipient a video file. We use the protocol
TFRC for transmission as well as the feedback functions between the recipient and
the sender. You can modify this script to examine various experiments.
4. You can use the script us to "save" time, which are located in the folder /ns-
2.30/experiments/ and are structured as follows :
run.sh a simple script that is used by several other script
guides . sh a simple script automatically after-treatment ( will be created

immediately all folders with necessary information such as bytes transmission,
PSNR , delay or packet loss rates)
average.sh uses the run . sh and gives results in average fuel consumption of
energy.
print_power.sh uses the run . sh and gives current energy prices so we can
create charts that are better for an intuitive understanding
clean _ remake . sh clean , rebuild ns ,

runExp 1. sh , runExp 2. sh , runNormal . sh

psnr log .
-
- ,
. script
.
1. script guides . sh ,
,

2. (
tracefiles ) . sd _ be _0 ( tracefile )
rd _ be _0 ( tracefile ) . et _ ra
.
:
et_ra sd_be_0 rd_be_1 st_concat_cif.yuv_Q2.txt video2.dat concat_cif.yuv_Q 2 31

frame_size.dat test1.m4v 01
OUTPUTS:
*** loss_01.txt ***: percentage of lost [frames|packets]
column 1: I
column 2: P
column 3: B
column 4: overall
*** delay_01.txt ***: delay statisctics in seconds
column 1: frame number
column 2: lost flag (1 when frame is lost)
column 3: End-to-end delay
column 4: Intra-frame sender delay
column 5: Intra-frame receiver delay
column 6: Inter-frame delay (Jitter delay)
comumn 7: Cumulative jitter
*** test1.m4v ***
3. test 1. m 4 v yuv
test 1 . yuv
ffmpeg -r 25 -i test1.m4v -vcodec rawvideo test1.yuv
4. PSNR
wine psnr.exe 352 288 420 concat_cif.yuv test1.yuv > psnr_1.txt
PSNR [dB] MOS

>37 Excellent (5) -
31-37 Good(4) -
25-31 Fair(3) -
20-25 Poor(2) -
<20 Bad(1) -
3 . PSNR MOS
5.
:
wine YUVviewer.exe
9.3 MIMD
rateAdjuster1.h
#ifndef RATE_ADJUSTER_H
#define RATE_ADJUSTER_H

class rateAdjuster {
private:
//to input einai to pososto tou packet loss
double input;
//to threshold einai to ano orio
double threshold;
//to output einai to epithymito power
double output;
//to coeff einai o syntelestis auksisis i meiosis tou output
double coeff;
//H adjust ypologizei to output synarthsei tou input
void adjust ();

public:
rateAdjuster (double initialPower) {output = initialPower;
coeff = 0.05; threshold = 0.05;}
rateAdjuster (double initialPower, double initialCoeff)
{output = initialPower; coeff = initialCoeff; threshold = 0.05;}
rateAdjuster (double initialPower, double initialCoeff,
double mInput) {input = mInput; output = initialPower; coeff = initialCoeff;
threshold = 0.05;}

double mInput, double initialThres) {input = mInput; output = initialPower;
coeff = initialCoeff; threshold = initialThres;}
void setInput (double mInput) {input = mInput;};
void setThreshold (double thres) {threshold = thres;};
double getOutput () {adjust (); return output;};
}?
#endif

rateAdjuster1.cc
// rateAdjuster mechanism
// by Vassilis Papapanagiotou and Giannis Zaoudis
// 14.04.2009

#include "rateAdjuster.h"
#include <cstdio>

inline double dabs (double a) {
return a> = 0? a: -a;
}
// function to check the current loss_rate
void rateAdjuster :: adjust () {
if (input> threshold) {
// if not adjust the power by a coefficient of our choice
(currently 5%)
output + = coeff * output;
// upper bound to prevent excessive consumption
if (output> = 0.04) output = 0.04;
printf ( "RATE adjuster: Increase power! \ n");

} Else if (input <(0.75 * threshold)) {
// we have an area currently 7.5-10% where loss_rate is
acceptable
output - = coeff * output;
// lower bound to prevent the base station from halting the
transmission
if (output <= 0.02) output = 0.03;
printf ( "RATE adjuster: MEIONO to power! \ n");
}
}
9.4 Implementation of Binary mechanism:

rateAdjuster2.h
#ifndef RATE_ADJUSTER_H
#define RATE_ADJUSTER_H

class rateAdjuster {
private:
// to input einai to pososto tou packet loss
double input_packet_loss;
double input_power;
// to threshold einai to ano orio
double threshold;
// to output einai to epithymito power, edo yparxei i
proigoumeni timi tou power kai tithetai i kainouria
double output_power;
// to coeff einai o syntelestis auksisis i meiosis tou output
double coeff;
// H adjust ypologizei to output synarthsei tou input
void adjust ();
// static rateAdjuster * inst;
enum possibleStates {STATE_A, STATE_B, STATE_C,
STATE_D, STATE_E, PRE_STATE};
possibleStates currentState;
double low_region, upper_region, low_current_region,
upper_current_region, region_length, previous_packet_loss, init_packet_loss;

public:
rateAdjuster (double initialPower) {input_packet_loss =
initialPower; coeff = 0.05; threshold = 0.05; currentState = PRE_STATE;}
rateAdjuster (double initialPower, double initialCoeff)
{input_power = initialPower; coeff = initialCoeff; threshold = 0.05;
currentState = PRE_STATE;}
double mInput) {input_packet_loss = mInput; input_power = initialPower;
coeff = initialCoeff; threshold = 0.05; currentState = PRE_STATE;}
double mInput, double initialThres) {input_packet_loss = mInput;
input_power = initialPower; coeff = initialCoeff; threshold = initialThres;
currentState = PRE_STATE;}
void setInput (double mInput) {input_packet_loss =
mInput;};
void setThreshold (double thres) {threshold = thres;};
double getOutput () {adjust (); return output_power; }
}?
#endif

rateAdjuster2.cc
// rateAdjuster mechanism
// by Vassilis Papapanagiotou
// 15-06-2009

#include "rateAdjuster.h"
#include <cstdio>

inline double dabs(double a){
return a>=0?a:-a;
}
//function to check the current loss_rate
void rateAdjuster::adjust(){
if(currentState == PRE_STATE){
printf("Eimai sto PRE_STATE!\n");
region_length = 0.02;
low_current_region = low_region = input_power -
region_length;
upper_current_region = upper_region = input_power;
//Allazei etsi ki allios
currentState = STATE_A;
previous_packet_loss = init_packet_loss = input_packet_loss;

output_power = input_power;
}else if (currentState == STATE_A){
printf("Eimai sto STATE_A! (Expand region)\n");
low_current_region = low_region = low_region +
region_length;
upper_current_region = upper_region = upper_region +

region_length;
previous_packet_loss = input_packet_loss;
output_power = upper_region;
currentState = STATE_B;
}else if (currentState == STATE_B){
printf ( "Eimai sto STATE_B! (test max) \ n");
// Is there improvement?
printf ( "previous_packet_loss =% lf \ n",
previous_packet_loss);
double improvement = previous_packet_loss == 0? 1.0:
(input_packet_loss - previous_packet_loss) / previous_packet_loss;
if (improvement <0.1) {
} Else {
currentState = STATE_C;
}

} Else if (currentState == STATE_C) {
// energy consumption optimization
printf ( "Eimai sto STATE_C! (check median of current
value) \ n");
upper_current_region = (upper_current_region +
low_current_region) / 2;
output_power = upper_current_region;
currentState = STATE_D;
} Else if (currentState == STATE_D) {
// energy consumption optimization
printf ( "Eimai sto STATE_D! (check improvement) \ n");

double improvement = previous_packet_loss == 0? 1.0:
(input_packet_loss - previous_packet_loss) / previous_packet_loss;
if (improvement> -0.1) {// good improvement
currentState = STATE_C;
} Else {
currentState = STATE_E;
}
} Else if (currentState == STATE_E) {
printf ( "Eimai sto STATE_E! (backtrack to previous
choice) \ n");
if (input_packet_loss> threshold) {
// if not adjust the power by a coefficient of our
choice (currently 5%)
// output = + Coeff * output?
// upper bound to prevent excessive consumption
if (output_power> = 0.06) output_power = 0.06;
printf ( "RATE adjuster: Increase power! \ n");
} Else if (input_packet_loss <(0.75 * threshold)) {
// we have an area currently 7.5-10% where
loss_rate is acceptable
output_power - = coeff * output_power;
// lower bound to prevent the base station from
halting the transmission
if (output_power <= 0.02) output_power = 0.02;
printf ( "RATE adjuster: MEIONO to power! \
n");
}
}
}
9.5 Changes in the physical layer ( wireless )

void
WirelessPhy :: sendDown (Packet * p)
{
/ *
* Sanity Check
* /
assert (initialized ());

if (em ()) {
// node is off here ...
if (Is_node_on ()! = true) {
Packet :: free (p);
return;
}
if (Is_node_on () == true && Is_sleeping () true
==) {
em () -> DecrSleepEnergy (NOW-
update_energy_time_,
P_sleep_);
update_energy_time_ = NOW;

}

}
/ *
* Decrease node's energy
* /
if (em ()) {
if (em () -> energy ()> 0) {

double txtime = hdr_cmn :: access (p) -> txtime ();
double start_time = MAX (channel_idle_time_, NOW);
double end_time = MAX (channel_idle_time_, NOW +
txtime);
double actual_txtime = end_time-start_time;

if (start_time> update_energy_time_) {
em () -> DecrIdleEnergy (start_time -
update_energy_time_,
P_idle_);
update_energy_time_ = start_time;
}

/ * It turns out that MAC sends packet even though, it's
receiving some packets.

if (txtime-actual_txtime> 0.000001) {
fprintf (stderr, "Something may be wrong at MAC
\ n");
fprintf (stderr, "act_tx =% lf, tx =% lf \ n",
actual_txtime, txtime);
}
* /

// Sanity check
double temp = MAX (NOW, last_send_time_);

/ *
if (NOW <last_send_time_) {
fprintf (stderr, "Argggg !! Overlapping
transmission. NOW% lf last% lf temp% lf \ n", NOW, last_send_time_,
temp);
}
* /

double begin_adjust_time = MIN (channel_idle_time_,
temp);
double finish_adjust_time = MIN (channel_idle_time_,
NOW + txtime);
double gap_adjust_time = finish_adjust_time -
begin_adjust_time;
if (gap_adjust_time <0.0) {
fprintf (stderr, "What the heck! negative gap time.
\ n");
}

if ((gap_adjust_time> 0.0) && (status_ == RECV)) {
em () -> DecrTxEnergy (gap_adjust_time,
Pt_consume_-Pr_consume_);
}

em () -> DecrTxEnergy (actual_txtime, Pt_consume_);
// the if (END_TIME> channel_idle_time_) {
// status_ = SEND?
// }
//
status_ = IDLE;

last_send_time_ = NOW + txtime;
channel_idle_time_ = end_time;
update_energy_time_ = end_time;

if (em () -> energy () <= 0) {
em () -> setenergy (0);
((MobileNode *) node ()) -> log_energy (0);
}

} Else {

// log node energy
if (em () -> energy ()> 0) {
((MobileNode *) node _) -> log_energy
(1);
}
//
Packet :: free (p);
return;
}
}

// Papapanagiotou and Zaoudis
double & txpwr = hdr_cmn :: access (p) -> txpower ();

// printf ( "To me WirelessPhy pire paketo power:% lf \ n", txpwr);

packet_t packet_types;
// printf ( "PT_TFRC =% x \ n", PT_TFRC)?
// papapana zaoudis
if (hdr_cmn :: access (p) -> ptype () PT_TFRC ==) {
Pt_ = txpwr;
printf ( "To paketo einai TFRC kai to Pt_ einai% lf !! \ n",
Pt_);
}
// printf("packet info src:%d\t dst:%d\t nhop:%d ptype:%d
ftype:%x \n ", hdr_ip::access(p)->saddr(), hdr_ip::access(p)->daddr(),
hdr_cmn::access(p)->next_hop(), hdr_cmn::access(p)->ptype(),
hdr_mac::access(p)->ftype());
// Pt_ = txpwr;
/*
* Stamp the packet with the interface arguments
*/
p->txinfo_.stamp((MobileNode*)node(), ant_->copy(), Pt_,
lambda_);

// Send the packet
channel_->recv(p, this);
9.6 TFRC
void TfrcAgent::sendpkt()
{
if (active_) {
// printf("Eimai energitikos !\n");

double now = Scheduler::instance().clock();
Packet* p = allocpkt();
hdr_tfrc *tfrch = hdr_tfrc::access(p);
hdr_flags* hf = hdr_flags::access(p);
if (ecn_) {
hf->ect() = 1; // ECN-capable transport
}
tfrch-> seqno = seqno _ ++;
tfrch-> timestamp = Scheduler :: instance (). clock ();
tfrch-> rtt = rtt_;
tfrch-> tzero = tzero_;
tfrch-> rate = rate_;
tfrch-> psize = size_;
tfrch-> fsize = fsize_;
tfrch-> UrgentFlag = UrgentFlag;
tfrch-> round_id = round_id;
ndatapack _ ++;
ndatabytes_ + = size_;
if (useHeaders_ == true) {
// printf ( "Stelno TFRC ............! \ N");
hdr_cmn :: access (p) -> size () + = headersize_;
// double txpower = hdr_cmn :: access (p) -> txpower
()?
// Na allaxtei !!
// printf ( "to txpower Before:% lf \ n", txpower)?

// papapana zaoudis
double my_loss_rate;
if (reports> = PREVIOUS_LOST_PACKETS) {
my_loss_rate = average (previous_lost_packets,
PREVIOUS_LOST_PACKETS);
} Else {
my_loss_rate = loss_rate_perc;
}
static rateAdjuster powerAdjuster2 (txpower, 0.05,
my_loss_rate, 0.1);
double newtxpower = powerAdjuster2.getOutput ();
txpower = newtxpower;

hdr_cmn :: access (p) -> settxpower (txpower);

printf ( "to txpower now:% lf to loss_rate:% lf \ n",
newtxpower, loss_rate_perc);
// rateAdjuster * powerAdjuster = new rateAdjuster (txpower, 0.05,
my_loss_rate, 0.1)?
// double newtxpower = powerAdjuster-> getOutput ()?

// txpower = newtxpower?

// hdr_cmn :: access (p) -> settxpower (txpower);
// printf ( "txpower to now:% lf to loss_rate:% lf \ n", newtxpower,
loss_rate_perc)?
// delete powerAdjuster;
fflush (stdout);
}
last_pkt_time_ = now;
send (p, 0);
}
}
/*
* Receive a status report from the receiver.
*/
void TfrcAgent :: recv (Packet * pkt, Handler *)
{
// printf ( "EIMAI STIN RECV !! \ n");
double now = Scheduler :: instance (). clock ();
hdr_tfrc_ack * nck = hdr_tfrc_ack :: access (pkt);
// double ts = nck-> timestamp_echo;
double ts = nck-> timestamp_echo + nck-> timestamp_offset;
double rate_since_last_report = nck-> rate_since_last_report;
// double NumFeedback_ = nck-> NumFeedback_;
double flost = nck-> flost;
int losses = nck-> losses;
true_loss_rate_ = nck-> true_loss;
losses_sum + = losses;

// papapana
printf ( "losses =% d loss_rate_ =% lf LOST PACKETS TILL
NOW:% d \ n", losses, nck-> true_loss, losses_sum);
fflush (stdout);

previous_lost_packets [reports% 5] = lost_packets;
reports ++;
printf ( "\ n \ nREPORTS received:% d \ n \ n", reports);

lost_packets = losses;
loss_rate_perc = nck-> true_loss;

round_id ++;
UrgentFlag = 0;

if (round_id> 1 && rate_since_last_report> 0) {
/* compute the max rate for slow-start as two times rcv rate
*/
ss_maxrate_ = 2*rate_since_last_report*size_;
if (conservative_) {
if (losses >= 1) {
/* there was a loss in the most recent
RTT */
if (debug_) printf("time: %5.2f losses: %d

rate %5.2f\n",
now, losses, rate_since_last_report);
maxrate_ = rate_since_last_report*size_;
} else {
/* there was no loss in the most recent
RTT */
maxrate_ =
scmult_*rate_since_last_report*size_;
}
if (debug_) printf("time: %5.2f losses: %d rate
%5.2f maxrate: %5.2f\n", now, losses, rate_since_last_report, maxrate_);
} else
maxrate_ = 2*rate_since_last_report*size_;
} else {
ss_maxrate_ = 0;
maxrate_ = 0;
}

/* update the round trip time */
update_rtt (ts, now);

/* .. and estimate of fair rate */
if (voip_ != 1) {
// From RFC 3714:
// The voip flow gets to send at the same rate as
// a TCP flow with 1460-byte packets.
fsize_ = size_;
}
rcvrate = p_to_b(flost, rtt_, tzero_, fsize_, bval_);
// rcvrate is in bytes per second, based on fairness with a
// TCP connection with the same packet size size_.
if (voip_) {
// Subtract the bandwidth used by headers.
double temp = rcvrate*(size_/(1.0*headersize_+size_));
rcvrate = temp;
}

/* if we get no more feedback for some time, cut rate in half */
double t = 2*rtt_ ;
if (t < 2*size_/rate_)
t = 2*size_/rate_ ;
NoFeedbacktimer_.resched(t);

/* if we are in slow start and we just saw a loss */
/* then come out of slow start */

if (first_pkt_rcvd == 0) {
first_pkt_rcvd = 1 ;
slowstart();
nextpkt();
}
else {
if (rate_change_ == SLOW_START) {
if (flost > 0) {
rate_change_ =
OUT_OF_SLOW_START;
oldrate_ = rate_ = rcvrate;
}
else {
slowstart();
nextpkt();
}
}
else {
if (rcvrate>rate_)
increase_rate(flost);
else
decrease_rate ();
}
}
if (printStatus_) {
/*
* ORIGINAL code masked out:
*/
// printf ( "time:% 5.2f rate:% 5.2f \ n", now, rate_);
// double packetrate = rate_ * rtt_ / size_;
// printf ( "time:% 5.2f packetrate:% 5.2f \ n", now,
packetrate);
// double maxrate = maxrate_ * rtt_ / size_;
// printf ( "time:% 5.2f maxrate:% 5.2f \ n", now, maxrate);

/ *** Evalvid-RA: Added by A. Lie 310106:
printStatus_ must be true in order for TFRC to
feedback * /
// to the codec rate controller (via TCL)
int diff = maxseq_ - seqno_;
printf ( "TFRC printStatus: time:% 5.2f rate [B / s]:% 5.2f
RTT [s]:% 5.4f Psize [B / packet]:% d TxQueue [pkts]:% d \ n",
now, rate_, rtt_, size_, diff);
// printf ( "time:% 5.2f packetrate [packets per RTT]:% 5.2f
\ n", now, packetrate);
// printf ( "Send queue size [packets]:% d \ n \ n", diff);
// double intrv = (double) (size _) / (double) rate_;
char out [100];
sprintf (out, "% s tfrc_ra% 8.7f% d", name (), rate_, diff);
Tcl & tcl = Tcl :: instance ();
tcl.eval (out);
// End Evalvid-RA modification
}
Packet :: free (pkt);
}

9.7 creating scenarios TFRC motion

proc attach_TFRC_traffic {startnode endnode connection_number} {
global ns tfrc opt trace_file vbr_in_use vbr
$ Startnode color green

$ Endnode color green
puts2 "eimai sto TFRC ................................. FDADFASDFASDFSDFSD"
set start_id [$ startnode id]
set end_id [$ endnode id]
set tfrc_agent ($ connection_number) [new Agent / TFRC]
puts "connection_num: $ connection_number"
# Set printStatus_ true
# Puts2 "$ connection_number !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
$ Tfrc_agent ($ connection_number) set fid_ $ connection_number
$ Ns attach-agent $ startnode $ tfrc_agent ($ connection_number)
set vbr ($ vbr_in_use) [new Application / Traffic / eraVbrTrace]
$ Vbr ($ vbr_in_use) attach-agent $ tfrc_agent ($ connection_number)

$ Tfrc_agent ($ connection_number) set packetSize_ $ opt (tfrc_pktsize);
$ Tfrc_agent ($ connection_number) set TOS_field_ 1

if {$ connection_number <15} {
$ Tfrc_agent ($ connection_number) set_filename $ opt (out_dir)
/sd_be.tfrc.$connection_number
}

$ Vbr ($ vbr_in_use) set running_ 0
$ Vbr ($ vbr_in_use) set r_ $ opt (vbr_rate);

puts2 "r_ = $ opt (vbr_rate)"
$ Vbr ($ vbr_in_use) attach-tracefile $ trace_file

$ Vbr ($ vbr_in_use) set b_ 1.5
$ Vbr ($ vbr_in_use) set q_ 4
$ Vbr ($ vbr_in_use) set Gop_ $ opt (GoP_size)
$ Vbr ($ vbr_in_use) set fps_ $ opt (fps)
$ Vbr ($ vbr_in_use) set isTFRC_ 1

set tfrcsink ($ connection_number) [new Agent / TFRCSink]
$ Ns attach-agent $ endnode $ tfrcsink ($ connection_number)
$ Ns connect $ tfrc_agent ($ connection_number) $ tfrcsink ($ connection_number)

if {$ connection_number == 0} {
$ Tfrcsink ($ connection_number) set_trace_filename $ opt (out_dir)
/rd_be.tfrc.$connection_number
}
#set trace_file [open trace_file w]
# $ Ns at 15.0 "$ ns trace-queue $ startnode $ endnode $ trace_file"
set bwt [open $ opt (out_dir) /bwt.TFRC.$connection_number w]
$ Ns at 0.0 "record $ tfrcsink ($ connection_number) $ bwt"
puts2 "added TFRC connection number $ connection_number (vbr ($ vbr ($
vbr_in_use)) between nodes $ start_id and $ end_id"
incr vbr_in_use
}

#
=================================================
=============================
#adaptive ra
#
=================================================
=============================
Agent / TFRC instproc tfrc_ra {bytes_per_sec backlog} {
global vbr ns opt sn_in_use vbr_in_use
set now [$ ns now]
$ Self instvar node_
set node_id [$ node_ id]

#set vbr_number [expr $ node_id + $ opt (nofUDP) -2];
if {$ opt (nofFTP)> 0} {
set vbr_number [expr $ vbr_number - 1]
}
if {$opt(nofWEB)>0} {
set vbr_number [expr $vbr_number - 1]
}
if {$opt(nofUDP)>0} {
set vbr_number [expr $vbr_number - 1]
}
puts2 "tfrc_ra behandler ack til vbr($vbr_in_use) (node($node_id)) B/s:
$bytes_per_sec"
#puts "In TFRC instproc. rate= $bytes_per_sec (B/s), node_id= $node_id"
#puts "TCL: before vbr($vbr_number) TFRC_rateadapt rate=$bytes_per_sec
node=$node_id"

$ns at [expr $now] "$vbr(0) TFRC_rateadapt $bytes_per_sec $node_id $backlog"
#puts "TCL: after vbr($vbr_number) TFRC_rateadapr rate= $bytes_per_sec
node=$node_id"
}
9.8
Script : ( )
proc wlan_topo_complex {} {
global ns nodes opt mn sn rn bs
puts2 "Building topology..."
#configuration for Orinoco 802.11b 11Mbps PC card with -> 22.5m range
Phy/WirelessPhy set Pt_ 0.05 ; #transmit power 0.031622777
Phy/WirelessPhy set L_ 1.0 ;#system loss factor
Phy/WirelessPhy set bandwidth_ 1 ;#$opt(wifi_bw)
Phy/WirelessPhy set freq_ 2.472e9 ;#channel 13=>2.472GHz
Phy/WirelessPhy set CPThresh_ 10.0 ;#simultaneos packets
Phy/WirelessPhy set CSThresh_ 5.011872e-12 ;#carrier sending
Phy/WirelessPhy set RXThresh_ 5.82587e-09 ;#reception

#ns does not support ARF,dynamic rate adjustment
Mac/802_11 set dataRate_ $opt(wifi_bw)
#commercial packets use RTS/CTS above a threshold
if { $opt(disableRTS_CTS)==1 } {
puts2 "Disabling RTS/CTS"
Mac/802_11 set RTSThreshold 3000
}
Mac/802_11 set basicRate_ 1Mb ;#for broadcast

#address setup
$ns node-config -addressType hierarchical
AddrParams set domain_num_ 2;
if {$opt(nofbs)>1} {
puts2 "no support for more than one base station"
puts2 "NS exiting"
exit 0
}
lappend cluster_num 1 2 ;

AddrParams set cluster_num_ $cluster_num

#set nodes per cluster
#lappend eilastlevel [expr $opt(nofsn) + 1] 1 [expr $opt(nofmn) + 1]
#AddrParams set nodes_num_ $eilastlevel

set topo [new Topography]
$topo load_flatgrid $opt(x) $opt(y)
create-god [expr $opt(nofmn) + $opt(nofbs)]

#creating wired nodes=> sn + rn
#set rn(0) [$ns node {0.0.0}]
#set rn(1) [$ns node {1.0.0}]
#puts2 "Router nodes:"
#puts2 [$rn(0) node-addr]
#puts2 [$rn(1) node-addr]
#create as many sn-addresses as needed

#if { $opt(nofsn)>9 } {
# puts2 "create for-loop to address more server nodes"
#puts2 "NS exiting"
#$ns halt
#}

#set sn_addr {0.0.1 0.0.2 0.0.3 0.0.4 0.0.5 0.0.6 0.0.7 0.0.8 0.0.9}
#puts2 "server nodes:"
#for {set i 0} {$i<$opt(nofsn)} {incr i} {
# set sn($i) [$ns node [lindex $sn_addr $i]]
#puts2 [$sn($i) node-addr]
#}

if {$opt(prop) == "Propagation/Shadowing"} {
#values for model
Propagation/Shadowing set pathlossExp_ $opt(pathlossExp)
Propagation/Shadowing set std_db_ $opt(std_db)

Propagation/Shadowing set dist0_ $opt(dist0)
Propagation/Shadowing set seed $opt(seed)

puts2 "values for shadownig propagation are set"
}

#ns configuring
$ns node-config -adhocRouting $opt(adhocRouting) \
-llType $opt(ll) \
-macType $opt(mac) \
-ifqType $opt(ifq) \
-ifqLen $opt(ifqlen) \
-propInstance [new $opt(prop)] \
-antType $opt(ant) \
-phyType $opt(netif) \
-wiredRouting ON \
-channel [new $opt(chan)] \
-topoInstance $topo \
-agentTrace $opt(agentTrace) \
-routerTrace $opt(routerTrace) \
-macTrace $opt(macTrace) \
-movementTrace $opt(movementTrace)
#-propType $opt(prop)

#create base-station
puts2 "create for-loop for more"
puts2 "Ns exiting"
$ns halt
exit 0
} else {
#creating and setting addresses
set bs(0) [$ns node {1.1.0}]
#bs is not moving

$bs(0) random-motion 0
$bs(0) set X_ 1.0
$bs(0) set Y_ 1.0
$bs(0) set Z_ 0.0
puts2 "Base station nodes:"
puts2 [$bs(0) node-addr]
}

#configure mobile nodes
$ns node-config -wiredRouting OFF

puts2 "create for loop to address mobile nodes"
puts2 "NS exiting"
$ns halt
exit 0
} else {
set x_pos 0.0
set y_pos 0.0
if {$opt(nofmn)>9} {
puts2 "for loop for more mobile"
puts2 "NS exiting"
$ns halt
exit 0
}

set adr {1.1.1 1.1.2 1.1.3 1.1.4 1.1.5 1.1.6 1.1.7 1.1.8 1.1.9}
puts2 "Mobile nodes:"
for {set j 0} {$j< $opt(nofmn)} {incr j} {
set mn($j) [$ns node [lindex $adr $j]]
puts2 [lindex $adr $j]

$mn($j) random-motion $opt(nm_motion)
$mn($j) set X_ 22.0 #23.0
$mn($j) set Y_ 3.0 #5.0

$mn($j) set Z_ 0.0 #2.0

set x_pos [expr $x_pos + $opt(nodeDist)/2]
set y_pos [expr $y_pos + $opt(nodeDist)/2]
$mn($j) base-station [AddrParams addr2id [$bs(0) node-addr]]
$ns initial_node_pos $mn($j) 20
}
}

#link servers to first core router
#set link_angle 135
#set angle_offset [expr 90 / $opt(nofsn)]
#for {set k 0} {$k<$opt(nofsn)} {incr k} {
# $ns duplex-link $sn($k) $rn(0) $opt(snet_bw) $opt(snet_prop) $opt(qm)
#$ns duplex-ling-op $rn(0) $sn($k) orient $link_angle
#set link_angle [expr $link_angle + $angle_offset]
#}
#core link
#$ns duplex-link $rn(0) $rn(1) $opt(core_bw) $opt(core_prop) $opt(qm)
#$ns duplex-ling-op $rn(0) $rn(1) orient right

#link base stations to seconde core router
# for {set l 0} {$l<$opt(nofbs)} {incr l} {
# $ns duplex-link $rn(1) $bs($l) $opt(bsnet_bw) $opt(bsnet_prop) $opt(qm)
# $ns duplex-link-op $rn(1) $bs($l) orient right-up
#}
puts2 "done topology"
}
Cross - Layer

.

Rate Adapt ns2 Code + Power Adapt

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Rate Adapt ns2 Code + Power Adapt

Uploaded by

Copyright:

Available Formats

9/12/2017 https://translate.googleusercontent.

"A DAPTIVE C ROSS - L AYER A LGORITHMS FOR M ULTIMEDIA

Konstantinos Berberidis, Professor

Christos Bouras, Professor

CHAPTER 2: CROSS-LAYER ARCHITECTURES ON WIRELESS NETWORKS

REQUIRE FOR CROSS-LAYERED ARCHITECTURES IN WIRELESS NETWORKS

2.1.2.1 PROTOCOLS HIERARCHY

2.1.2.4 CROSS-LAYERED ARCHITECTURE DESIGN PROBLEMS

CHAPTER 3: VIDEO DELIVERY AND SIMULATION TOOLS

3.3 INTRODUCTION H .264

4.1 DESCRIPTION OF THE PROBLEM

CHAPTER 7: FUTURE WORK

9.1 PLATFORM INSTALLATION AND DEVICE ANALYSIS

9.6 CHANGES TO THE TFRC PROTOCOL L

Figure 1. Objective from which cross-layer architectures emerge

Figure 2. Levels, protocols and interfaces

Figure 3. The ISO OSI reference model

Figure 4. Comparison of OSI with TCP

Figure 5. Evolution of multimedia applications over networks

Figure 6. Video MPEG-4 structure.

Figure 7. Frame transmission in conjunction with an adaptive algorithm

Figure 8. Video coding mechanism based on H.264 standard

Figure 9. Video decoding mechanism based on the H.264 standard

Figure 10. H.264 Architecture Levels

Figure 11. Example video transmission using the H .264

Figure 12. Recommended cross-layer design for MIMD and Binary

Figure 13. Packet loss control and power adjustment mechanism

Figure 15. Topology of Mechanism

Figure 16. Overall video transmission process in the simulator.

Figure 17. Script 1: 2 nodes fixed

Figure 18. Script 2: 2 nodes, 1 fixed, 1 spacing

Figure 19. Scenario 3: 2 nodes, 1 fixed, 1 approaching and then removing

Figure 20. Script 4: 2 nodes, 1 fixed, 1 is approaching

Figure 22. Scenario 6: 2 nodes, 1 fixed, 1 is removed and stopped

Figure 23. Scenario 7: 2 nodes, 1 fixed, 1 approaches and stops

Figure 24. Scenario 8: 2 nodes, 1 fixed, 1 moves randomly

Figure 25. Hybrid network

Table 1. Matching PSNR with MOS

Table 2. Scenario results

Table 3. Assignment of PSNR to MOS values

ACM Adaptive Coding and Modulation

ARQ Automatic Rep eat re-Quest

A VC Advanced Scalable Coding

FGS Fine Granularity Scalability

GoF Group of Frames

GoP Group of Pictures

CPU Computer Processing Unit

MOS Mean Opinion Square

MPEG Moving Picture Experts Group

NS2 Network Simulator 2

PSM Pipe-to-Soil Monitor

PSNR Peak Signal-to-Noise Ratio

RTT Round Trip Time

QoS Quality of Service

SNR Signal-to-Noise Ratio

SVC Scalable Video Coding

TCP Transfer Control Protocol

TFRC TCP Friendly Rate Control

UDP User Datagram Protocol

WWW World Wide Web

Chapter 6 presents the conclusions of this diploma thesis.

PUBLICATIONS IN JOURNALS (JOURNALS)