Rate Adaptive Video Streaming over Wireless Networks

Size: px
Start display at page:

Download "Rate Adaptive Video Streaming over Wireless Networks"

Transcription

1 Rate Adaptive Video Streaming over Wireless Networks Explained & Explored Torgeir Haukaas Master of Science in Communication Technology Submission date: June 2007 Supervisor: Yuming Jiang, ITEM Co-supervisor: Arne Lie, Sintef Norwegian University of Science and Technology Department of Telematics

2

3 Problem Description Through the use of the "Evalvid-RA" software package ( RA.htm), large networks supporting rate adaptive packet video can be simulated on a single computer. Typically, Internet congestion control mechanisms assume packet loss events are due to some link capacity contention. When one or more hops are wireless, packet loss events may have many other reasons. In such cases, the normal source rate control behavior may not be desirable. This project puts focus on how rate adaptive media will react when run over error prone wireless links. TFRC (DCCP) and P-AQM are congestion control methods that Evalvid-RA currently supports. The student may also suggest modifications to make media transport over such networks more robust. WLAN shall be modeled using available packet drop modules. The student must have a computer with ns-2 and Evalvid-RA installed, and some Internet protocol and programming skills. There exists written detailed background information other than provided on the web-page. Assignment given: 17. January 2007 Supervisor: Yuming Jiang, ITEM

4

5 Abstract In the search for improved methods of transporting real time video and VoIP over the Internet, new rate control mechanisms need to be developed and standardized. Ongoing research in the field has led to several new protocol suggestions. This thesis covers simulations of rate adaptive video transfers over wireless networks using one of them, TCP-Friendly Rate Control (TFRC). It is known that both TCP and TFRC have performance issues in wireless networks because their rate controllers react to random packet error as if it were congestion. On the other hand, UDP as used today for many real-time services, endanger the health of the network with unfair occupation of network resources. Moreover, the shared medium topology of many wireless networks add significant delay to the data transport. Through the use of ns-2 and Evalvid-RA, several simulation scenarios have been formed to illustrate how these problems affect real-time video as perceived by a wireless end user. The simulations illustrate the missing inter- and intraflow fairness of UDP, reveal protocol and implementation vulnerabilities of TFRC, and show a remarkable delay caused by the IEEE b networks. The thesis also includes a study of past and current protocol refinement proposals and suggestions to novel re-design. The study reveals that the variety of proposals form an information stream that is difficult to follow, a scarcity of problem domain overview and decisive variations in the problem definition.

6 Preface This is the master thesis for the degree MSc. in Communications Technology, carried out Spring 2007 at the Department of Telematics (ITEM) at the Norwegian University of Science and Technology (NTNU) in cooperation with Professor Yuming Jiang and Sintef-researcher and Ph.D. candidate at ITEM, Arne Lie. It is a continuation of my Project Report Next Generation Internet and support for Streaming Media: Trace driven simulation from Fall 2006, and it is aimed to go deeper under the surface of nearly all topics discussed in that report. The thesis is written to be understandable for a fellow student within the fields of electronics, networking and computer science. If the reader is interested in the code and scripts used, they are attached in the back of this document together with a list of abbreviations. I would like to thank Professor Yuming Jiang for support, and supervisor Arne Lie for invaluable help, support and patience during my work.

7 Contents 1 Introduction Problem Limitations Scope Simulator Accuracy Related work Method and Structure Background MPEG-4 Video Uncompressed video MPEG frame types Quantization Quality Measure: PSNR Rate adaptive video Simulation environment Hardware Operating system ns Evalvid-RA Presentation tools Other Scripting and coding languages Feedback mechanisms and rate control DCCP TFRC Network intelligence Wireless transmission: The group General architecture and specifications MAC Access procedures and timing iii

8 2.6.4 Link stability Quality of Service enhancement: e Simulation background and layout Goal Topology Simulation controller: tcl ns-2 modifications IO-handling Wireless channel Scenarios Case I: Congested wireless link Case II: Node movement and variable link quality Case III: MAC layer efficiency Results and analysis Vulnerability Scenarios Case I: Congested wireless link Case II: Node movement and variable link quality Case III: MAC layer efficiency Summary Standards development Definition: TCP-friendliness Network or client intelligence? Multiple streams Designing from scratch Application and cross-layer solutions Summary Conclusion The simulations The development Yet to come Bibliography A List of abbreviations 83 B Shell scripts 87 C AWK scripts 93 D Tcl scripts 97

9 CHAPTER 1 Introduction The available hardware and technology for consumers and service providers today allow for advanced multimedia services over IP-based networks. Hence, the popularity of video and audio streaming services such as Video-on-Demand (VoD), advanced on-line gaming, and video chatting and conferences are increasing. The demand for resource efficiency and robustness in the network follows. The current commercially available data transfer technology for streaming media does not adjust well to the best effort heterogeneous Internet architecture, and QoS demands are impossible to guarantee. A central problem with this development is that the Internet itself is extremely dynamic and unpredictable, while the real-time services we want to lay on top of it demand stable conditions for constant and uninterrupted throughput. It is not only the demand for QoS that increases. As CPU and memory get physically smaller and more efficient, the number of applications that can be run on small devices increases as well. With this new flora of handheld computers, PDAs and cell phones, the wish for terminal mobility and easy wireless access to the same advanced services follows. Now, while the Internet itself has unpredictable throughput, the wireless access networks add even more uncertainty to the QoS-possibilities. Most Internet based VoD services today rely on pre-compressed media, allowing consumers to choose between two or three different qualities to fit the given end to end connection (fig. 1.1(a)). For video conferencing and live streaming, the media is compressed on the fly, but the compression rate is normally controlled by an offline codec. This means that the video codec has no direct contact with the network and transport layer, where the actual transmission status is found. Thus, these approaches do not fully utilize the available resources at any given time and they might not provide the chosen quality during the entire session because of sudden changes in the network load somewhere along the path. With an online codec solution, the communicating parties of a multimedia transfer could adopt to the network state at any given time in the session. This is extra desirable for a mobile terminal which has a constantly changing radio coverage, or for a system that supports session-mobility, allowing the user to change terminal equipment 1

10 2 CHAPTER 1. INTRODUCTION (a) Today (b) Tomorrow Figure 1.1 Typical streaming service with (b) and without (a) congestion feeback. without interrupting or restarting an ongoing session. Figure 1.1(b) illustrates the concept behind a solution based on continuous network feedback upstream from the client to the media server. 1.1 Problem In the development of robust, scalable and intelligent new technologies for multimedia transfer over present and future wireless IP-networks, many concerns need to be taken into account. As will be further discussed in chapter 5, the solutions can be found by improvements in many levels of the ISO stack, or by novel protocol design. The challenges include: Calculating desired rates from current status and collected statistics. Transporting network feedback to the sender. Interpreting the feedback and notifying the transmitting application. Scaling the multimedia output rate from the sender. Providing stable transmission conditions for mobile users. Minimizing delay and jitter for real-time applications. Staying fair to concurrent traffic on the link. Differentiating between congestion loss and link error loss. All of the challenges above have been addressed by separate research groups around the world, but where one solution is brilliant in the aspect discussed in that study, it fails to solve problems discussed in another. This thesis aims to summarize the problems found and the suggested solutions, and to account for the complexity of multimedia streaming over wireless networks. An

11 1.2. LIMITATIONS 3 Figure 1.2 The combination of these three technologies is the essence of the problem domain. extensive part of the thesis is used to explain how the technologies can be tested with simulations. Illustrations of the features and problems of current and new technologies will be presented through the described simulation framework. 1.2 Limitations The topic of this thesis touches all protocol layers involved in a video streaming service. However, the presented simulation, status summary and analysis have limitations both in scope and possibilities Scope The methods, mechanisms and protocols that are presented, tested and analyzed are discussed given the need and demand for a set of services with a certain quality. How the services are built up, and how the technology will and can be used in different scenarios and settings, is mentioned but not emphasized any further. The focus of this work is mainly on the transport and MAC layers of the protocol stack, and does not prioritize details from the physical or application layers. The cost-efficiency of each technology in real-life implementation and business-related topics such as time to market, commercial support, industry cooperation and market potential, which are fundamental for a thourough understanding of a standard development process, are left for future studies. The thesis seeks to enlighten the technological possibilities in terms of quality and performance, but an important factor such as security is left out of the scope. For every new product and service intended for online use today, security is a big concern that may be regarded as a part of the total QoS. Understanding topics such as service authentication, authorization and confidentiality, and how current technology in this field can be integrated with new media transport without breaking their performance and intention, is very important. Without this knowledge,

12 4 CHAPTER 1. INTRODUCTION technology that can replace today s well-established protocol stack (or parts of it) may not succeed Simulator Accuracy A significant part of this thesis is the preparation and the simulation of video streaming with TFRC over a wireless network link. The ns-2 simulation environment, as described in section 2.4.3, is a complex mixture of code languages and application program interfaces (APIs). It s manual [1] is extensive but the content is partially outdated or inadequate 1. The user interface to set up and control a ns-2 simulation is the Tcl scripting language (described in 2.4.7). However, to understand how the different parameters are set and how they work, the user is often forced to read the C++ source code due to the lack of sufficient documentation. Many standard simulator functions can be learned in practice by reading and using Tclexample files that are bundled with the ns-2 simulator. Alas, the quality and correctness of these scripts does not seem to have been thoroughly evaluated in all cases 2. The user can often observe the simulator to crash because of bad parameter settings or input/output problems. Errors are seldom caught in a proper manner, and the user is not always informed what caused the error. The mentioned complexity, improper documentation and scripts combined with untidy and experimental source code, gives the ns-2 simulator an advanced entry-level for students, scientists or other users. In the work presented in chapter 3, ns-2 add-ons are used to enable video trace simulations. This code is not widely used and tested, and is known to be highly experimental. One consequence of these factors is that it is time consuming to get a simple simulation running, but a more severe consequence is that it is very difficult for the user to ensure that obtained results are correct. In [2] three different simulator environments, including ns-2, are used to simulate a simple mobile ad-hoc network. The paper concludes that the results differed both quantitatively and qualitatively to such an extent that the results from one single simulation environment does not have the credibility needed in serious science and development. Allthough this does not directly imply that ns-2 is inaccurate, it is a reminder that only real-life use and realistic testing can prove the functionalities or dysfunctionalities of new technology. In the light of all the above, it is not guaranteed that the results presented in this thesis are 100 % correct. In sections 2.4.3, 3.4, 3.6 and 4.1, the functionality, use and bugs of ns-2 will be further discussed. 1.3 Related work The Internet research community is trying to find the best way to improve the quality and availability of video streaming services. One central topic for discussion is the differing operation of TCP and UDP traffic in the IP networks. The differences in their ways of adjusting to router congestion can result in situations where UDP traffic dominates the use of router resources since 1 paragraphs like this can be found in the middle of the text: but why/where is this information used??-answer awaited from CMU. 2 comments like this can be found in the embedded scripts: Poor hack. What should we do without a link object??

13 1.4. METHOD AND STRUCTURE 5 it does not adjust the transmission rate automatically according to the given conditions. In [3], Floyd and Fall promotes the research on and use of protocols with congestion control. They introduce the term TCP-friendliness (which will be further discussed in section 5.1) and, as the article title says, promote the use of end-to-end congestion control in the Internet. The research effort has led to several suggestions to new congestion control mechanisms such as VBR over ATM ABR services [4], RAP [5], MPEG-TFRCP [6], LDA+ [7] and P-AQM+ECF [8], the latter being a NTNU proprietary protocol. Among the suggestions, TCP-Friendly Rate Control (TFRC) [9] has gained most attention and become a IETF standard that is intended to be used together with Datagram Congestion Control Protocol (DCCP, see section 2.5). In [10] and [11], Evalvid, a framework for quality evaluation of streaming video is presented and tested. In [12] this framework (now called Evalvid-RA) is extended to work with rate adaptive video and with network and transport protocols based on transmission feedback from the client or the network. In [13], which is a pre-study to this master thesis, the Evalvid-RA framework is tested over an erroneous link simulated by a simple stochastic packet dropping mechanism. The results from the latter study show that the TFRC has performance problems when the link has random losses. This motivates for further study of TFRC over a more realistic wireless interface; The IEEE MAC wireless protocol. TFRC is designed with a rate adoption very similar to the one in TCP in order to be TCP- Friendly. In many studies such as [14], [15] and [16], the performance issues of TCP in wireless scenarios with random packet losses are discussed. The studies in this field has led to several suggestions to improved congestion control in TCP (i.e. TCP Westwood [17]). It is natural to assume that TFRC suffers from the same problems as TCP in the presence of wireless random errors. A further discussion and analysis of related work, which is a central part of this thesis, can be found in Chapter Method and Structure As seen in 1.1 and 1.3 above, there are many past and ongoing studies on the challenges regarding real time multimedia transport and QoS in wireless networks. This thesis will address some of these problems. While the TFRC protocol mainly has been tested and simulated over wired networks, this thesis presents simulation results over a realistic wireless access network. The Evalvid-RA framework is used to show realistic simulations of variable bit rate (VBR) video transfer. While many other studies have throughput and packet loss as the main evaluation criteria, this thesis uses measurements from the transferred and decoded video as evaluation criteria to see how the losses and rate adjustments affect it in practice. The simulations based on a combination of video trace driven simulation with rate adaptive video, transport protocols with congestion feedback and wireless networks (fig. 1.2), results in the first out of two main contributions of this thesis. The simulations presented, is mainly intended to illustrate the benefits and disadvantages of TFRC compared to TCP and UDP in a realistic environment. The second main contribution is the analysis and comparison of different approaches and works surrounding the field of video transfer and QoS in wireless networks. The work presented in this thesis consists of four main parts. In Chapter 2, some background

14 6 CHAPTER 1. INTRODUCTION information and relevant theory is gathered to ease the understanding of the following discussion. The environment, coding languages, codecs and protocols used in the practical work are described. The reader will also find relevant theory to the discussion on standard development in Chapter 5. In Chapter 3, the implementation and simulation setup is described for three different scenarios, while their results and analysis are found in Chapter 4. In Chapter 5, the problems, solutions, barriers, possibilities and trade-offs of different novel technologies in the domain are presented, before the thesis is summed up with the conclusions in Chapter 6.

15 CHAPTER 2 Background In this section, background information on used tools, languages and theory will be presented. It is a brief overview, explaining only the terms that are used in this thesis and the technology and environment used in the simulations. Some of the sections in this chapter contain simulation specific background information, whilst others are background theory for the discussions in Chapter 5. The level of detail is sufficient to understand the further discussion without the need of pre-studies. 2.1 MPEG-4 Video MPEG-4 video compression, as defined by the ISO/IEC Moving Picture Experts Group, is a standard for compressing and decompressing digital video aimed for distribution over media with limited bandwidth. The MPEG-4 standard suite includes 23 parts describing different aspects of multimedia compression and transfer. For instance, part 3 defines how to compress and encode audio to AAC-streams, and part 12, 14 and 15 describe the file and container formats. However, only two of the 23 parts describe how the raw video is encoded into a compressed datastream suitable for network transfer. These are part 2 and part 10. The latter describes the newest and most advanced codec, namely Advanced Video Coding (AVC), often referred to as H The former is the one most commonly referred to as MPEG-4 video. This is a coding scheme with several different profiles, where the most normal are Simple Profile and Advanced Simple Profile (ASP). In the rest of this document, the term MPEG-4 will refer to the standardized MPEG-4 part 2 ASP. ITU-T 1 In fact, the MPEG-4 part 10 does not describe H.264, but it is technically identical to H.264 which is defined by 7

16 8 CHAPTER 2. BACKGROUND Uncompressed video Raw video consists of a series of digital photos, each of them consisting of a grid of pixels (e.g. CIF 352x288 pixels). Each pixel is represented with three values of typically one byte each in the RGB format, which enables presentation of 256 intensities of each hue. Uncompressed, this produces a bit-stream that is impractical to store, process and distribute over normal available computers and network equipment due to its size. The following example shows the calculated size of one minute of CIF RGB video: 3colors 1 byte/color ( pixels) 25 fps 60 seconds/minute = 435 MB/minute A more space efficient alternative to storing a video with three full colors, is to store it in the YUV format. This format models the human perception of color better. It stores the luminance and chrominance in different layers (given by Y, Cb and Cr in digital systems). Since the luminance is easier percepted by the human eye than chrominance, the latter need not be stored with equal resolution. Typical YUV subsampling schemes is YUV 4:2:0 and YUV 4:1:1. This notation indicates varying ways to arrange the chrominance and luminance layers in each frame. With both of these schemes, the number of bits needed for each pixel is reduced from 24 (RGB: 3x8) to 12. The uncompressed original and reconstructed videos in this work are in YUV 4:2:0 format. The size reduction introduced by YUV compared to RGB, which is of factor two, is not enough to make a video stream easy to handle for computers and networks. The video compression used in this project is described in the following MPEG frame types With MPEG-compressing, none of the pictures in the raw-stream are stored or sent in its original form. Typically, the series of pictures or frames are divided into Groups Of Pictures (GOPs, see figure 2.1). The frames are then coded in various ways within each GOP. There are normally three types of frames in a MPEG GOP: Intra coded frames (I) These are coded as single frames as in JPEG. They do not have references to any other frames and are relatively large. Predictive coded frames (P) Are coded as the difference from a motion compensated prediction frame 2, generated from an earlier I-frame in the GOP. They are typically smaller than the I-frames, but bigger than the B-frames. Bi-directional coded frames (B) Are coded as the difference from a bi-directionally interpolated frame, generated with motion compensation from earlier and later I or P frames in the sequence. B-frames are typically smaller than both I and P-frames. The most important thing to note about this structure when talking about Quality of Service, is the fact that the I-frames are much more important to the quality of the video than the P-frames, which in turn are more important than the B-frames. Now, if a I-frame is lost during transmission 2 Motion compensation basically means that instead of storing pixel-values, the difference vector from a reference frame is stored

17 2.1. MPEG-4 VIDEO 9 Figure 2.1 A typical MPEG GOP [18] due to congestion or erroneous links, the impact on the result is big. However, smart decoders are able to reconstruct a usable image even if one or several packets from one frame is lost as long as the packet containing the frame header is received. The number of packets needed to transfer one frame depends on the ratio between frame-size and the packet transfer unit size, called Maximum Transfer Unit (MTU). The overall result can be seen on measures such as the Peak Signal-to-Noise ratio (PSNR, see section 2.2), Mean Opinion Score (MOS) or simply by watching the video in a MPEG-compatible player Quantization The image compression of an I-frame is very similar to that of a JPEG-image. The image is split into smaller blocks (of e.g. 8x8 pixels), processed in a discrete cosine transform, quantized and entropy encoded. The quantization process is the one introducing the loss to the image quality in the encoding process. Hence, in addition to resolution and frame-rate (frames per second, fps), the number of quantization levels is the best indicator of the total bit-stream and the quality of the resulting compressed video. In fact, the quantization parameter is often referred to as a quality-parameter. The encoding of P- and B-frames, which include both JPEG-like encoding and motion prediction, is often referred to as a hybrid encoding (figure 2.2). After the discrete cosine transform (DCT), each block of each layer Y, U and V of a frame can be represented in the frequency domain as a coefficient matrix. In the quantization process, each of these coefficients get divided by a quantization factor given in a quantization matrix. This matrix is predefined based on a quantization parameter, and ordered so that the least significant coefficients are reduced more than the most significant coefficients. In this way, the data that is most frequent in the frame gets the highest degree of detail, or depth, while other components are compressed harder. This process is not reversible (the data can not be 100 % restored), hence causing direct quality loss to the compressed data. However, with intelligent design of the quantization matrices, the sensibility of a human eye can be taken into account so that the loss is minimized [20]. 3 VideoLAN Client (VLC) is used for viewing compressed video in this work

18 10 CHAPTER 2. BACKGROUND Figure 2.2 Basic block diagram of a MPEG-4 video encoder [19] 2.2 Quality Measure: PSNR To measure the quality of a network service for video streaming, it is not sufficient to look at classical QoS terms such as jitter, delay and throughput. The way a video sequence is encoded with different frame types, and how it is split into smaller packets, results in a variable bit rate stream 4 where it is not irrelevant which packets that are lost. So the loss patterns of a congested router or an erroneous link can result in different video qualities for the same average loss rate. In the end, it is the perceived quality impression of the user that counts. Both subjective and objective approaches to quality measurements exists, but where subjective methods are expensive and requires much resources, objective measurement with the Peak Signal-to-Noise Ratio (PSNR) can be automated and simple [11]. To quantify the observed losses from compression, decompression and transfer of a video, a PSNR value can be calculated for the given video sequence. This value is the ratio between the maximum power of the original signal (data from the original video) and the power of the interfering noise that is introduced in the process. Because the signal quality can have a very wide dynamic range, the PSNR values are normally given in a logarithmic decibel scale. The PSNR values used in this work, are calculated as the mean of the PSNR values for each frame in the video sequence. The PSNR for one frame is calculated by comparison with the respective original frame. First, the Mean Square Error (MSE) between each layer Y, Cr or Cb 5 is calculated as MSE = 1 mn m 1 i=0 n 1 j=0 [I(i, j) K(i, j)] 2 (2.1) 4 The term Constant Bit Rate (CBR) means that the rate is held constant over time, but will normally have bitrate peaks for each I-frame. 5 Allmost all quality assessment studies that use PSNR, only calculate on the luminance layer (Y) since it is the most relevant to the quality perception[11].

19 2.3. RATE ADAPTIVE VIDEO 11 where I and K are frame layers with resolution m n. Then the PSNR is defined as ( ) MAXI PSNR = 20log 10 MSE (2.2) where MAX I is the maximum allowed pixel value. The PSNR introduced by a hybrid coder is normally in the range 30 to 40 db when providing good image or video quality. Values below 30 db are not necessarily satisfactory (depending on the range of application), while values below 20dB represent garbled results ([21], [20]). 2.3 Rate adaptive video Today, a normal real-time video streaming service will provide the viewer with several different quality choices as parallel unicast streams. Often, the streaming server will perform some probing or end-to-end bandwidth check to be able to suggest a suitable bit-rate for the user. This is not a very elegant approach to the challenge of serving all kinds of users, whether it is a user with optical fiber access or a user with a 3G mobile phone, nor is it suitable for a mobile user who has constantly changing signal strength and bandwidth. This thesis aims to investigate the robustness of the suggested transport protocols for rate adaptive video. The concept of rate adaptiveness is this: When a video is streamed real-time from a server to a client, the network capacity is reported back to the server continuously. Since it is a real-time service, the server can not simply adjust the bit-rate from its outgoing buffer, as this will break the continuity at the client side if the sent rate is lower than the rate of the compressed video. Therefore, rate adaptive transmitters adjust the quality of the video encoding directly instead, thus providing optimal streaming bit rate and full network utilization at any time. The quality and bit rate of a video transmission can change upon adjustment of several different encoding parameters. These can be the number of frames per second, the frame size or the quantization used in the compression process. Which of these parameters that affect the quality of the resulting video the most depends on subjective measures, the purpose and content of the video and the display on which it is shown. In the Evalvid-RA framework used in this thesis, the network feedback affects the quantization parameter of the compression to adjust the transmitting rate. How this is done is explained in section and 4.1. A simplified version of the simulated architecture is given in figure 2.3. It illustrates that several compression qualities are available on the streaming server. These can be available as pre-compressed versions in the server storage, or they can be compressed on the fly with a realtime encoder that supports dynamically changing quality parameters. To store the full range of compression alternatives with the quantization parameter altering from 2 to above 30, some six times the storage space is required compared to only storing the best quality. In a real life implementation, a reduction of the number of quantization steps is more probable. In the case of live streaming, storing the video on disc is not an option since the video should not be buffered more than absolutely necessary. However, when serving Video-on-Demand, it is a trade-off between CPU-usage and storage space on the server(s) 6. The Evalvid-RA framework is thus 6 Further discussion of services and implementation issues are out of the scope of this thesis.

20 12 CHAPTER 2. BACKGROUND Figure 2.3 The server can provide several compression qualities simultaneously, and decides which one to serve the client based on congestion feedback. The rate indicated in the illustration, is the average bitrate for each quantization level. mainly constructed to simulate live encoding. 2.4 Simulation environment Testing of new transfer protocols in real networks would require big investments in design and implementation of new router software, in many cases even hardware. Additionally, one would need sufficient equipment with multiple sources of different types to support realistic big-scale end-to-end cases for heterogeneous networks. Since this is equipment that might crash during tests, this must be done on a separate network without any commercial or important traffic. These demands, among others, make real testing with physical data transfer too costly for most research institutions, at least in the early phases of development. A local simulation environment enables the researcher to build customized fictive networks at a low cost. The simulations in this study are carried out on a single standard computer without any special hardware or costly software. The details are explained in this section Hardware The only necessary hardware is a normal modern computer. Description of the computer used: Fujitsu Siemens Computers S-Series Lifebook 1.8 GHz Intel Centrino CPU 1536 MB DDR RAM (512 MB sufficient) 64 MB Graphical memory (not necessary) 80 GB harddisc It is worth mentioning here that if the rebuilt videos from all iterations of cases shall be kept for visual inspection and further analysis, several gigabytes of free space might be necessary. In this study, a YUV-file of 32.7 MB was used. The sum of all tracefiles, mp4-files and recreated YUV-files for all simulation cases sum up to 6.4 GB.

21 2.4. SIMULATION ENVIRONMENT Operating system Most of the simulation tools described below are parts of open source projects compiled on Unix-like machines using classical Unix development tools. However, they are successfully compiled and used on other platforms as well. Description of the platform used: Kubuntu 7.04 (Feisty Fawn) Linux kernel (for i586 architecture) Compilators: gcc / c C-library 2.4 X-window system (for graphical output and video inspection): KDE ns-2 The most central part of the simulation environment is the network simulator itself, ns-2 [1]. It is a discrete event based simulator supporting simulation of TCP/IP, multicast and unicast, wired and wireless networks, several routing protocols and more. It is a tool developed by the VINT-project [22], released as open source for any researcher to modify to own needs. ns-2 is an object oriented simulator build on Otcl 7 and C++. The program is constructed with a C++ class hierarchy and a corresponding class hierarchy in OTcl. The Otcl is a front end that enables the user to combine the different C++-implemented objects and do function-calls from Tcl. The protocols and tools available to the user is made available from OTcl and instantiated with C++-classes. Due to this dependency, protocol design or bigger design changes must be done in both languages. ns-2 is build with two languages to support speed in data treatment at run-time (C++) as well as easy and fast re-configuration of parameters and settings without the need of recompilation (OTcl) [1]. The ns-software has some package-dependabilities, but all packages may be installed from a bundle containing 8 : ns-2.30 nam-1.12 (see chapter ) xgraph-12.1 (see chapter ) tcl (see chapter ) tk otcl Object oriented Tcl. Tcl is pronounced tickle, often referred to together with the Tk GUI-toolkit: Tcl/Tk. 8 for current latest stable build

22 14 CHAPTER 2. BACKGROUND tclcl-1.18 gt-itm (Georgia Tech Internetwork Topology Models) Evalvid-RA As mentioned, researchers can modify ns-2 code, or add new modules to it. One addition that is needed for these simulations, is the Evalvid-RA package [12]. This package enables simulation of rate adaptive multimedia transfer based upon tracefile generation of MPEG video. This means that instead of using the real binary multimedia content, which is resource demanding and time consuming, the simulation runs with tracefiles generated from the media files beforehand. A typical tracefile holds information on frame number, frame type, size, fragmentation into segments and timing for each video frame. While running, ns-2 can keep track of the timing and throughput of packets at each node including the receiver. With this information and the original compressed videofile, Evalvid-RA can rebuild the video the way it would have been received on a real network. The obvious benefit of this is that one can play the video and inspect the result visually. Additionally, the total noise introduced by compressing and transferring the video (measured in db PSNR, see 2.2) and Mean Opinion Score can now be calculated. Evalvid-RA is a branch of the open source tool EvalVid, invented by J. Klaue [11]. The addition to the original is made by Arne Lie [12] and consists of functionality for rate adaptive video, including support for congestion feedback mechanisms such as TCP-Friendly Rate Control (TFRC) [9]. The use of the tool-set is illustrated in figure 2.4. Figure 2.4 The pre-process, simulation and post-process of the Evalvid-RA framework.[12] The Evalvid-RA tool-set includes several smaller programs, namely mp4, et ra, fixyuv ra

23 2.4. SIMULATION ENVIRONMENT 15 and psnr. A short description of each one of them follows. mp4 is a program used in the pre-process to generate tracefiles including information about each frame in the video. See first GOP of the reference video in code snippet 1. et ra (Evaluate Traces - Rate Adaptive) is a program that performs the actual calculation of jitter and packet-loss. Further, it combines the data from input (one mp4-file and one tracefile for each compression level) and output (packet-arrival statistics from the ns-simulation) to form a resulting m4v-video. Due to complication with the decompressor (ffmpeg), this program is tuned to work in frame-mode. That means that if the tracefile contains information about one lost packet, the entire frame the packet belongs to is considered lost (more about this in section 4.2.2). fixyuv ra is a program that fixes broken parts of the received video. This is necessary because the resulting sequence must be of equal length as the original sequence for objective overall quality-measures. Fixyuv detects missing frames, and duplicates last received frame until new frames arrive (i.e. until the received video is synchronized with the original). psnr is the last program being used in the simulation and calculation sequence in this thesis. It takes the original YUV-sequence as input and compares it to the recovered and fixed YUV-sequence obtained at the receiver. For an example of how these tools can be combined, which parameters they take and give, see 3.5, and how everything can be triggered from a shell-script, see Appendix B. Code Snippet 1 The first 13 frames indicated in a video trace file. The columns are: Frame number, frame-type (H for header), frame size, number of segments (i.e. number of packets for that frame) and offset from start of video (B-frames are not used by FFmpeg in this compression). 0 H 52 1 segm a t 0 ms 1 I segm a t 0 ms 2 P segm a t 0 ms 3 P segm a t 0 ms 4 P segm a t 1 ms 5 P segm a t 1 ms 6 P segm a t 1 ms 7 P segm a t 1 ms 8 P segm a t 1 ms 9 P segm a t 2 ms 10 P segm a t 2 ms 11 P segm a t 2 ms 12 P segm a t 2 ms

24 16 CHAPTER 2. BACKGROUND Presentation tools To analyze the results of a simulation, tools for graphical presentation often make the output more understandable. In this project, the tools xgraph and nam where used both to present the final results as well as to check correctness of coding and scripting in the development progress. Xgraph is a simple tool to draw a graph based on text-files with data. It is very useful to indicate for instance if a newly implemented protocol or simulation function works or not (see figure 2.5). Figure 2.5 An example showing the throughput from a TFRC source (green) and a TCP source (red) at a mobile node using wireless interface. The Network Animator (nam) is a tool that is tightly coupled with ns-2 to display the transmission of packets in the chosen network architecture. It is capable of drawing all the nodes and lines that are set up, and animates how the packets flow through the given topology. It can also track a specific packet end-to-end, display link throughput and give further pinpoints to the network performance in terms of routing-delay, packet drops, congestion and more. Unfortunately, it lacks the capability of tracing the packet in a wireless zone. In the simulations performed in this work, the packet can be tracked from the server to the base-station, but to see that the packet arrives to the correct wireless client, the tracefiles must be investigated Other The list of software and tools is long, and in addition to the mentioned software that comes included with ns-2 and Evalvid-RA, two additional tools where used to run the complete simulation in this study. These tools are FFmpeg and mp4creator. For raw video inspection, VidView was used. Mp4creator is a program from the MPEG4IP-project, a open source project aimed to provide a fully open and standards based solution for video streaming applications. In this work has been used to convert the output from et ra, a m4v-file, to a playable mp4-file. Mp4creator adds metadata and header information, called a media container, so that a video player can read the necessary parameters for correct play back.

25 2.4. SIMULATION ENVIRONMENT 17 FFmpeg is a complete solution to record, convert and stream audio and video [23]. It is a free program mainly intended for Unix-like platforms to compress and decompress video and audio in several formats. These include open standards such as H.264 and closed proprietary codec-formats such as Windows Media Video (wmv). In this thesis it is the chosen codec implementation and it is used to convert a binary YUV-sequence into mp4-files with the given quantizations (described in 2.1) in the pre-process. In the post-process, FFmpeg decodes the reassembled mp4-file into a sequence of YUV-images. Sometimes, the calculated PSNR-numbers can not tell the entire truth about the video quality. For example, one video might have excellent resolution and low quantization but has lots of dropped frames, while another video is harder compressed but with a lower amount of frame drops. These two videos have very different characteristics, and the user preferences here are subjective. To be able to tell the difference, and to inspect the effects of compression and transfer visually, the program VidView is excellent. This tool can read YUV videos and compare two instances in parallel. It enables inspection of the differences between the videos by showing only the delta values of the degraded version, and separation into the layers Y, Cr and Cb Scripting and coding languages To be able to understand the mechanisms of ns-2, several programming-languages need to be understood. The ns-2 software is build with both C++ and object oriented Tcl code (OTcl). To make simple scripts and topologies with well documented standard protocols, a basic understanding of Tcl is sufficient. However, once the goal is to simulate with protocols in the development stage, editing of both Tcl/OTcl and the relevant C++-object instantiations might be necessary. To run Evalvid-RA with ns-2, the latter needs to be recompiled together with some new source code. Evalvid-RA introduces changes in the ns-2 TFRC-objects, the objects agent, packet and scheduler in addition to a set of new objects. The Evalvid-RA package also includes a Tcl-script that acts as a topology- framework for generation of both TCP and UDP streams, as well as treatment of trace files for the video streaming study. The methods, syntax and semantics found in this example script has been used as a basis for constructing a new Tclscript to define the topology and components used in the simulations described in Chapter 3, and a copy can be found in appendix D. If a special printout of data is wanted, the AWK general purpose computer language can be used. It is a scripting language that is designed for processing text-based data, either in files or data streams. In this thesis, AWK has been used to gather relevant data-fields from the program execution output, to print these data to new text-files and to make computations for correct results that can be presented with xgraph. The simulation process and the iterations of it is coupled together with shell-scripts. These are basically collections of Unix/Linux bash shell commands, with the addition that they allow variables to be stored temporarily. All the shell-scripts used in this project are given in appendix B.

26 18 CHAPTER 2. BACKGROUND 2.5 Feedback mechanisms and rate control In this work, the flexibility and adaptivity issues of multimedia flows in the Internet are discussed and analyzed. Today s client, server and router software mainly support two branches of transport protocol types; TCP and UDP. The TCP protocol was originally designed to offer a reliable connection oriented transmission (RFC 793 from 1981), where the sender gets all data acknowledged before the session ends. Since router congestion causes packet drops and forces TCP retransmissions, the TCP-designers added rate controlling mechanisms (RFC 1122 from 1989 and RFC 2581 from 1999). With the development over the years, the rate controlling mechanisms have been modified and improved in several suggestions, and with the enormous popularity of Internet services, the importance of a fair and correct rate controller is greater than ever. Some of the TCP improvements include TCP Vegas, TCP Westwood[17], High Speed TCP and Fast TCP. These studies are interesting in this context because of one big challenge for TCPtraffic: How to separate congestion loss in wired links from sporadic packet loss in erroneous wireless links? The solutions chosen for this problem in the future TCP version is important to the remaining Internet traffic because of the need for inter-flow fairness. The UDP protocol is believed to be phased out and replaced by a more refined and intelligent protocol with throughput feedback and rate control for multimedia useage [24]. In other words, the future rate controllers for real-time traffic should be developed in corelation to the future TCP rate control in order to be TCP-friendly. In this section, the needed background information to understand the simulations is presented. More about the different approaches to defining a new real-time protocol standard and an analysis of some suggestions can be found in Chapter DCCP As mentioned earlier, the Datagram Congestion Control Protocol is a IETF standardized unreliable transport protocol with end-to-end congestion control. It is intended for use with applications such as streaming media or on-line gaming, where the real-time constraint is most important and packet retransmissions are uninteresting. The UDP protocol was originally designed for short request-response transfers, such as DNS and SNMP, where the TCP handshake routines are unnecessary overhead. With the use and popularity of applications such as radio-streaming, IP-TV, VoIP and massive multiplayer online games, the dominant UDP-traffic pattern in the Internet has moved from short-lived and small to long-lived and massive. The observed growth of these inelastic flows is feared to pose a threat to the health of the Internet, despite the fact that some applications implement their own congestion control mechanisms. DCCP is planned to be the Internet savior in this context because of the following [24]: Avoiding congestion collapse by introducing congestion control on unreliable flows. Defining a standard solution for reliable congestion feedback and congestion parameter negotiation for unreliable flows.

27 2.5. FEEDBACK MECHANISMS AND RATE CONTROL 19 Implementing a standard usage of Explicit Congestion Notification (ECN, see section 2.5.3). Providing a pre-defined and easy to use TCP-Friendly congestion control. Allowing easier NAT- and firewall-traversal. Providing low per-packet byte overhead. Maintaining the properties that makes UDP so much used: Low start-up delay compared to TCP three-way handshake. Statelessness. Prioritizing timely data arrival instead of reliable arrival. All of the above should be beneficial arguments for application developers if a common standard protocol is available and enabled in network and consumer equipment, since they remove the congestion control burden from the application layer and the developer. The DCCP protocol as such is not used in the simulations presented here. However, the DCCP standard defines several sets of congestion control mechanisms, each of whom are identified by a Congestion Control Identifier (CCID). To determine which congestion control to use, the server and client negotiate at connection setup or possibly thereafter by exchanging CCIDs. They can request to change congestion control mechanism during the connection, and different choices can be prioritized by listing CCIDs in datagram header. As of 2006 and DCCP standard document RFC4340 [25], only two types of congestion control are defined: CCID 2: TCP-like Congestion Control CCID 3: TCP-Friendly Congestion Control The CCIDs 0-1 and are reserved for other and future congestion control mechanisms. DCCP requires that any implementation supports at least CCID 2, but for multimedia transfer, CCID 3 is likely to be more popular. Therefore, CCID 3, TFRC, is used in the simulations presented here. TFRC is described in the next section TFRC UDP is often referred to as greedy because it has no congestion control mechanism, thus transmitting at a given pre-defined rate even though the path might be congested. This greedy nature of UDP will in competition with TCP traffic let the latter suffer because it reacts to returned network load parameters such as round-trip-time and packet loss probability by adjusting its transmission rate accordingly [6]. To make sure that a certain degree of traffic fairness is obtained in the network, the definition for TCP-friendliness must be met: A non-tcp connection should receive the same share of bandwidth as a TCP connection if they traverse the same path [26], [3]. TCP-Friendly Rate Control (TFRC) is a young protocol, first standardized by IETF in 2003 with RFC 3448 [9] and in 2006 included in the Datagram Congestion Control Protocol (DCCP).

28 20 CHAPTER 2. BACKGROUND It is described as the DCCP Congestion Control ID 3 (CCID 3) in RFC 4342 [27]. The protocol operates on unicast flows in a best effort Internet environment. It generates bit rates comparable to TCP connections on the same link, but with smoother transmission rate transitions than TCP has. Therefore, it is specially apt for applications that require smooth streams, like video conferences or other streaming media [9]. TFRC works according to the following four general steps: 1. Loss events are measured at the receiver and sent back to the sender. 2. The sender calculates round-trip-time (RTT) based on the feedback. 3. The loss event rate (from receiver) and calculated RTT is used as input for calculation of a new transmission rate. 4. The sender adjusts the rate accordingly. The new transmission rate is calculated using the TCP throughput equation: s X = R 2 b 3 p +t RTO 3 3 b p 8 p ( p2 ) (2.3) Where X is the new rate, s is the packet size (bytes), R is RTT (seconds), p is loss event rate, t RTO is the TCP retransmission timeout (seconds) and b is the number of packets acknowledged in one feedback packet. A feedback timer at the sender controls when the rate should be adjusted if no feedback is reported. The TFRC specification does not detail the content and set up of data transport, as it is meant to work alongside different types of transport protocols. However, some general requirements need to be met, i.e. sequence numbers, timestamps and a timestamp estimate. With the Evalvid- RA framework, it is possible to simulate pure TFRC transport directly on top of the network layer. In this setup, the TFRC header is 16 byte. With a maximal transfer unit (MTU) of 1000 byte and a 20 byte IP header, the total packet size is 1036 bytes. Through the TFRC interface to the application layer, Evalvid-RA fetches information about the current packet rate and adjusts the video compression accordingly. This interface is discussed further in section 4.1.

29 2.5. FEEDBACK MECHANISMS AND RATE CONTROL Network intelligence In the simulations of Chapter 3, tests of ECN, RED and P-AQM where originally planned. Due to scope limitation and other constraints, the simulations now focus more in depth on TFRC. Nevertheless, the technologies introduced here are discussed in Chapter 5 as some of several possible solutions to the challenge of providing more reliable real-time services over Internet. ECN & RED In a traditional TCP network, the packets are dropped if the input buffers on the routers are full according to the drop tail queuing algorithm. First when reports of packet drops are returned to the sender(s), the transmission rate is adjusted and the dropped packet is queued for retransmission. With a Random Early Detection (RED) queuing algorithm, the congestion can be foreseen and reported back to the sender(s) before any packets are dropped. Thus, the throughput and resource utilization is improved and the phenomenon called global TCP synchronization 9 can be avoided. RED monitors the average queue-length, and drops packets randomly according to a statistical distribution and minimum and maximum queue length thresholds (see fig. 2.6(b)). The packet dropping is simply a indication to the sender that the queues might overflow if its current rate is kept or raised. A problem with this solution is that the drop forces the sender to retransmit the unlucky packet, so it would be better to inform the sender about the congestion possibilities in another fashion [28]. ECN is a mechanism to do this congestion feedback without dropping any packets as long as they are not overflowing the router buffer. It is an extention to the IP-layer that can be used if both sender and receiver support the use of it. It is also depending on router support, since a) there is no point in using ECN if no routers knows how to use it for congestion indication, and b) some old IP routers might discard an IP packet with active ECN field (mistaking it for being corrupt). The addition to IP consists of a header field of two bits in the DiffServ-field (called the Type Of Service (TOS) field and the Traffic Class Octet in IPv4 and IPv6 respectively), see fig This header field is called the Congestion Experienced (CE) codepoint, and can have the values 01 or 10 to indicate that ECN is enabled (ECN-Capable Transport, ECT), or 11 to flag that congestion is observed (CE) [29]. To implement ECN in the Internet, it is necessary to enable support in the interface between network layer and transport layer so that the transport protocol receives information correctly. With TCP, this can be done as an evolution, since the use of ECN can be determined when the TCP connection is established. With UDP on the other hand, there is no two-way communication on the transport layer, so the sender has no way of knowing if the CE-flag has been set or whether the receiver supports ECN at all. One solution could be to allow applications access to the ECN mechanisms on the IP layer through the UDP sockets. Another solution, which would be more of a transport layer revolution, is to convert to DCCP, which has ECN-support by default [24]. 9 This occurs when several TCP sources are notified of packet drops simultaneously, thereby increasing/decreasing output rates simultaneously. Results are bursty traffic and poor utilization.

30 22 CHAPTER 2. BACKGROUND (a) RED & ECN enabled router (b) Drop or mark possibility Figure 2.6 A conceptual flow-chart of a RED & ECN enabled router (a) and a graph showing the drop possibility P(drop) of a packet when the queue average is between the two thresholds (Max/Min). Figure 2.7 The Differentiated Services and ECN fields in IP. (DSCP = Differentiated services Code Point) P-AQM DCCP is the IETF choice for the new generation streaming media transport protocol. It s use of binary congestion level feeback 10 has been questioned, and claimed to limit the accuracy and speed of rate adaption [8]. The Proportional Active Queue Management (P-AQM) introduces a different form of router queuing and a more detailed feedback report. P-AQM is not a transport protocol in itself and must be combined with UDP as a data carrier. The P-AQM suggestion consists of two functionalities; The queue management and the feedback mechanism. 10 Binary because the packet is reported dropped or not dropped, or the 1-bit ECN field of ECN enabled routers is set.

31 2.5. FEEDBACK MECHANISMS AND RATE CONTROL 23 AQM is a queuing method that can warn about congestion before a buffer overflow occurs. It uses queue length limits smaller than the buffer capacity and activates congestion feedback for all packets exceeding this limit. P-AQM uses a two-queue scheduler (see figure 2.8) that separates adaptive flows (TCP) and aggressive flows (UDP). While the TCP queue is kept under control by TCP s own rate controll mechanism, the P-AQM system takes care of congestion feedback for the UDP queue. Figure 2.8 The two-queue scheduler of P-AQM[8] Explicit Congestion Feedback (ECF) or Explicit Rate Feedback (ERF) are the two tested and analyzed methods for calculating and returning feedback to the stream source in [8] and [30] respectively. Both variants are suggested to be sent via Internet Control Message Protocol (ICMP) Source Quench packets directly to the sender, since neither TCP, UDP nor IP has suitable fields for this use. These packets have a 32 bit unused field that can carry more detailed feedback information than the ECN system. In the ECF variant, the congestion level is indicated by a value below 1 to report congestion and above 1 to indicate available resources. The values are calculated as Additive Increase / Multiplicative Decrease (AIMD). In P-AQM, this value is not calculated to ensure TCP-fairness, since this is taken care of by the router queue scheduler (see eq. (2.5)). The calculated value is instead optimized to ensure intra-udp flow fairness and to make the rate adoption smooth and dynamic to fast traffic load changes. When the server receives the ECF value, it calculates the new rate with { ECF(n) r(n) ECF(n) < 1.0 r(n + 1) = min{(n) + ECF(n),r max ECF(n) > 1.0 (2.4) where r max is the original or maximum rate of the streamed source. Also, the server has to take into account that several router nodes my be sending reports. In that case, the report with the lowest value should be used as ECF(n) in eq. (2.4). This rate adaption ensures max-min fairness, which is a traffic shaping property that assigns a fair share of the bandwidth to both low and high bit rate data flows. DCCP in contrast, uses RTT measures to achieve proportional fairness and TCP-friendliness. The queue scheduler is responsible for fairness between elastic (TCP) and inelastic (UDP) traffic. In P-AQM, the available bandwith to non-elastic traffic is given by c ud p (n + 1) = c no fudp f (n) no fudp f (n) + no f TCP f (n), (2.5)

32 24 CHAPTER 2. BACKGROUND where c is the total output capacity, no f TCP f (n) is the number of long running TCP-flows and no fudp f (n) is the number of UDP flows chosen based on the proportional bandwidth demand of each present flow. Output capacity available for TCP is thus c tcp (n + 1) = c c ud p (n + 1). (2.6) This queue scheduling method is not claimed to be optimally TCP-friendly for all combinations of short/long-lived, bursty/stable and small/big flows, but it has proved good performance when the TCP flows are long-lived and the UDP flows are persistent (Section sources: [8], [30], [31]).

33 2.6. WIRELESS TRANSMISSION: Wireless transmission: To get a thorough understanding of the problems connected to transport layer feedback mechanisms in wireless environments, it is important to have a brief overview of the relevant technology in wireless networks. This master thesis focuses on the most widespread wireless broadband access today; the ANSI/IEEE wireless LAN system The group The standard has been developed since the mid-90s, leading to a comprehensive group of standards and enhancements today. The first edition of the standard was approved in 1997, and offered bitrates of 1 or 2 Mbps. Two years later, the first substandard called b introduced bitrates of 5 or 10 Mbps, working in the GHz-band. In a parallel research process, another substandard called a was defined. This standard operates in the same frequency band as the legacy (5 GHz), a band that is not as heavily used as the 2.4 GHz-band of b. It allows for faster signaling and less interference, so the a standard works on velocities from 6 to 54 Mbps. However, due to the high carrier frequency, the standard has limitations on distance and coverage. In practice, the a standard has a reach of about 30 meters and is limited to almost line of sight [32]. In 2003, a new amendment joined the group, ratified and known as g. This variant combines benefits from both its predecessors by allowing up to 54 Mbps in the 2.4GHzband. Hence, faster data transfer can be achieved in a larger coverage area, and walls or obstacles do not interrupt the traffic to the same extend as with a. Today, most consumer equipment supports a tri-band mode covering all three substandards in the group [33]. To keep up with the velocities of wired ethernet LAN, a group was formed in 2004 to develop n. The working drafts of this group has recently passed a working group voting, and are estimated to be published in September 2008 [34] n is supposed to support bitrates of up to about 700 Mbps, using two antennas transceiving 360 Mbps each in Advanced beamforming mode [33]. In addition to the the original standard and these three amendments, the standard covers security (802.11i), bridge operation procedures (802.11c), roaming extensions (802.11d) and QoS (802.11e) among others. The latter can have a significant impact on video streaming speed and quality, and will be covered in section General architecture and specifications The standard specifies the use of both the physical (PHY) and the Media Access Control (MAC) layer. The legacy specification included three alternative PHY implementations; Frequency Hopping spread spectrum, Direct Sequence Spread Spectrum (DSSS) and Infrared. However, only DSSS has been further developed in the later amendments (802.11b). Both layers of the stack have a layer management entity to provide management interfaces within and between the layers. Additionally, each unit has a station management entity that operates on both layers. The PHY layer carries out the modulation and encoding.

34 26 CHAPTER 2. BACKGROUND a and g uses Orthogonal Frequency Division Multiplexing (OFDM) but with different types of subcarrier modulation b uses Complementary Code Keying (CCK) which is a variation of Code Division Multiple Access (CDMA). The MAC layer has several responsibilities. The standard defines: An asynchronous data service with the upper layer, normally Logical Link Control (LLC) layer. This includes fragmentation and reassembly of packets and MAC Protocol Data Units (MPDUs), and framing procedures. Unlike Ethernet (802.3), depends on framing from the LLC. Security services: Originally, the security was covered by Wired-Equivalent Privacy (WEP), but as this encryption proved to be insecure, the i-group was formed. Before the i amendment was complete, Wi-Fi-Protected Access (WPA) was released to the market. This protocol implements parts of the i specifications, while the newer WPA2 satisfies all requirement stated in i. MPDU ordering of multicast, broadcast and directed MPDU traffic. Access procedures, which is covered in section Association service: Controls the association state between STAs and APs. This service includes media scanning (passive or active) and synchronization. Figure 2.9 STAs connected to AP1 are part of one BSS, STAs connected to AP2 are part of another. Together, the two BSS form an ESS. A wireless network can have two distinct topology modes; Ad-Hoc or Managed. In the former mode, at least two mobile stations (STA) are interconnected without external management. The latter and most commen mode consists of one or several Access Points (APs) and STAs. Each STA is associated to one AP and this AP is usually connected to a wired LAN or backbone network through a Portal (PO). Together this forms an infrastructure Basic Service Set (BSS). An interconnected WLAN with several APs is called a Extended Service Set (ESS),

35 2.6. WIRELESS TRANSMISSION: see figure 2.9. In the simulations presented later in this report, a topology with support for one multi-bss ESS will be used MAC Access procedures and timing To avoid collision of traffic on the same channel and minimize the chances of network internal interference, the MAC layer must have rules to regulate how and when the mobile network nodes (STAs) access the medium. There are three types of access procedures defined in the current standard: PCF The Point Coordination Function access procedure requires one central node to coordinate which station that is allowed to send at each given time. It can be used in point to point connection (ad-hoc) between to stations, or it can be the job of an AP. PCF provides contention free frame transfer and thus allows for better QoS, but it does not define traffic classes, nor does it work with RTS/CTS scheme (described later). PCF is not widely implemented because it is optional, and will not be used in simulations in this report. HCF The Hybrid Coordination Function is a part of the new QoS-amendment; e. It will be fully described in DCF The Distributed Coordination Function is the most common form of media access control in networks. The DCF technique used in is called Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA). It will be further described in the following. For elastic traffic types such as normal web-traffic or FTP-traffic, the main priority is to get every sent byte to the receiver, so variable delay and retransmissions are acceptable. For nonelastic traffic such as real-time video and audio however, the delays should be minimized and held as constant as possible. Since the DCF access procedure of is the most used and implemented technique in wireless networks today, it is interesting to study how it impacts the end to end delay of a multimedia session. This will be covered in the simulation case III, section The DCF access procedure is carried out in several steps. First, the STA senses the medium before transmitting. If the medium is free for a given period, called the Distributed Interframe Space (DIFS), the STA is allowed to send its data. While the STA transmits, other STAs can sense the transmission and defer access. When the Transmission is over, other stations can send after a DIFS period. If the medium is not available after a DIFS, the STA activates a backoff algorithm. This is called a binary exponential backoff algorithm and the backoff interval is chosen randomly to form a uniform distribution. The reason for this is that several STAs may be waiting to transmit at the same time. When they sense that the medium is available, the random backoff interval will make it less possible that they start transmitting simultaneously. In addition to being triggered when a STA senses that the medium is busy, the backoff algorithm is triggered after each transmission and retransmission. The backoff time is upwards limited with the contention window parameter. The contention window is increased exponentially for every retransmission n of a MPDU following CW = 2 n 1 [transmission slots], but with an upper

36 28 CHAPTER 2. BACKGROUND Figure 2.10 Complete CSMA/CA procedure for transmitting one frame with RTS/CTS. (Note that the packet sizes are not displayed in realistic order of magnitude.) boundary set by the physical layer. For example, the DSSS type limits the maximum contention window to 1023 transmission slots 11. Most unicast frametypes are required to be acknowledged by the MAC protocol. This is sent with an acknowledgment packet after a period called Short Interframe Space (SIFS). The entire MPDU transmission and acknowledgment process is illustrated in figure Broadcast or multicast traffic will not be acknowledged. An optional CSMA/CA feature is the exchange of packets called Request To Send (RTS) and Clear To Send (CTS). This is mainly used to solve the hidden station problem, which is as follows: Two STAs wants to transmit data at the same time. They can both reach and sense traffic from the associated AP, but due to distance, walls or other physical obstacles, they cannot sense each other. Both stations will assume that they have available transmit time, but the AP will receive from both STAs, resulting in interference and failed reception. The RTS/CTS carrier sense mechanism forces STAs to ask for a pre-transmission application with a RTS package containing the length of the transmission, as seen in fig All STAs do not necessarily hear the RTS transmission, however, all STAs must hear the AP. So, if the transmission application gets approved by the AP, a CTS, which everyone hears, is returned. All STAs with the same AP association will then set a Network Allocation Vector (NAV) which indicates the length of a pre-transmission SIFS, the transmission, a post-transmission SIFS and the acknowledgment. The NAV effectively blocks any transmission from the other STAs when it is set. When the NAV is released, all STAs must wait one DIFS and the random backoff period before they can apply for a transmission (Sources: [32], [33], [36]) Link stability As mentioned earlier in this report, the wireless transmission medium, air, can be error-prone. Unlike wired connections, it is difficult to guarantee throughput, bandwith, delay or jitter, especially when the wireless nodes are allowed to move while transceiving and the current frequency a and.11g have a slot time of 9 µs while b has 20 µs g scales down to 20 µs if some stations lack the high speed mode [35].

37 2.6. WIRELESS TRANSMISSION: Figure 2.11 The different rates have different modulations which results in different SNR [37]. band is not 100% reserved for the service. Some of the reasons for link instability are briefly summarized in the following. Rate control Rate control in the network interface is used to make a STA flexible to the big signal strength variations observed when the STA is moving or interference fluctuations occur. The PHY layer of provides different discrete rate services to the above layers 12. Each discrete level corresponds to a coding and modulation scheme, all differing in radio coverage and noise sensitivity. For instance, the 64-QAM 3/4 offers large throughput but is noise sensitive and thus provides a narrower coverage, see figure It is up the device driver to choose which rate service it currently wants based on information on the link conditions, called Channel State Information (CSI). For real-time applications, it is important that the algorithm that chooses desired rate is fast and clever enough to adjust the rate according to temporary and constant signal strength changes. Normally, this algorithm is based on feedback statistics calculated over time. Now, a short and temporary drop in signal strength might cause packet loss and trigger MAC layer retransmission. In the rate controller, the throughput is smoothed by the statistical process, so the short drop-out will have no effect. To elastic traffic, this is not a problem, in fact, it is the most effective solution. For real-time traffic however, it may cause severe quality degradation rate controller algorithms for real-time traffic is discussed further in [37] (paragraph source). 12 i.e. 6, 9, 12, 18, 24, 36, 48, and 54 Mbit/s in a

38 30 CHAPTER 2. BACKGROUND Fading and shadowing Fading and shadowing are typical radio issues that decrease the QoS of a link. Shadowing occurs when an object cuts off the line of sight between two communicating STAs or STA to AP. The effect of such a blockade of the direct signal depends on the signal strength and the amount and quality of reflected signals. In open air, there is ideally no reflected signal components, while on open ground there is at least one set of reflected rays 13. In a home or office network, all objects, walls and buildings will cause a mesh of scattered reflections. While these reflections can reduce the consequences of direct shadow, they introduce another problem: Multipath fading. When a radio antenna receives both a direct signal and a reflected signal, it will observe that the reflected signal is slightly delayed because of the added distance. Reception of several delayed signal can lead to both destructive and constructive interference and phase shifting. Destructive interference happens when the signal is partially cancelled by a phase-shifted variant of itself. This phenomenon is often referred to as Rayleigh fading or Rician fading. The Rayleigh fading distribution model is most applicable if there is no line of sight between sender and receiver (source [38], [33]). Interference Interference is common in networks because of the frequency band licensing. The 2.4 GHz band 14 which is used by both b, g and n, is not a dedicated channel for WLAN only. A normal household appliance today that has emissions in the ISM-band is the microwave oven. A normal oven for private use operates on a relatively narrow band close to 2.45 GHz and transmits on that frequency only every 20 ms. Therefore, its external radiation is only disturbing some of the channels used by , see figure A professional restaurant oven on the other hand, uses two instead of one magnetron tubes (transmittors) which occupy a broader frequency range twice as often. Allthough the commercial ovens normally are better shielded than residential ones, the radiation is sufficient to cause problems for several channels a majority of the time [39]. Another widely discussed source of interference to is Bluetooth. This wireless network protocol is designed for small distances, and the senders have a power output of about 20 dbm. Still, a significant interference is observed if transmitting Bluetooth devices are within about 5 meters from a receiving STA. The effect is stronger the further away from the AP the STA is because the Signal-to-Interference (S/I) ratio decreases (Sources: [40], [41]) Quality of Service enhancement: e The IEEE 802 working group fully accepted the new standard amendment for enhanced Quality of Service, e, in September 2005, almost five years after the task force was originally formed [34]. The need for improved jitter and delay control was increasing as the use of both 13 Called Two Ray Ground Propagation, discussed more in section Called the ISM-band (Industry, Science and Medical applications).

39 2.6. WIRELESS TRANSMISSION: Figure 2.12 Commercial/professional microwave ovens (red) generate noise in a broader band and interferes with more channels than residential ovens (green). (Note that the channel allocation on the y-axis has no direct relation to the noise value.) WLANs and realtime media escalated. To give this traffic type better conditions three things had to be improved with the new amendment: 1. A transmitting STA must get a guarantee of a certain minimum of medium access to avoid buffer delay and jitter problems. 2. A system for traffic flow classification and differentiation must be available. 3. The transmission overhead should be minimized without making the transmission more vulnerable to interference and errors. The e amendment introduces solutions to these three points through a new scheme for grouping and acknowledging MPDUs and two new schemes for medium access. The acknowledgment scheme is called block-ack, and works in the following way. The transmitter is allowed to transmit several MPDUs in a row without waiting the duration of two SIFS and an acknowledgment between each MPDU. This is called a Transmission Opportunity (TXOP). At the end of this TXOP, it sends a block-ack request containing the MPDU sequence numbers contained in the burst. The receiver replies with a block-ack for all the correctly received MPDUs. The missing MPDUs will be buffered at the sender until they have been acknowledged or their packet life time expires. The receiver MAC buffers the incomplete burst until the remaining MPDUs are received or it receives MPDUs with higher sequence number than the lost ones. This indicates that the lost MPDU s lifetime at the sender has expired. Note that e enables the MAC entities to operate with packet lifetime instead of retry limits. This gives a better delay constraint for real time applications. An effect of the TXOP / block- ACK mechanism is that the receiver MAC delivers the MPDU-bursts to the above layers only when the entire burst is received or the MPDU lifetime has expired. Hence, application layer bandwith estimators may be fooled to compute wrong results. The new schemes for medium access in e are improvements to PCF and DCF through the new Hybrid Coordination Function (HCF). Two variations are defined; The Enhanced Distributed Channel Access (EDCA) and HCF Controlled Channel Access (HCCA).

40 32 CHAPTER 2. BACKGROUND EDCA EDCA is an improvement to the legacy DCF and was therefore formerly known as Enhanced Distributed Coordination Function (EDCF). It provides relative qualitative differentiation of traffic based on traffic classes at each STA. It is however not able to provide any hard QoS guarantees. The legacy DCF mechanisms ensures a inter- and intra-sta traffic fairness by giving all STAs equal chances of acquiring a transmission slot in the backoff period. Additionally, DCF uses only one queue for outbound traffic. These two issues limits the QoS differentiation significantly. EDCA addresses both problems by allowing a certain traffic unfairness and by splitting traffic classes into separate queues. Four Access Categories (ACs) are defined in EDCA, listed in prioritized order: Voice, video, best effort and background. These ACs are treated with different Contention Windows. The high priority AC is assigned with a smaller CW than the lower prioritized ACs so that it will always have a higher probability of acquiring the medium. Additionally, EDCA allows the ACs to use different Interframe Spaces (IFS). While all traffic in DCF uses fixed values for DIFS and SIFS, EDCA assigns a bigger IFS to the low prioritized ACs and thereby forces them to wait longer than the prioritized ACs before initiating the backoff algorithm. HCCA HCCA is an improvement of the legacy PCF, the contention-free access method. HCCA is the most complicated of the available and standardized access methods, but is also the one which can promise the strongest QoS. As with PCF, the HCCA divides the timeline into a Contention Period (CP) and a Contention-Free Period (CFP). While PCF uses polling from the AP to allow STAs to transmit in CFP and uses legacy DCF in the CFP, HCCA uses the more advanced and effective EDCA in CFP. Moreever, the hybrid controller (which is the AP), can define both traffic classes and traffic streams, which enables it to prioritize on a session-level. Each STA can report its queue lengths for every AC. With this information, the AP can make improved decisions and differentiation for better over-all QoS performance. Despite that HCCA can provide the best QoS available following the IEEE standard, it is rarely implemented in consumer equipment as is the case with PCF. The international Wi-Fi-Alliance has developed an equipment certificate based on the e amendment called Wireless Multimedia Extension (WME) or Wi-Fi Multimedia (WMM). This is mainly used to certify Voice over IP and WLAN equipment such as IP-telephones (sources: [42], [35], [43]).

41 CHAPTER 3 Simulation background and layout This section of the report covers the details of the simulations carried out, and how the system was set up to obtain interesting results. The reader will find discussions on how the different parameters where chosen, and how they affect the system in theory. Before the performed simulations are described, their goal is further defined and the simulator implementation is described. The results and analysis of the obtained results can be found in Chapter Goal As stated in the introduction of this document, the primary goal of the simulations in this thesis is to illustrate the advantages and disadvantages with TFRC in a realistic wireless environment and compared to TCP and UDP traffic. The protocols in question have all been tested thouroughly over wired networks with different types of cross-traffic, topologies, equipment, capacity and levels of realism. Both UDP and TCP traffic have been tested and simulated over wireless networks, but TFRC performance in wireless networks is not so thoroughly documented. The simulation results shall be a basis for further discussion of TFRC and DCCP as a multimedia carrier, but also to pinpoint the performance of for real-time traffic. In the master pre-study [13], the focus of the simulations was to see how TFRC performed when unavoidable packet losses occurred due to an unstable link. That study is continued here with a proper MAC and PHY implementation in ns-2. The TFRC and performance is evaluated through a set of cases with the following hypothesis : Case I: TFRC gives better results than UDP with high traffic load and interference (sec ). Case II: UDP gives better results than TFRC with low link quality or noise (sec 3.7.2). Case III: MAC gives significant added delay (sec 3.7.3). 33

42 34 CHAPTER 3. SIMULATION BACKGROUND AND LAYOUT The results from these cases are meant to illustrate a set of effects that are of importance for a real-time multimedia service delivered to a wireless client. The goal is to find the vital deviations in behavior and performance in a relatively coarse scale. 3.2 Topology With ns-2, most topologies can be defined with Tcl-code. The Tcl-script base used (see Appendix D) is written completely from scratch to ensure a tidy and structured code that fits the simulation purpose optimally. It defines a dumbbell -topology as illustrated in figure 3.1. The setup defines a server access network, a simple core network, a base station network and wireless access networks 1. To simulate l streams to m users in n formats or types, the script automatically sets up n separate servers, m clients and the l connections between them. The supported applications and protocols are: VBR Video/UDP Rate-Adaptive VBR Video/TFRC FTP/TCP Web(HTTP)/TCP Ping/ICMP All of these will be used in different numbers and combinations to get the desired scenarios described later. When studying the impact of errors on a link, it is important to isolate the error source in the analysis. To avoid confusion from queue delays and contention in other part of the network, the Tcl-script is set up to let all data stream without long propagation and contention delay from their respective sources to the wireless access network. Figure 3.1 shows the final topology with all application types enabled. It has five source nodes, or media servers, and seven consuming nodes, or clients. Note that while two FTP clients are connected to one FTP server, and two VBR Video/UDP clients are connected to one VBR Video/UDP server, each VBR Video/TFRC client requires a separate VBR Video/TFRC server. This is done to make the interaction with the Evalvid-RA toolset smooth. The toolset in its current state is only capable of monitoring and rebuilding one video flow per simulation for further analysis. This video can be transported with either UDP or TFRC, but to compare the results of two video streams, two separate simulation iterations must be executed. The Evalvid- RA toolset simply monitors the flow that starts first. How the different simulation iterations are controlled by external scripts are described in section 3.5 and under each case description (sections 3.7.1, and 3.7.3). The simulations carried out to test TFRC and performance here are similar to classical client-server service. However, the technologies in question are equally interesting to use 1 The latter two are also known as Extended Service Set (ESS) and Base Service Set (BSS) respectively in literature.

43 3.3. SIMULATION CONTROLLER: TCL 35 Figure 3.1 The implemented topology with utilization of all application types. in video-conferencing, where the communicating nodes act as both servers and clients simultaneously. Allthough the script can be used for the latter service with only minor modifications, the results from the presented simulations apply to both service types as is. The most important difference in QoS demand is short RTT for video-conferencing, a parameter that can easily be tuned in the simulation framework. 3.3 Simulation controller: tcl The main part of the programming and implementation challenge in the performed study is the design and testing of the script that sets up and controls the simulation. As mentioned in section 2.4.3, the ns-2 simulator has a core of compiled C++-objects which can be controlled and linked together through an interface with OTcl. The OTcl framework of ns-2 is in turn controlled by a user made script written in Tcl. The script that sets up and controls the simulation of this study is called tcl, can be found in Appendix D, and will be briefly explained here. The complete interaction of one end-to-end video transmission is not totally controlled by this script, but includes all elements of the Evalvid-RA framework described in section How this framework is controlled, is described in section 3.5. Now, since the tcl-script is not the top-controller, it should be controllable through an interface to other scripts or programs. Therefore, the script execution starts with a method that reads in all parameters delivered from command-line and sets the correct internal parameters accordingly. For example, the shell command $ ns tcl -noftfrc 1 -nofudp 1 -doping 1 -disablerts_cts 1 -prop Propagation/Shadowing -verbose 0 tells the simulator to set up one TFRC server and client, one UDP server and client (nof = number of ), to do an initial ping to check the connection, to turn off the MAC-layer RTS/CTSmechanism (described in section 2.6), to use a shadowing propagation model, and not to write

44 36 CHAPTER 3. SIMULATION BACKGROUND AND LAYOUT Figure 3.2 The network layer address hierarchy out information at run-time 2. The parameters that are not set through this command-line interface, are used based on default values set in the beginning of the script (i.e. TwoRayGround is default propagation, pinging is disabled by default etc.). The next thing the script does, is to count all source and destination nodes required, and to set up the topology with nodes and links accordingly. All nodes are addressed in an IP-like manner, with a three layer hierarchical model as seen in figure 3.2. They are set up with specified queuing types, routing algorithms and link layer types, and are connected with links with the specified bandwidth and propagation delay. All MAC- and PHY-layer parameters for the network are set in this phase. The next task for the script is to prepare input and output streams for the Evalvid-RA cooperation. The script tells the simulator where to find video tracefiles and what to do with them. It opens files to write the simulation results such as video frame send and arrival time from and to the Evalvid-RA application layer implemented in ns-2. So far in the script-execution, the nodes are set up and the input/output is prepared, but no services are defined. Each service-type (FTP, WEB, Video/UDP and Video/TFRC) has a dedicated setup-function that instantiates the application server and client at each node and connects them. Once this is done, the simulator is fed with the transmission schedule, which is the the start and stop times of each application. In addition to this setup, the script has functions to record the data throughput, and connectors for incoming/returned data to the Ping/ICMP and Video/TFRC instances. When the Tcl-script has been executed, all necessary variables and settings are loaded into the compiled ns-2 core and the simulation starts. 2 This function can only control the output of the Tcl-script, not the compiled code.

45 3.4. NS-2 MODIFICATIONS ns-2 modifications The current ns-2 framework contains all the necessary code for both wireless networking with and the transport layer protocols UDP, TCP and TFRC. Virtual application servers for web and FTP traffic are also included, but to enable the rate adaptive video application, some changes and add-ons must be made. To enable this, code from the Evalvid-RA project [12] must be plugged in with a seven step manual installation procedure. When the ns-2 package with the new add-on is recompiled, a rate adaptive video service can be added to a server node via the Tcl interface. To enable the Evalvid-RA video application to run over both TFRC and UDP at the same time (from different servers, but with the same simulation source code), some changes in the Evalvid-RA source code had to be made. The source file called vbr rateadapt.cc had predefined states with static variables to enable or disable the TFRC header type 3. To provide dynamic changing of header type, code was added to receive and store this setting directly from the Tcl script via a boolean-style variable called istfrc. The standard protocols in ns-2 have a variable called bytes to store the number of bytes received in the protocol s sink entity. The modified UDP protocol eraudp however, lacks this variable. Thus, the throughput to an eraudp-node can not be recorded with the same methods as for other protocol types. To change this, the OTcl-to-C++ interface for bytes was added together with a line to ensure correct updates of the value in evalvid ra sink.cc and evalvid ra sink.h. 3.5 IO-handling As mentioned in several sections earlier, the simulation process is not one single program thread but a compilation of several programs, all executed from various shell-scripts. Most of the programs take different relevant parameters as input and write results to binary files, text files and/or to the standard output buffer of the shell. Each program can easily be run directly from the command line, but because many of the simulation scenarios are best tested as iterative processes, shell scripts with loops are necessary (see Appendix B). To coordinate the program executions, correct input must be given to each program, and their respective output must be named and stored in a place where the next program can find it, if necessary. This master study has led to the development of several shell-scripts: manyq.sh This script comes with the Evalvid-RA package, but is slightly cleaned up and modified to fit the video input. The script takes minimum and maximum quantization and filename as input, and executes FFmpeg and mp4 iteratively. For example, FFmpeg is controlled with the following: ffmpeg -r 30 -s 176x144 -i [original YUV video] -vcodec mpeg4 -g 12 -sc threshold qscale [Q-param] -s 176x144 -r 30 -y videovariants/[video-name] Q[Q-param].m4v 3 A TFRC packet has 36 bytes of header while a UDP packet has only 28 bytes.

46 38 CHAPTER 3. SIMULATION BACKGROUND AND LAYOUT This line means that a video specified with the -i parameter, a frame rate of 30 fps and qcif size (176x144) should be compressed with mpeg4 to a m4v-file with quality specified in -qscale. When looped several times in manyq.sh with different [Q-param], this creates a library of the different available compression levels on the streaming server. Note that while the total system described here simulates an online encoder, the library of video files are encoded offline. Next, the mp4-utility uses the newly constructed compressed files as basis for trace file generation. Since it runs through all necessary actions to prepare a Evalvid-RA ns-2 simulation, it is called the pre-process. Since it is normally only needed to run this script once for each raw video that is used in the simulation, and since the process is time consuming, the pre-process is not included in the case controlling scripts. case(n).sh Each case uses a shell script (the three variants are found in Appendix B) to run the simulation and its post-process. Each of these scripts enable the user to specify the number wanted of each service type, and to control which parameters are changed for each iteration of a simulation. It executes all programs necessary to obtain the wanted data (i.e. PSNR-value(s), delay or throughput) and displays the results in a graph with suitable layout and axis-texts. Figure 3.3 shows the typical sequence of an Evalvid-RA process end to end. clean.sh This is a simple script to remove all temporary output from previous simulation, so that the next simulation is not disturbed by previous values. For instance, mp4creator concatenates its output to allready existing output with same name, so that a mp4-file might be several times bigger than it should be. Clearly, this affects the following programs in the process chain. Since all of the different processes provide runtime-messages and write one or several output files, the working folder can be quite messy and the user looses overview if the temporary files are not removed from time to time. To sort out the relevant data from various tracefiles and other simulation output, Awk-scripts have been made (see Appendix C). These scripts search through the given input data line by line for a specified pattern, performs calculations on the found data and prints the result to standard out in the shell.

47 3.5. IO-HANDLING 39 Figure 3.3 The complete interaction model between program instances for pre-process, simulation and postprocess. This process can be controlled by shell scripts containing loops to do it several times with differing input parameters.

48 40 CHAPTER 3. SIMULATION BACKGROUND AND LAYOUT 3.6 Wireless channel The ns-2 comes with code and framework to simulate b networks with both ad-hoc and infrastructure topology. The implemented protocols feature MAC and PHY layer simulation with the possibility to set parameters to get close to specific real implementations. This is useful for all scenarios where the researcher wants to be as realistic as possible and if the results from a physical installation is to be compared with simulation results. However, the control interface in Tcl is not as intuitive as one might think and the default values of ns-2 are not always very useful. In [44], J. Robinson walks through a set of features that should be added or modified to enable close to real-life simulations of b: The data rate of ns-2 is only 2Mbps by default. Today most cards support g or even n with 54Mbps and 270Mbps+ theoretical capacity respectively, but since ns-2 seems to be most tested with b, the data rate should be set to 11Mbps with Tcl (MAC/ set datarate 11Mb). An unfortunate limitation with the ns-2 implementation, is that it does not support Auto Rate Fallback (ARF). The consequences of this is discussed further in section In MAC, the standard defines that a Request To Send packet (RTS) should be sent if the PDU size is above a RTS threshold. According to [44], most commercial equipment for non-professional use is stripped for the entire RTS/CTS functionality to save transmission overhead. To simulate a home wlan, which is relevant in this study, the RTS/CTS can be effectively turned off in ns-2 by setting the RTS threshold to a value higher than the MTU of the protocol (MAC/ set RTSThreshold 3000). This will be tested in Case III, section (results in 4.2.3). The preamble used in the PHY to synchronize sender and receiver directly in front of a packet transmission, has different size from implementation to implementation. However, the preamble size will be the same for all protocols in the simulations presented here and the possible inaccuracy involved is assumed to be minimal. The physical channel implementation models of ns-2 are said to be simple and inaccurate. For example, [45] argues that the threshold parameters in the simulator should be used together with a Bit Error Rate (BER) calculation to provide accurate real-life imitation. [44] recommends the use of specially designed channel model add-ons to simulate more realistic scenarios. An option is to integrate Rayleigh and Ricean fading models, but the pitfalls and added complexity of adding more unknown code to the ns-2 core taken into account, the existing channel models are considered sufficient for the simulations carried out here. A final interesting observation made in [44], is that the maximal achieved throughput varies substantially with different transport layer packet size. Evalvid-RA has 1000 bytes as MTU for both TFRC and UDP. This can imply a bandwidth reduction of about 1Mbps in standard b networks.

49 3.7. SCENARIOS 41 During the development and setup of the simulator controller script, several pitfalls where discovered. One example is the use of Phy/WirelessPhy set bandwidth, a Tclcommand that can be seen in several of the example scripts that comes with ns-2. It was discovered that the values set here had no effect on the wireless throughput. After some testing and searching, the cause was found: the bandwidth -parameter in wireless-phy.cc was commented out and in fact never used in the remaining source code. Another example of a pitfall is that the interface queue of the wireless access point consistently drops the two first packets in a simulation if they are from a UDP flow. For video transfer, this is crucial since the first packet contains header information that is needed to decode the rest of the video stream. When these two packets are dropped, the ffmpeg decoder is not able to decode any of the subsequent data. The cause of this problem is not found, but it is solved by sending a downstream ping message from server to client before the initial video packets 4. A third and last example is that the user is not notified by a misspelled parameter setting in Tcl. The consequence is that ns-2 runs just as normal, but with another parameter setting than the user expects, until the misspelling is discovered. 3.7 Scenarios To test the simulation environment, link types, transport protocols and applications, different scenarios, or use-cases, had to be defined. In each of these, some result should be expected based on previous simulations and theoretical background information. In this section three different cases are defined and explained. The two first cases are formulated based on results from [13] and are focused on the TFRC performance in congested and erroneous environments. The third case is made to illustrate how the MAC algorithms in affect the performace in terms of delay and delay-variations (jitter), which are of high importance to real-time services. While the cases I, II and III are introduced here, their results are found in the results chapter under sections 4.2.1, and respectively Case I: Congested wireless link TFRC gives better results than UDP with high traffic load and interference This first case is based on the original theories behind rate adaptive video, namely that the video quality is better when the compression and transmission rate is adjusted to the changes in network congestion compared to static compression and high packet loss rate. Evalvid-RA is tested and verified to provide good scaling and QoS over wired congested networks, so in this work the performance in a congested wireless network will be tested. While the real bottleneck of a wireless network is the physical layer bandwidth limitations, the most interesting aspect of the network performance is how the MAC layer allocates the resources to the different traffic types and connected nodes under high traffic load. The CSMA/CA scheme with RTS/CTS generates a significant amount of chatting and overhead on the link. How this affects the video 4 the script must get -doping 1 as input, see proc ping in Appendix D

50 42 CHAPTER 3. SIMULATION BACKGROUND AND LAYOUT quality with TFRC (rate adaptive video) and UDP (non-rate adaptive video) will be measured with PSNR and manually inspected. The case is separated in two blocks with four different runs on each: 1. A TFRC-flow is monitored while different traffic types runs simultaneously: From one to eight concurrent TFRC-flows. From one to eight concurrent TCP-flows. From one to eight concurrent UDP-flows. From one to eight concurrent flows of mixed type. 2. A UDP-flow is monitored while different traffic types runs simultaneously: From one to eight concurrent UDP-flows. From one to eight concurrent TFRC-flows. From one to eight concurrent TCP-flows. From one to eight concurrent flows of mixed type. The reason for this high number of different tests is to be able to pinpoint which competing traffic types that are critical to the video quality and to check inter- and intra-protocol friendliness (see definition in section 5.1). To execute the simulations in this case, the shell-script case1.sh (found in Appendix B) has been made. The script basically does the entire simulation and post-process described in section 3.5 and seen in figure 3.3 for different numbers of competing traffic. Each iteration generates a bandwidth graph that displays the throughput to each wireless node. This is very useful to see the inter- and intra-friendliness of the different flows. At the end of the run, a graph displays the average PSNR-value for each iteration to illustrate how the over-all video quality is affected by an increasing degree of congestion as the number of concurrent flows grow. In addition to the program executions of ns, ffmpeg and so on, a little Awk-command is inserted to read out the resulting PSNR-value from the psnr program output. The script also arranges the resulting files for archiving and analysis Case II: Node movement and variable link quality UDP gives better results than TFRC with low link quality or noise Whereas Case I is meant to illustrate a benefit of using TFRC to control the video data transfer in a wireless environment, this case is meant to point out a drawback caused by the congestion control mechanism. The problem found in the pre-study [13] is that TFRC does not distinguish congestion losses from link error losses. In a wired environment, a packet is typically lost because of buffer overflow due to queues in intermediate routers. TFRC catches this event and adjusts the transmitting rate accordingly so that the subsequently sent packets get through the router queue. When TFRC is used as a bearer of rate adaptive video, reduced sending rate

51 3.7. SCENARIOS 43 implies reduced video quality due to harder compression (higher quantizer value in MPEG-4). However, temporary reduced video quality is considered better for the overall quality perception than interrupts and freezes because of dropped frames and packets. In a wireless environment on the other hand, a packet can be lost because of a sudden propagation shadow, a hand-over, interference from other transmitting equipment or signal fading. In this case, it is not always helpful to reduce the bit rate, frame rate or packet rate since the link quality may still be poor and packets will be dropped anyway. The expected results from the tests performed in this case, are that beyond some link quality threshold, the video transported with TFRC will experience both a quality reduction due to quantizer increasment and a reduction due to link error drops. To simulate varying link quality with ns-2 and b, the general idea was to adjust the distance of the nodes to and from the access point, possibly using different link layer propagation models provided by the simulator. In the development of a control script for this case, several problems were encountered. First, adjusting the distance of the nodes had no effect up to a limit of 16 meters. Beyond 16 meters the throughput fell from 100% to 0%. Second, the two models FreeSpace, which is signal propagation with no reflection, and TwoRayGround, which is propagation with one reflector surface, gave totally identical results for all distances. Third, the ns-2 option of using random node movement did not work 5. Fourth, the more complex Shadowing propagation model gave segmentation faults at run-time. Now, as recommended by [45], the Rayleigh and/or Ricean fading models could be implemented instead of the existing shadowing model, but luckily a satisfactory solution was found with the latter when a bug was discovered. The bug was related to the distance between mobile nodes and access points, and the reference distance used in the calculation of the received power within the shadowing model. When the reference distance d 0 and the node-to-ap distance d had a difference of more than one meter, the segmentation fault was avoided. The shadowing model then uses the following representation for power calculation: [ P r (d) P r (d 0 ) ] db ( ) d = 10βlog + X db (3.1) d 0 Here, P r is the reception power, β is called the path loss exponent (controllable with Propagation/Shadowing set pathlossexp in ns-2), and X db is a Gaussian random variable with zero mean and standard deviation σ db controlled by Propagation/Shadowing set std db in ns-2 [1, p.189]. To ensure a relatively linear signal quality degradation when increasing the distance to the access point, the values β = 2.0, σ db = 4.0 and d 0 = 1 were found to be most apt. The controller script now only has to vary the distance parameters in y and x directions to change the received signal quality. The final script is almost equal to the one described in Case I, only with iterative changes in the distance instead of iterative changes in flow numbers (see Appendix B) Case III: MAC layer efficiency MAC gives significant added delay 5 In fact, the following message was found in the ns-2 manual: We have not used the second method and leave it to the user to explore the details.

52 44 CHAPTER 3. SIMULATION BACKGROUND AND LAYOUT Since the wireless access network is a shared medium, the MAC layer has buffer capabilities to hold the traffic until an available slot in the medium is available. The buffer size and queuing time depends on the algorithms used in the allocation of transfer times. Thus, the algorithm has a direct impact on the delay and jitter of traffic. As explained in section 2.6.3, the legacy MAC uses several types of interframe spaces, a backoff procedure and the RT- S/CTS mechanism to avoid in-air collisions of traffic from different STAs. This simulation case will illustrate the total delay introduced by these collision avoidance techniques. The results can be used to show the need for e as described in section Four different comparisons are made in this simulation case: 1. Comparing the delay variations to the throughput of one flow. 2. Comparing the average delay for different network congestion levels. 3. Comparing the average delay for different RTT values. 4. Comparing the delay with and without RTS/CTS. To generate data for these comparisons, the VBR UDP traffic source from the Evalvid-RA is used. This traffic type is chosen because a) the video source generates variable bitrate which in turn is expected to give variable delay, b) the source is not adjusting to congestion, buffer overflow and jitter in the network and c) because it is band-limited 6. Note that UDP traffic only generates one way traffic, thus giving the AP full control of all the medium access. To check how bandwidth variations and different input pressure affects the delay, the measurements are made with between one to six concurrent UDP flows to the wireless network. With more than four to five flows simultaneously, the network is assumed to be completely congested since the videos generate about 1.20 Mbps in average and the actual throughput of the link is found to be about 5Mbps 7. The controlling script for this case, as seen in Appendix B, consists of a for-loop to execute three commands iteratively i times (i = {1,..., 6). The commands are the ns execution with -nofudp $i -doping 1 -disablerts CTS 1 (the last parameter is 1 or 0), an Awkscript to gather all timing information for packets on the monitored flow (added-delay.awk, found in Appendix C) and one Awk-script to calculate the average delay for all packets in one flow (avg-delay.awk, found in Appendix C). Since a resulting decimal number in milliseconds is only considered interesting information if the reader is experienced in the field and knows which values are common, the results are presented as the share of the total end-to-end delay. With this presentation, the reader can more easily understand the impact of a wireless link. However, since these results can be misleading if the rest of the network is either very fast or very slow, the tests are run with several scenarios (that is, with propagation delays from 6 ms to 200 ms from sender to access point). The actual decimal values are also discussed in the contexts where it is useful. 6 FTP-traffic as an alternative will utilize the full possible TCP throughput both for one and several concurrent flows. 7 A statement that is confirmed by the results of all cases.

53 CHAPTER 4 Results and analysis In this section, the most relevant and interesting results from the simulations will be presented. The results will be discussed, analyzed and explained next to illustrating graphs and tables. First, a TFRC feature or implementational bug will be presented as a vulnerability to the system, then the different simulation scenarios will be discussed, before the most important findings will be repeated in a summary at the end. 4.1 Vulnerability Figure 4.1 This graph shows the video throughput rate when the first TFRC acknowledgment is lost. As discovered in [13], the TFRC protocol is vulnerable if the first packet is not acknowledged by the receiver. Figure 4.1 illustrates that the problem exists with the new topology and architecture as well. The example shows the flow from a TFRC source that is started at time 45

54 46 CHAPTER 4. RESULTS AND ANALYSIS t = 10s. As can be seen on the figure and verified by the trace file, the first packet seems to arrive correctly (note the little bump in the circle). But since the acknowledgment is lost, the TFRC source refuses to continue the transfer. TFRC believes that the disappearance of the first packet is an indicator of a congested network, which triggers it to wait and retry. After about three seconds the sender gets an acknowledgment and starts the remaining transfer. The TFRC RFC [9] explains this behavior in chapter 4.2; TFRC has a transmit rate X that is initialized to 1 packet/second and a feedback timer that expires after 2 seconds. This suits well with the delay of about 3 seconds seen in figure 4.1. Another observation from figure 4.1, is that when the traffic starts, it accelerates to a bitrate that is higher than what the compressed video can produce at best quality quantization. The video used in all simulations has a bitrate peak in the first seconds, but not as dramatic as seen in the shaded area of figure 4.1. The average bitrate at minimum compression (q=2) is r = size(q) 4.2MB + overhead(pdu) = = 1.20 Mbps (4.1) duration 30s where overhead(pdu) is the network and transport layer overhead in data unit framing and packet headers. Since the bitrate on the figure peaks at well above 2.1 Mbps, an explanation needs to be found. As mentioned earlier, the feedback mechanism makes the video compression rate adjust dynamically to the reported congestion and loss statistics of the network. The TFRC daemon receives the feedback packets and adjusts its packet rate thereafter. Now, how is the application level being notified of the rate change and how may it react? TFRC has an interface to the network layer, which lies beneath it in the protocol stack, and an interface to the application level above. The Evalvid-RA implementation uses the latter interface to read out the current transmission rate in use by TFRC. With this information, it calculates a new suitable video bitrate and a new quantizer parameter. The video frames with the new compression rate are fetched and queued in the input buffer of the TFRC application level interface. In the case shown in figure 4.1, the video transmission is started on the application level, but because TFRC does not receive the first acknowledgment from the client, it refuses to forward the flow it receives from the application level. Instead, this flow is buffered in the TFRC input queue until the network path is cleared for transmission. When TFRC finally gets its retransmitted header packet acknowledged, the queue will contain several seconds with video ready for transmission. Until TFRC stabilizes or receives new congestion feedback, the queue will burst out on the network. The Evalvid-RA application starts by default at a quantization rate of Q=8 in this implementation. This is applied to the first GOP in the transmitted video. Normally, TFRC should receive one feedback for the very first packet, and thereafter with one or two RTT intervals. So by the time the first GOP, which can consist of several tens of packets depending on the video resolution and contents, is sent, one or several feedback messages is assumed to have arrived. If Evalvid-RA is not informed of a congestion by this time, it lowers the quantizer and is soon transmitting with full quality. The problem, or implementational bug, seems to be that the TFRC agent does not report that the first feedback message is missing to the application. A solution suggestion is that the video application compresses its output maximally until

55 4.2. SCENARIOS 47 proper feedback is received, thus minimizing the chances of packet loss when the buffered top quality data bursts out on the (possibly congested) network. The data backlog in the TFRC queue is illustrated with the shaded area in figure 4.1, and the interface between TFRC and the application is conceptually illustrated in 4.2. Figure 4.2 This figure shows how the incoming acknowledgment triggers the TFRC rate calculation mechanism which can report the new rate to the application layer. Here, the rate parameter is converted to a suitable quantizer value for the video compression. Compressed video is sent to TFRC input buffer before transmitted through the network. 4.2 Scenarios The simulations are mainly presented with graphs showing PSNR values or throughput values. An example of a throughput graph is given in figure 4.3. This graph shows the basic shape of the video with minimum compression, Q=2. It is beneficial to know the basic shapes of the videos in order to easily interpret the results when the video-flow is damaged or band limited later on 1. Three main observations should be made in this case. First, the video used is 30s long and comprised by 3 equal sequences of 10s (300 frames at 30fps). This can be seen by the three peaks of each transfer type in figure 4.3. Second, the TFRC throughput is slightly higher than the UDP throughput. This can be explained with the bigger header size of TFRC packets. Third, the TFRC flow is less aggressive in the first seconds. This is due to the slow start mechanisms employed in the congestion controller Case I: Congested wireless link In this case, the benefits of rate adaption and dynamic quality scaling is tested. To prove the hypothesis ( TFRC gives better results than UDP with high traffic load and interference ), expected results would be to see that the overall PSNR value for a video sequence would be higher with TFRC transport than with plain UDP transport. 1 The same video is used in all the simulations presented here.

56 48 CHAPTER 4. RESULTS AND ANALYSIS Figure 4.3 This graph compares maximal uninterrupted throughput for one separate UDP and one separate TFRC simulation run. In figure 4.4, the results from both UDP and TFRC objective quality is shown for (a) only TFRC traffic running concurrently and (b) mixed traffic sources running concurrently (UDP, FTP, WEB and TFRC), and in figure 4.7(a) the results with only UDP competition. None of these graphs confirm that TFRC is superior in any way. In fact, the most realistic case which is the mixed traffic shown in 4.4(b), indicate that the UDP traffic provides the overall best results in objective quality. (a) With TFRC traffic (b) With mixed traffic Figure 4.4 These graphs show UDP (green line) and TFRC (red line) video compared with concurrent traffic of two different types. To take a closer look at what happens here, let us step into the details of the simulation iterations with 3 concurrent TFRC sources 2. Figure 4.5 shows the throughput for all the simultaneous flows, where the first TFRC flow is monitored in a) and the UDP flow is monitored in b). What we observe is as expected: The UDP-flow has a significantly higher throughput to the end user in b) under the same circumstances as the TFRC flow in a). Now, while this graph shows the throughput, it does not show the amount of lost packets, a metric that is important due to the the interpacket dependency of MPEG video explained in section 2.1. An analysis of the receiver trace file produced by Evalvid-RA can give information on how many frames that 2 The number 3 is randomly chosen for this example.

57 4.2. SCENARIOS 49 where accepted at the receiver node. The results here are also as expected for the UDP traffic; 332 out of 4958 packets where lost in this flow, which gives a percentage packet loss of 7%. With such a high loss rate, many header and reference frames (I-frames) may have been lost, causing severe damage to the video even if the the frames that arrive correctly have minimum compression. (a) Monitored TFRC (red line) (b) Monitored UDP (bright blue line) Figure 4.5 These graphs show the throughput of the different concurrent flows when TFRC-flows are the competitors In the TFRC flow, one would expect to have close to zero packet loss since TFRC should adjust the transmission rate until all packets get through. This is not the case here; The receiver trace file says that 51 out of 3108 packets, or 2%, where lost with compression rates of Q=3 and Q=4. So, TFRC still observes packet loss and the effect expected to be seen in Case II, that the adaptive stream is degraded due to both packet loss and quantization, is already present here in Case I. The fact that TFRC can not adjust perfectly to the loss type and rate is crucial, as will be discussed further in Case II (section 4.2.2).

58 50 CHAPTER 4. RESULTS AND ANALYSIS Figure 4.6 This is the same frame from three different versions of a video: The original (left), the non-adaptive (center) and the adaptive (right). Subjective quality So far we have seen that TFRC adjusts the transmission rate and forces Evalvid-RA to adjust the quantization level up. The adjustment does not seem to be enough, since the PSNR graph indicates that the all-over quality of the non-adaptive video is almost the same or better then the quality of the adaptive video from Evalvid-RA. As mentioned earlier, there are many ways to measure the quality of a video, but none of them are cheap, scalable and always correct. PSNR is one of the cheapest and easiest ways of measuring the quality of a video, but it has some flaws. For instance, while the PSNR measurement can see defects such as missing blocks or pixel errors, it fails to see if a series of frames compose a smooth video sequence or if it is jagged and uneven. Another is that it is not intelligent enough to synchronize the video in case of a bigger delay. The effect of delayed or early frames is not necessarily too bad for the end user, while the PSNR calculation compares each incoming frame with a reference frame from a time-shifted part of the original video, resulting in low SNR-values. One of the superior qualities with the Evalvid-RA tool-set, is the possibility to inspect the resulting video for each simulation run. Together with the raw-file viewer VidView (referred to in section 2.4.6), one can expose if the PSNR value is correct or not for the sequence. Figure 4.6 illustrates how videos with the same PSNR value can have different appearance. Again, the example is from UDP non-adaptive versus three TFRC adaptive sources (4.6, center) and four TFRC adaptive sources (4.6, right). What can be observed is that the non-adaptive flow has had recent packet losses, disturbing the picture noteably but not crucially, while the adaptive flow shows a delayed frame (compared to the original (4.6, left)). Inter and intra-protocol friendliness The discussion in Chapter 5 will address properties of a TCP-friendly flow, and the different definitions of the term. Here, the term friendliness will be extended to represent if a flow is or is not damaging to the throughput and stability of other concurrent flows of the same or other type. The graphs in figure 4.7 illustrate the problems connected to UDP traffic, in fact the main reason for the wish to change UDP with DCCP: UDP traffic does not scale at all to the existing conditions in a router or a link. In figure 4.7(a) concurrent UDP traffic not only destroys the throughput and quality of the more discreet TFRC, but also destroys for flows of its same kind.

59 4.2. SCENARIOS 51 Allready with 3 concurrent flows, the monitored UDP flow is unusable ( PSNR < 20dB, see section 2.2 for more), while the TFRC flow scales the rate to provide a barely watchable result. The throughput of this flow is seen in figure 4.7(b). It is interesting to watch how the PSNR-to-throughput-ratio differ between the two flows in this example. While the PSNR values are nearly equal for all but one measurement, the throughput differ significantly. The UDP flows compete to get the full rate through, thereby destroying each other s flows with interference, while TFRC is forced to scale down to the lowest quantization values. The best example from the performed simulation is shown in figure 4.7, where the TFRC flow provides better PSNR than the UDP flow, while having a considerably lower bandwidth consumption with an average throughput of about 380 Kbps. (a) PSNR (b) Throughput (TFRC=purple line) Figure 4.7 This graph displays the quality of a video from a UDP or TFRC source measured in PSNR (a) and throughput (b) when the concurrent traffic on the link is only UDP. The classical friendliness test does not include UDP because there is no doubt about its lack of friendliness. A new transport protocol suggestion is rather compared against TCP traffic, since this constitutes the main share of today s Internet traffic. In these simulations, rate adaptive video over TFRC was tested against FTP over TCP. These simulations reveal that TFRC is apparently TCP-friendly, but not very TCP-robust. What can be seen in figure 4.8 is that the TFRC flow adjusts its rate to fit the bandwidth requirements of the concurrent TCP flows (4.8(b)). In 4.8(a), we can see how TFRC suffers from its friendliness (red line) whereas UDP gets a far better performance, strangling the other flows on the link (blue line). Since TFRC and TCP have almost equivalent rate control mechanisms, one would expect to see that a monitored TFRC flow has the same performance in an environment with TCP or TFRC traffic. Figure 4.8(a) shows something else: The TFRC flow in the TFRC environment (green line) shows an all-over better performance than the TFRC flow in the TCP environment (red line). Figure 4.8(b) is taken from the inflection point where four TCP flows result in an unwatchable video with PSNR below 20dB. Compared to figure 4.5(a), where TFRC shows superb intra-friendliness as the four flows adjust to almost equal rate in a few seconds, figure 4.8(b) shows a highly fluctuating behavior from all the TCP flows that results in poor bandwidth utilization and interference-caused packet loss. This is the observation referred to as not TCP-robust above.

60 52 CHAPTER 4. RESULTS AND ANALYSIS (a) PSNR (b) Throughput Figure 4.8 This graph illustrates the TCP-fairness of TFRC in PSNR (a) and throughput (b) Case II: Node movement and variable link quality In Case I, the video flows where tested against flows from different transport protocols to see how the videos where influenced by the different interference pattern the concurrent traffic formed. In Case II on the other hand, interfering traffic is not interesting and adaptive and non-adaptive traffic will be compared by results from separate simulation runs. The only variable to be changed here is the distance between the client and the access point, thereby creating controlled variance in signal strength. As stated earlier, the expected result here is that the adaptive video source will experience an amplified loss due to both high compression quantization and random packet loss in the wireless link. Figure 4.9 shows the throughput from the two transfer types in question; UDP and TFRC. Each line describes the throughput for one separate simulation of one flow over the specified distance. For all distances from 0 to 8 meters, the throughput is more or less equal for all flows with the propagation model set up in section 3.7.2, but when the receiver node is moved further away, the link fading gets an effect on the received throughput. The figure shows us what one would expect; The UDP throughput is higher than the TFRC

61 4.2. SCENARIOS 53 (a) TFRC (b) UDP Figure 4.9 Throughput graphs for TFRC (a) and UDP (b) for distances 9 to 15 meters from the access point. throughput for all distances where the signal strength is close to the reception threshold of the receiving wireless interface. In these cases, the UDP flow would push through on a best effort basis, thus exploiting the available resources maximally, while the TFRC flow adjusts the transmitted rate down in an attempt to avoid what it assumes to be congestion. On distance 14 and 15 meters we see that TFRC has adjusted all the way down to the initial base rate of one packet per second with two seconds feedback timer (figure 4.9(a), note the small bumps circa every third second), while the UDP flow works at a 200 to 400 Kbps bitrate. Intuitively, this would imply that UDP performs better at these distances. However, as can be seen in the PSNR graph in 4.10(a), the video client can not decode any of the received material because the loss ratio is too big and the required throughput of a flow that transfers data with minimal compression is high. Figure 4.10 shows two versions of the same effect. Figure 4.10(a) shows the over all PSNR values for each distance from 5 to 15 meters for both adaptive and non adaptive video. The observations agree with the throughput results since the PSNR values are almost equal up to about 9 meters, and a PSNR of zero is indicated from 13 meters and beyond. Now, since the only deviation is in the area between 9 and 13 meters, a variant of the simulation described in

62 54 CHAPTER 4. RESULTS AND ANALYSIS section was made to get a higher resolution of the results here. The output from those simulations is shown in figure 4.10(b). This graph confirms our suspicions; When packet loss is frequent, random and not due to congestion, TFRC provides poor performance compared to UDP as a video bearer. (a) 5 to 15 meters (b) 9.5 to 12.5 meters Figure 4.10 In (a), the PSNR results from a video streamed to a client with different distances to the AP is shown. Figure (b) is a re-sampling of the most interesting area of the curves in (a). The assumptions made to form the hypothesis for this case ( UDP gives better results than TFRC with low link quality and noise ) was, as stated repeatedly, TFRC s amplified loss. But while the PSNR-graphs in figure 4.10 alone confirms the result of this effect, the throughput graphs in 4.9(a) gives reason to do a further analysis of the cause of the effect. What can be observed in the latter figure is namely that the delayed-start effect discussed in 4.1 seems to occur for all simulations with distance above 9 meters. Therefore, it is possible that this alone is the cause of the inferior PSNR values in the 9 to 13 meter region. To find the answer, the tracefiles for the different simulations must be studied. Distance (m) Q Lost (pkts.) Total (pkts.) Loss rate (%) PSNR Table 4.1 This table summarizes the loss statistics of the simulated TFRC flows. Several things should be noted about table 4.1 and First the numbers shown, are not from measurements with equal distance difference in meters. Actually, allthough the simulations where done with a resolution of 3 dm between 9.5 and 3 Note that the results are partly based on random processes, which produces slightly different numeric results with other seeds.

63 4.2. SCENARIOS 55 Distance (m) Q Lost (pkts.) Total (pkts.) Loss rate (%) PSNR Table 4.2 This table summarizes the loss statistics of the simulated UDP flows meters, the results where identical for all samples left out of the tables. This can also be seen by the flat segments in figure 4.10(b). The reason for this remains unknown, but presumably, it has to do with the construction of the ns-2 implementation of the propagation model. Second, the total number of packets depends on the quantization level and the MTU used. Both TFRC and UDP have MTU=1000 bytes. The UDP transfer has Q=2 for all GOPs, which gives a total of 4959 packets to be transmitted for all simulation runs, header packets included. Third, while the UDP transfers show strongly increasing and logical loss rates, the TFRC flows do not. While the number of lost packets rise from 2 to 16 between 10.1 and 11.0 meters, it falls to 11 on 12.2 meters. Still, the PSNR value for 12.2 meters is far lower than for What we see is that the average quantization level, Q, rises notably and the number of total packets sinks correspondingly. Fourth, the numbers given for distances in table 4.1 do not tell the entire truth. The quantization parameter should have been close to 31 (maximum) for these simulations, but since the client feedback never arrives the sender, the TFRC agent keeps transmitting with initial settings ( 1 packet/second), but does not tell the Video application that the network feedback is missing. Therefore, Evalvid-RA will continue to produce video at Q=2 until a proper feedback has been reported. This happens at t=37s for 14 and t=25 for 15 meters wireless distance. This start-up delay causes most of the video sequence to arrive the client after the simulation is finished, which is at t=55s. Now, with all of the above in mind, three questions arise: 1) How does the variable delay on the adaptive video affect the end result? In this case, the UDP traffic is never delayed since there is no congestion in any parts of the network. The TFRC traffic is delayed if the first feedback is lost. This results in a delay of several seconds of the video, which makes the PSNR-calculator compare each incoming frame with an offset to the original. For example, with 3 seconds initial delay, 10% of the sequence will be delayed at the receiver. Now, in a real-time system, such delays are not acceptable. Neither are they in this simulation environment. When the video is received and reconstructed, the system uses a parameter called Play out Buffer (PoB) to limit how big the delay can be. Figure 4.11 shows the PSNR values for each reconstructed raw frame. The PoB (set to 250 ms

64 56 CHAPTER 4. RESULTS AND ANALYSIS Figure 4.11 The PSNR graph for all frames in the video sequence transmitted with 11m wireless distance. in all simulations) limits which frames that are included in the final video and which are not. As earlier, VidView allows us to check these results by manual inspection of the reconstructed video. In figure 4.12, the original frame is compared to the reconstructed frame after transmission. First, frame 350, which is in the Arrives too late area of 4.11 is compared to the original frame 350. Ten frames later the first actually accepted and reconstructed frame arrives with good quality. This frame is sent from the server application at t=12s and received by the client application at t=15s, which means that it is the first of the buffered frames to be accepted. 2) How important are the header frames in the loss statistics? When Evalvid-RA downgrades the video quality, the video stream from the application down to the TFRC-agent is reduced. Therefore, the TFRC agent does not have to segment each video frame into as many packets as is the case for a higher quality stream. One effect of this packetrate reduction, is that the rate, or density, of absolutely necessary packets increases. As explained in section 2.1, the I-frames have a much bigger importance than the other frames, and the packet containing the first segment of an I-frame must be received in order to decode the rest. Furthermore, the first header-frame, which is sent before the first I-frame, is also necessary for proper decoding. To prioritize the importance of the packets: 1. The first packet contains the first header-frame, which the decoder must have in order to decode the subsequent stream. 2. The first packet of each I-frame, which contains the quantizer scale parameter for the entire frame and is necessary to decode the frame. 3. The first packet of each P-frame, which contains the quantizer scale parameter for the entire frame and is necessary to decode the frame. 4. The first packet of each B-frame, which contains the quantizer scale parameter for the entire frame and is necessary to decode the frame.

65 4.2. SCENARIOS 57 (a) Frame 350 (b) Frame 360 Figure 4.12 A comparison of the reconstructed frames 350 (arrives too late) and 360 (arrives in time) to the original frames. Now, an increased density of crucial packets will increase the probability of a crucial packet drop. For example, from table 4.1 and 4.2, it can be seen that TFRC and UDP have sent 2946 and 4959 packets respectively. If we define the two first types above as crucial, both streams will have H-packet + [header I-packets] = = 76 crucial packets. The TFRC stream will have = 2.5% density while the UDP stream will have 4959 = 1.5%, a reduction of 40%. How can this effect be seen directly on the result presented here? Well, they can not. The reason is mentioned in section 2.4.4: The Evalvid-RA program that simulates the packet-tovideo-stream reassembly, defines one entire frame as dropped if one or more belonging packets are lost. Since the TFRC stream under lossy conditions produces fewer packets per frame, it is reason to believe that the density effect is reversed, making the UDP stream most vulnerable. The total effect and analysis of packet drop versus frame drop is left for future work. 3) Finally, is the quality degradation of the adaptive flow due to delay or amplified loss? The above analysis of trace files and PSNR data started due to the suspicion that the degraded quality of the adaptive flow was caused by the somewhat buggy start-up delay, or if it is caused by packet loss in the weak wireless link. The data presented above does not provide a clear answer. The TFRC flow is delayed, something that definitely has an effect on the overall result,

A Tool for Multimedia Quality Assessment in NS3: QoE Monitor

A Tool for Multimedia Quality Assessment in NS3: QoE Monitor A Tool for Multimedia Quality Assessment in NS3: QoE Monitor D. Saladino, A. Paganelli, M. Casoni Department of Engineering Enzo Ferrari, University of Modena and Reggio Emilia via Vignolese 95, 41125

More information

QOS Requirements and Service Level Agreements. LECTURE 4 Lecturer: Associate Professor A.S. Eremenko

QOS Requirements and Service Level Agreements. LECTURE 4 Lecturer: Associate Professor A.S. Eremenko QOS Requirements and Service Level Agreements LECTURE 4 Lecturer: Associate Professor A.S. Eremenko Application SLA Requirements Different applications have different SLA requirements; the impact that

More information

An Introduction to VoIP Protocols

An Introduction to VoIP Protocols An Introduction to VoIP Protocols www.netqos.com Voice over IP (VoIP) offers the vision of a converged network carrying multiple types of traffic (voice, video, and data, to name a few). To carry out this

More information

Behavior Analysis of TCP Traffic in Mobile Ad Hoc Network using Reactive Routing Protocols

Behavior Analysis of TCP Traffic in Mobile Ad Hoc Network using Reactive Routing Protocols Behavior Analysis of TCP Traffic in Mobile Ad Hoc Network using Reactive Routing Protocols Purvi N. Ramanuj Department of Computer Engineering L.D. College of Engineering Ahmedabad Hiteishi M. Diwanji

More information

Bandwidth Adaptation for MPEG-4 Video Streaming over the Internet

Bandwidth Adaptation for MPEG-4 Video Streaming over the Internet DICTA2002: Digital Image Computing Techniques and Applications, 21--22 January 2002, Melbourne, Australia Bandwidth Adaptation for MPEG-4 Video Streaming over the Internet K. Ramkishor James. P. Mammen

More information

Performance Evaluation of AODV, OLSR Routing Protocol in VOIP Over Ad Hoc

Performance Evaluation of AODV, OLSR Routing Protocol in VOIP Over Ad Hoc (International Journal of Computer Science & Management Studies) Vol. 17, Issue 01 Performance Evaluation of AODV, OLSR Routing Protocol in VOIP Over Ad Hoc Dr. Khalid Hamid Bilal Khartoum, Sudan dr.khalidbilal@hotmail.com

More information

Performance Evaluation of VoIP Services using Different CODECs over a UMTS Network

Performance Evaluation of VoIP Services using Different CODECs over a UMTS Network Performance Evaluation of VoIP Services using Different CODECs over a UMTS Network Jianguo Cao School of Electrical and Computer Engineering RMIT University Melbourne, VIC 3000 Australia Email: j.cao@student.rmit.edu.au

More information

Digital Audio and Video Data

Digital Audio and Video Data Multimedia Networking Reading: Sections 3.1.2, 3.3, 4.5, and 6.5 CS-375: Computer Networks Dr. Thomas C. Bressoud 1 Digital Audio and Video Data 2 Challenges for Media Streaming Large volume of data Each

More information

Classes of multimedia Applications

Classes of multimedia Applications Classes of multimedia Applications Streaming Stored Audio and Video Streaming Live Audio and Video Real-Time Interactive Audio and Video Others Class: Streaming Stored Audio and Video The multimedia content

More information

Transport Layer Protocols

Transport Layer Protocols Transport Layer Protocols Version. Transport layer performs two main tasks for the application layer by using the network layer. It provides end to end communication between two applications, and implements

More information

ADVANTAGES OF AV OVER IP. EMCORE Corporation

ADVANTAGES OF AV OVER IP. EMCORE Corporation ADVANTAGES OF AV OVER IP More organizations than ever before are looking for cost-effective ways to distribute large digital communications files. One of the best ways to achieve this is with an AV over

More information

10CS64: COMPUTER NETWORKS - II

10CS64: COMPUTER NETWORKS - II QUESTION BANK 10CS64: COMPUTER NETWORKS - II Part A Unit 1 & 2: Packet-Switching Networks 1 and Packet-Switching Networks 2 1. Mention different types of network services? Explain the same. 2. Difference

More information

Chapter 3 ATM and Multimedia Traffic

Chapter 3 ATM and Multimedia Traffic In the middle of the 1980, the telecommunications world started the design of a network technology that could act as a great unifier to support all digital services, including low-speed telephony and very

More information

MPEG-4 Video Transfer with SCTP-Friendly Rate Control Mohamed N. El Derini

MPEG-4 Video Transfer with SCTP-Friendly Rate Control Mohamed N. El Derini MPEG-4 Video Transfer with SCTP-Friendly Rate Control Mohamed N. El Derini elderini@ieee.org Amr A.Elshikh elshikha@emro.who.int Faculty of Engineering, Alexandria University, Egypt Computer Science and

More information

Video compression: Performance of available codec software

Video compression: Performance of available codec software Video compression: Performance of available codec software Introduction. Digital Video A digital video is a collection of images presented sequentially to produce the effect of continuous motion. It takes

More information

Broadband Networks. Prof. Dr. Abhay Karandikar. Electrical Engineering Department. Indian Institute of Technology, Bombay. Lecture - 29.

Broadband Networks. Prof. Dr. Abhay Karandikar. Electrical Engineering Department. Indian Institute of Technology, Bombay. Lecture - 29. Broadband Networks Prof. Dr. Abhay Karandikar Electrical Engineering Department Indian Institute of Technology, Bombay Lecture - 29 Voice over IP So, today we will discuss about voice over IP and internet

More information

The OSI model has seven layers. The principles that were applied to arrive at the seven layers can be briefly summarized as follows:

The OSI model has seven layers. The principles that were applied to arrive at the seven layers can be briefly summarized as follows: 1.4 Reference Models Now that we have discussed layered networks in the abstract, it is time to look at some examples. In the next two sections we will discuss two important network architectures, the

More information

Measure wireless network performance using testing tool iperf

Measure wireless network performance using testing tool iperf Measure wireless network performance using testing tool iperf By Lisa Phifer, SearchNetworking.com Many companies are upgrading their wireless networks to 802.11n for better throughput, reach, and reliability,

More information

PART III. OPS-based wide area networks

PART III. OPS-based wide area networks PART III OPS-based wide area networks Chapter 7 Introduction to the OPS-based wide area network 7.1 State-of-the-art In this thesis, we consider the general switch architecture with full connectivity

More information

Final for ECE374 05/06/13 Solution!!

Final for ECE374 05/06/13 Solution!! 1 Final for ECE374 05/06/13 Solution!! Instructions: Put your name and student number on each sheet of paper! The exam is closed book. You have 90 minutes to complete the exam. Be a smart exam taker -

More information

Power management of video transmission on wireless networks for multiple receivers

Power management of video transmission on wireless networks for multiple receivers Power management of video transmission on wireless networks for multiple receivers Christos Bouras, Kostas Stamos and Giannis Zaoudis Research Academic Computer Technology Institute and Computer Engineering

More information

Figure 1: Relation between codec, data containers and compression algorithms.

Figure 1: Relation between codec, data containers and compression algorithms. Video Compression Djordje Mitrovic University of Edinburgh This document deals with the issues of video compression. The algorithm, which is used by the MPEG standards, will be elucidated upon in order

More information

Note! The problem set consists of two parts: Part I: The problem specifications pages Part II: The answer pages

Note! The problem set consists of two parts: Part I: The problem specifications pages Part II: The answer pages Part I: The problem specifications NTNU The Norwegian University of Science and Technology Department of Telematics Note! The problem set consists of two parts: Part I: The problem specifications pages

More information

Module 8 VIDEO CODING STANDARDS. Version 2 ECE IIT, Kharagpur

Module 8 VIDEO CODING STANDARDS. Version 2 ECE IIT, Kharagpur Module 8 VIDEO CODING STANDARDS Version ECE IIT, Kharagpur Lesson H. andh.3 Standards Version ECE IIT, Kharagpur Lesson Objectives At the end of this lesson the students should be able to :. State the

More information

CSE 237A Final Project Final Report

CSE 237A Final Project Final Report CSE 237A Final Project Final Report Multi-way video conferencing system over 802.11 wireless network Motivation Yanhua Mao and Shan Yan The latest technology trends in personal mobile computing are towards

More information

Performance Analysis and Comparison of JM 15.1 and Intel IPP H.264 Encoder and Decoder

Performance Analysis and Comparison of JM 15.1 and Intel IPP H.264 Encoder and Decoder Performance Analysis and Comparison of 15.1 and H.264 Encoder and Decoder K.V.Suchethan Swaroop and K.R.Rao, IEEE Fellow Department of Electrical Engineering, University of Texas at Arlington Arlington,

More information

Using Fuzzy Logic Control to Provide Intelligent Traffic Management Service for High-Speed Networks ABSTRACT:

Using Fuzzy Logic Control to Provide Intelligent Traffic Management Service for High-Speed Networks ABSTRACT: Using Fuzzy Logic Control to Provide Intelligent Traffic Management Service for High-Speed Networks ABSTRACT: In view of the fast-growing Internet traffic, this paper propose a distributed traffic management

More information

White paper. Latency in live network video surveillance

White paper. Latency in live network video surveillance White paper Latency in live network video surveillance Table of contents 1. Introduction 3 2. What is latency? 3 3. How do we measure latency? 3 4. What affects latency? 4 4.1 Latency in the camera 4 4.1.1

More information

A Comparison Study of Qos Using Different Routing Algorithms In Mobile Ad Hoc Networks

A Comparison Study of Qos Using Different Routing Algorithms In Mobile Ad Hoc Networks A Comparison Study of Qos Using Different Routing Algorithms In Mobile Ad Hoc Networks T.Chandrasekhar 1, J.S.Chakravarthi 2, K.Sravya 3 Professor, Dept. of Electronics and Communication Engg., GIET Engg.

More information

Analysis of QoS parameters of VOIP calls over Wireless Local Area Networks

Analysis of QoS parameters of VOIP calls over Wireless Local Area Networks Analysis of QoS parameters of VOIP calls over Wireless Local Area Networks Ayman Wazwaz, Computer Engineering Department, Palestine Polytechnic University, Hebron, Palestine, aymanw@ppu.edu Duaa sweity

More information

Ethernet. Ethernet. Network Devices

Ethernet. Ethernet. Network Devices Ethernet Babak Kia Adjunct Professor Boston University College of Engineering ENG SC757 - Advanced Microprocessor Design Ethernet Ethernet is a term used to refer to a diverse set of frame based networking

More information

ANALYSIS OF LONG DISTANCE 3-WAY CONFERENCE CALLING WITH VOIP

ANALYSIS OF LONG DISTANCE 3-WAY CONFERENCE CALLING WITH VOIP ENSC 427: Communication Networks ANALYSIS OF LONG DISTANCE 3-WAY CONFERENCE CALLING WITH VOIP Spring 2010 Final Project Group #6: Gurpal Singh Sandhu Sasan Naderi Claret Ramos (gss7@sfu.ca) (sna14@sfu.ca)

More information

How To Monitor Performance On Eve

How To Monitor Performance On Eve Performance Monitoring on Networked Virtual Environments C. Bouras 1, 2, E. Giannaka 1, 2 Abstract As networked virtual environments gain increasing interest and acceptance in the field of Internet applications,

More information

Question: 3 When using Application Intelligence, Server Time may be defined as.

Question: 3 When using Application Intelligence, Server Time may be defined as. 1 Network General - 1T6-521 Application Performance Analysis and Troubleshooting Question: 1 One component in an application turn is. A. Server response time B. Network process time C. Application response

More information

Mesh Network Testbed and Video Stream Measurement

Mesh Network Testbed and Video Stream Measurement Mesh Network Testbed and Video Stream Measurement Nan Li Email: nli@cs.uml.edu Abstract In this project, we set up a mesh network testbed with nine desktops and three laptops. We install on desktop two

More information

How To Test Video Quality With Real Time Monitor

How To Test Video Quality With Real Time Monitor White Paper Real Time Monitoring Explained Video Clarity, Inc. 1566 La Pradera Dr Campbell, CA 95008 www.videoclarity.com 408-379-6952 Version 1.0 A Video Clarity White Paper page 1 of 7 Real Time Monitor

More information

RARP: Reverse Address Resolution Protocol

RARP: Reverse Address Resolution Protocol SFWR 4C03: Computer Networks and Computer Security January 19-22 2004 Lecturer: Kartik Krishnan Lectures 7-9 RARP: Reverse Address Resolution Protocol When a system with a local disk is bootstrapped it

More information

Guide to TCP/IP, Third Edition. Chapter 3: Data Link and Network Layer TCP/IP Protocols

Guide to TCP/IP, Third Edition. Chapter 3: Data Link and Network Layer TCP/IP Protocols Guide to TCP/IP, Third Edition Chapter 3: Data Link and Network Layer TCP/IP Protocols Objectives Understand the role that data link protocols, such as SLIP and PPP, play for TCP/IP Distinguish among various

More information

Quality Estimation for Scalable Video Codec. Presented by Ann Ukhanova (DTU Fotonik, Denmark) Kashaf Mazhar (KTH, Sweden)

Quality Estimation for Scalable Video Codec. Presented by Ann Ukhanova (DTU Fotonik, Denmark) Kashaf Mazhar (KTH, Sweden) Quality Estimation for Scalable Video Codec Presented by Ann Ukhanova (DTU Fotonik, Denmark) Kashaf Mazhar (KTH, Sweden) Purpose of scalable video coding Multiple video streams are needed for heterogeneous

More information

Narrow Bandwidth Streaming Video Codec

Narrow Bandwidth Streaming Video Codec Software Requirements Specification for Narrow Bandwidth Streaming Video Codec Version 1.0 approved Internal Supervisors Dr. Shantha Frenando Dr. Chathura de Silva External Supervisors Mr. Harsha Samarawicrama

More information

We are presenting a wavelet based video conferencing system. Openphone. Dirac Wavelet based video codec

We are presenting a wavelet based video conferencing system. Openphone. Dirac Wavelet based video codec Investigating Wavelet Based Video Conferencing System Team Members: o AhtshamAli Ali o Adnan Ahmed (in Newzealand for grad studies) o Adil Nazir (starting MS at LUMS now) o Waseem Khan o Farah Parvaiz

More information

Multimedia Data Transmission over Wired/Wireless Networks

Multimedia Data Transmission over Wired/Wireless Networks Multimedia Data Transmission over Wired/Wireless Networks Bharat Bhargava Gang Ding, Xiaoxin Wu, Mohamed Hefeeda, Halima Ghafoor Purdue University Website: http://www.cs.purdue.edu/homes/bb E-mail: bb@cs.purdue.edu

More information

Note! The problem set consists of two parts: Part I: The problem specifications pages Part II: The answer pages

Note! The problem set consists of two parts: Part I: The problem specifications pages Part II: The answer pages Part I: The problem specifications NTNU The Norwegian University of Science and Technology Department of Telematics Note! The problem set consists of two parts: Part I: The problem specifications pages

More information

Study and Implementation of Video Compression Standards (H.264/AVC and Dirac)

Study and Implementation of Video Compression Standards (H.264/AVC and Dirac) Project Proposal Study and Implementation of Video Compression Standards (H.264/AVC and Dirac) Sumedha Phatak-1000731131- sumedha.phatak@mavs.uta.edu Objective: A study, implementation and comparison of

More information

Chapter 3. TCP/IP Networks. 3.1 Internet Protocol version 4 (IPv4)

Chapter 3. TCP/IP Networks. 3.1 Internet Protocol version 4 (IPv4) Chapter 3 TCP/IP Networks 3.1 Internet Protocol version 4 (IPv4) Internet Protocol version 4 is the fourth iteration of the Internet Protocol (IP) and it is the first version of the protocol to be widely

More information

Bandwidth Control in Multiple Video Windows Conferencing System Lee Hooi Sien, Dr.Sureswaran

Bandwidth Control in Multiple Video Windows Conferencing System Lee Hooi Sien, Dr.Sureswaran Bandwidth Control in Multiple Video Windows Conferencing System Lee Hooi Sien, Dr.Sureswaran Network Research Group, School of Computer Sciences Universiti Sains Malaysia11800 Penang, Malaysia Abstract

More information

TECHNICAL CHALLENGES OF VoIP BYPASS

TECHNICAL CHALLENGES OF VoIP BYPASS TECHNICAL CHALLENGES OF VoIP BYPASS Presented by Monica Cultrera VP Software Development Bitek International Inc 23 rd TELELCOMMUNICATION CONFERENCE Agenda 1. Defining VoIP What is VoIP? How to establish

More information

Per-Flow Queuing Allot's Approach to Bandwidth Management

Per-Flow Queuing Allot's Approach to Bandwidth Management White Paper Per-Flow Queuing Allot's Approach to Bandwidth Management Allot Communications, July 2006. All Rights Reserved. Table of Contents Executive Overview... 3 Understanding TCP/IP... 4 What is Bandwidth

More information

White paper. H.264 video compression standard. New possibilities within video surveillance.

White paper. H.264 video compression standard. New possibilities within video surveillance. White paper H.264 video compression standard. New possibilities within video surveillance. Table of contents 1. Introduction 3 2. Development of H.264 3 3. How video compression works 4 4. H.264 profiles

More information

Networked AV Systems Pretest

Networked AV Systems Pretest Networked AV Systems Pretest Instructions Choose the best answer for each question. Score your pretest using the key on the last page. If you miss three or more out of questions 1 11, consider taking Essentials

More information

Measuring IP Performance. Geoff Huston Telstra

Measuring IP Performance. Geoff Huston Telstra Measuring IP Performance Geoff Huston Telstra What are you trying to measure? User experience Responsiveness Sustained Throughput Application performance quality Consistency Availability Network Behaviour

More information

Protocols and Architecture. Protocol Architecture.

Protocols and Architecture. Protocol Architecture. Protocols and Architecture Protocol Architecture. Layered structure of hardware and software to support exchange of data between systems/distributed applications Set of rules for transmission of data between

More information

Gaming as a Service. Prof. Victor C.M. Leung. The University of British Columbia, Canada www.ece.ubc.ca/~vleung

Gaming as a Service. Prof. Victor C.M. Leung. The University of British Columbia, Canada www.ece.ubc.ca/~vleung Gaming as a Service Prof. Victor C.M. Leung The University of British Columbia, Canada www.ece.ubc.ca/~vleung International Conference on Computing, Networking and Communications 4 February, 2014 Outline

More information

TCP over Multi-hop Wireless Networks * Overview of Transmission Control Protocol / Internet Protocol (TCP/IP) Internet Protocol (IP)

TCP over Multi-hop Wireless Networks * Overview of Transmission Control Protocol / Internet Protocol (TCP/IP) Internet Protocol (IP) TCP over Multi-hop Wireless Networks * Overview of Transmission Control Protocol / Internet Protocol (TCP/IP) *Slides adapted from a talk given by Nitin Vaidya. Wireless Computing and Network Systems Page

More information

Application Note. Low Bandwidth Media Configuration V7.0

Application Note. Low Bandwidth Media Configuration V7.0 Application Note Low Bandwidth Media Configuration V7.0 INTRODUCTION... 3 Network Overview... 3 Wireless Wide Area Networks (Cellular)... 3 Satellite... 3 Onsight Solution Architecture... 4 ONSIGHT BANDWIDTH

More information

Internet Video Streaming and Cloud-based Multimedia Applications. Outline

Internet Video Streaming and Cloud-based Multimedia Applications. Outline Internet Video Streaming and Cloud-based Multimedia Applications Yifeng He, yhe@ee.ryerson.ca Ling Guan, lguan@ee.ryerson.ca 1 Outline Internet video streaming Overview Video coding Approaches for video

More information

Understanding TCP/IP. Introduction. What is an Architectural Model? APPENDIX

Understanding TCP/IP. Introduction. What is an Architectural Model? APPENDIX APPENDIX A Introduction Understanding TCP/IP To fully understand the architecture of Cisco Centri Firewall, you need to understand the TCP/IP architecture on which the Internet is based. This appendix

More information

MOBILITY AND MOBILE NETWORK OPTIMIZATION

MOBILITY AND MOBILE NETWORK OPTIMIZATION MOBILITY AND MOBILE NETWORK OPTIMIZATION netmotionwireless.com Executive Summary Wireless networks exhibit uneven and unpredictable performance characteristics which, if not correctly managed, can turn

More information

www.mindteck.com 6LoWPAN Technical Overview

www.mindteck.com 6LoWPAN Technical Overview www.mindteck.com 6LoWPAN Technical Overview 6LoWPAN : Slide Index Introduction Acronyms Stack Architecture Stack Layers Applications IETF documents References Confidential Mindteck 2009 2 6LoWPAN - Introduction

More information

How To Write A Transport Layer Protocol For Wireless Networks

How To Write A Transport Layer Protocol For Wireless Networks Chapter 9: Transport Layer and Security Protocols for Ad Hoc Wireless Networks Introduction Issues Design Goals Classifications TCP Over Ad Hoc Wireless Networks Other Transport Layer Protocols Security

More information

Clearing the Way for VoIP

Clearing the Way for VoIP Gen2 Ventures White Paper Clearing the Way for VoIP An Alternative to Expensive WAN Upgrades Executive Overview Enterprises have traditionally maintained separate networks for their voice and data traffic.

More information

point to point and point to multi point calls over IP

point to point and point to multi point calls over IP Helsinki University of Technology Department of Electrical and Communications Engineering Jarkko Kneckt point to point and point to multi point calls over IP Helsinki 27.11.2001 Supervisor: Instructor:

More information

VOICE OVER IP AND NETWORK CONVERGENCE

VOICE OVER IP AND NETWORK CONVERGENCE POZNAN UNIVE RSITY OF TE CHNOLOGY ACADE MIC JOURNALS No 80 Electrical Engineering 2014 Assaid O. SHAROUN* VOICE OVER IP AND NETWORK CONVERGENCE As the IP network was primarily designed to carry data, it

More information

Performance Monitoring on Networked Virtual Environments

Performance Monitoring on Networked Virtual Environments ICC2129 1 Performance Monitoring on Networked Virtual Environments Christos Bouras, Eri Giannaka Abstract As networked virtual environments gain increasing interest and acceptance in the field of Internet

More information

Understanding Megapixel Camera Technology for Network Video Surveillance Systems. Glenn Adair

Understanding Megapixel Camera Technology for Network Video Surveillance Systems. Glenn Adair Understanding Megapixel Camera Technology for Network Video Surveillance Systems Glenn Adair Introduction (1) 3 MP Camera Covers an Area 9X as Large as (1) VGA Camera Megapixel = Reduce Cameras 3 Mega

More information

Computer Network. Interconnected collection of autonomous computers that are able to exchange information

Computer Network. Interconnected collection of autonomous computers that are able to exchange information Introduction Computer Network. Interconnected collection of autonomous computers that are able to exchange information No master/slave relationship between the computers in the network Data Communications.

More information

CPS221 Lecture: Layered Network Architecture

CPS221 Lecture: Layered Network Architecture CPS221 Lecture: Layered Network Architecture Objectives last revised 9/10/12 1. To discuss the OSI layered architecture model 2. To discuss the specific implementation of this model in TCP/IP Materials:

More information

12 Quality of Service (QoS)

12 Quality of Service (QoS) Burapha University ก Department of Computer Science 12 Quality of Service (QoS) Quality of Service Best Effort, Integrated Service, Differentiated Service Factors that affect the QoS Ver. 0.1 :, prajaks@buu.ac.th

More information

Analysis of IP Network for different Quality of Service

Analysis of IP Network for different Quality of Service 2009 International Symposium on Computing, Communication, and Control (ISCCC 2009) Proc.of CSIT vol.1 (2011) (2011) IACSIT Press, Singapore Analysis of IP Network for different Quality of Service Ajith

More information

Receiving the IP packets Decoding of the packets Digital-to-analog conversion which reproduces the original voice stream

Receiving the IP packets Decoding of the packets Digital-to-analog conversion which reproduces the original voice stream Article VoIP Introduction Internet telephony refers to communications services voice, fax, SMS, and/or voice-messaging applications that are transported via the internet, rather than the public switched

More information

Influence of Load Balancing on Quality of Real Time Data Transmission*

Influence of Load Balancing on Quality of Real Time Data Transmission* SERBIAN JOURNAL OF ELECTRICAL ENGINEERING Vol. 6, No. 3, December 2009, 515-524 UDK: 004.738.2 Influence of Load Balancing on Quality of Real Time Data Transmission* Nataša Maksić 1,a, Petar Knežević 2,

More information

Voice over IP. Overview. What is VoIP and how it works. Reduction of voice quality. Quality of Service for VoIP

Voice over IP. Overview. What is VoIP and how it works. Reduction of voice quality. Quality of Service for VoIP Voice over IP Andreas Mettis University of Cyprus November 23, 2004 Overview What is VoIP and how it works. Reduction of voice quality. Quality of Service for VoIP 1 VoIP VoIP (voice over IP - that is,

More information

BCS THE CHARTERED INSTITUTE FOR IT. BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 5 Diploma in IT COMPUTER NETWORKS

BCS THE CHARTERED INSTITUTE FOR IT. BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 5 Diploma in IT COMPUTER NETWORKS BCS THE CHARTERED INSTITUTE FOR IT BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 5 Diploma in IT COMPUTER NETWORKS Friday 2 nd October 2015 Morning Answer any FOUR questions out of SIX. All questions carry

More information

IP - The Internet Protocol

IP - The Internet Protocol Orientation IP - The Internet Protocol IP (Internet Protocol) is a Network Layer Protocol. IP s current version is Version 4 (IPv4). It is specified in RFC 891. TCP UDP Transport Layer ICMP IP IGMP Network

More information

VoIP QoS. Version 1.0. September 4, 2006. AdvancedVoIP.com. sales@advancedvoip.com support@advancedvoip.com. Phone: +1 213 341 1431

VoIP QoS. Version 1.0. September 4, 2006. AdvancedVoIP.com. sales@advancedvoip.com support@advancedvoip.com. Phone: +1 213 341 1431 VoIP QoS Version 1.0 September 4, 2006 AdvancedVoIP.com sales@advancedvoip.com support@advancedvoip.com Phone: +1 213 341 1431 Copyright AdvancedVoIP.com, 1999-2006. All Rights Reserved. No part of this

More information

University of Modena and Reggio Emilia. Laboratorio di Comunicazioni Multimediali EVALVID. Daniela Saladino (daniela.saladino@unimore.

University of Modena and Reggio Emilia. Laboratorio di Comunicazioni Multimediali EVALVID. Daniela Saladino (daniela.saladino@unimore. University of Modena and Reggio Emilia Laboratorio di Comunicazioni Multimediali EVALVID Daniela Saladino (daniela.saladino@unimore.it) Features and Target Complete framework and tool-set for video quality

More information

CHAPTER 6. VOICE COMMUNICATION OVER HYBRID MANETs

CHAPTER 6. VOICE COMMUNICATION OVER HYBRID MANETs CHAPTER 6 VOICE COMMUNICATION OVER HYBRID MANETs Multimedia real-time session services such as voice and videoconferencing with Quality of Service support is challenging task on Mobile Ad hoc Network (MANETs).

More information

Understanding Compression Technologies for HD and Megapixel Surveillance

Understanding Compression Technologies for HD and Megapixel Surveillance When the security industry began the transition from using VHS tapes to hard disks for video surveillance storage, the question of how to compress and store video became a top consideration for video surveillance

More information

STANDPOINT FOR QUALITY-OF-SERVICE MEASUREMENT

STANDPOINT FOR QUALITY-OF-SERVICE MEASUREMENT STANDPOINT FOR QUALITY-OF-SERVICE MEASUREMENT 1. TIMING ACCURACY The accurate multi-point measurements require accurate synchronization of clocks of the measurement devices. If for example time stamps

More information

CREW - FP7 - GA No. 258301. Cognitive Radio Experimentation World. Project Deliverable D7.5.4 Showcase of experiment ready (Demonstrator)

CREW - FP7 - GA No. 258301. Cognitive Radio Experimentation World. Project Deliverable D7.5.4 Showcase of experiment ready (Demonstrator) Cognitive Radio Experimentation World!"#$% Project Deliverable Showcase of experiment ready (Demonstrator) Contractual date of delivery: 31-03-14 Actual date of delivery: 18-04-14 Beneficiaries: Lead beneficiary:

More information

Multimedia Requirements. Multimedia and Networks. Quality of Service

Multimedia Requirements. Multimedia and Networks. Quality of Service Multimedia Requirements Chapter 2: Representation of Multimedia Data Chapter 3: Multimedia Systems Communication Aspects and Services Multimedia Applications and Transfer/Control Protocols Quality of Service

More information

Thwarting Selective Insider Jamming Attacks in Wireless Network by Delaying Real Time Packet Classification

Thwarting Selective Insider Jamming Attacks in Wireless Network by Delaying Real Time Packet Classification Thwarting Selective Insider Jamming Attacks in Wireless Network by Delaying Real Time Packet Classification LEKSHMI.M.R Department of Computer Science and Engineering, KCG College of Technology Chennai,

More information

Mobile VoIP: Managing, scheduling and refining voice packets to and from mobile phones

Mobile VoIP: Managing, scheduling and refining voice packets to and from mobile phones Mobile VoIP: Managing, scheduling and refining voice packets to and from mobile phones MOHAMMAD ABDUS SALAM Student ID: 01201023 TAPAN BISWAS Student ID: 01201003 \ Department of Computer Science and Engineering

More information

Video Codec Requirements and Evaluation Methodology

Video Codec Requirements and Evaluation Methodology -47pt -30pt :white Font : edium t Video Codec Requirements and Evaluation Methodology www.huawei.com draft-filippov-netvc-requirements-02 Alexey Filippov, Jose Alvarez (Huawei Technologies) Contents An

More information

OPNET - Network Simulator

OPNET - Network Simulator Simulations and Tools for Telecommunications 521365S: OPNET - Network Simulator Jarmo Prokkola Project Manager, M. Sc. (Tech.) VTT Technical Research Centre of Finland Kaitoväylä 1, Oulu P.O. Box 1100,

More information

Scalable Video Streaming in Wireless Mesh Networks for Education

Scalable Video Streaming in Wireless Mesh Networks for Education Scalable Video Streaming in Wireless Mesh Networks for Education LIU Yan WANG Xinheng LIU Caixing 1. School of Engineering, Swansea University, Swansea, UK 2. College of Informatics, South China Agricultural

More information

QoS Parameters. Quality of Service in the Internet. Traffic Shaping: Congestion Control. Keeping the QoS

QoS Parameters. Quality of Service in the Internet. Traffic Shaping: Congestion Control. Keeping the QoS Quality of Service in the Internet Problem today: IP is packet switched, therefore no guarantees on a transmission is given (throughput, transmission delay, ): the Internet transmits data Best Effort But:

More information

Distributed Systems 3. Network Quality of Service (QoS)

Distributed Systems 3. Network Quality of Service (QoS) Distributed Systems 3. Network Quality of Service (QoS) Paul Krzyzanowski pxk@cs.rutgers.edu 1 What factors matter for network performance? Bandwidth (bit rate) Average number of bits per second through

More information

Internet Control Protocols Reading: Chapter 3

Internet Control Protocols Reading: Chapter 3 Internet Control Protocols Reading: Chapter 3 ARP - RFC 826, STD 37 DHCP - RFC 2131 ICMP - RFC 0792, STD 05 1 Goals of Today s Lecture Bootstrapping an end host Learning its own configuration parameters

More information

Improving the Performance of TCP Using Window Adjustment Procedure and Bandwidth Estimation

Improving the Performance of TCP Using Window Adjustment Procedure and Bandwidth Estimation Improving the Performance of TCP Using Window Adjustment Procedure and Bandwidth Estimation R.Navaneethakrishnan Assistant Professor (SG) Bharathiyar College of Engineering and Technology, Karaikal, India.

More information

Transport layer issues in ad hoc wireless networks Dmitrij Lagutin, dlagutin@cc.hut.fi

Transport layer issues in ad hoc wireless networks Dmitrij Lagutin, dlagutin@cc.hut.fi Transport layer issues in ad hoc wireless networks Dmitrij Lagutin, dlagutin@cc.hut.fi 1. Introduction Ad hoc wireless networks pose a big challenge for transport layer protocol and transport layer protocols

More information

Protocol Data Units and Encapsulation

Protocol Data Units and Encapsulation Chapter 2: Communicating over the 51 Protocol Units and Encapsulation For application data to travel uncorrupted from one host to another, header (or control data), which contains control and addressing

More information

Level 1 Technical. Networking and Technology Basics. Contents

Level 1 Technical. Networking and Technology Basics. Contents Level 1 Technical Networking and Technology Basics Contents 1 Glossary... 2 2 IP Networking Basics... 4 Fundamentals... 4 IP Addresses... 4 Subnet Masks... 5 Network Communication... 6 Transport Protocols...

More information

CROSS LAYER BASED MULTIPATH ROUTING FOR LOAD BALANCING

CROSS LAYER BASED MULTIPATH ROUTING FOR LOAD BALANCING CHAPTER 6 CROSS LAYER BASED MULTIPATH ROUTING FOR LOAD BALANCING 6.1 INTRODUCTION The technical challenges in WMNs are load balancing, optimal routing, fairness, network auto-configuration and mobility

More information

EINDHOVEN UNIVERSITY OF TECHNOLOGY Department of Mathematics and Computer Science

EINDHOVEN UNIVERSITY OF TECHNOLOGY Department of Mathematics and Computer Science EINDHOVEN UNIVERSITY OF TECHNOLOGY Department of Mathematics and Computer Science Examination Computer Networks (2IC15) on Monday, June 22 nd 2009, 9.00h-12.00h. First read the entire examination. There

More information

SIP Trunking and Voice over IP

SIP Trunking and Voice over IP SIP Trunking and Voice over IP Agenda What is SIP Trunking? SIP Signaling How is Voice encoded and transported? What are the Voice over IP Impairments? How is Voice Quality measured? VoIP Technology Confidential

More information

Optimization of VoIP over 802.11e EDCA based on synchronized time

Optimization of VoIP over 802.11e EDCA based on synchronized time Optimization of VoIP over 802.11e EDCA based on synchronized time Padraig O Flaithearta, Dr. Hugh Melvin Discipline of Information Technology, College of Engineering and Informatics, National University

More information

Application Note. IPTV Services. Contents. Title Managing IPTV Performance Series IP Video Performance Management. Overview... 1. IPTV Services...

Application Note. IPTV Services. Contents. Title Managing IPTV Performance Series IP Video Performance Management. Overview... 1. IPTV Services... Title Managing IPTV Performance Series IP Video Performance Management Date September 2012 (orig. February 2008) Contents Overview... 1 IPTV Services... 1 Factors that Affect the Performance of IPTV...2

More information

VoIP network planning guide

VoIP network planning guide VoIP network planning guide Document Reference: Volker Schüppel 08.12.2009 1 CONTENT 1 CONTENT... 2 2 SCOPE... 3 3 BANDWIDTH... 4 3.1 Control data 4 3.2 Audio codec 5 3.3 Packet size and protocol overhead

More information

Marratech Technology Whitepaper

Marratech Technology Whitepaper Marratech Technology Whitepaper Marratech s technology builds on many years of focused R&D and key reference deployments. It has evolved into a market leading platform for Real Time Collaboration (RTC)

More information