UNIVERSITY OF OSLODepartment of Informatics

Quality of ServiceMonitoring forVideo Streaming inMobile Ad-hocNetworks

Master’s thesis

Magnus EnghHalvorsen

1st February 2008

Abstract

This thesis work is done in the context of a recently launchedresearch project on delay-tolerant streaming, where the vision is toprovide a video streaming solution capable of performing in a dy-namic, wireless, mobile environment without the presence of a fixedinfrastructure.

There are situations where regular wireless communication net-works are not accessible or the connectivity is limited. Examples ofsuch situations are emergency and rescue operations, where commu-nications infrastructure may be non-existent or destroyed. The useof mobile devices connected using mobile ad-hoc network (MANET)technology and operating independently of any existing infrastructure,can help overcome these difficulties and provide connectivity despitelarge-scale disasters. Also, a lot of information cannot be commu-nicated through conventional systems, such as phones or radio. Theability to transmit streaming multimedia data could potentially savelives in an emergency situation.

Multimedia streaming is a topic that has not received much at-tention in MANET research. Furthermore, most of the research andexperiences with MANETs in general are based on work done in sim-ulated environments. However, in contrast to most prior MANETresearch, this thesis uses a practical approach. We present a workingsolution for serving and consuming streaming video using the Nokia770 Internet Tablet that can serve as a starting point for future workon video streaming in mobile ad-hoc networks. The solution is basedentirely on open-source software, and can thus be freely used andmodified for future research.

We also demonstrate how we were able to perform cross-layer mon-itoring of the video streaming solution through a strategy of combin-ing hardware resource monitoring and different network measurementmethods. In addition, we show how to set up a small-scale, real-worldtestbed for mobile ad-hoc networks to perform such monitoring.

Using this testbed, we the evaluated the performance of videostreaming on the Nokia 770 in a mobile ad-hoc network environment.Our main finding is that to avoid degrading the normal operation ofthe devices or the network during streaming, conservation of CPU re-sources must be a priority when designing a video streaming solutionfor mobile ad-hoc networks.

We also investigated the wireless link data reported by the Nokia770 wireless interface drivers, and found that the reported values haveserious limitations compared to the values reported by other wirelessdevices.

2

Acknowledgements

I want to thank everyone who have given their time, assistance and patienceso generously throughout the past two years.

First and foremost, I would like to express my utmost gratitude to mysupervisors, Thomas Plagemann and Matti Siekkinen, for their invaluableguidance and constructive comments throughout the course of my thesiswork. Without your support and expertise, this work would not have beenpossible.

I would also like to thank the participants of the Delay-Tolerant StreamingProject and the people in the DMMS research group at the University of Oslofor their helpful feedback and assistance on various matters. In particular, Iwant to thank Sergio Cabrero, for taking the time to explain their work ondesigning protocols for delay-tolerant streaming, and for assisting me withthe initial configuration and software installation on the Nokia 770.

Finally, I would like express my thanks to those of my friends who spentseveral hours of their valuable time proofreading this thesis. Your efforts andfeedback helped much in improving its quality.

4

Contents

I Background and concepts 14

1 Introduction 141.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.2 Motivation and problem description . . . . . . . . . . . . . . . 151.3 Goals and methods . . . . . . . . . . . . . . . . . . . . . . . . 161.4 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.5 Technical challenges . . . . . . . . . . . . . . . . . . . . . . . . 171.6 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . 181.7 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2 Mobile ad-hoc networks 212.1 Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . 212.2 MANET Applications . . . . . . . . . . . . . . . . . . . . . . 222.3 Routing in MANETs . . . . . . . . . . . . . . . . . . . . . . . 22

2.3.1 Single-channel vs. multi-channel . . . . . . . . . . . . . 222.3.2 Uniform vs. non-uniform . . . . . . . . . . . . . . . . . 232.3.3 Topology based vs. destination based . . . . . . . . . . 232.3.4 Proactive vs. reactive protocols . . . . . . . . . . . . . 23

2.4 Examples of MANET routing protocols . . . . . . . . . . . . . 232.4.1 Optimized Link State Routing (OLSR) . . . . . . . . . 242.4.2 Ad-hoc On-demand Distance Vector Routing (AODV) 24

3 Multimedia streaming 263.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.2 Quality of Service (QoS) requirements . . . . . . . . . . . . . 263.3 Transport protocols . . . . . . . . . . . . . . . . . . . . . . . . 27

3.3.1 Transmission Control Protocol (TCP) . . . . . . . . . . 283.3.2 User Datagram Protocol (UDP) . . . . . . . . . . . . . 293.3.3 Real-Time Transport Protocol (RTP) . . . . . . . . . . 29

3.4 Control protocols . . . . . . . . . . . . . . . . . . . . . . . . . 293.4.1 Hypertext Transfer Protocol (HTTP) . . . . . . . . . . 293.4.2 Session Initiation Protocol (SIP) . . . . . . . . . . . . 303.4.3 Real-Time Streaming Protocol (RTSP) . . . . . . . . . 30

3.5 Multimedia streaming issues MANETs . . . . . . . . . . . . . 303.5.1 Wireless medium . . . . . . . . . . . . . . . . . . . . . 313.5.2 Resource constraints . . . . . . . . . . . . . . . . . . . 313.5.3 Heterogeneity . . . . . . . . . . . . . . . . . . . . . . . 32

6

3.5.4 Lack of fixed infrastructure . . . . . . . . . . . . . . . 323.5.5 Topology changes . . . . . . . . . . . . . . . . . . . . . 323.5.6 Malicious nodes . . . . . . . . . . . . . . . . . . . . . . 323.5.7 Transport protocol design issues . . . . . . . . . . . . . 33

4 Measuring Quality of Service 344.1 Measurements at the network level . . . . . . . . . . . . . . . 344.2 Link quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.2.1 Received Signal Strength Indicator (RSSI) . . . . . . . 354.2.2 Signal-to-Noise Ratio (SNR) . . . . . . . . . . . . . . . 364.2.3 Expected Transmission Count (ETX) . . . . . . . . . . 364.2.4 Expected Transmission Time (ETT) . . . . . . . . . . 36

4.3 Route quality . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.3.1 Expected Transmission Count (ETX) . . . . . . . . . . 374.3.2 Weighted Cumulative ETT (WCETT) . . . . . . . . . 374.3.3 Route stability . . . . . . . . . . . . . . . . . . . . . . 37

4.4 Measurements at the media level . . . . . . . . . . . . . . . . 384.4.1 Subjective vs. objective measurement methods . . . . . 384.4.2 Mean Square Error (MSE) . . . . . . . . . . . . . . . . 394.4.3 Peak Signal-to-Noise Ratio (PSNR) . . . . . . . . . . . 394.4.4 Relative Peak Signal-to-Noise Ratio (rPSNR) . . . . . 394.4.5 Summary of measurement methods . . . . . . . . . . . 40

4.5 QoS measurement in MANETs . . . . . . . . . . . . . . . . . 40

II Experiments 41

5 The Nokia 770 Internet Tablet 415.1 About the device . . . . . . . . . . . . . . . . . . . . . . . . . 415.2 Basic software . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.2.1 Operating system . . . . . . . . . . . . . . . . . . . . . 435.2.2 xterm . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.2.3 SSH2 server . . . . . . . . . . . . . . . . . . . . . . . . 435.2.4 Wireless Tools . . . . . . . . . . . . . . . . . . . . . . . 435.2.5 NTP client . . . . . . . . . . . . . . . . . . . . . . . . 445.2.6 OLSR daemon . . . . . . . . . . . . . . . . . . . . . . 44

5.3 Network measurements . . . . . . . . . . . . . . . . . . . . . . 445.3.1 The proc filesystem (procfs) . . . . . . . . . . . . . . 445.3.2 ifconfig . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.3.3 netstat . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.3.4 Linux Wireless Tools . . . . . . . . . . . . . . . . . . . 46

7

5.3.5 The sys filesystem (sysfs) . . . . . . . . . . . . . . . 505.3.6 Connection Manager . . . . . . . . . . . . . . . . . . . 515.3.7 OLSR daemon . . . . . . . . . . . . . . . . . . . . . . 52

5.4 The Nokia 770 multimedia architecture . . . . . . . . . . . . . 555.4.1 GStreamer . . . . . . . . . . . . . . . . . . . . . . . . . 555.4.2 The digital signal processor (DSP) . . . . . . . . . . . 565.4.3 Video streaming . . . . . . . . . . . . . . . . . . . . . . 58

5.5 Video streaming software . . . . . . . . . . . . . . . . . . . . . 595.5.1 gst-launch (GStreamer) . . . . . . . . . . . . . . . . . . 605.5.2 Flumotion . . . . . . . . . . . . . . . . . . . . . . . . . 605.5.3 Helix DNA Server . . . . . . . . . . . . . . . . . . . . . 605.5.4 Icecast . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.5.5 FFmpeg . . . . . . . . . . . . . . . . . . . . . . . . . . 615.5.6 VideoLAN . . . . . . . . . . . . . . . . . . . . . . . . . 625.5.7 Video Player . . . . . . . . . . . . . . . . . . . . . . . 635.5.8 MPlayer . . . . . . . . . . . . . . . . . . . . . . . . . . 635.5.9 Xine . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.6 Resource monitoring . . . . . . . . . . . . . . . . . . . . . . . 645.6.1 The /proc filesystem . . . . . . . . . . . . . . . . . . . 645.6.2 ps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655.6.3 top . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655.6.4 sysstat . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.7 Other software . . . . . . . . . . . . . . . . . . . . . . . . . . 665.7.1 Mediautils . . . . . . . . . . . . . . . . . . . . . . . . . 665.7.2 MediaConverter . . . . . . . . . . . . . . . . . . . . . . 675.7.3 VidConvert . . . . . . . . . . . . . . . . . . . . . . . . 675.7.4 RTPTools . . . . . . . . . . . . . . . . . . . . . . . . . 675.7.5 LIVE555 test programs . . . . . . . . . . . . . . . . . . 67

6 Wireless monitoring experiment 686.1 Motivation and purpose . . . . . . . . . . . . . . . . . . . . . 686.2 Experiment setup . . . . . . . . . . . . . . . . . . . . . . . . . 696.3 Measurements with laptop and Nokia 770 . . . . . . . . . . . 706.4 Measurements with two Nokia 770s . . . . . . . . . . . . . . . 796.5 Lessons learned . . . . . . . . . . . . . . . . . . . . . . . . . . 82

7 Video streaming experiment 887.1 Network monitoring . . . . . . . . . . . . . . . . . . . . . . . . 88

7.1.1 Kismet . . . . . . . . . . . . . . . . . . . . . . . . . . . 887.1.2 tcpdump . . . . . . . . . . . . . . . . . . . . . . . . . . 887.1.3 mmdump . . . . . . . . . . . . . . . . . . . . . . . . . 89

8

7.1.4 Wireshark . . . . . . . . . . . . . . . . . . . . . . . . . 897.2 Experiment setup . . . . . . . . . . . . . . . . . . . . . . . . . 90

7.2.1 Choice of streaming server . . . . . . . . . . . . . . . . 907.2.2 Choice of video player . . . . . . . . . . . . . . . . . . 917.2.3 Choice of video . . . . . . . . . . . . . . . . . . . . . . 917.2.4 Choice of resource monitoring software . . . . . . . . . 957.2.5 Wireless testbed . . . . . . . . . . . . . . . . . . . . . . 95

7.3 Performing the experiment . . . . . . . . . . . . . . . . . . . . 997.3.1 Scenario 1: Local playback . . . . . . . . . . . . . . . . 997.3.2 Scenario 2: Node-to-node . . . . . . . . . . . . . . . . 1087.3.3 Scenario 3: MANET . . . . . . . . . . . . . . . . . . . 121

7.4 Lessons learned . . . . . . . . . . . . . . . . . . . . . . . . . . 1297.5 Playback on the Nokia N800 . . . . . . . . . . . . . . . . . . . 129

7.5.1 About the Nokia N800 . . . . . . . . . . . . . . . . . . 1307.5.2 Performing the measurements . . . . . . . . . . . . . . 1307.5.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 1317.5.4 Lessons learned . . . . . . . . . . . . . . . . . . . . . . 136

8 Conclusions 1378.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1378.2 Critical evaluation . . . . . . . . . . . . . . . . . . . . . . . . 1388.3 Open problems and future work . . . . . . . . . . . . . . . . . 138

A Configuration of software 144A.1 Flashing the latest Nokia image . . . . . . . . . . . . . . . . . 144A.2 Gaining local root access on the Nokia 770 . . . . . . . . . . . 144A.3 Setting up Scratchbox . . . . . . . . . . . . . . . . . . . . . . 145A.4 Compiling and running FFserver . . . . . . . . . . . . . . . . 146A.5 Software repositories . . . . . . . . . . . . . . . . . . . . . . . 147

B Source code 148B.1 wlantest.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148B.2 generate plotdata.py . . . . . . . . . . . . . . . . . . . . . . . 150B.3 generate all plots.sh . . . . . . . . . . . . . . . . . . . . . . . . 152B.4 resourcelogger.sh . . . . . . . . . . . . . . . . . . . . . . . . . 153B.5 networklogger.sh . . . . . . . . . . . . . . . . . . . . . . . . . 155B.6 wlanmonitor.sh . . . . . . . . . . . . . . . . . . . . . . . . . . 157B.7 start ffserver.sh . . . . . . . . . . . . . . . . . . . . . . . . . . 158B.8 start olsrd.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . 159B.9 playallstreams.sh . . . . . . . . . . . . . . . . . . . . . . . . . 160B.10 parse rtcp data.sh . . . . . . . . . . . . . . . . . . . . . . . . . 162

9

B.11 generate resource plots.sh . . . . . . . . . . . . . . . . . . . . 163

List of Figures

1 OLSR: Example illustrating the use of MPRs . . . . . . . . . 242 The Nokia 770 Internet Tablet . . . . . . . . . . . . . . . . . . 413 Main components of the Maemo platform . . . . . . . . . . . . 424 Sample output: /proc/net/dev . . . . . . . . . . . . . . . . . 455 Sample output: ifconfig. . . . . . . . . . . . . . . . . . . . . 456 Sample output: /proc/net/wireless . . . . . . . . . . . . . . 487 Sample output: iwconfig on the Dell XPS m1210. . . . . . . 498 Sample output: iwconfig on the Nokia 770. . . . . . . . . . . 499 Sample output: iwlist’s scan command. . . . . . . . . . . . . 5010 Sample output: iwspy . . . . . . . . . . . . . . . . . . . . . . 5011 The Nokia 770 connection manager . . . . . . . . . . . . . . . 5112 Maemo connectivity licences . . . . . . . . . . . . . . . . . . . 5213 Sample output: OLSR daemon . . . . . . . . . . . . . . . . . 5314 Nokia 770 multimedia architecture . . . . . . . . . . . . . . . 5515 Output of DSP tasks from sysfs . . . . . . . . . . . . . . . . 5816 The VideoLAN streaming solution . . . . . . . . . . . . . . . . 6317 Laptop and Nokia 770: Reported bit rate at 16 meters . . . . 7118 Laptop and Nokia 770: Reported bit rate at 32 meters . . . . 7219 Laptop and Nokia 770: Reported bit rate at 64 meters . . . . 7220 Laptop and Nokia 770: Link quality at 0 meters . . . . . . . . 7321 Laptop and Nokia 770: Link quality at 2 meters . . . . . . . . 7322 Laptop and Nokia 770: Link quality at 4 meters . . . . . . . . 7423 Laptop and Nokia 770: Link quality at 64 meters . . . . . . . 7424 Laptop and Nokia 770: Noise level at 0 meters . . . . . . . . . 7525 Laptop and Nokia 770: Noise level at 64 meters . . . . . . . . 7526 Laptop and Nokia 770: Signal level at 0 meters . . . . . . . . 7627 Laptop and Nokia 770: Signal level at 64 meters . . . . . . . . 7728 Laptop and Nokia 770: Tx errors at 64 meters . . . . . . . . . 7729 Laptop and Nokia 770: Tx excessive retries at 16 meters . . . 7830 Laptop and Nokia 770: Tx excessive retries at 64 meters . . . 7831 2 Nokia 770s: Signal level at 0 meters . . . . . . . . . . . . . . 8032 2 Nokia 770s: Signal level at 32 meters . . . . . . . . . . . . . 8133 2 Nokia 770s: Link quality at 0 meters . . . . . . . . . . . . . 8134 2 Nokia 770s: Link quality at 32 meters . . . . . . . . . . . . . 8235 2 Nokia 770s: Tx excessive retries at 0 meters . . . . . . . . . 8336 2 Nokia 770s: Tx excessive retries at 16 meters . . . . . . . . . 83

10

37 2 Nokia 770s: Tx excessive retries at 32 meters . . . . . . . . . 8438 2 Nokia 770s: Tx errors at 32 meters . . . . . . . . . . . . . . 8439 The action video clip . . . . . . . . . . . . . . . . . . . . . . . 9440 The interview video clip . . . . . . . . . . . . . . . . . . . . . 9441 CPU utilization: Local playback of clip no. 1 . . . . . . . . . . 10042 CPU utilization: Local playback of clip no. 4 . . . . . . . . . . 10143 CPU utilization: Local playback of clip no. 3 . . . . . . . . . . 10144 CPU utilization: Local playback of clip no. 7 . . . . . . . . . . 10245 CPU utilization: Playing MPEG-4 video in MPlayer . . . . . . 10346 CPU utilization: Playing MPEG-4 video in Video Player . . . 10447 DSP int./sec.: Playing MPEG-4 video in MPlayer . . . . . . . 10448 DSP int./sec.: Playing MPEG-4 video in Video Player . . . . 10549 CPU utilization: Playing MPEG-1 video in MPlayer . . . . . . 10550 CPU utilization: Playing MPEG-1 video in Video Player . . . 10651 DSP int./sec.: Playing MPEG-1 video in MPlayer . . . . . . . 10652 DSP int./sec.: Playing MPEG-1 video in Video Player . . . . 10753 Node-to-node experiment setup . . . . . . . . . . . . . . . . . 10854 CPU utilization: Server node streaming clip no. 1 . . . . . . . 10955 CPU utilization: Client node streaming clip no. 1 . . . . . . . 11056 CPU utilization: Server node streaming clip no. 3 . . . . . . . 11057 CPU utilization: Client node streaming clip no. 3 . . . . . . . 11158 Block device activity: Server node streaming clip no. 1 . . . . 11259 Block device activity: Server node streaming clip no. 2 . . . . 11260 Block device activity: Server node streaming clip no. 3 . . . . 11361 Block device activity: Client node streaming clip no. 1 . . . . 11362 Network activity: Server node streaming clip no. 1 . . . . . . 11463 Network activity: Server node streaming clip no. 2 . . . . . . 11564 Network activity: Server node streaming clip no. 3 . . . . . . 11565 Link quality: Client node streaming clip no. 1 . . . . . . . . . 11666 Link quality: Client node streaming clip no. 3 . . . . . . . . . 11667 RTCP cumulative packet loss: Streaming clip no. 1 and 4 . . . 11768 RTCP cumulative packet loss: Streaming clip no. 7 and 10 . . 11869 Excerpt of the decoded packet headers from Wireshark . . . . 12070 MANET experiment setup . . . . . . . . . . . . . . . . . . . . 12171 CPU utilization: Server streaming clip no. 1 . . . . . . . . . . 12272 CPU utilization: Client streaming clip no. 1 . . . . . . . . . . 12373 CPU utilization: Intermediate node streaming clip no. 1 . . . 12374 CPU utilization: Intermediate node streaming clip no. 3 . . . 12475 CPU utilization: Server node streaming clip no. 3 . . . . . . . 12476 CPU utilization: Client node streaming clip no. 3 . . . . . . . 12577 Network activity: Server node streaming clip no. 3 . . . . . . 125

11

78 Link quality: Intermediate node streaming clip no. 3 . . . . . 12679 Link quality: Server node streaming clip no. 3 . . . . . . . . . 12780 Link quality: Client node streaming clip no. 3 . . . . . . . . . 12781 The Nokia N800 . . . . . . . . . . . . . . . . . . . . . . . . . . 13182 CPU utilization: Playing MPEG-4 video in MPlayer . . . . . . 13283 CPU utilization: Playing MPEG-4 video in MediaPlayer . . . 13284 CPU utilization: Playing MPEG-1 video in MPlayer . . . . . . 13385 CPU utilization: Playing MPEG-1 video in MediaPlayer . . . 13386 CPU utilization: Local playback of clip no. 1 in MPlayer . . . 13487 CPU utilization: Local playback of clip no. 1 in MediaPlayer . 13488 CPU utilization: Local playback of clip no. 4 in MPlayer . . . 13589 CPU utilization: Local playback of clip no. 4 in MediaPlayer . 135

List of Tables

1 Comparison of transport protocols . . . . . . . . . . . . . . . . 282 Comparison of control protocols . . . . . . . . . . . . . . . . . 303 Quality of Service perspectives . . . . . . . . . . . . . . . . . . 344 Nokia 770 hardware specifications . . . . . . . . . . . . . . . . 415 File formats with built-in support on the Nokia 770 . . . . . . 566 Audio formats with built-in support on the Nokia 770 . . . . . 577 Supported audio/video format combinations . . . . . . . . . . 578 Laptop and Nokia 770: File transfer results . . . . . . . . . . . 709 2 Nokia 770s: File transfer results . . . . . . . . . . . . . . . . 7910 Video clips used in the experiment . . . . . . . . . . . . . . . 9311 Information accessible from the different protocol layers . . . . 9812 Summary of network measurement possibilities . . . . . . . . . 9813 Monitoring methods by layer . . . . . . . . . . . . . . . . . . . 9914 Nokia N800 hardware specifications . . . . . . . . . . . . . . . 130

12

Part I

Background and concepts

1 Introduction

1.1 Background

During the last years, mobile devices have become more and more common-place, to the point that statistically, every person in Norway owns a mobilephone. In addition to this, laptops are rapidly replacing traditional desktopcomputers, and the number of PDAs are increasing.

Also, today’s mobile devices usually support several wireless communica-tion technologies, such as Bluetooth, 3G and 802.11 WLAN, with each tech-nology having different advantages and disadvantages. Thus, mobile devicescan choose the most suitable wireless interface to communicate in a particu-lar scenario. This is known as the ”wireless technologies convergence” (Kwonet al., 2002, p. 66).

Traditionally, data networks are designed, deployed and based around afixed infrastructure. But a group of mobile devices can also form a networkof their own in order to exchange information. Such a network, formedspontaneously by wireless, mobile nodes without any existing infrastructure,is called a mobile ad-hoc network (MANET).

However, the strengths of the MANET are also what leads to its weak-nesses. Mobile devices are small and have limited resources, such as pro-cessing power and storage capacity. Also, wireless networks are shared me-dia, which suffer from contention and are vulnerable to interference from ex-ternal sources. This, in combination with the lack of a fixed infrastructure,makes it hard to provide the necessary quality of service to support delayand bandwidth sensitive services, such as streaming of multimedia data. Thetraditional methods of providing quality of service guarantees, such as over-provisioning of bandwidth and routing capacity or strict admission control,cannot be applied, as they require ownership and policing of the networkinfrastructure.

This thesis work is done in the context of a recently launched researchproject on delay-tolerant streaming, where the vision is to provide a videostreaming solution capable of performing in a dynamic, wireless, mobile en-vironment without the presence of a fixed infrastructure.

Multimedia streaming is a topic that has not received much attentionin MANET research. Furthermore, most of the research and experiences

14

with MANETs in general are based on work done in simulated environments.Very little work has been done on performing practical experiments with realmobile devices in real-world MANETs. This is largely due to the difficultyof creating such networks in a laboratory setting, as it is hard to limit thecommunication range of the nodes to create indoor multi-hop testbeds, andto create reproducible results.

In addition, software for delivering multimedia services is rarely designedto operate in mobile environments, and the mobile devices themselves areseldom designed to provide such services. This particularly applies to theserver side.

1.2 Motivation and problem description

There are situations where the regular wireless communication networks arenot accessible or the connectivity is limited. Examples of such situationsare emergency and rescue operations, where communications infrastructuremay be non-existent or destroyed. As an example, imagine a large-scaleearthquake, where large parts of the existing infrastructure are damaged,rendering the traditional communication networks useless. Also, many othercommunication issues can arise under such circumstances with respect tothe technical equipment, for instance due to extreme weather conditions.At the same time, the need for communication is even greater than usual,as it is vital for the command and control of such operations. Differentdepartments and organizations have to cooperate and coordinate their efforts,and emergency teams must be dispatched to provide medical assistance toinjured victims.

The use of mobile devices connected using mobile ad-hoc network tech-nology and operating independently of any existing infrastructure, can helpovercome these difficulties and provide connectivity despite large-scale dis-asters. Also, while phones and radio are sufficient in many circumstances,some information, e.g. maps and pictures, cannot be communicated throughthese conventional systems (Sanderson et al., 2007). The ability to transmitstreaming multimedia data using a mobile device carried by the members ofa rescue team can potentially save lives. As an example, streaming videofrom a camera could be used to assess the severity of injuries sustained bypeople during an accident, or damages to important structures or machinery.

Applications for multimedia streaming over MANETs are of course notlimited to emergency and rescue scenarios. It might also be used for en-tertainment purposes, or as a way to provide location-based, self-scalablemultimedia services, such as guided tours at a museum.

In general, mobile ad-hoc networks can provide flexible, adaptive and

15

low-cost networking solutions. But while MANETs open up new possibil-ities, they also introduce new challenges. Mobility causes problems whentrying to find a suitable path that can sustain a multimedia streaming ses-sion, and mobile devices are usually small and limited in terms of processingpower, storage capacity, and battery power. It thus follows that monitoringof available resources in the mobile ad-hoc network is essential to providesufficient quality of service for a video streaming solution to operate.

Meeting the quality of service demands of an application requires thatthe quality of service demands are met at each layer in every componentalong the data path. Thus, measurements must be performed at every layerto ensure that these demands are met. This requires monitoring of systemresources, as well as monitoring at each layer of the OSI model, includinghop-by-by and end-to-end network measurements.

1.3 Goals and methods

The goal of this thesis is to create an experimental platform for video stream-ing in mobile ad-hoc networks, including a set of measurement tools andstrategy to evaluate the performance of the solution. This platform can thenserve as a starting point for further practical investigations to find factorsthat limit the performance of mobile ad-hoc network video streaming. Thecomplete solution should be based entirely on open source software.

This work is also an effort to gain greater insight into the reliability ofthese measurement methods, and the quality of the measurement data, aswell as services and techniques that rely on monitoring services, such as routeoptimization, etc.

In contrast to most prior research on mobile ad-hoc networks, this worktakes a practical approach. Using real mobile devices, we seek to createa small-scale testbed for video streaming over mobile ad-hoc networks. Toevaluate the performance of our video streaming platform, we then conduct aseries of experiments while performing measurements at the hardware layer aswell as all network layers in order to see the interaction between the differentlayers, and to provide a complete picture of the performance of the solution.

The nodes in our experiments are Nokia 770 Internet Tablets, which is aLinux-based tablet released in late 2005, with 802.11 WLAN and Bluetoothconnectivity.

1.4 Contributions

This thesis demonstrates how we successfully created a platform for opensource, mobile ad-hoc network video streaming with the Nokia 770 Internet

16

Tablet. It also shows how we composed a set of tools, scripts and strategies toprovide cross-layer monitoring of the video streaming solution. In addition,we show an example on how to set up a small-scale, real-world testbed formobile ad-hoc networks to perform such monitoring.

Using these tools and strategies, we evaluate the performance of videostreaming on the Nokia 770 in a mobile ad-hoc network environment. Wealso investigate the wireless link data reported by the Nokia 770 wirelessinterface drivers, and find that the values reported by the driver have seriouslimitations compared to the values reported by other wireless devices.

Additionally, this work serves as an introduction into what kind of net-work quality of service information is available in a Linux environment gener-ally, and on a Nokia 770 specifically, as well as an example on how to developthe means to extract and log these measurements in an effective manner.

1.5 Technical challenges

The general impression of the Nokia 770 is that it is not a very stable device.During our work, our devices would frequently hang or reboot, particularlywhen performing CPU intensive tasks and opening several applications atonce.

In terms of measurements, the first problems we faced were issues with thedriver for the wireless interface in the Nokia 770. It turned out that someof the measurements that it reports cannot be interpreted in the way onewould expect from experience with other wireless interfaces, or are clearlyincorrect, when compared to measurements made by other devices.

Availability of software packages was another issue. While there are sev-eral repositories containing large numbers of software packages for the Nokia770, as well as for the newer generations of the Internet Tablet series, theselection of media playing software was not very large, and the availabilityof packaged software for serving multimedia streams was non-existent.

Normally, when a package is missing, open source software can easily bedownloaded and compiled. Unfortunately, due to the Nokia 770’s limitedstorage capacity, installing a compiler suite and other necessary prerequis-ites is not very feasible. In addition to this, the processor architecture ofthe device is different from the x86 architecture of most common computersystems, meaning that in order to compile software for the Nokia 770 on aregular desktop computer, we were required to set up a cross-compilationenvironment.

Finally, there was the issue of creating a real-world test bed for performingmobile ad-hoc network measurements on a limited area without access to

17

customized equipment. We managed to find a solution that worked well forour very small MANET, but will not scale to much bigger networks.

1.6 Related work

Providing delay and bandwidth sensitive services such as multimedia stream-ing in MANETs are a major challenge, and very little research has been donein this area.

However, one related project is NonStop, by Li and Wang (2003). Non-Stop is ”a collection of middleware-based algorithms that collectively guar-antee the continuous availability of multimedia streaming services from thepoint of view of any mobile users in the network” Li and Wang (2003, p. 2).The work focuses on mobility prediction, and as most other MANET re-search, it is based on experiments running in simulators.

Rojviboonchai et al. (2005) presented the Ad Hoc Multipath StreamingProtocol (AMTP), which is designed to work with a multipath routing pro-tocol, optimizing QoS by using cross-layer information to stream multimediadata over disjoint paths. Ghannay et al. (2004) extended the OLSR protocolto monitor and collect QoS parameters from the nodes of a mobile ad-hocnetwork. Chen et al. (1999) presented the Ad Hoc Management Protocol(ANMP), which builds on SNMP to collection resource information fromad-hoc network nodes. However, all this work is also based on experimentsperformed in simulators.

Ngo et al. (2003), on the other hand, demonstrated a prototype of WAN-Mon, ”a monitoring tool that allows the user to monitor the resource con-sumption by ad-hoc wireless network based activities.” It is able to monitorfour categories of statistics: Network, power, memory and CPU.

In the area of wireless link monitoring, Yeo et al. (2004) developed aframework for monitoring of wireless networks, conducting measurements bysniffing of the wireless medium. Yeo et al. (2005) showed that wireless mon-itoring is a reliable method of capturing traces for wireless traffic analysis.They also demonstrated how to improve the accuracy of wireless monitoringby merging traces from multiple monitoring devices. Bianchi et al. (2006) dida performance analysis of outdoor 802.11 wireless links based on link layermeasurements. The link layer measurement data was obtained by modifyingthe open source MADWiFi driver. The work by Mahanti et al. (2007) focuseson how to assess the quality of wireless traces, and the placement of wirelesssensors for performing wireless sniffing.

While the work on wireless monitoring mentioned so far has focusedon monitoring of wireless networks in infrastructure mode, there has alsobeen research on link layer monitoring in multi-hop networks. Aguayo et al.

18

(2004) used link layer measurements to analyze the causes of packet loss in an802.11b multi-hop network. The data was provided through per-frame meas-urements obtained through special features of the Prism2 wireless chipset.Das et al. (2007), on the other hand, compared the performance of variouslink quality metrics in multi-hop wireless networks.

On the topic of multimedia stream monitoring, van der Merwe et al.(2000) did work on analyzing packet captures of multimedia data, and de-veloped a the tool mmdump to aid in parsing said data. Zhou et al. (2007)have developed the Portable MultiMedia Monitor (p3m), for kernel spacemonitoring of multimedia streams. p3m is extensible, server independent,and is claimed to greatly reduce the resource requirements associated withparsing and analyzing multimedia streams. Both of these tools are designedwith larger scale, wired IP networks in mind, however.

Kuang and Williamson (2002) was perhaps the first to perform a meas-urement study of video streaming performance on a wireless network, usinga combination of packet capturing with tcpdump at each node and wirelesssniffing. Koucheryavy et al. (2004) evaluated the performance of RealVideostreaming in a wireless network using end-to-end measurements, performingexperiments with different signal-to-noise ratios and competing cross-traffic.However, both works perform their measurements on a regular 802.11 WLANin infrastructure mode.

Sun et al. (2005) performed a performance evaluation of both video andvoice traffic in a real-world mesh network. Still, these experiments were notperformed using actual video and voice streaming software, but by replayingan RTP stream using RTPtools. It thus only looks at the networking aspect,and does not take into account the resource requirements of video playbackon the client node, for instance.

Xue and Chandra (2006) performed real-world experiments with videostreaming in mobile ad-hoc networks. Their analysis focuses on hardware andhardware resource management. In contrast to the work presented in thisthesis, the nodes in their experiments were quite powerful laptops runningprimarily closed-source software.

Evaluation of image and video quality is perhaps a more mature researcharea. A good overview on the topic of video quality assessment can be foundin Wang et al. (2003). Reibman et al. (2004) have also done some workon predicting video quality based on network measurements. They havedeveloped NoParse, QuickParse and FullParse; three methods for monitoringvideo quality in a network, each with varying degrees of complexity andmeasurement requirements. However, their work is mostly theoretical andthe experimental results are obtained through simulations.

Finally, there has been a small amount of work made on creating real-

19

world testbeds for mobile ad-hoc network experiments. Kaba and Raichle(2001) used signal attenuation and external antennas to limit the transmis-sion range of wireless nodes to create multi-hop topologies, while Kaul et al.(2006) accomplished the same using noise injection. However, their work wasprimarily motivated by routing protocol development.

1.7 Outline

This thesis is divided into two parts: Part I gives an introduction to theproblem area and discusses the different concepts. Part II then describes theexperiments we performed and presents the results.

In Part I, Chapter 2 looks at mobile ad-hoc networks and mobile ad-hoc network routing protocols. Chapter 3 introduces multimedia streamingand the concept of quality of service requirements, while Chapter 4 discussesmethods for measuring quality of service in video streaming.

In Part II, Chapter 5 gives an introduction to the Nokia 770 Internet Tab-let, and discusses how to perform quality of service measurements using thisdevice. Chapters 6 and 7 then present our wireless networking experimentand multimedia streaming experiments, respectively, and discuss the resultsof the measurements that were performed.

Finally, we present a summary of our results and experiences, and anevaluation of the methods and solutions we chose for our work, as well assome ideas for future work in this area.

20

2 Mobile ad-hoc networks

This chapter provides an introduction to mobile ad-hoc networks, and theircharacteristics and applications. We also look at mobile ad-hoc networkrouting protocols, in particular OLSR and AODV.

2.1 Characteristics

A mobile ad-hoc network (MANET) is a network consisting of heterogeneous,self- organizing, mobile, wireless nodes. It is characterized by the absenceof infrastructure; systems are both end-nodes and routers. The nodes in aMANET will typically be small devices, such as a mobile phone or a PDA,but also larger mobile devices, such as laptops, can potentially participate ina MANET.

Mobility requires that the devices use wireless communication. The devicesmay support a number of different wireless interfaces, and communicate overthe one most suitable in a particular situation.

As there is no fixed infrastructure in a MANET, the nodes in a MANETneed to be self-organizing and have significant autonomy. Each device acts asboth an end-node and a router. The consequence of these added responsibil-ities is an increased load on both CPU and bandwidth for each node. It alsoraises some questions regarding security. As any node may be an intermediatenode along the path from source to destination, there are many opportunit-ies for man-in-the-middle attacks, where an intermediate node can eavesdropand/or modify data that is passing through it. There is also the possibilityof spoofing attacks, where a node can provide false routing information tothe rest of the network.

A MANET differs from a normal ad-hoc network in that in regular ad-hoc network, nodes are limited to direct node-to-node communication, whilea MANET allows communication through a multi-hop path. MANETs bearsome resemblance to the more well-known peer-to-peer networks. They bothconsist of autonomous nodes, organizing themselves without the presence ofcentral control. Also, the nodes are heterogeneous, with varying hardwarespecifications and bandwidth. The main difference is that while peer-to-peernetworks operate at the application layer, MANETs operate at the networklayer. (Hollick and Steinmetz, 2006, slide 10) Nodes in a MANET will alsogenerally have higher resource limitations than nodes in a P2P-network.

21

2.2 MANET Applications

Mobile ad-hoc networks provide flexible, adaptive and low-cost networkingsolutions. They are suitable where communication infrastructure is unavail-able, either because it does not exist, or because it has been damaged. Thereare also cases where deployment of infrastructure is not cost-effective or evenimpossible.

As already mentioned in Section 1.2, an example of an area where MANETsmay be particularly useful, is in emergency and rescue operations, where thenormal communication infrastructure is non-operational or non-existing. Theuse of mobile devices connected in a mobile ad-hoc network and operatingindependently of any existing infrastructure can help provide connectivitydespite large-scale disasters.

Applications for multimedia streaming over MANETs are of course notlimited to emergency and rescue scenarios. It might also be used for en-tertainment purposes, or as a way to provide location-based, self-scalablemultimedia services, such as guided tours at a museum.

However, the volatile nature of MANETs requires special considerationwhen running many of the services that we take for granted in regular infra-structure networks. This thesis considers video streaming in particular, andwe take a closer look at the issues surrounding video streaming services inMANETs in Section 3.5.

2.3 Routing in MANETs

Feeney (1999) suggests that MANET routing protocols can be classified ac-cording to the following criteria:

Communication model: Single-channel vs. multi-channel

Structure: Uniform vs. non-uniform

State information: Topology based vs. destination based

Scheduling: Proactive vs. reactive (on-demand)

2.3.1 Single-channel vs. multi-channel

This refers to communication model of the wireless physical layer. Withsingle-channel routing protocols, all nodes communicate over the same wire-less channel. Multi-channel protocols on the other hand, combine channelassignment and routing functionality.(Feeney, 1999, p. 2)

22

2.3.2 Uniform vs. non-uniform

In uniform routing protocols all nodes are treated and behave in the samemanner, while non-uniform protocols imposes a form of structure on thenetwork, by partitioning nodes into different groups. For instance, it mayfeature ”special” nodes with extended responsibilities.(Feeney, 1999, p. 3)

2.3.3 Topology based vs. destination based

Topology based protocols maintain information about the network topology.The class of link state routing protocols fall into this category.

Destination based protocols, on the other hand, do not attempt to main-tain topology information. The classic distance vector routing protocols arethe best known examples of this.(Feeney, 1999, p. 4)

2.3.4 Proactive vs. reactive protocols

The difference between proactive and reactive routing protocols pertains towhen the routing protocols obtains the route to the destination node.

Proactive protocols attempt to maintain an updated routing table withroutes to all known destination nodes in the MANET. The nodes participat-ing in the network exchange routing information periodically, or in responseto topology changes, in order to keep an updated view of the network. Thishas the advantage of minimizing the delay during route look-up, at the ex-pense of increased network traffic to maintain the routing tables.

Reactive protocols only update the routing table in response to a routingrequest. This has the advantage of minimizing network traffic overhead, atthe expense of an increased delay during route look-up.(Feeney, 1999, p. 5)

2.4 Examples of MANET routing protocols

As an example, we present two MANET routing protocols: OLSR andAODV. These two protocols were chosen because they are two of the mostcommon routing protocols used in MANETs and MANET research today.In addition, they are based on very different routing strategies. While theyare both single-channel protocols, they differ in most other aspects.

23

Figure 1: OLSR: Example illustrating the use of MPRs

2.4.1 Optimized Link State Routing (OLSR)

Optimized Link State Routing (OLSR) is a proactive routing protocol formobile ad-hoc networks. It is based on the classic link state algorithm, buthas been tailored to suit the requirements of a MANET. It is therefore atopology based routing protocol. The protocol is optimal in terms of numberof hops.

In general, link state routing functions by each node periodically flood-ing the state of its links to the network. Every node stores the link stateinformation received from all nodes in the network. From this information,each node gets a global view of the network and independently builds up arouting table using shortest-path-first (Dijkstra’s algorithm).

OLSR includes an optimization to limit the overhead resulting from flood-ing link state information and other control traffic through the network. Thisoptimization is based on the idea of multi-point relays (MPRs). (Clausen andJacquet, 2003, p. 14) Every node selects a set of its neighbor nodes as multi-point relays. Only nodes selected as MPRs forward control traffic an othertraffic meant to be distributed to the entire network. The MPRs are alsoused during route calculation, where they are used to form routes from anode to any destination in the network. The number of MPRs per nodeshould be minimized, but any 2-hop neighbor must be covered by at leastone MPR. The use of MPRs is illustrated in Figure 1.

2.4.2 Ad-hoc On-demand Distance Vector Routing (AODV)

Ad-hoc On-Demand Distance Vector Routing (AODV)is, as its name sug-gests, a proactive routing protocol based on the distance vector routingparadigm. It is therefore also a destination based protocol. AODV is auniform protocol, as all nodes behave in the same manner, and are treated

24

equally by all other nodes.Upon transmission of a data packet, a Route Request (RREQ) is broad-

cast by the sending node. This RREQ is rebroadcast by any neighboringnodes until it eventually reaches the destination. A reverse path pointingtowards the source is set up by the nodes along the path to the destination.All routes are cached in a routing table for a certain amount of time to avoidexcessive flooding of Route Requests. (Hollick and Steinmetz, 2006)

25

3 Multimedia streaming

This chapter provides an overview of multimedia streaming and an introduc-tion to the concept of quality of service (QoS). We also give a short descrip-tion of some of the most common protocols used when streaming multimediadata, and discuss the issues related to multimedia streaming in mobile ad-hocnetworks.

3.1 Introduction

Multimedia streaming refers to the consumption of multimedia data while itis being delivered, e.g. listening to a sound clip while it is being downloaded.

A multimedia stream can be live or on demand. Live streaming refers tostreaming of data from a live event, where the media data is not stored fora period of time before it is distributed. Streaming is necessary to enableviewing of live multimedia content. On demand streaming refers to streamingof non-live media, where the media data is stored and transmitted to the userupon request.

The demand for multimedia content in general has steadily increased sincethe introduction of broadband Internet services for home customers, and asbandwidth continues to increase, so does the demand for multimedia content.During the last few years, downloading of songs and eventually movies, hasbecome commonplace.

Eventually, high bandwidth and low latency has made streaming of thesemedia feasible, and live multimedia applications such as Internet telephony,or Voice over IP (VoIP), has become popular through applications such asSkype. The introduction of 3G mobile telephone networks and growing con-cerns about global warming have also brought increased attention to videotelephony and video conferencing.

But the increased and demand for streaming multimedia content placesnew demands on the network infrastructure and end-systems. This is be-cause, in contrast to traditional content, multimedia streaming requires acertain Quality of Service (QoS). The concept of QoS is described further inthe next section.

3.2 Quality of Service (QoS) requirements

To properly support streaming of multimedia, parameters such as avail-able memory, processing power and bandwidth must be taken into account.Transmission of multimedia streams across channels that are unable to fulfill

26

the resource requirements, results in choppy playback and a bad user experi-ence. We say that multimedia streaming requires a certain Quality of Service(QoS).

This paper will use the following understanding of the meaning of theterm QoS, used in Steinmetz and Nahrstedt (2004, p. 16):

Quality of Service indicates the defined and controlling behavior ofa service expressed through quantitative measurable parameter(s)

According to Steinmetz and Nahrstedt (2004, pp. 14-15), the QoS require-ments of a multimedia application can be specified by these parameters:

• Throughput - Determined from the needed data rate and data unitsize

• Delay - Both local and end-to-end

• Jitter - The maximum allowed variance in end-to-end delay

• Reliability - Of transmissions and error detection and correction

The importance of each of these parameters depends on the nature of themultimedia application. For a telephone-conferencing application, end-to-end delay will be very important, as it is very difficult to have a conversationwith large delays. On the other hand, in a video-on-demand system, end-to-end delay will be almost insignificant, while throughput and jitter willbe the variables of most concern. In any case, meeting the QoS demandsof an application requires that QoS demands are met at each layer in everycomponent along the data path.

Most current computing and communication services are so-called ”besteffort services”, based on either no guarantees or partial guarantees (Stein-metz and Nahrstedt, 2004, p. 24). Implementation of multimedia streamingin such systems is done by over-provisioning. Where instead of allocatingscarce resources fairly among the different services, one makes sure that thereis always enough resources available for each service.

3.3 Transport protocols

The transport protocol is responsible for end-to-end data transmission. Thereare several transport protocols in use in the Internet today, and they eachhave their strengths and weaknesses. Not all are suited for streaming ofmultimedia data streaming.

27

TCP UDP RTP

Session-oriented Yes No NoReliable Yes No No

Sequence numbering Yes No YesTime-stamping No No Yes

Multicast No No YesDesigned for multimedia No No Yes

In widespread use Yes Yes Yes

Table 1: Comparison of transport protocols

According to Steinmetz and Nahrstedt (2004, p. 258), to support multi-media transmission, transport protocols need to provide the following func-tions:

• Timing information

• Semi-reliability

• Multicasting

• NAK-based error recovery mechanism

• Rate control

The two transport protocols in the Internet Protocol Suite, TransmissionControl Protocol (TCP) and User Datagram Protocol (UDP), are the twomost common transport protocols in the Internet today. However, both TCPand UDP lack important features required for multimedia streaming. We willtherefore also have a closer look at RTP, which is designed for streaming ofmultimedia data. The differences between the three protocols are summar-ized in Table 1.

3.3.1 Transmission Control Protocol (TCP)

TCP is the most widely used transport protocol in the Internet today. It isa connection-oriented protocol, that provides reliable delivery of a stream ofbytes. The data is guaranteed to be delivered in order.

This reliability makes it well suited for applications such as regular filetransfer, e-mail, etc. On the other hand, this also makes it unsuited forstreaming of multimedia data, as the failed delivery of a single packet canintroduce large delays in the reception of the media stream.

28

3.3.2 User Datagram Protocol (UDP)

UDP is a very simple protocol, that facilitates end-to-end delivery of a singlepacket of data, a so-called datagram. There is no connection setup priorto the data transmission. UDP provides no delivery guarantees, sequencenumbering or acknowledgements of received data packets.

3.3.3 Real-Time Transport Protocol (RTP)

RTP is an end-to-end protocol that provides network transport functionsto facilitate transmission of real-time data over multicast or unicast networkservices. It is very flexible, and can be used over any packet-based lower-layerprotocol, but UDP is the usual choice.

Components called translators and mixers can be used to change thecharacteristics of a media stream in order to satisfy heterogeneous require-ments. Through mixers, RTP supports mixing of multiple media streamsfrom several sources. Translators provide transformations such as formatand rate conversion.

RTP is accompanied by RTCP, which provides feedback to senders andreceivers about the on-going media stream. Media senders and receiversperiodically send RTCP packets to the same multicast group. These RTCPpackets contain information about the media stream. This information canbe used by the senders to adjust their sending behavior to adapt to changingnetwork conditions. (Steinmetz and Nahrstedt, 2004, ch. 6.5.2)

3.4 Control protocols

In addition to a protocol to transport the data from the source to the des-tination(s), we need a control protocol to set up, control and tear down thestreaming session. The control protocol is responsible for retrieving a descrip-tion of the offered multimedia stream(s), and the negotiation of transmissionparameters.

We will have a look at three of the most common control protocols in usethe Internet today: Hypertext Transfer Protocol (HTTP), Session InitiationProtocol (SIP) and Real-Time Streaming Protocol (RTSP). Table 2 containsa quick comparison of the protocols.

3.4.1 Hypertext Transfer Protocol (HTTP)

The HTTP protocol is most commonly used to transfer data on the WorldWide Web (WWW). While originally designed to transfer hypertext pages,it is now used for transmission of other media types as well. For instance, it

29

HTTP SIP RTSP

Designed for multimedia No Yes YesMulticast No Yes YesSimple Yes No Yes

Supports control of video stream No No YesIn widespread use Yes Yes Yes

Table 2: Comparison of control protocols

is often used to set up and tear down multimedia stream sessions. However,it lacks the features of the more specialized protocols, such as SIP and RTSP.

3.4.2 Session Initiation Protocol (SIP)

SIP is a signaling protocol for setting up, controlling and tearing down mediastreams. It is commonly used in Voice over IP (VoIP) and video conferencing.Although it is designed for a different purpose, it has many similarities tothe HTTP protocol.

3.4.3 Real-Time Streaming Protocol (RTSP)

RTSP is designed to control real-time multimedia streams over IP networks.It provides media player functionality, with functions to set up and terminatedata streams, and to start or stop playback or recording. It can also beextended for special requirements.

RTSP operates independently of the underlying transport protocol, andcan therefore be used both over UDP and TCP. As it is based on HTTP 1.1,it is similar to HTTP in several mechanisms. But one important difference isthat while HTTP is a stateless protocol, RTSP stores state information foreach session.

(Steinmetz and Nahrstedt, 2004, p. 308)

3.5 Multimedia streaming issues MANETs

As mentioned, the traditional method of obtaining acceptable quality of ser-vice in a wired network is over-provisioning. But the characteristics mobilead-hoc network communications makes this approach impossible.

There are several aspects of mobile ad-hoc networks that complicate theissue of multimedia streaming. The nodes in the network are wireless; they

30

have resource constraints; the nodes in the network are heterogeneous; andthe topology is constantly changing due to node mobility and the lack ofa fixed infrastructure. In addition, there is the possibility of sabotage bymalicious nodes. See Section 2.1 for more information about these issues.

3.5.1 Wireless medium

Operating on a wireless medium, MANETs are susceptible to the traditionalproblems with wireless communications.

Wireless transmissions are susceptible to various transmission errors, causedby interference from other electrical equipment, multi-path fading, or collid-ing transmissions by other nodes. Recovering from such errors may requireretransmission of data. This leads to an increase in delay and jitter, impact-ing the quality of the multimedia stream.

Each node has a limited transmission range. This range is dependentupon many factors, such as the wireless transmission protocol, antennae size,energy use, obstacles and weather conditions. This limited range means thatdata must be routed through several other nodes to reach the destination.Each hop adds processing delay and increases the possibility of introducinga bottleneck into the network path. For each hop, there is also the addedpossibility of a transmission error occurring, which adds delay and increasesjitter.

The wireless medium is a shared medium. While a wireless node is trans-mitting, all other nodes within range of the sender or within range of thereceiver must hold their transmissions. This raises some interesting questionsregarding streaming of data across multiple wireless hops. For instance, amultimedia stream from node A to node D, passing through nodes B andC, requires continuous transmission of packets from node A to node B, fromnode B to node C, and from node C to node D. But while e.g. node B istransmitting data to node C, both node A and node D must hold all theirtransmissions to avoid interfering with transmission between B and C. Thequestion is how this will affect delay and jitter for a multimedia stream.

Conditions affecting the quality of the wireless transmission may alsochange suddenly and unexpectedly. Thus, even if sender and receiver areable to agree on QoS parameter values that are optimal at one point time,those values may be sub-optimal only seconds later.

3.5.2 Resource constraints

The devices participating in a MANET will predominantly be small devices,which implies limited processing power, memory and storage capacity. Being

31

small mobile devices, they will normally be battery powered, which meansenergy consumption must be kept at a minimum.

Wireless communication will often mean limited bandwidth, and as men-tioned, the nature of wireless communications means that this bandwidth isshared by all devices in the surrounding area. Additionally, an increase innetwork traffic places additional load on the nodes in the network, which inturn increases energy consumption. It is therefore important to keep networktraffic overhead at a minimum.

3.5.3 Heterogeneity

While most or all of the nodes in a MANET will have some resource con-straints imposed on them, the capabilities and resources of each node canbe very varying. A laptop computer, for example, has several times the pro-cessing power and storage capacity of e.g. a cellular phone, while a cellularphone has communication capabilities usually not available to a computer.Link bandwidth may also vary dramatically depending on the type of wirelessinterface used for communication.

3.5.4 Lack of fixed infrastructure

The lack of a fixed infrastructure requires that nodes function as routers inthe network. This can introduce large bottlenecks, if a lot of responsibilityis assigned to a node with very limited resources.

3.5.5 Topology changes

The node mobility leads to continuous changes in topology, which meansthat routes may be formed and broken rapidly. When a route breaks, thediscovery of a new route will most likely introduce delays, which will affect thequality of an ongoing media stream. In addition, the topology change mayintroduce new bottleneck links in the network path, leading to a reductionin bandwidth. In the worst case, parts of the network may even separate insuch a way that there is no route from one part of the network to another.This is known as partitioning. If source and destination nodes wind up inseparate partitions, the media stream will be broken.

3.5.6 Malicious nodes

There is also a real concern that malicious nodes may delay or disrupt net-work traffic, by providing false routing information to neighboring nodes.One type of malicious nodes are so-called ”black holes”, that masquerade as

32

a bogus destination. Models show that using the AODV routing protocol,if only 0.8% of nodes are ”black holes”, the resulting packet loss is close to50%. If the fraction of ”black holes” increases to 4.0%, the resulting packetloss is close to 80% (Hollick and Steinmetz, 2006, slide 84). Such high packetlosses would adversely affect a multimedia stream.

3.5.7 Transport protocol design issues

Standard TCP has proved very inefficient in a MANET, due to its inabilityto distinguish between link failure and congestion. TCP flow control worksunder the assumption that packet loss is an indication of congestion, ratherthan link errors. In mobile ad-hoc networks however, link errors will happenmuch more frequently than in traditional, wired networks, due to factorssuch as mobility. Holland and Vaidya (1999) showed that as node speedapproaches 10 m/s, throughput quickly drops down to 50%. It is also notparticularly suited to multimedia streaming, as discussed above.

Because of the complex movement patterns that may arise in a MANET,it may be better to use a simpler protocol such as UDP, rather than tryingto do something clever. RTP may be a good compromise, as it is a relativelysimple protocol, which can use UDP for data transport, with added featuresfor streaming of real-time data.

33

Perspective Network level Media level Content level

Technical (QoS) Yes Yes YesUser (QoP) No Yes Yes

Table 3: Quality of Service perspectives

4 Measuring Quality of Service

. As mentioned, meeting the QoS demands of an application requires thatQoS demands are met at each layer in every component along the data path.Multimedia streaming sessions require constant monitoring to ensure thatQoS demands are met. Changes in network conditions or an increase inprocessing load may lead to broken QoS guarantees. Resource monitoring isthus an essential part of QoS enforcement (Steinmetz and Nahrstedt, 2004,p. 69).

(Wikstrand in Gulliver and Ghinea (2006)) proposes a model that se-gregates quality into three discrete levels: The network level, the media level,and the content level. The network level is concerned with all issues relatedto the flow of data in the network, e.g. bandwidth, delay, jitter and packetloss. The media level concerns quality issues related to the methods usedto transform the network data back into media information, such as videoand audio data. This includes parameters such as frame rate, bit rate, colordepth and compression methods. Finally, the content level concerns qualityfactors that influence the presentation and perception of media data to theuser.

Gulliver and Ghinea (2006) also proposes that the media level and thecontent level can be viewed from two perspectives: The technical perspective,and the user perspective. The technical perspective represents what is tra-ditionally viewed as Quality of Service (QoS), while a new term introducedby the authors, Quality of Perception (QoP), considers the user perspect-ive of the multimedia experience. See Table 3. Any results of a measure-ment greatly depend on where the measurements are performed (Gulliverand Ghinea, 2006). We will not concern ourselves with measurements at thecontent level, as this falls outside the scope of this thesis.

4.1 Measurements at the network level

When performing network QoS measurements, one needs to consider at whichlayer(s) to perform the measurements. In particular, whether to perform end-

34

to-end or hop-by-hop measurements.Hop-by-hop measurements allows greater insight into where along the

path any problems occur, but it also requires measurements to be performedat each node along the network path. Depending on the network, one maynot have the required privileges to perform such measurements. End-to-endmeasurements on the other hand, will only tell us when something is wrong,but not where along the network path any problems occur.

This means that to get a complete picture, one needs to perform meas-urements at as many layers as possible.

4.2 Link quality

Please bear in mind that since this thesis focuses on mobile ad-hoc networks,several of the link quality measurement methods discussed in this sectionapply only for wireless networks.

Also note that when discussing wireless networks, the term signal qualityis often used interchangeably with link quality. Even so, the only mention ofsignal quality in the IEEE 802.11 standard, is that

signal quality = PN code correlation strength

which is only defined when using DSSS modulation, and DSSS is only oneof several modulation schemes used in the physical layer of the 802.11abgstandards (Bardwell, 2004; IEEE-SA Standards Board, 1999).

To avoid confusion, we will avoid the use of the term ”signal quality”,and instead use the term ”link quality”, which is consistent with the termused in common wireless LAN tools, such as iwconfig on Linux.

4.2.1 Received Signal Strength Indicator (RSSI)

RSSI is the only measure of signal strength defined in the 802.11 standard(Bardwell, 2004, p. 8), and is designed for internal use in wireless interfaces.”The receive signal strength indicator (RSSI) is an optional parameter thathas a value of 0 through RSSI Max....RSSI is intended to be used in a relativemanner. Absolute accuracy of the RSSI reading is not specified.”(IEEE-SAStandards Board, 1999, p. 150) As pointed out in Bardwell (2004, p. 10),802.11 requires no specific relationship between RSSI and dBm or mW. Thismeans that vendors are free to, and certainly do, calculate the signal strengthfrom the RSSI in different ways.

35

4.2.2 Signal-to-Noise Ratio (SNR)

Another measure of link quality is the Signal-to-Noise-Ratio (SNR), which isdefined as the ratio between the power of a signal and the power of corruptingnoise. Because the range of the signals can be very dynamic, it is commonto express the SNR in terms of a logarithmic decibel scale.

SNR = 10 × log10

(

Psignal

Pnoise

)

4.2.3 Expected Transmission Count (ETX)

The Expected Transmission Count (ETX) denotes the expected number oftransmissions to successfully deliver a packet across a given 802.11 networklink. It is designed as a metric to used in routing protocols.

Let pf and pr be the probability of packet loss during packet transmissionover a given link in the forward and reverse direction, respectively. Then theprobability that the transmission is not successful is:

p = 1 − (1 − pf ) × (1 − pr)

The ETX is then defined as:

ETX =1

1 − p

(Das et al., 2007; Draves et al., 2004).

4.2.4 Expected Transmission Time (ETT)

Draves et al. (2004) suggests a new link quality metric, building on the ETX.The Expected Transmission Time (ETT) is a ”bandwidth-adjusted” ETX,where the ETX is multiplied by the link bandwidth, to obtain the time spenttransmitting the packet. As with ETX, it is designed to be used in routingprotocols.

ETT = ETX ×

S

B

36

4.3 Route quality

4.3.1 Expected Transmission Count (ETX)

The ETX of a route is just the sum of the ETX values of each individual linkalong the path. That is:

ETXpath =n

∑

i=1

ETXi

ETX is designed for a homogeneous environment, as it does not takebandwidth into account. It does not perform so well when the links havedifferent data rates, or the nodes have multiple radios.

(Draves et al., 2004, p. 115)

4.3.2 Weighted Cumulative ETT (WCETT)

To compute the quality of an entire route, Draves et al. (2004) introducesthe Weighted Cumulative ETT (WCETT). In its simplest form, WCETT isdefined as the sum of ETT values for all hops on the path:

WCETT =

n∑

i=1

ETTi

Draves et al. (2004) showed that WCETT significantly outperforms ETXin a heterogeneous environment, where the nodes have multiple radios or thelinks have different data rates.

4.3.3 Route stability

Route changes can have a major impact on the QoS, as it can introducesudden delays, packet loss and even disconnection. As route changes arequite common in mobile ad-hoc networks due to mobility, it must be takeninto consideration during QoS monitoring in MANETs. By choosing a stableroute, one can deliver more predicable QoS.

Routing stability can be analyzed using the metrics prevalence, persist-ence and route flapping :

37

Prevalence is the probability of observing a given route. For a given pairof source and destination, the prevalence, pd of the route d it can be computedby the formula

pd =kp

np

where kp is the number of times the dominant route was observed, and np isthe number of times the given route d was observed.

Persistence is the duration for which a route lasts before a route changeoccurs.

Route flap refers to a change in route.

(Ramachandran et al., 2007)

4.4 Measurements at the media level

Evaluation of media quality can be done through subjective or objectivemeasurements. Each approach has its own advantages and disadvantages.

4.4.1 Subjective vs. objective measurement methods

Subjective QoS measurements requires evaluation of the media quality byhumans. While it has proved to be the most reliable way of evaluating videovideo quality, subjective evaluation has a number of problems that limits itsusefulness. The most obvious is the amount of time and resources required,which limits the number of measurements that are possible to perform. Also,results of the experiments performed in (Zink, 2003, p. 61) contain some evid-ence that the content of a video clip influences the perceived quality duringsubjective quality measurements. However, further research is required todraw any conclusions.

Recommended reading is The ITU Radiocommunication Assembly (2002),which contains several specifications on how to conduct subjective video qual-ity measurements.

Objective video quality measurement methods can be categorized intothree different classes, based on the type of measurements they use:

Full reference Compare the measured video stream to the original stream.

Reduced/partial reference Uses only parts of the information containedin the original stream.

38

No reference Uses only data from the measured video stream, withoutcomparison to the original.

(Reibman et al., 2004, p. 328)

4.4.2 Mean Square Error (MSE)

The MSE is defined as:

MSE =1

N

N∑

i=1

(xi − yi)2

where N is the number of pixels in the image or video signal, and xi and yi

are the i-th pixels in the original and distorted signals, respectively (Wanget al., 2003, p. 1042). As it compares the signal to the original, the MSE isa full reference method.

4.4.3 Peak Signal-to-Noise Ratio (PSNR)

The Peak Signal-to-Noise Ratio (PSNR) estimates the quality of a recon-structed image compared to the original, and is the most commonly usedobjective measurement technique for video and image quality. It is a fullreference method, and is relatively easy to compute.

PSNR = 10 log10

MAX2

¯MSE

(Wang et al., 2003, p. 1042).

4.4.4 Relative Peak Signal-to-Noise Ratio (rPSNR)

Tao et al. (2005) proposes a new video quality metric based on the PSNRmetric, called relative PSNR (rPSNR). The rPSNR is calculated relative tothe quality of video transmitted over a network path that meets the desiredQoS requirements. This means that the video quality can be be estimatedusing only network statistics and some basic configuration parameters of thevideo application. This metric is thus a no reference method.

39

4.4.5 Summary of measurement methods

The majority of objective image quality assessment models are based on theMSE measure, or modifications of the MSE measure, such as the PSNR.Unfortunately, these methods have been proved to be unreliable measuresof perceived visual quality. Wang et al. (2003, p. 1043) points out thatthe fundamental problem with these methods, is the assumption that ”thatthe loss of perceptual quality is directly related to the visibility of the errorsignal”. Wang et al. (2004) suggests that object quality measures shouldconsider structural information, as the human visual system is more adaptedto extract structural information from a scene. Still, the traditional MSEand PSNR approaches remain popular, as they are easier to compute andhave a clear physical meanings (Wang et al., 2004).

Also, results of experiments performed by Zink (2003) suggest that thetraditional method of using average PSNR to measure objective quality isparticularly unsuited for layer-encoded video. The author proposes an al-ternative metric called the spectrum which is designed to better capture theproperties of layered video. This shows that the choice of video encodingmust be taken into account when deciding upon which method of objectivequality measurement to use.

4.5 QoS measurement in MANETs

The process of QoS monitoring can add overhead. Coupled with the limitedresources of a typical node in a MANET, this overhead may be signific-ant compared to the available resources and the resources demanded by themultimedia application. One must therefore take care so that the monitor-ing process itself is not responsible for lowering the QoS of the multimediaapplication. There will often be a trade-off between the accuracy of the mon-itoring, and the resource requirements of the monitoring. Due to the resourceconstraints in a MANET, it is imperative that all monitoring processes belightweight.

Another question is how often to perform the measurements. Resourcemonitoring can be performed proactively or on-demand. Proactive monitor-ing delivers measurements on a regular basis, while on-demand monitoringis initiated upon request from a user or a service. (Steinmetz and Nahrstedt,2004, p. 70) On-demand monitoring may lower the resource consumption andallow measurements to be performed at times when it is the least intrusive.On the other hand, proactive monitoring provides a steady stream of meas-urement data that might better capture resource consumption history whichcan be valuable during analysis and research.

40

Figure 2: The Nokia 770 Internet Tablet

CPU 252 MHz TI OMAP 1710Display 800x480x16 touch-screenConnectivity 802.11g WLAN, Bluetooth 1.2Memory 64 MB RAMStorage 128 MB flash, 64 MB RS-MMC (upgradable to 1 GB)Dimensions 14.1cm7.9cm1.9cmWeight 230 g

Table 4: Nokia 770 hardware specifications (maemo.org, g)

Part II

Experiments

5 The Nokia 770 Internet Tablet

This chapter gives an introduction to the Nokia 770 Internet Tablet and itscapabilities. We will also have a look at how to perform network measure-ments using the device.

5.1 About the device

The Nokia 770 Internet Tablet is a wireless, tablet computer designed toprovide Internet connectivity, such as web browsing and e-mail, as well asbasic media player functionality. It has a 800x480 touch-screen, capable ofdisplaying up to 65536 simultaneous colors. A summary of the Nokia 770’s

41

Figure 3: Main components of the Maemo platform (maemo.org, g)

hardware specifications is presented in Table 4 on the preceding page.The Nokia 770 runs an operating system called OS 2006, which is a

modified version of the Debian/Linux, with a graphical user interface. Thiswas the most attractive feature of the device, as it enabled us to use softwarewritten for the Linux platform to conduct our research.

The complete platform is an open source platform known as Maemo ver-sion 2. Figure 3 gives a quick overview of the components of the Maemoplatform.

(maemo.org, f; Nokia, 2006).

5.2 Basic software

An effort was made to use standard Linux software wherever possible. How-ever, the Nokia 770 comes with a very limited selection of software by de-fault. In addition, many of the common utilities that are included, are justBusyBox versions. BusyBox is a utility that combines many common UNIXutilities into a single executable. The versions of the included utilities areoften limited, but the included functionality works just as in their originalUNIX counterparts. We therefore had to install some additional software onour devices.

42

5.2.1 Operating system

The OS version preinstalled on our devices was 1.2006.26-8. Nokia has sincethen releases two updates to the 2006 version of the operating system, andthe latest version is 3.2006.49-2. 1

We used both version 1.2006 and 3.2006 in our experiments. More detailsare in the chapters dedicated to each set of experiments. For details onflashing the Nokia 770 with a new OS image, please see Appendix A.1.

Version 1.2006.26-8 features kernel version 2.6.16-omap1, CX3110x driverversion 0.8, and CX3110x firmware version 2.13.0.0.a.13.9. Version 3.2006.49-2 features kernel version 2.6.16.27-omap1, CX3110x driver version 0.8, andCX3110x firmware version 2.13.0.0.a.13.14.

The 1.1 and 1.2 versions of the CX3110x driver, which is used in thenewer Nokia N800 have been open source and released since the start of2007, but the 0.8.1 version used in OS 3.2006.49-2 for the Nokia 770 werenot open-sourced until 2007-10-29 (CX3110x Linux 2.6 driver).

5.2.2 xterm

The X Terminal Emulator is a port of the traditional xterm utility for theUNIX platform, and provided us with a graphical interface to the Nokia 770command line. We used the osso-xterm package version 0.13.mh24.

Access to a command line is necessary to perform many of the admin-istrative tasks required to set up the device with mobile ad-hoc networkingcapabilities. Also, most of the applications we used provided only a commandline interface. .

5.2.3 SSH2 server

To provide remote access to the Nokia devices, we installed OpenSSH version1:4.6p1-5.maemo1. This way, we could get a remote shell through SSH andperform file transfers to and from the devices through SFTP. Installationof an SSH server is also required to gain root access to the devices. SeeAppendix A.2 for details.

5.2.4 Wireless Tools

We installed version 28-1 of Wireless Tools for Linux to provide informationabout the physical and link layers. The Linux Wireless Tools are a set of

1Later, Nokia has also released an OS 2007 ”Hacker’s edition” for the 770, but it is notofficially supported, and was not stable enough for our use at the time.

43

utilities to configure the wireless networking interfaces in Linux, and theyare commonly included with most Linux distributions.

5.2.5 NTP client

We installed the package ntpdate to set the system clock of the Nokiasusing the Network Time Protocol (NTP). By synchronizing the clocks of ourmeasurement devices, we could properly compare the measurements fromeach device. Note that ntpdate does not compensate for clock drift, butonly performs a one-time synchronization with the NTP servers. Even so,the relatively short duration of our experiments should make this irrelevant.

5.2.6 OLSR daemon

We will be using version 0.4.10 of OLSRd for the Maemo platform. Thisis just a cross-compiled and packaged version of the OLSRd provided atthe official homepage www.olsr.org. OLSRd version 0.4.10 is RFC3626compliant, and implements all auxiliary functions specified in the RFC, withthe exception of Link Layer Notifications.

5.3 Network measurements

In this section, we will present methods for extracting information from thephysical and link layers of wireless interfaces on the Nokia 770. Most of thesemethods are common for all Linux distributions, however.

In order to keep things as simple as possible, we preferred software thatis available pre-packaged for the Nokia 770. Due to the resource constraintsimposed on us by the platform, the software to perform these measurementshad to be light-weight, both in size on disk, as well as in memory and CPUtime consumption. Of course, in order to perform analysis we had to be ableto log the output from these utilities, and the output format should be easyto parse.

5.3.1 The proc filesystem (procfs)

The proc filesystem, or process information pseudo-filesystem, is a pseudo-filesystem that is used as an interface to kernel data structures. It is com-monly mounted at /proc. (Linux Programmer’s Manual, b)

The proc filesystem enables common tools that need access to kernelstructures, such as ps, top, lspci, free, etc., to be implemented entirely inuser space.

44

Inter-| Receive |

face |bytes packets errs drop fifo frame compressed multicast|

lo: 5507 67 0 0 0 0 0 0

eth0:1489016188 2541166 0 0 0 0 0 131

eth1: 73997 0 0 798 0 0 0 0

Transmit

bytes packets errs drop fifo colls carrier compressed

5507 67 0 0 0 0 0 0

56984652 598733 0 0 0 0 0 0

326214 0 0 0 0 0 0 0

Figure 4: Sample output: /proc/net/dev

eth1 Link encap:Ethernet HWaddr 00:13:02:CA:01:43

inet addr:10.0.0.1 Bcast:10.255.255.255 Mask:255.0.0.0

inet6 addr: fe80::213:2ff:feca:143/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:4 errors:0 dropped:142 overruns:0 frame:0

TX packets:939 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:256 (256.0 b) TX bytes:34417 (33.6 KiB)

Interrupt:17 Base address:0xc000 Memory:ecfff000-ecffffff

Figure 5: Sample output: ifconfig.

Most of the network relevant information is found in the directories/proc/net/ and /proc/sys/net/. While the exact number depends on theLinux kernel version, modules, compilation options, etc., these directoriescontain about 500 files with information about the networking stack.

For our purposes, however, we will focus on the files /proc/net/dev

and /proc/net/wireless, which provide access to kernel data structurescommon for all network interfaces and data structures specific to wirelessnetwork interfaces, respectively. While the information in these files can beread directly, a better way is to use the utilities ifconfig and iwconfig,which are presented below.

5.3.2 ifconfig

ifconfig is a standard UNIX utility used to configure the network interfacesof the system. It also provides information and statistics for each interface.The interface statistics are read from /proc/net/dev and presented in amore human-readable format.

From the sample output in Figure 5, we see that ifconfig provides thefollowing information:

45

Link encap The type of network link.HWaddr The MAC address of the interface.inet addr The IP address associated with the interface.Bcast The broadcast address associated with the interface.Mask The network mask of the interface.MTU The maximum transfer unit set for the interface.RX packets Total number of packets received by the interface.errors Number of packets received in error by the interface.dropped Number of packets dropped by the interface.overruns Number of packets dropped due to overrun.frame Number of packets dropped due to frame errors.TX packets Total number of packets transmitted.errors Number of transmission errors.dropped Number of transmitted packets dropped.overruns Number of transmission errors due to overrun.carrier Number of transmission errors due to loss of carrier.collisions Number of transmission errors due to collisions.txqueuelen The size of the transmission queue.RX bytes Number of bytes received in total.TX bytes Number of bytes transmitted in total.

One problem with these statistics, is that there appears to be no easyway of resetting these counters. Resetting the counters requires unloadingthe driver module for the network interface - simply reconnecting the linkwill not help.

5.3.3 netstat

netstat is a utility for printing information about the Linux networkingsubsystems, such as current network connections, routing tables, interfacestatistics, and more (Eckenfels, 2001). Normally, running netstat withthe -i parameter, will output the same statistics from /proc/net/dev asifconfig -s, but the netstat command on the Nokia 770 does not supportthis parameter.

5.3.4 Linux Wireless Tools

The Linux Wireless Tools are tools to manipulate the Linux Wireless Ex-tensions. There are several other tools for manipulation the wireless con-figuration through the Wireless Extensions API, but the Wireless Tools are

46

the reference implementation, and are usually installed by default on mostcommon Linux distributions.

It is important to note that the features provided by the Wireless Toolsthrough the Wireless Extensions, depend on the drivers for the wireless in-terface. Thus, not all statistics or configuration options are available on allsystems. (Tourrilhes, 2007)

Wireless Tools are not supplied with the Nokia 770, but must be installedfrom third-party repositories. The package comprises the following tools:

iwconfig reports measured signal level, noise level and link quality as wellas transfer statistics for each wireless interface. These values are read from/proc/net/wireless and presented in a more human-readable format. SeeFigure 6 on the next page for a sample of the output from /proc/net/wireless.Compare this to the sample output from iwconfig, in Figure 7 on page 49.

Tourrilhes (2006) gives the following description of the parameters avail-able for inspection using iwconfig:

47

Inter-| sta-| Quality | Discarded packets | Missed | WE

face | tus | link level noise | nwid crypt frag retry misc | beacon | 21

eth1: 0000 67. 233. 233. 0 0 0 0 13 0

Figure 6: Sample output from /proc/net/wireless on the Dell XPS m1210.

ESSID The Extended service set identifier (i.e. the ”name”) of the wireless network.Mode The transmission mode of the wireless interface. In an ad-hoc network, this

is ”Ad-Hoc”.Frequency The frequency band used by the wireless network with which the interface is

currently associated.Bit Rate The current bit rate used by the wireless interface.Tx-Power The current transmission power.Retry limit The retry limit of the MAC.RTS thr The size of the smallest packet for which the node sends RTS.Fragment thr The fragmentation threshold. IP packets larger than this will be split into

several fragments before sending.Access Point/Cell An address equal to 00:00:00:00:00:00 means that the card failed to asso-

ciate with an Access Point (most likely a configuration issue). The Access

Point parameter will be shown as Cell in ad-hoc mode (for obvious reasons),but otherwise works the same.

Link Quality Overall quality of the link. May be based on the level of contention or in-terference, the bit or frame error rate, how good the received signal is, sometiming synchronization, or other hardware metric. This is an aggregate valueand depends totally on the driver and hardware.

Signal level Received signal strength (RSSI - how strong the received signal is). May bearbitrary units, or dBm, iwconfig uses drive meta information to interpret theraw value given by /proc/net/wireless and display the proper unit or max-imum value (using 8-bit arithmetic). In Ad-Hoc mode, this may be undefinedand you should use iwspy.

Noise level Background noise level (when no packet is transmitted). Similar commentsas for Signal level.

Rx invalid nwid Number of packets received with a different NWID or ESSID. Used to de-tect configuration problems or adjacent network existence (on the same fre-quency).

Rx invalid crypt Number of packets that the hardware was unable to decrypt. This can beused to detect invalid encryption settings.

Rx invalid frag Number of packets for which the hardware was not able to properly re-assemble the link layer fragments (most likely one was missing).

Tx excessive retries Number of packets that the hardware failed to deliver. Most MAC protocolswill retry the packet a number of times before giving up.

Invalid misc Other packets lost in relation with specific wireless operations.Missed beacon Number of missed beacons from the Cell or the Access Point we have missed.

Beacons are sent at regular intervals to maintain the cell coordination, failureto receive them usually indicates that the card is out of range.

As mentioned earlier, all the parameters and statistics are device depend-ent, meaning that usually only a subset of them will be provided, dependingon the hardware and driver support (Tourrilhes, 2006). As an example, com-pare the output from iwconfig on a the Nokia 770 in Figure 8 to the outputfrom iwconfig on the Dell laptop in Figure 7 on the next page.

Some of the parameters have two modes: Fixed mode and automaticmode. If the value of a parameter is prefixed by a ”=”, it means that the

48

eth1 IEEE 802.11b ESSID:"unikum"

Mode:Ad-Hoc Frequency:2.412 GHz Cell: 5A:5C:CD:1D:BA:17

Bit Rate:2 Mb/s Tx-Power:15 dBm

Retry limit:15 RTS thr:off Fragment thr:off

Power Management:off

Link Quality=67/100 Signal level=-31 dBm Noise level=-32 dBm

Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0

Tx excessive retries:0 Invalid misc:143 Missed beacon:0

Figure 7: Sample output: iwconfig on the Dell XPS m1210.

wlan0 IEEE 802.11b ESSID:"unikum"

Mode:Ad-Hoc Frequency:2.417 GHz Cell: 22:61:B9:D0:DB:2E

Bit Rate=11 Mb/s Tx-Power=19 dBm Sensitivity=0/200

RTS thr=2347 B Fragment thr=2346 B

Encryption key:off

Power Management:off

Link Quality=69/0 Signal level=-26 dBm Noise level=-95 dBm

Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0

Tx excessive retries:114 Invalid misc:0 Missed beacon:0

Figure 8: Sample output: iwconfig on the Nokia 770.

value is fixed and forced to that value. If the value is prefixed by a ”:”, theparameter is in automatic mode, and the current value is shown, but maychange. (Tourrilhes, 2006)

Note that value of both Signal level and Noise level may be un-defined when in ad-hoc mode. To monitor the signal level and noise levels ofthe nodes of an ad-hoc network, one should use iwspy instead (Tourrilhes,2006). Unfortunately, the use of iwspy appears to be unsupported by thedevice driver on the Nokia 770 (see below). Still, iwconfig seems to reportthe correct value as long as the ad-hoc network consists of only two nodes.

iwgetid Depending on the supplied argument, iwgetid prints either thecurrent access point address, channel, frequency, mode or protocol name.

All the information reported is also reported by iwconfig, but iwgetidis designed to be easier to use for scripting purposes. (Linux Programmer’sManual, a).

iwlist delivers more detailed wireless information from a wireless interface.In particular, it supports scanning the wireless medium for wireless networks,with detailed information on the parameters of each network (see Figure 9 onthe following page).

During our trials, the scanning facility has been very unstable on theNokia 770. Using it will frequently result in disconnection from the wireless

49

eth1 Scan completed :

Cell 01 - Address: 02:13:02:BA:EB:8F

ESSID:"unikum"

Protocol:IEEE 802.11g

Mode:Ad-Hoc

Channel:3

Encryption key:off

Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s

9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s

48 Mb/s; 54 Mb/s

Quality=96/100 Signal level=-31 dBm Noise level=-31 dBm

Extra: Last beacon: 132ms ago

Figure 9: Sample output: iwlist’s scan command.

eth1 Statistics collected:

00:14:A7:FA:85:34 : Quality:232/100 Signal level:-24 dBm Noise level:-24 dBm

00:19:4F:9E:B7:ED : Quality:240/100 Signal level:-16 dBm Noise level:-16 dBm

Link/Cell/AP : Quality=98/100 Signal level=-26 dBm Noise level=-26 dBm

Typical/Reference : Quality:70 Signal level:0 Noise level:0

Figure 10: Sample output: iwspy on the Dell XPS m1210.

network and/or the device crashing. This happens for OS 1.2006 as well asOS 3.2006.

iwspy is used to monitor a list of up to 8 addresses (Linux Programmer’sManual, c) in a wireless network. For each of these addresses, it monitorslink quality, signal strength and noise level. See Figure 10 for a sample ofthe output from this command.

Unfortunately, the features required by iwspy appears to be unsupportedby the Nokia 770 WLAN driver. Running iwspy returns with the message"Interface doesn’t support wireless statistic collection". Thismeans that we have not been able to take advantage of this feature in ourexperiments.

5.3.5 The sys filesystem (sysfs)

Beginning with kernel version 2.6, much of the non-process related inform-ation has been moved from the proc-filesystem to a new pseudo-filesystemcalled sysfs, commonly mounted at /sys. Among other things, it is usedby udev to handle device management.

The file structure of sysfs reflects the physical devices and device driversinstalled on the computer, and as such, the contents of /sys will vary de-pending on the hardware configuration.

50

Figure 11: The Nokia 770 connection manager

On the Nokia 770, information about the wireless network interface islocated in the directory /sys/devices/platform/wlan-omap. However, thefolder does not seem to include much interesting information beside whatis already available in the proc filesystem. The data in the files rssi,signal quality contain the values for signal level and link quality, respect-ively, and are both the same values found in the proc filesystem, and thusthe same as those reported by iwconfig. On the other hand, unlike thevariable /proc/net/wireless, these variables are hardware dependant, andthus specific to the Nokia 770 WLAN adapter and device drivers.

The only variables of interest that are not accessible through iwconfig

are cal iq, cal output limits, cal pa curve data and cal rssi, whichseem to contain tuning/calibration values for the various parameters. E.g.cal rssi contains tuning values for the RSSI (see Section 4.2.1.

But without information on how to interpret the values, it is very hardto take advantage of the information contained in these variables. A requestwas sent to Nokia R&D, asking if they could provide some help in this regard,but we did not receive an answer. This unfortunately means that we havenot been able to take any of these values into consideration.

5.3.6 Connection Manager

The Connection Manager is the standard GUI tool for setting up wirelessconnections on the Nokia 770. When connected, it provides a graphical rep-resentation of the wireless link quality. However, this representation deviatesfrom the intuitive interpretation of the link quality reported by iwconfig.Even when the link quality reported by iwconfig varies between 80 and 50,Connection Manager will still report the link to be of excellent quality, with4 green bars. Figure 11 shows link quality reported by Connection Managerwhile iwconfig reported a link quality of 53/0.

Our first idea was to examine the source code for Connection Manager,

51

Figure 12: Licences of Nokia 770 / Maemo 2.2 connectivity components(maemo.org, e).

in order to see how the link quality values were obtained and, if they val-ues obtained were the same as the ones reported by iwconfig, how theywere converted into the graphical representation used by Connection Man-ager. Unfortunately, Connection Manager turns out to be a closed-sourcecomponent (in maemo connectivity UI ), as demonstrated by Figure 12.

We therefore had to look for other solutions. By monitoring DBUS mes-sages using dbus-monitor, we hoped to intercept the link quality readingsfrom Connection Manager. This is possible with Network Manager, which isa connection manager commonly used on regular Linux installs. However, itappears that the Nokia 770 Connection Manager only sends messages dur-ing connection and disconnection. We then investigated the possibility ofretrieving the link quality values by sending DBUS messages to the Con-nection Manager using the dbus-send utility, but the values that then werereturned, were incomprehensible.

The result was that we had to abandon the hope of retrieving link qual-ity readings from Connection Manager. Nonetheless, the results from thewireless experiment turned out to at least shed some light on the possible in-terpretation of the link quality values read from iwconfig. This is discussedfurther in Section 6.

5.3.7 OLSR daemon

The OLSR daemon offers an implementation of an ETX-like metric. Inthis implementation, the link quality between a node and its neighbor isdefined as the probability of a successful packet transmission the node to itsneighbor. Conversely, the neighbor link quality on the other hand, is definedas the probability of a successful packet transmission from the neighbor tothe node. OLSR does not support computing the ETX for a complete path.

52

*** olsr.org - 0.4.10 (Feb 16 2007) ***

--- 16:54:23.75 ------------------------------------------------- DIJKSTRA

10.0.0.2:1.00 (one-hop)

10.0.0.3:1.00 (one-hop)

--- 16:54:23.75 ---------------------------------------------------- LINKS

IP address hyst LQ lost total NLQ ETX

10.0.0.3 0.000 1.000 0 10 1.000 1.00

10.0.0.2 0.000 1.000 0 10 1.000 1.00

--- 16:54:23.75 ------------------------------------------------ NEIGHBORS

IP address LQ NLQ SYM MPR MPRS will

10.0.0.2 1.000 1.000 YES NO NO 3

10.0.0.3 1.000 1.000 YES NO NO 3

--- 16:54:23.75 ------------------------------------------------- TOPOLOGY

Source IP addr Dest IP addr LQ ILQ ETX

10.0.0.2 10.0.0.1 1.000 1.000 1.00

10.0.0.2 10.0.0.3 1.000 1.000 1.00

10.0.0.3 10.0.0.1 1.000 1.000 1.00

10.0.0.3 10.0.0.2 1.000 1.000 1.00

Figure 13: Sample output: OLSR daemon olsrd at debugging level 2

It is worth noting that enabling these Link Quality Extensions breaksRFC3626 compatibility, as the OLSR daemon distributes link quality inform-ation by modifying the HELLO and TC messages of the OLSR protocol.

(Lopatic, 2004)

53

DIJKSTRA This table displays the best routes for each destination that OLSRd knowsabout. The leftmost IP address is the destination, and the the remainingIP addresses on each line are the addresses of the nodes on the route to thedestination.

LINKS This

IP address The IP address of the interface over which we have contact withthe neighbor.

hyst The current hysteresis value for the link. Hysteresis is not used whenLink Quality Extensions are enabled.

LQ The link quality value for this link determined at our end.

lost The number of lost packets within the current link quality window size.

total The total number of packets received. The value is capped at the linkquality window size.

NLQ The neighbor link quality value for this link.

ETX This is the expected transmission count for this link.

NEIGHBORS

IP address The IP address of the main interface of this neighbor.

LQ The link quality value of the best link we have to this neighbor.

NLQ The neighbor link quality value of the best link we have to this neigh-bor.

SYM Shows whether or not the link to this neighbor is considered symmet-ric.

MPR Indicates if this neighbor has been selected to act as an MPR for thisnode.

MPRS Indicates if the neighboring node has selected this node to act as anMPR for it.

will Shows the neighbor’s willingness.

TOPOLOGY This table shows topology information for the entire MANET.

Source IP addr The node that reports a link.

Dest IP addr The node to which the source node reports a link.

LQ The quality of the link as determined by the source node.

ILQ The quality of the link as determined by the destination node.

ETX The expected transmission count for this link.

54

Figure 14: Nokia 770 multimedia architecture. (maemo.org, f)

5.4 The Nokia 770 multimedia architecture

Because of the GStreamer support of the multimedia architecture (Figure14), the Nokia 770 comes with out-of-the-box support for a number of mediaformats.

5.4.1 GStreamer

GStreamer is the core of the Nokia 770 multimedia architecture. It is anopen source multimedia framework that supports ”construction of graphsof media- handling components”. The multimedia data passes through apipeline of media-handling components, each responsible for a small part ofthe processing required to read the media from an input and send it to thedesired output in the desired format. By building on the GStreamer frame-work, multimedia applications can thus take advantage of advances in codecand filter technology transparently. (GStreamer: open source multimedia

55

MIME type Extension Format Application

video/3gpp *.3gp 3GPP video, MPEG4 Visual Simple ProfileLevel 2, H.263 profile 0 level 10, 3GPP demuxbased on spec 3GPP TS 26.244 v6.0.0 (2004-03): Basic profile, excluding timed text, audio-only clips not supported

Video Player

video/3gpp *.3gpp 3GPP video, MPEG4 Visual Simple ProfileLevel 2, H.263 profile 0 level 10, 3GPP demuxbased on spec 3GPP TS 26.244 v6.0.0 (2004-03): Basic profile, excluding timed text, audio-only clips not supported

Video Player

video/mpeg *.mpe MPEG-1 Video, up to CIF resolution @30 fps Video Playervideo/mpeg *.mpeg MPEG-1 Video, up to CIF resolution @30 fps Video Playervideo/mpeg *.mpg MPEG-1 Video, up to CIF resolution @30 fps Video Player

video/x-msvideo *.avi AVI file format (containing MPEG4 VisualSimple Profile Level 2/H.263 profile 0 level 10,MPEG audio layer III)

Video Player

video/x-real *.ra RealAudio 8,9,10 Video Playervideo/x-real *.ram RealNetworks Metafile Video Playervideo/x-real *.rm RealAudio, RealVideo 8,9,10 (QCIF @15 fps) Video Playervideo/x-real *.rmj Real Jukebox file Video Playervideo/x-real *.rmvb RealVideo variable bitrate Video Playervideo/x-real *.rpm RealNetworks Metafile Video Playervideo/x-real *.rv RealVideo 8,9,10 (QCIF @15 fps) Video Playervideo/x-real *.sdp Session Description Protocol File Video Player

Table 5: File formats with built-in support on the Nokia 770

framework)The 770 come with GStreamer version 0.10 installed, together with some

device specific elements to access the DSP. The video and audio formatssupported out-of-the box by the Nokia 770 are listed in Table 5.

5.4.2 The digital signal processor (DSP)

The Nokia 770 does not have a separate audio card. Instead, audio streamsare by a digital signal processor (DSP). In addition to basic PCM, the DSPcan also handle encoded audio streams, such as MP3. This has the advantageof saves valuable clock cycles in the ARM processor core, which means thathigher quality videos can be played. The DSP can assist in the decoding ofsome video formats, listed in Table 7 on the next page.

The decoding of multimedia data using DSP requires special support bythe decoder, however. In the Nokia 770, the decoder support is handledthrough the GStreamer plug-ins. See Table 6 on the following page for a listof supported formats.

We also note that the available DSP tasks can also be read from sysfs,in the directory /sys/devices/platform/dsp. See Figure 15. For moreinformation about sysfs, please see Section 5.3.5.

56

Format Decoded with

PCM N/A Raw PCM audioMP2 DSP MPEG audio layer-2MP3 DSP MPEG audio layer-3AAC DSP Advanced Audio Coding, only LC

and LTP profiles supportedAMR-NB DSP Adaptive Multi-Rate narrowbandAMR-WB DSP Adaptive Multi-Rate wideband

IMA ADPCM CPU Adaptive Differential Pulse CodeModulation

G.711 a-law DSP ITU-T standard for audio com-panding

G.711 mu-law DSP ITU-T standard for audio com-panding

WAV - MP3 DSP MP3 audio in WAV containerWAV - PCM DSP PCM audio in WAV containerRM - RA10 DSP RealAudio in RealMedia con-

tainer. Uses closed source soft-ware, no support in GStreamer.

Table 6: Audio formats with built-in support on the Nokia 770 (maemo.org,b)

Container Video format Audio format Video decoded with

MPG MPEG1 MP2 CPUAVI MPEG4 MP3 DSPAVI H263 MP3 DSP3GP MPEG4 AAC DSP3GP MPEG4 AMR-NB DSP3GP MPEG4 AMR-WB DSP3GP H263 AAC DSP3GP H263 AMR-NB DSP3GP H263 AMR-WB DSPRM RV10 RA10 CPU

Table 7: Supported audio/video format combinations (maemo.org, b)

57

Nokia770-01:~# cat /sys/devices/platform/dsp/*/devname

pcm0

pcm1

videofb

mp2dec

pcm_rec

aep

g711_enc

g711_dec

ilbc_enc

ilbc_dec

avsync

audiopp

pcm2

aacdec

amrnb

amrwb

mp3dec

mpeg4dec

Figure 15: Output of DSP tasks from sysfs

5.4.3 Video streaming

A lot of information is available on the Internet on streaming multimedia tothe Nokia 770. There are several approaches to accomplish this, dependingon what kind of media streams one wants to set up. Examples can be foundin Ikke’s Blog; Brown (2007); maemo.org (i).

On the other hand, very little has been written on streaming video fromthe Nokia 770. Lifton (2007) has an article on how to stream live audio andvideo from a camera connected to a Nokia N800 to Second Life. However,the approach depends on an external QuickTime streaming server to actuallydistribute the stream to Second Life and other interested viewers. As we areconcentrating on setting up video streaming in a MANET, our solution cannot be dependant upon existing infrastructure. We will therefore have tolook for alternative solutions that enable us to stream video from a singleNokia 770.

Both maemo.org (j) and maemo.org (d) contains useful information onencoding video for optimal playback on the Nokia 770 (as well as for theN800). They state the standard Nokia 770 Video Player has some limitationsdue to the internal hardware of the device:

In particular:

• The maximum bandwidth the Nokia 770 can handle properly is about352 × 288 × 30 = 1.52 megapixels per second, depending on the com-plexity of the action.

58

• The 770 is not capable of decoding video with bandwidth greater than800 Kbps.

• It can only decode video where horizontal and vertical dimensions aremultiples of 16.

These limitations have spurred the development of several tools to convertvideos to Nokia 770 compatible formats. See Section 5.7 for more informationabout such tools.

maemo.org (j) mentions that ”MPlayer can be used to overcome some ofthe default player limitations and play full frame rate video.”, but from thelist above, it is not entirely clear which limitations are due to the internalhardware, and which are due to the video playing software, but the onlylimitations mentioned by MPlayer for Maemo relates to the hardware pixeldoubling capabilities of the Nokia 770.

The display on the Nokia 700 has a resolution of 800x480 pixels. Whenrunning in full screen mode, video is played at the native resolution ofMaemo, which is 800x480 pixels. When running in windowed mode, thevideo is played at a resolution of 600x360 pixels. Both display modes are15:9 format, as opposed to the wide-screen broadcasting standard of 16:9.As mentioned, the Nokia 770 supports hardware pixel doubling, and theMPlayer documentation recommends a video resolution of 400x224 (16:9),400x240 (15:9) or 320x240 (4:3) to make the most efficient use of these cap-abilities, resulting in improved image quality, as well as reduced CPU loadand battery consumption (MPlayer for Maemo). In addition, maemo.org (d)adds 352x288 (CIF), 352x208, 240x144 (15:9) and 176x144 (QCIF) to thelist of recommended resolutions.

5.5 Video streaming software

For the purpose of constructing a video streaming solution we required threemain pieces of software:

• Streaming server

• Multimedia player

• Monitoring software

On the server side, we required a streaming server that supports stream-ing of video using the RTP protocol.On the client side, we required videoplaying software capable of playing streaming video through the RTP pro-tocol. Due to the resource constraints of the Nokia 770, all the software

59

should be as light-weight as possible. To allow for scripting of test-cases,the software should allow configuration through the command line. In bothcases we preferred software that was available pre-packaged for the Nokia770, to avoid issues with cross-compilation. The availability of debugginginformation during playback of video streams is also important, particularlyon client side, as this is where the effect of the network conditions can beobserved.

5.5.1 gst-launch (GStreamer)

The GStreamer package (see Section 5.4.1 for more information about GStreamer)includes the tool gst-launch, which can be used to create such pipelines fromthe command line. Although this tool is not meant to be used for productionsystems, it can be used to easily create pipelines for testing purposes.

On the Nokia 770, gst-launch is contained in the gst-tools software.The Farsight RTP plug-in version 0.1, which provides RTP support forGStreamer, as well as decoders for a wide variety of formats, was installedby default.

Homepage: http://gstreamer.freedesktop.org/

5.5.2 Flumotion

Developed with the backing of Fluendo, Flumotion is an open source stream-ing server. While it is written in Python, the development is focused on theLinux platform, and uses the GStreamer framework for all its low-level func-tionality.

No packaged version of Flumotion was available for the Nokia 770. In ad-dition, the build procedure when compiling from source is very complicated,and doing so is strongly discouraged by the developers.

Homepage: http://www.flumotion.net

5.5.3 Helix DNA Server

The Helix DNA Server is an open source streaming server from the HelixCommunity, founded by Real.

The only supported media formats in addition to the RealAudio andRealVideo formats (*.rm, *.ra, *.rv), is MP3 audio. Support for additionalformats requires purchase of the commercial Helix Server. The Helix DNAServer supports RTSP/RTP streaming, as well as HTTP and TCP, UDPunicast and multicast.

60

No package exists for the Nokia 770, and the impressions is also that itis too big and and resource hungry for our needs.

Homepage: https://helix-server.helixcommunity.org

5.5.4 Icecast

Icecast is a free and open source streaming server, available for Linux andWindows. It started out as a audio streaming server, but starting withversion 2.2.0, Icecast supports streaming of video via the Theora format,an open and free video codec. Both Icecast and Theora are developed bythe Xiph.org Foundation, also known for the FLAC and Ogg Vorbis audiocodecs.

(Ikke’s Blog) describes how to set up Icecast to stream sound to the Nokia770, but using a desktop computer as a server. We were not able to find aversion of Icecast packaged for the Nokia 770.

Homepage: http://www.icecast.org

5.5.5 FFmpeg

The FFmpeg project is is a part of the MPlayer project, and is made up ofseveral components:

ffmpeg A command line tool for converting videos.

ffserver A multimedia streaming server.

ffplay A simple media player based on SDL and the FFmpeg libraries.

libavcodec A library of all the FFmpeg audio/video encoders and decoders.

libavformat A library of parsers and generators for audio/video formats.

Several other projects are based on, or incorporate a significant amountof work from FFmpeg. Among these are most of the other video playersmentioned in this section.

The FFmpeg package contains a simple streaming server, named FF-server. It also turns out that FFmpeg can also be set up to send its outputto an RTP stream. This way, it can actually function as a simple streamingserver (even simpler than FFserver).

Unfortunately, even after several hours of searching on the Internet, wewere not able to locate a pre-packaged version of FFserver for the Nokia 770.

61

However, compiling from source is encouraged by the developers, and thebuild process is very simple, in stark contrast to several of the other projectsmentioned here, such as VLC and Flumotion. See Section 7.2.1 for moreinformation.

Homepage: http://ffmpeg.mplayerhq.hu.

5.5.6 VideoLAN

The VideoLAN project produces open-source video software. It is mostknown for its cross-platform video player, the VideoLAN Client (VLC), andperhaps also for the library libdvdcss, which allows reading of encryptedDVDs.

VideoLAN Client (VLC) The VideoLAN Client is a free, cross-platformmedia player available for Linux, Windows and MacOS X, released under theGPL (GNU Public Licence) version 2. It is extremely feature rich, and canplay a wide array of media formats. In addition to being a media player,it includes streaming server functionality, with the ability to do on-the-flytranscoding of the media stream. Streams can be set up both using a graph-ical user interface, as well as the command line.

Unfortunately, all the features comes a price. VLC is a rather largeapplication, both on disk and in memory. There have been efforts to portVLC to the Maemo platform (Torra, 2006), but we were not able to locate aversion packaged for the Nokia 770.

VideoLAN server (VLS) The VideoLAN Server is a legacy streamingserver, which has now been mostly replaced by VLC. In fact, most of thefunctionality provided by VLS can be found in VLC, and the VideoLANteam recommends using VLC instead of VLS. Yet, its much smaller size andlower complexity, makes it interesting for our use.

Whereas VLC supports streaming from practically any imaginable source,VLS is limited to streaming from MPEG-1, MPEG-2 and MPEG-4 files,DVDs, MPEG encoding card and DV camcorders.

Figure 16 gives an overview of the capabilities of the VideoLAN streamingsolution.

Homepage: http://www.videolan.org

62

Figure 16: Overview of the VideoLAN streaming solution (Source:www.videolan.org)

5.5.7 Video Player

The Nokia 770 comes with a simple video player pre-installed, aptly namedVideo Player. It is based on the GStreamer framework, and can play localvideo files as well as streaming video from the network. However, experiencehas shown that it is very picky in terms of which media streams it will play.We were also not able to make it play videos that did not contain an audiostream. Also, it only supports stream setup through HTTP, not RTSP.

5.5.8 MPlayer

MPlayer is a video player that is widely renowned in the open source com-munity. It has been ported to a multitude of platforms, including Maemo.It has a pluggable architecture, and supports an impressive number of inputformats and audio and video codecs.

The Nokia 770 version of MPlayer includes a special GStreamer soundoutput module, which enables it to use the DSP core to decode MP2 andMP3 audio. This makes it possible to play videos of higher bit rate, as theARM processor core does not have to decode audio data. It also includesa video output driver developed specifically for the Nokia 770. This driveruses direct framebuffer access to benefit from the hardware accelerated YUVsupport. (MPlayer for Maemo)

63

MPlayer is very configurable, and allows the output of verbose debug-ging information from playback and streaming sessions. It even has a ”slavemode”, which allows remote control of the player.

Ideally for us, such a feature rich player would include some streamingserver functionality, as VideoLAN does. Alas, there does not seem to be anyway of hosting a streaming session using MPlayer. The lack of streamingserver functionality is confirmed in a response to a question regarding thison the MPlayer mailing list.

Homepage: http://www.mplayerhq.hu

5.5.9 Xine

Together with MPlayer, Xine is the most well-known media player in theopen source community. It is licenced under the GPL 2, and can play backmost common, and uncommon, multimedia formats available.

Xine is designed to be portable, and supports a range of platforms, in-cluding Linux, FreeBSD, Solaris, Irix and Darwin/MacOS X. Like MPlayer,it has a modular architecture, and is composed of an engine core with severaldifferent input, de-muxer, decoder and output plug-ins.

We were unfortunately not able to locate a Xine version compiled andpackaged for the Nokia 770.

Homepage: http://www.xinehq.de

5.6 Resource monitoring

As mentioned in Section 1.6, there has been some work on resource monitor-ing of MANET nodes. However, the only tool that could be of interest to us,was WANMon. According to Ngo et al. (2003), a prototype was developedfor the RedHat Linux Platform in 2003, but we were not able to find anymore current information about this tool. We were therefore forced to findother solutions to perform resource monitoring on the Nokia 770.

5.6.1 The /proc filesystem

As with other hardware information and statistics mentioned earlier in thissection, CPU load and memory statistics can be read directly from the proc-filesystem. This is where the utilities in this section read their information.As an example, memory statistics can be accessed through /proc/meminfo

and system load information can be read from /proc/loadavg, though the

64

output is less readable and harder to parse than the output of utilities de-signed for this purpose. We therefore wanted to use such utilities, if possible.

5.6.2 ps

To monitor CPU usage, we initially planned to use the standard POSIXutility ps, which can output a list of processes on the system, together withthe resource utilization for each process. However, as pointed out in Section5, the utilities provided by the BusyBox shell on the Nokia 770 are not full-featured equivalents to what would be provided with a regular Linux install,for instance. The BusyBox version of ps only has a single output format(equivalent to running ps -eo pid,user,vsize,stat,cmd), which does notinclude CPU utilization and memory utilization statistics.

5.6.3 top

top is another standard POSIX utility that normally can be configuredthrough command line parameters to provide customized information aboutall or selected processes on the system, similar to ps, but at regular inter-vals. Unfortunately, does BusyBox again only provide a limited and non-configurable version of the utility.

We could of course have installed full-featured versions of these utilities,but as we had to rely on installation of third-party software anyway, we couldmight as well look around for something that would be even more suited forour use.

5.6.4 sysstat

The sysstat package comprises a set of utilities for monitoring the hardwareresources of a system:

sar is an incredibly powerful logging utility that reports statistics and coun-ters for several operating system variables. A very useful feature is that allstatistics can be stored in a file and replayed with various parameters at alater time, showing only the statistics of interest.

Some of the areas that sar collects statistics on are: I/O and transfer ratestatistics; paging statistics; task creation activity; block device activity; IRQstatistics; network interface statistics; CPU statistics; memory statistics; andmore. Most statistics reported by the other utilities in the sysstat package,are also logged by sar.

65

Interestingly, the network interface statistics that are reported, are thesame as those reported by ifconfig. But ifconfig only reports cumulativecounts, and does not have the same features for logging of the statistics assar.

pidstat reports statistics for the running tasks on a Linux system. It canbe used for monitoring all tasks, or just selected tasks on system.

iostat reports I/O statistics for devices as well as CPU statistics.

mpstat reports statistics for each individual processor in a multiprocessorsystem.

vmstat reports virtual memory statistics.

isag is a tool for creating graphs for resource data logged by sar. This toolis really designed for plotting of daily, weekly and monthly resource graphswhen sar is run as a daemon on the system. It does not work very well forplotting graphs of resource data gathered when running sar ”ad-hoc”.

5.7 Other software

In this section we list various utilities and software packages that cannot becategorized as streaming servers or playback software, but which may stillbe of use when working with video and multimedia streaming on the Nokia770.

5.7.1 Mediautils

Mediautils are a collection of open source utilities for transcoding, managingand watching videos on Nokia 770, N800 and N810 Internet Tablets. At themoment, Mediautils consists of tablet-encode and mediaserv.

tablet-encode converts videos to Nokia compatible formats using MEn-coder. It was previously known as 770-encode.

mediaserv builds on tablet-encode, to provide a web interface for on-demandtranscoding and watching of videos in a media library

Homepage: http://mediautils.garage.maemo.org/

66

5.7.2 MediaConverter

MediaConverter is a Java based tool to convert videos for the Nokia 770.

Homepage: https://garage.maemo.org/projects/mediaconverter/

5.7.3 VidConvert

VidConvert is web site that offers online conversion of video files to a Nokia770 compatible format. However, at the moment the site says that the serviceis offline due to the bandwidth requirements.

Homepage: http://www.bleb.org/services/vidconvert/

5.7.4 RTPTools

RTPTools is a set of applications to process RTP data, often used to conductexperiments and analyze RTP streams.

rtpdump parses and prints RTP packets.

rtpplay replays RTP sessions that have been recorded by rtpdump.

rtpsend generates RTP packets from a textual description.

rtptrans functions as a translator between unicast and multicast networks.

Homepage: http://www.cs.columbia.edu/IRT/software/rtptools/

5.7.5 LIVE555 test programs

LIVE555 is a set of C++ libraries for multimedia streaming using standardprotocols, to be used for building multimedia streaming applications. Amongother things, it is used to implement the streaming support in MPlayer.

This library includes a set of test software, designed to demonstrate howto develop applications using the LIVE555 library. The test software includesa command line RTSP client, openRTSP, that can be used to open, streamand record RTSP media streams. It also includes a small RTSP server, te-stOnDemandRTSPServer, which can stream from various types of mediafiles on-demand, using RTP or raw UDP.

Homepage: http://www.live555.com/liveMedia/

67

6 Wireless monitoring experiment

In spite of the issues with the link quality readings mentioned in Section 5,we hoped to find a correlation between the wireless link statistics provided bythe operating system and the performance of the wireless link. This chapterdescribes how we investigated this matter by means of experiments withwireless transmission.

6.1 Motivation and purpose

Since much of the instabilities in mobile ad-hoc networks are due to featuresof the wireless medium mentioned in Section 3.5, link layer measurementsare a valuable supplement to measurements at the network and applicationlayers. However, in order to implement such measurements, one needs todecide upon a metric for performing link quality measurements. In addition,one needs to understand how the variations of the chosen metrics affect thelink quality. (Das et al., 2007) did a study on the performance of several of thecommon link quality metrics discussed in Section 4.2, and their performancein real world mesh network testbeds.

The purpose of this experiment was two-fold:

• Firstly, as a motivation to see what kind of link layer information isavailable in a Linux environment generally and on a Nokia 770 specific-ally, as well as an exercise in developing the means to extract and logthese measurements in an effective manner.

• Secondly, to gain greater insight into the reliability of these measure-ment methods and the quality of the measurement data.

The general idea was to start out with two devices at close range, and gradu-ally increase the distance between them, while logging as much wireless meas-urement data as possible on the units. By gradually increasing the distancein this manner, we were changing the networking conditions in a way thatwe knew would have an effect on the quality of the wireless network link.

By plotting graphs and performing visual analysis of results, we hoped tosee what measurement data we could hope to use in further experiments. Wealso hoped to be able to identify correlations between some of the parameters,which could form the basis for further investigations.

68

6.2 Experiment setup

We performed the measurements using Nokia 770 Internet Tablets. See Sec-tion 5.1 for more general information about this device. We switched thesupplied 64MB memory card with a 1GB memory card, to provide extendedstorage capacity for multimedia files and log files.

In the experiment, we used the 802.11b/g interface, which provides abandwidth of up to 54 Mb/s, depending on the conditions. The interface isbased on the STLC4370 chipset from STMicroelectronics, which is a variantof the CX3110x chipset from Conexant.

The experiment was performed by connecting two devices using the WLANinterface in 802.11 ad-hoc mode. The script wlantest.sh (see Appendix B.1)was running on each of the devices for the duration of each measurement,reading and storing the link quality, signal level and noise level values repor-ted by iwconfig at 1 second intervals. The script also logged the output ofifconfig, as well as /proc/net/wireless and /proc/net/dev.

The initial idea was to vary the signal strength by manipulating the trans-mission power of the wireless network interface of the devices, thereby simu-lating changing conditions. Unfortunately, our attempts to manually adjustthis, were largely unsuccessful. Preliminary testing showed that lowering thetransmission power using iwconfig did not seem to have any noticeable effecton neither reported link quality, signal level, noise level, nor the automaticbit rate setting.

Still, from looking at the options in the Connection Manager, it seemsthat the WLAN interface should support setting the transmission power.However, only two settings are available: 10 mW and 100 mW, with thedefault value being 100 mW. But even trying to set the power using theConnection Manager did not reveal any noticeable differences between thetwo settings.

We therefore concluded that setting the transmission power in this waydid not have the desired effect, or at least the effect was not large enoughto make an impact, for the purposes of our experiment. The decision wasthen made to perform the experiment by physically increasing the distancebetween the devices.

We started out by placing the two devices next to each other, and gradu-ally increasing the distance between them. This way, we hoped to see howthe link quality measurements varied according to the changing conditions.We performed measurements at the following distances: 0 meters, 1 meter,2 meters, 4 meters, 8 meters, 16 meters, 32 meters and 64 meters.

Care was taken to perform the measurements in an environment with aslittle interference as possible. The measurements were performed outside, on

69

Laptop to Nokia Nokia to laptop

Distance Time Average Time Average(mm:ss) KB/s (mm:ss) KB/s

0 m 03:05 276.8 02:55 292.61 m 03:07 273.8 02:43 314.12 m 03:05 276.7 02:37 326.14 m 03:03 279.8 02:57 289.38 m 03:14 263.9 02:35 330.316 m 04:35 186.2 02:16 376.532 m 03:04 278.3 02:34 332.564 m 03:35 238.1 06:36 129.3

Table 8: Results of transferring of a 50 MB file

a dry, sunny summer’s day, in level terrain on a large open field (a soccerfield). A scan of the wireless medium using iwlist was performed prior toeach measurement, to reveal any other wireless networks that could causeinterference. These scans had to be made on the laptop, due to the problemswith iwlist’s scanning on the Nokias mentioned in 5.3.4. No other wirelessnetworks were detected by these scans.

6.3 Measurements with laptop and Nokia 770

For the initial measurements, we used a Nokia device and a laptop com-puter. The laptop was a Dell XPS 1210m, running Ubuntu Linux 7.04,kernel v. 2.6.20-16. The wireless network adapter in the laptop was an IntelPRO/Wireless 3945abg, using the ipw3945 driver, version 1.2.0mp and firm-ware version 14.2. The Nokia device used in this set of measurements wasthe upgraded one running OS version 3.2006.49-2.

File transfer In Table 8 we see the results of the file transfer tests. Onmost occasions, transferring files from the Nokia to the laptop was signific-antly faster than the other way around. We suspect this to be because theperformance of TCP is heavily influenced by the performance of the receiver,and the Nokia is not powerful enough to receive at higher speeds.

Bit rate The Nokia reports a bit rate of 54 Mbps at all distances, while thelaptop reports a constant bit rate of 11 Mbps up to and including 8 meters,

70

1 2

5.5 6 9

11 12

18

24

36

48

54

0 100 200 300 400 500 600 700 800 900 1000

1 2

5.5 6 9 11 12

18

24

36

48

54

Bit

rate

(M

bps)

Time (seconds)

Bit rateLaptop & Nokia 770 (3.2006)

Distance: 16 m

LaptopNokia 770

Figure 17: Reported bit rate at a distance of 16 meters.

and then appears to adapt its bit rate according to the changing channelconditions. From Figures 17, 18 and 19 we see how the fluctuations in thelaptops reported bit rate increases with the distance.

Link quality For link quality, there seems to be a consistent difference of35 - 40 dBm between the link qualities reported by the two devices. Thelaptop always reports the higher link quality, with the exception of when thedistance is 0 meters, where both the devices report the same link quality. Wealso see that at shorter distances, the Nokia also reports much more changinglink qualities than the laptop. See Figures 20, 21, 22 and 23.

Noise level From Figures 24 and 25 we see that the two devices reportwildly different values when it comes to noise level. This is true for alldistances.

The laptop’s noise level values fluctuate greatly at the lower distances,and gradually even out as the distance between the two devices increase.Intuitively, the high noise level experienced at the short distances is explainedby interference caused by the Nokia. As the distance between the two devicesincrease, this interference gradually diminishes.

The noise level values reported by the Nokia remain around -95 dBmregardless of distance and conditions.

71

1 2

5.5 6 9

11 12

18

24

36

48

54

0 50 100 150 200 250 300 350 400 450 500

1 2

5.5 6 9 11 12

18

24

36

48

54

Bit

rate

(M

bps)

Time (seconds)

Bit rateLaptop & Nokia 770 (3.2006)

Distance: 32 m

LaptopNokia 770

Figure 18: Reported bit rate at a distance of 32 meters.

1 2

5.5 6 9

11 12

18

24

36

48

54

0 100 200 300 400 500 600 700 800 900 1000

1 2

5.5 6 9 11 12

18

24

36

48

54

Bit

rate

(M

bps)

Time (seconds)

Bit rateLaptop & Nokia 770 (3.2006)

Distance: 64 m

LaptopNokia 770

Figure 19: Reported bit rate at a distance of 64 meters.

72

0

20

40

60

80

100

0 50 100 150 200 250 300 350 400 450 500

Link

qua

lity

Time (seconds)

Link qualityLaptop & Nokia 770 (3.2006)

Distance: 0 m

LaptopNokia 770

Figure 20: Link quality at a distance of 0 meters.

0

20

40

60

80

100

0 100 200 300 400 500 600

Link

qua

lity

Time (seconds)

Link qualityLaptop & Nokia 770 (3.2006)

Distance: 2 m

LaptopNokia 770

Figure 21: Link quality at a distance of 2 meters.

73

0

20

40

60

80

100

0 100 200 300 400 500 600

Link

qua

lity

Time (seconds)

Link qualityLaptop & Nokia 770 (3.2006)

Distance: 4 m

LaptopNokia 770

Figure 22: Link quality at a distance of 4 meters.

0

20

40

60

80

100

0 100 200 300 400 500 600 700 800 900 1000

Link

qua

lity

Time (seconds)

Link qualityLaptop & Nokia 770 (3.2006)

Distance: 64 m

LaptopNokia 770

Figure 23: Link quality at a distance of 64 meters.

74

-100

-80

-60

-40

-20

0

0 50 100 150 200 250 300 350 400 450 500

Noi

se le

vel (

dBm

)

Time (seconds)

Noise levelLaptop & Nokia 770 (3.2006)

Distance: 0 m

LaptopNokia 770

Figure 24: Noise level at a distance of 0 meters.

-100

-80

-60

-40

-20

0

0 100 200 300 400 500 600 700 800 900 1000

Noi

se le

vel (

dBm

)

Time (seconds)

Noise levelLaptop & Nokia 770 (3.2006)

Distance: 64 m

LaptopNokia 770

Figure 25: Noise level at a distance of 64 meters.

75

-100

-80

-60

-40

-20

0

0 50 100 150 200 250 300 350 400 450 500

Sig

nal l

evel

(dB

m)

Time (seconds)

Signal levelLaptop & Nokia 770 (3.2006)

Distance: 0 m

LaptopNokia 770

Figure 26: Signal level at a distance of 0 meters.

Signal level Interestingly, the devices seem to agree on the signal level.From Figures 26 and 27, we see that the reported signal level is very similar,although, in general, the laptop reports signal level 1 - 5 dBm higher thanthe Nokia.

Errors No transfer errors are reported by any of the devices at distancesup to and including 32 meters, but at 64 meters we see a sharp increase intransmission errors on the Nokia. If we compare 28 and 30, we see how thevalues for Tx error and Tx excessive retries correlate. The curve for Txerror follows the shape of the Tx excessive retries curve, while stayingslightly above it.

From figure 8 we also see how the transmission speed suffers, as it drops60 % compared to the results from a distance of 32 meters.

Tx Excessive Retries At a distances from 1 to 4 meters, the laptop andNokia are able to communicate without any packets exceeding the retry limit.At further distances, we experience varying numbers of excessive retries onthe Nokia 770, with the largest amount of undelivered packets when thedistance is 64 meters. The laptop reports of no undelivered packets at anyof the distances. See figures 29 and 30.

76

-100

-80

-60

-40

-20

0

0 100 200 300 400 500 600 700 800 900 1000

Sig

nal l

evel

(dB

m)

Time (seconds)

Signal levelLaptop & Nokia 770 (3.2006)

Distance: 64 m

LaptopNokia 770

Figure 27: Signal level at a distance of 64 meters.

0

50

100

150

200

250

0 100 200 300 400 500 600 700 800 900 1000

Err

ors

Time (seconds)

ErrorsLaptop & Nokia 770 (3.2006)

Distance: 64 m

Laptop (Tx)Laptop (Rx)

Nokia 770 (Tx)Nokia 770 (Rx)

Figure 28: Link layer transmission errors at a distance of 64 meters.

77

0

5

10

15

20

25

30

35

0 100 200 300 400 500 600 700 800 900 1000

Tx

exce

ssiv

e re

trie

s

Time (seconds)

Tx excessive retriesLaptop & Nokia 770 (3.2006)

Distance: 16 m

LaptopNokia 770

Figure 29: Tx excessive retries at a distance of 16 meters.

0

50

100

150

200

250

0 100 200 300 400 500 600 700 800 900 1000

Tx

exce

ssiv

e re

trie

s

Time (seconds)

Tx excessive retriesLaptop & Nokia 770 (3.2006)

Distance: 64 m

LaptopNokia 770

Figure 30: Tx excessive retries at a distance of 64 meters.

78

3.2006 to 1.2006 1.2006 to 3.2006

Distance Time Average Time Average(mm:ss) KB/s (mm:ss) KB/s

0 m 03:41 231.7 04:16 200.01 m 03:07 273.8 05:16 162.02 m 03:55 217.9 04:28 191.04 m 03:14 263.9 04:39 183.58 m 03:46 226.6 04:35 186.216 m 03:36 237.0 04:30 189.632 m 03:03 279.8 04:10 204.864 m N/A N/A N/A N/A

Table 9: Results of transferring a 50MB file

6.4 Measurements with two Nokia 770s

The second set of measurements was performed with the two Nokia devices.One of the Nokias had the original OS 1.2006 installed, while the other onehad been upgraded to OS 3.2006. As the release notes for the 3.2006.49-2 version of OS 2006 state that it improves the quality of wireless LANconnections, we hoped to identify differences in the behavior of and the resultsreported by the two operating system versions.

It was apparent that the connection between the Nokias was generallymuch more unstable than in the case with one laptop and one Nokia 770. Inaddition, xterm would frequently crash and in some cases it would be neces-sary to reboot the device. This meant that several of the measurements hadto be restarted. When interacting with the tablet during the measurements,trying to open menus, etc., performance was noticeably degraded from theopen xterm tabs running the logging script and ssh sessions.

The range of transmission also seemed to be more limited in the casewith two Nokias. At a distance of 64 meters, we were not able to make aconnection at all between the two devices.

File transfer Again, the results from the file transfer show higher speedswhen transferring files from one device to the other. This time, the higherspeeds are achieved when transferring from the tablet running OS 3.2006 tothe one running OS 1.2006.

79

-100

-80

-60

-40

-20

0

0 100 200 300 400 500 600 700

Sig

nal l

evel

(dB

m)

Time (seconds)

Signal levelNokia 770 (1.2006) & Nokia 770 (3.2006)

Distance: 0 m

Nokia 770 (1.2006)Nokia 770 (3.2006)

Figure 31: Signal level at a distance of 0 meters.

Bit rate While laptop and the Nokia disagreed on the bit rate on almostall occasions, the two Nokias reported the same bit rate of 11 Mbps on alloccasions. The results of the file transfer tests, on the other hand, suggestthat this value may not be entirely accurate.

Noise level The two Nokias also reported more or less the same noiselevels of -95 dBm in all the measurements, just as the Nokia 770 did in thefirst set of meaurements.

Signal level As for signal level, the Nokias also seem to agree, althoughthe Nokia running OS 1.2006 reports several sharp drops in signal level thatdo not occur at the Nokia running OS 3.2006. It also reports slightly highervalues at greater distances. See Figures 31 and 32.

Link quality The interesting part is when we compare the link qualityand signal level graphs. Aside for the actual values, the curves seem almostidentical. The drivers for the Nokia 770 apparently reports link quality assome sort of constant difference of signal level. Hence, we also make the sameobservations for link quality as for signal level.

Tx Excessive Retries Unlike the previous set of measurements, excessivelink layer retries occur at all distances. Not surprisingly, as the distance

80

-100

-80

-60

-40

-20

0

0 100 200 300 400 500 600

Sig

nal l

evel

(dB

m)

Time (seconds)

Signal levelNokia 770 (1.2006) & Nokia 770 (3.2006)

Distance: 32 m (2nd try)

Nokia 770 (1.2006)Nokia 770 (3.2006)

Figure 32: Signal level at a distance of 32 meters.

0

20

40

60

80

100

0 100 200 300 400 500 600 700

Link

qua

lity

Time (seconds)

Link qualityNokia 770 (1.2006) & Nokia 770 (3.2006)

Distance: 0 m

Nokia 770 (1.2006)Nokia 770 (3.2006)

Figure 33: Link quality at a distance of 0 meters.

81

0

20

40

60

80

100

0 100 200 300 400 500 600

Link

qua

lity

Time (seconds)

Link qualityNokia 770 (1.2006) & Nokia 770 (3.2006)

Distance: 32 m (2nd try)

Nokia 770 (1.2006)Nokia 770 (3.2006)

Figure 34: Link quality at a distance of 32 meters.

increases, so does the number of retries. As one can see from Figures 35, 36and 37, the Nokia running OS 1.2006 seems to suffer from a greater numberof excessive retries compared to the Nokia running OS 3.2006.

Errors Despite the number of reported excessive link layer retries, the onlydistance where we see transmission errors occurring in the case of two Nokiasis at a distance of 32 meters. See Figure 38. Comparing with Figure 37, wesee that there is a sharp increase in the number of excessive link layer retriesat the same point in time.

Comparing with the link quality graph in Figure 34, we see that the errorsoccurred just as both nodes reported a drop in link quality. For some reason,we also see that the node running 3.2006 reports a spike in link quality justbefore this drop.

6.5 Lessons learned

When starting the logging script on the Nokia, it was apparent that it didnot have the processing power to run the logging at full speed. Althoughthe script was configured to log results every second, the Nokia could onlyoutput results every 2-3 seconds.

The two Nokia 770s had trouble transmitting at a distance of 64 meters.Trial and failure suggested that a connection could be established up to about60 meters.

82

10

15

20

25

30

35

40

45

50

55

0 100 200 300 400 500 600 700

Tx

exce

ssiv

e re

trie

s

Time (seconds)

Tx excessive retriesNokia 770 (1.2006) & Nokia 770 (3.2006)

Distance: 0 m

Nokia 770 (1.2006)Nokia 770 (3.2006)

Figure 35: Tx excessive retries at a distance of 0 meters.

60

70

80

90

100

110

120

130

140

0 50 100 150 200 250 300 350 400

Tx

exce

ssiv

e re

trie

s

Time (seconds)

Tx excessive retriesNokia 770 (1.2006) & Nokia 770 (3.2006)

Distance: 16 m (2nd try)

Nokia 770 (1.2006)Nokia 770 (3.2006)

Figure 36: Tx excessive retries at a distance of 16 meters.

83

0

2

4

6

8

10

12

14

16

18

20

0 100 200 300 400 500 600

Tx

exce

ssiv

e re

trie

s

Time (seconds)

Tx excessive retriesNokia 770 (1.2006) & Nokia 770 (3.2006)

Distance: 32 m (2nd try)

Nokia 770 (1.2006)Nokia 770 (3.2006)

Figure 37: Tx excessive retries at a distance of 32 meters.

0

5

10

15

20

25

30

35

40

45

0 100 200 300 400 500 600

Err

ors

Time (seconds)

ErrorsNokia 770 (1.2006) & Nokia 770 (3.2006)

Distance: 32 m (2nd try)

Nokia 770 (1.2006) (Tx)Nokia 770 (1.2006) (Rx)Nokia 770 (3.2006) (Tx)Nokia 770 (3.2006) (Rx)

Figure 38: Link layer transmission errors at a distance of 32 meters.

84

In both sets of measurements there is an obvious asymmetry in the trans-mission speeds. The Nokia 770 running OS 3.2006 is much slower at receivingthan both the laptop and the Nokia running OS 1.2006. We noticed that alltransmissions started out much faster than the average speed, but graduallydropped to about half the rate. We suspect that this is caused by TCP’srate control, due to the receiver’s buffers filling up.

It is apparent that the bit rate reported by the Nokia 770 wireless drivercan not be trusted. Comparisons with the bit rate reported by the wirelessdriver of the laptop and the results of file transfers shows that this value isinaccurate.

In addition, the noise levels reported by the Nokia wireless driver on theare obviously incorrect. The almost constant noise level reported by theNokias, compared to the very fluctuating noise levels reported by the laptop,leads us to conclude that noise detection on the wireless channel is brokenon the Nokia 770.

The erroneous noise level reporting could be an explanation for the Nokiasfailure to adjust the bit rate with varying channel conditions, which in turnwould explain the low transmission speeds experienced at the longer dis-tances.

Finally, there definitely seems to be a problem with the link quality meas-urement reported by the Nokia devices. The values reported are consistentlybelow 60, although the device is sitting right next to the transmitter. Also,the maximum link quality is reported to be 0, instead of 100. There alsoseems to be little correlation with the link quality reported by other devices,such as laptops.

Looking at the figures for Link quality and signal level reported by theNokia, we see that the graphs are identical, aside from the actual valuesreported. This relationship between link quality and signal strength explainswhy the reported link quality drops so sharply with distance.

Digging a little further, we examined the log of iwconfig output fromthe Nokias, and discovered that difference between the link quality and signallevel was not constant, but seemed to vary slightly by just a couple of units.Looking at the noise level values, we noticed the correlation. The Nokia 770wireless drivers apparently calculate link quality simply as:

Link quality = Signal level − Noise level

Due to the issues with reported noise level already mentioned, this causes therelationship between link quality and signal level to be an almost constantdifference.

It also explains the strange spike in reported link quality in Figure 34.By examining the logs for the exact values reported by iwconfig, we found

85

that it reported a signal level of −96dBm, and a noise level of −95dBm. Thisresulting in a link quality value of -1. The link quality value is apparentlystored as an unsigned byte, causing an underflow and a reported link qualityof 255.

As the distance increases, signal strength does not decrease linearly.Rather, it decreases according to the inverse square law. This means that asthe distance doubles, signal strength decreases by a factor of four (Bardwell,2004, p. 6). In the case of the Nokia 770, where the difference between repor-ted link quality and signal strength is nearly constant, this means that thelink quality value also follows the inverse square law. With this in mind, weunderstand why a link can still function very well, despite reporting very lowlink quality values. Knowing this, we suspect that the Connection Manageris designed to interpret and convert the link quality values reported by theinterface accordingly.

We were unable to find any official documentation on the receive thresholdfor the Conexant CX3110x that the Nokia 770 uses. However, according toBardwell (2004, p. 7), the most sensitive 802.11 cards have a receive thresholdof about −96 dBm.

Looking at all of the results, the only parameter that seems relativelyconsistent between all three devices is the signal level. While the WLANinterface in the laptop almost always reports a higher signal level than theinterface in the Nokia, the difference between the values is very slight. Theexception is the sharp drops in reported signal quality at short distances onthe Nokia running OS 1.2006. The release notes of version 3.2006.49-2, statethat it improves the quality of wireless LAN connections. These drops maybe a symptom of these issues.

At the shorter distances, we see a correlation between the increases in Tx

excessive retries reported by the Nokia and fluctuations in signal level.Intuitively, one would think that the number of Tx excessive retries

would be reflected in the number of reported transmissions errors, in thatseveral sequential errors in transmitting a packet more times than Retry

Limit eventually would trigger Tx excessive retries. But after study-ing the results, this does not seem to be the case, as the total number oftransmission errors remains constant throughout all measurements, with oneexception.

The retry limit on the Nokia 770 is not reported by iwconfig. We alsochecked the output of iwlist wlan0 retry, but this only outputs the min-imum and maximum values for this limit, which are 1 and 65535 respectively.We therefore have to assume that the retry limit is set to the default values.

The default MAC retry limit in the 802.11 standard is 4 for long dataframes with a length greater than the RTS/CTS threshold, and 7 for short

86

frames with a length less than or equal to this threshold (IEEE-SA StandardsBoard, 1999, p. 484).

According to the statistics we gathered, it appears that link layer retrans-missions only occur in our setup when communicating at distances close tothe maximum range, that is at 64 meters for the combination of laptop andNokia 770, and 32 meters for the 2 Nokia combination.

Finally, we also note that the batteries of the Nokias lasted about 2.5hours into the experiment, at which time we had to recharge them to completeit. Bearing in mind that the units were transmitting at full speed about halfof the time, often at large distances requiring high power, it is not that bad,but not very impressive either.

87

7 Video streaming experiment

This chapter describes our choice of setup for conducting some initial videostreaming measurements with the Nokia 770, and a discussion of the exper-iences and results of these measurements.

7.1 Network monitoring

For monitoring of the network we built upon the experiences from 6. But,as sar also handles monitoring of the network interfaces of the system, therewas no longer any need to log the output of ifconfig or the contents of/proc/net/dev. We still logged the output from iwconfig, to store generaldata about the wireless link, which sar does not log.

Often when doing monitoring of wireless networks, one will use deviceswith wireless network cards that have special features that enable enhancedand simplified monitoring of the wireless medium. Examples are cards thatare based on the Prism2 chipset, or chipsets that are supported by theMadWiFi driver, or the newer ath5k driver. Due to the closed nature ofour experimental devices, however, we did not have the possibility of hand-picking a wireless chipset according to the capabilities of the interface in thedevices available to us.

In order to capture complete 802.11 frames, wireless interfaces have to bein monitoring mode, which means that the nodes cannot participate activelyin the network. This meant that we could not use the Nokias participatingin the streaming session to also capture the wireless traffic.

7.1.1 Kismet

Kismet is a well-known wireless network sniffer, with the ability to passivelymonitor and log the traffic of wireless networks.

We were also able to locate a version of Kismet packaged for the Nokia770.

Homepage: http://www.kismetwireless.net/

7.1.2 tcpdump

tcpdump is a utility to dump traffic on a network, by capturing packetsat layer 2. It is included in most Linux distributions, and could easily beinstalled on the Nokia 770 from the repositories listed in Appendix A.5.

tcpdump has the ability to store the captured packets to a file using thelibpcap format. libpcap is a packet capturing library, and files stored using

88

this library can be interpreted by several other network analysis tools, suchas Ethereal/Wireshark mentioned below.

By capturing the traffic to file, the traffic can later be ”replayed”. tcpdumphas the ability to filter based on various parameters, such as incoming net-work interface, source and destination ports, etc. It can also decipher trafficfrom some protocols, and display the contents to the user.

As Grewal and DeDourek (2005) points out, there can be some issueswhen using tcpdump to capture packets on wireless interface. In particular,there is a risk of logging duplicate packets due to the interface running inpromiscuous mode.

Homepage: http://www.tcpdump.org/

7.1.3 mmdump

van der Merwe et al. (2000) presents a tool called mmdump, which extendstcpdump to provide extended support for parsing of multimedia traffic traces.For example, it supports setup of dynamic filters, based on the port numbersannounced by RTSP during the setup of a streaming session.

Unfortunately, we were not able to find a version of this tool available fordownload from anywhere to test it.

7.1.4 Wireshark

Wireshark is an open source network protocol analyzer, capable of perform-ing deep inspection of several hundreds of protocols. Older versions of thissoftware were released under the name of Ethereal.

The ability to plot graphs of the values of various protocol fields in apacket capture is also very convenient. Unfortunately, the functionality tocustomize these plots and export the results is still very limited.

On the other hand, the ”read filter” mechanism which allows filtering theoutput from a capture file based fields in the protocol headers of many of thehundreds of supported protocols is very powerful. This allowed us to use thecommand line version of Wireshark, TShark, to output this data to a textfile, which we could then feed to Gnuplot in order to create proper graphs.

In addition, Wireshark contains functionality to do analysis on capturedRTP streams. Using this functionality, we could easily compute statisticsfrom the RTP streams captured in scenarios 2 and 3, and export this resultto a CSV-file. The results could then be plotted using Gnuplot.

Homepage: http://www.wireshark.org

89

7.2 Experiment setup

In this subsection, we will discuss the choice of software we used to conductour video streaming experiment, as well as the choice of codecs, protocolsand physical layout of the network.

7.2.1 Choice of streaming server

Even after several days of scouring the web, we were not able to locate astreaming server that had been compiled and packaged for the Nokia 770.Our second choice was then to try to set up a GStreamer pipeline to streamvideo from the Nokias. Unfortunately, it became apparent that gst-launchwas not suitable for setting up RTP pipelines, as the RTP component requiresconfiguration options which cannot be passed on the command line. Wewould therefore be required to create an application to be able to send RTPusing GStreamer.

GStreamer bindings exists for several languages, including Python. Wehad hoped that this would be a quick way to create a simple applicationfor setting up an RTP stream for testing purposes, but the documentationfor the Python language bindings in its current state was very incomplete(Python GStreamer Documents), and GStreamer is a complex framework.Since the development of applications using the GStreamer framework isoutside the scope of this thesis, we concluded that this would have been tootime consuming considering the time frame.

We therefore decided to try to cross-compile an existing streaming ap-plication ourselves, using the Scratchbox environment. See Appendix A.3for information about installing Scratchbox.

We went with FFserver from the FFmpeg package, as this had the fewestdependencies and is designed to be small and lightweight. Also, while FFm-peg is still in active development, VLS has not had a release since late 2004.VLC, on the other hand, depends on libraries from FFmpeg, so in order tocompile it, we would have to compile FFmpeg first anyway.

There was some trouble getting it to compile and run, as there were somebugs in both the build script and in the RTP stream setup code. After someresearch and tweaking, we were eventually able to cross-compile FFserverand make it run on the Nokia 770. See Appendix A.4 for details. 2

Another problem with FFserver and FFmpeg is that the official docu-mentation is somewhat lacking. Fortunately, due to the widespread use ofthese components, it is not very hard to find answers to a lot of common

2We eventually also managed to compile a version of both VLS and VLC for the Nokia770, but had some issues in getting them to run properly.

90

questions from unofficial sources on the Internet, such as various technicalforums, etc. Also, the example configuration file provided a good startingpoint.

7.2.2 Choice of video player

While the standard Nokia 770 video player is able to play media streams, ithas a number of limitations regarding the types of videos it is able to play. Italso does not have a command line interface that allows for easy scripting oftests, nor the ability to output information about the playback of the mediastream.

Testing also revealed incompatibilities between FFserver and the RTSPstreaming functionality of Video Player. Furthermore, it also appears thatVideo Player does not support playing video files without an audio stream, asit would hang when trying to load our MPEG-1 video files, and also refuse toload the MPEG-4 files, with the error message ”audio codec not supported”.

We therefore decided to go with MPlayer, as a Nokia 770-optimized ver-sion of this is easily downloadable from online package repositories. Theversion we used was 1.0rc1-maemo.18.n770.

7.2.3 Choice of video

FFserver/MPlayer appears to be much more sensitive to errors in the videostream compared to when the video file is played locally. Fortunately, thiswas not really an issue, as we would have to re-encode all our test video clipsanyway, and the results produced by FFmpeg streamed perfectly.

Given the screen size of the Nokia 770, we wanted to perform the exper-iment with full screen video playback, as we imagine that this would be themost useful way to view video on the device.

Initially, we were planning to also try with videos that the Nokia 770 wasnot able to scale to full screen using hardware scaling. However, after tryingto play videos encoded in several resolutions, both listed and unlisted, wewere not able to find something that MPlayer would not report as scalingto full screen using hardware scaling. This also verified that there are nohardware limitation preventing MPlayer from playing videos with resolutionsthat are not a multiple of 16, as reported in 5.4.

This could mean that the resolution limit only pertains to the NokiaVideo Player. Since we would not primarily be using Video Player for ourexperiment, we found it best to choose two resolutions we were sure wouldscale nicely to full screen on the device, with no or minimal loss of quality,and without the need to add black bands.

91

Since the display of the device is 15:9 scaled at 800x480 pixels, we decidedto encode the video in the two listed 15:9 resolutions that are recommended:400x240 and 240x144. 240x144 was chosen as we could see from initial trialsthat it yields acceptable quality on the 770, with only 1/3 the number ofpixels of 400x240 resolution, thus requiring a much lower bandwidth. Thiswould also test the Nokia 770 stated limitation of maximum number of 1.52megapixels per second, as with 25 frames per second, the high-quality videoswould have a total of 2.4 megapixels per second. With a bandwidth of 1000Kbps, it would also test the stated bandwidth limitation of 800 Kbps. SeeSection 5 for more information about these limitations.

We made some initial tests to decide what codecs to use for the videosin the experiment. Table 7 on page 57 shows which combinations of video,audio and container formats are supported by the Nokia 770, and whetherthey can be decoded by the DSP or not. According to LIVE555, the RTPmedia types currently known to be working in MPlayer are MPEG-1, MPEG-2 and MPEG-4 elementary streams, H.263+ and MJPEG. We see that mostof the video formats listed can be decoded by the DSP, possibly saving theresources of the main CPU, and increasing battery life.

As mentioned in Section 5.5.8, MPlayer supports DSP decoding of bothMP2 and MP3 audio. Still, the status of MPlayer’s support of DSP decodingof video was somewhat of a question mark. As MPlayer does not integrateinto the GStreamer stack of the Nokia 770, and so it could not be taken forgranted that MPlayer would provide DSP decoding support for all or evenany of the formats on the list. MPlayer for Maemo does not mention thestatus of video DSP decoding support.

We therefore decided to select two different codecs, where one codec couldbe decoded by the DSP, and the other could not, and then analyze theperformance difference between the two. If one performed much better thanthe the other, then we could tell whether or not there was any DSP supportfor that format in MPlayer, and how large an impact the DSP had on theperformance.

In the search for two codecs to use for our experiment, testing revealedan incompatibility between MPlayer and FFserver when streaming H.263+encoded video. There were also issues with getting MPEG-2 working withFFserver. Since MJPEG is more of a special-purpose video codec, we there-fore chose to go with MPEG-1 and MPEG-4, as they both worked flawlesslyin both FFserver and MPlayer. They are also two of the most widely usedcodecs in the world of digital video.

For the measurements, we used two different clips encoded in severaldifferent combinations of resolutions, bit rates and encodings. As we wantedto focus on video streaming performance, all of the clips were encoded without

92

Clip number Clip type Resolution Bit rate (Kbps) Codec

1 Action 400x200 1000 MPEG-42 Action 240x144 500 MPEG-43 Action 240x144 200 MPEG-44 Action 400x200 1000 MPEG-15 Action 240x144 500 MPEG-16 Action 240x144 200 MPEG-17 Interview 400x200 1000 MPEG-48 Interview 240x144 500 MPEG-49 Interview 240x144 200 MPEG-410 Interview 400x200 1000 MPEG-111 Interview 240x144 500 MPEG-112 Interview 240x144 200 MPEG-1

Table 10: Video clips used in the experiment

sound. As the audio and video streams are transmitted in two separate RTPstreams, this would mean that we would only have one single media streamto worry about when monitoring the network. The video clips were encodedfrom the DVD-original using FFmpeg with 2-pass encoding.

In order to see whether the level of action in a clip would influence theresults, the two clips were chosen such that one of the clips had a high-levelof action, and the other had a very low level of action. The high-actionclip (Figure 39) is from the last action scene in the movie Top Gun, whichincidentally is one of the author’s favorite movies. The low-action clip (Figure40) is from an interview of Tom Cruise included in the extra material featuredon the same Top Gun DVD. This clip contains very little motion, and littlecutting.

The different combinations of video encoding parameters used are listedin Table 10. All the clips were encoded with a frame rate of 25 fps, and allof the following measurements were performed using these two clips, in thelisted combinations of bit rates and resolutions. The only exception is in thelocal playback scenario, as explained in Section 7.3.1. Note that demuxingof the container format is always done on the main CPU, so it should nothave any influence on the results (maemo.org, b).

93

Figure 39: The action video clip

Figure 40: The interview video clip

94

7.2.4 Choice of resource monitoring software

We decided to use the sysstat package to handle resource monitoring a eachnode. The only available packages of sysstat were for Maemo version 3.2and 4, so we had to compile this using Scratchbox, but this was straight-forward.

Monitoring of per-process CPU utilization turned out to be a CPU in-tensive task in itself. Initial testing showed that the pidstat utility usesup to 20% CPU time when monitoring all tasks on the system in 1 secondintervals. With this in mind, we also did a quick test with top, and foundthat this also consumed about 10% CPU when running with 1 second updateinterval.

But, we also found that the CPU utilization was heavily dominated by theapplications we were running for our experiment, FFserver and MPlayer. Wetherefore settled with monitoring the resources of our Nokias with only thesar utility, running at 1 second intervals. We wrote the script resourcelogger.sh(see Appendix B.4, which was run on each node before the start of each meas-urement to setup and start logging the system resource utilization.

7.2.5 Wireless testbed

A major hurdle was now to design and set up a multi-hop mobile ad-hocnetwork in a limited area. There has not been very much research on thesubject, and existing solutions rely on using large outdoor areas, signal at-tenuation or noise injection (Kaul et al., 2006), (Kaba and Raichle, 2001),(Jadhav et al., 2005). All these solutions were too complex for our needs,and rely on custom hardware.

We chose to set up our ad-hoc network using the OLSR protocol (seeSection 2.4.1). Intuitively, a proactive routing protocol is what best caters tothe delay requirements of multimedia streaming. Also, a version of the OLSRdaemon packaged for the Nokia 770 was easily available, and preliminarytesting showed that it functioned very well.

Through a little trial-and-error, we found that the bomb shelter in thebasement of the department building was a good location to conduct ourstreaming experiment. By carefully placing the nodes in a ”zigzag” patternpartly behind the thick walls, and then turning down the transmission poweron the nodes on both edges, we were able to set up a multi-hop, three-nodeMANET.

The proactive nature of the OLSR protocol simplified the setup, in theway that we could easily tell whether or not a link existed between anytwo nodes. A reactive protocol would have required us to try to establish a

95

connection in order to test this. Also, by logging the output of OLSR, wewould easily be able to tell if a link between any of our nodes went downcausing changes in the topology.

The two-node scenario was also performed within this shelter, as it providedgood isolation from any other wireless networks that could interfere with ourmeasurements.

To monitor system hardware resources, we decided to the sar utilityfrom the sysstat package. This was running on all nodes in the experi-ment, enabling us to track the resource consumption on the server, clientand intermediate node.

The properties of the wireless adapter were monitored using a slightlymodified version of the script from the wireless experiment, logging the out-put from iwconfig.

We also logged the output from OLSRd, running with debug level 1.This logs all topology changes happening in the MANET. By passing theparameters -dispin and -dispout to OLSRd, we could easily have logged allincoming and outgoing OLSR-packets as well. Even so, we decided to capturethe OLSR traffic by means of TCPdump instead, by logging UDP traffic atport 698. In this way, the OLSR packet traces could be inspected by in thesame manner as the other network traffic. Also, we wanted the output fromOLSR to be printed to screen as well as to the log file, in order to monitor thetopology of the MANET. Adding the options -dispin and -dispout causesa lot extra console output, which leads to a considerable slowdown on the770. A quick investigation showed that the central process maemo-launcheruses about 50% CPU time, which clearly would have affected the results ofour measurements. We thus concluded that capturing the OLSR packetswith tcpdump would be more reliable, and less intrusive.

To capture raw 802.11 frames, we used Kismet running on the Dell XPS1210m laptop also used in 6. Our solution was to use a laptop running Kismetto sniff the wireless medium during the experiment, and store all the traffic tofile for later analysis. Although Wireshark is also able to perform capturingof wireless traffic, we chose Kismet, as Wireshark produced incomplete tracesduring initial testing.

Since our ad-hoc network was a single frequency network, we only hadto concern ourselves with sniffing a single wireless channel (see Deshpandeet al. (2006) for information on monitoring multiple channels). By placingthe sniffer node next to the intermediate node in our 3-node MANET, thesniffer was able to hear all three nodes in the network. This way, we avoidedtrouble with merging logs from several sniffers.

Each Nokia 770 participating in the measurements was running tcpdump

to capture the OLSR, RTP and RTCP traffic to and from the device. Due to

96

the limited resources of the Nokias, only the first 128 bytes of each packetswere captured, which is enough to store all protocol headers contained in thepackets, but which leaves out the payload.

In order to easily be able to set up the network related logging on eachnode, we wrote the script networklogger.sh (Appendix B.5).

However, while performing the third and final set of measurements, weexperienced more problems with the sniffing, which we unfortunately wereunable to solve in time. Thus, the third set of measurements had to beperformed without wireless sniffing enabled.

Like any other network traffic, RTCP packets can be captured usingtcpdump.One difficulty with setting up capturing of RTP/RTCP traffic, tough, is thatRTSP by default picks a random even port number for the RTP stream. TheRTCP traffic corresponding to each RTP stream will then be sent at the oddport number following the chosen RTP port.

Fortunately, MPlayer has an option -rtsp-port, which allows the userto direct the RTP traffic to a specific port number, thus making the task ofcapturing the traffic with tcpdump very simple.

Finally, we logged all output from the streaming server, thereby loggingall the requests made by the client.

The plan was initially to also perform subjective evaluation of the stream-ing video quality, by using the ”editing list” feature in MPlayer to mark lowquality parts. However, the lack of a hardware keyboard made this im-possible, and we did not have access to an external Bluetooth keyboard atthe time. Instead, we had to settle for just general observation of the qualityof each streaming session.

Analysis of the packet captures made by Kismet and tcpdump were ana-lysed using Wireshark and the command line version, Tshark, as it is capableof inspecting RTP and RTCP packets, OLSR, TCP and UDP packets, as wellas 802.1 and 802.11 frames.

Information that is accessible in the different protocol layers are summar-ized in Table 7.2.5. Headers of several of the protocols contain informationthat is not shown. Only protocol fields that would be considered interestingduring an analysis is listed.

Table 12 summarizes which network related QoS metrics mentioned in4 we are able to measure with our current setup.From the experiment inSection 6, we learned that the noise level reported by the Nokia 770 wirelessdriver cannot be trusted. This also means that we are unable to compute theSNR of the wireless link. As mentioned in Section 5.3.7, OLSRd supportscomputation of ETX for the wireless links. But as this breaks RFC com-patibility and could possibly interfere with our measurements, we chose todisable this. As we are logging the output of the OLSR daemon, we also have

97

802.11 IP UDP OLSR

Frame type and sub type Total length Source port Packet lengthMore fragments Identification Destination port Packet sequence numberRetry Time to live Length Message typeDuration Next level protocol Message sizeBSSID address Source IP address Originator addressSource MAC address Destination IP address Hop countReceiver MAC address Message sequence numberTransmitter MAC addressFragment numberSequence number

RTP RTCP RTSP

Payload type Sender SSRC Media control informationSequence number NTP timestamp Media locationTimestamp RTP timestamp Transport protocolSync. src. (SSRC) identifier Sender’s packet count (SR only)Contrib. src. (CSRC) identifier Sender’s octet count (SR only)

Per source:Timestamp of last SRDelay since last SR (RR only)Interarrival jitter (RR only)Fraction lost (RR only)Cum. no. of packets lost (RR only)Highest seq.no. received (RR only)

Table 11: Information accessible from the different protocol layers

Metric Can measure? Method

Signal strength Yes iwconfig

Noise level No* (iwconfig)SNR No*ETX Yes OLSRdETT NoWCETT No

Prevalence Yes OLSRdPersistence Yes OLSRdRoute flap Yes OLSRd

Table 12: Summary of network measurement possibilities

98

Layer Monitoring method

Hardware sarLink iwconfig, KismetNetwork/MANET OLSRd, tcpdumpTransport tcpdumpSession FFserverApplication FFserver, MPlayerMedia Simple subjective evaluation

Table 13: Monitoring methods by layer

the ability to compute the route stability metrics prevalence, persistence androute flap. Our cross-layer monitoring strategy is summarized in Table 13.

7.3 Performing the experiment

Before starting with the experiments, we measured the average CPU utiliza-tion when idle to be about 9% each for both user and system CPU, totallingat 18% idle CPU utilization.

7.3.1 Scenario 1: Local playback

The purpose of this scenario was to see how much resources is consumedby the playback of the media itself, without involving data transmission,routing and other complicating factors. It also served as a test of the resourcemonitoring software.

Each of the 6 different videos were played back using MPlayer. For eachvideo, the resource consumption was monitored using the the script in Ap-pendix B.4 on page 153, which logs output from sar and pidstat.

Figures 41, 42, 43 and 43 show graphs of the CPU utilization for the400x240 1000 Kbps clip and 240x144 200 Kbps clip in both MPEG-4 andMPEG-1 encoding. From the graphs we can see how the total CPU utilizationis close to 100% for the 1000 Kbps clip in the case of both MPEG-4 andMPEG-1. The outlook is somewhat better for the 200 Kbps clips, where thetotal CPU utilization is somewhere around 60% on average. In both cases,we see that the CPU utilization for each clip is slightly higher when playingthe MPEG-4 version. This is not surprising, since MPEG-4 is more complexto decode than MPEG-1.The results for the 500 Kbps clips are not shownhere, but were somewhere in between.

99

0

20

40

60

80

100

00:00 00:30 01:00 01:30 02:00 02:30 03:00 03:30 04:00 04:30 05:00

CP

U u

tiliz

atio

n (%

)

Time (MM:SS)

% user% system

Figure 41: CPU utilization: Local playback of action clip at 400x240 1000Kbps with MPEG-4 encoding.

When comparing the graphs for the two action and interview clips, we seethat they both have about the same CPU utilization, despite the fact that thelevel of action in the interview clip is very small compared to the action clip.One difference though, are the sharp drops in CPU utilization that happen4 times during playback of the interview clip. These drops occurred for allthe tested combinations of resolution and bit rate, but are most prominentin the 400x240 1000 Kbps clip. The cause of these sharp drops were quite apuzzlement at first, until the obvious reason occurred to us:

The interview clip is divided into 4 sequences, which each are separatedby a still frame showing the topic for the next section of the interview. Theseframes are displayed for about 6 seconds each. Thus, we see that the contentof the video clip being played does indeed affect the CPU utilization. Still,very little movement is needed to bring the CPU utilization up to the levelof the action clip.

Still unsure of MPlayer’s support for DSP video decoding, we decidedto compare the performance of MPlayer to the Nokia 770 Video Player. Asmentioned in 5, decoding through the DSP is handled automatically throughGStreamer plug-ins in the Nokia 770 multimedia architecture. The standardVideo Player included with the device uses the GStreamer architecture, soby measuring the CPU utilization when playing a video using MPlayer, andcomparing it to the CPU utilization when playing it in the standard Nokia770 Video Player, we hoped to be able to see the difference between regular

100

0

20

40

60

80

100

00:00 00:30 01:00 01:30 02:00 02:30 03:00 03:30 04:00 04:30 05:00

CP

U u

tiliz

atio

n (%

)

Time (MM:SS)

% user% system

Figure 42: CPU utilization: Local playback of action clip at 400x240 1000Kbps with MPEG-1 encoding.

0

20

40

60

80

100

00:00 00:30 01:00 01:30 02:00 02:30 03:00 03:30 04:00 04:30 05:00

CP

U u

tiliz

atio

n (%

)

Time (MM:SS)

% user% system

Figure 43: CPU utilization: Local playback of action clip at 240x144 200Kbps with MPEG-4 encoding.

101

0

20

40

60

80

100

00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00

CP

U u

tiliz

atio

n (%

)

Time (MM:SS)

% user% system

Figure 44: CPU utilization: Local playback of interview clip at 400x240 1000Kbps with MPEG-4 encoding.

and DSP optimized decoding.But, as mentioned in Section 5.5.7, the Nokia 770 Video Player apparently

does not support playback of video files that do not contain an audio stream.We were therefore not able to use our regular video clips for this test. Instead,we chose to use the video clip Discovery.avi, which is included with theNokia 770 by default. This clip was chosen under the assumption that it isreasonable well optimized for playback on the Nokia 770, using the standardvideo player.

By examining the interrupt statistics from the two experiments, we learnedthat the number of interrupts/second for interrupt number 10 was twice ashigh in the case of the Nokia Video Player. The output from /proc/interrupts

told us that interrupt 10 was a DSP interrupt, which would suggests an in-crease in DSP utilization, which would explain the much lower CPU utiliza-tion.

Afterwards, we performed the measurements again, using the same videoclip, Discovery.avi, but converted to MPEG-1 video with MPEG-1 layer 2audio. According to maemo.org (b), the DSP does not support decodingof MPEG-1 video. Note that the original video had 15 frames per second,but due to limitations in MPEG-1, this had to be increased to 30 in thetranscoded video, although the bit rate was kept very close to the original.

From Figures 51 on page 106 and 52 on page 107, we see that playing thisvideo in Video Player causes an even higher number of DSP interrupts per

102

0

20

40

60

80

100

00:00 00:05 00:10 00:15 00:20 00:25 00:30 00:35 00:40 00:45 00:50 00:55 01:00

CP

U u

tiliz

atio

n (%

)

Time (MM:SS)

% user% system

Figure 45: CPU utilization: Playing MPEG-4 video in MPlayer

second, while the number for MPlayer remain similar. However, when lookingat Figures 49 on page 105 and 50 on page 106, we see that CPU utilizationfor Video Player has increased drastically, and is now much higher than forMPlayer.

103

0

20

40

60

80

100

00:00 00:05 00:10 00:15 00:20 00:25 00:30 00:35 00:40 00:45 00:50 00:55

CP

U u

tiliz

atio

n (%

)

Time (MM:SS)

% user% system

Figure 46: CPU utilization: Playing MPEG-4 video in Video Player

0

20

40

60

80

100

120

140

00:00 00:05 00:10 00:15 00:20 00:25 00:30 00:35 00:40 00:45 00:50 00:55 01:00

DS

P in

terr

upts

/sec

ond

Time (MM:SS)

Figure 47: DSP interrupts/second: Playing MPEG-4 video in MPlayer

104

0

20

40

60

80

100

120

140

00:00 00:05 00:10 00:15 00:20 00:25 00:30 00:35 00:40 00:45 00:50 00:55

DS

P in

terr

upts

/sec

ond

Time (MM:SS)

Figure 48: DSP interrupts/second: Playing MPEG-4 video in Video Player

0

20

40

60

80

100

00:00 00:05 00:10 00:15 00:20 00:25 00:30 00:35 00:40 00:45 00:50 00:55

CP

U u

tiliz

atio

n (%

)

Time (MM:SS)

% user% system

Figure 49: CPU utilization: Playing MPEG-1 video in MPlayer

105

0

20

40

60

80

100

00:00 00:05 00:10 00:15 00:20 00:25 00:30 00:35 00:40 00:45 00:50 00:55 01:00

CP

U u

tiliz

atio

n (%

)

Time (MM:SS)

% user% system

Figure 50: CPU utilization: Playing MPEG-1 video in Video Player

0

20

40

60

80

100

120

140

00:00 00:05 00:10 00:15 00:20 00:25 00:30 00:35 00:40 00:45 00:50 00:55

DS

P in

terr

upts

/sec

ond

Time (MM:SS)

Figure 51: DSP interrupts/second: Playing MPEG-1 video in MPlayer

106

0

20

40

60

80

100

120

140

00:00 00:05 00:10 00:15 00:20 00:25 00:30 00:35 00:40 00:45 00:50 00:55

DS

P in

terr

upts

/sec

ond

Time (MM:SS)

Figure 52: DSP interrupts/second: Playing MPEG-1 video in Video Player

107

Figure 53: Node-to-node experiment setup

Summary All of the streams played smoothly. This shows that maximumnumber of megapixels that the 770 is able to handle, is somewhat higherthan the 1.52 megapixels that is reported by maemo.org (d). Our test videoswith a resolution of 420x200, has 420x200x25 = 2.4 megapixels, and playedwithout problems.

Even so, the graphs show that the CPU load is close to 100% when playingthe most demanding video clips, and that use of the DSP for decoding of videodata significantly reduces this CPU load.

Subjectively, the quality of all the clips were good enough to watch on theNokia 770, although the 200x140 200 Kbps video may be to grainy to see somedetails in the image, which could be important in some practical scenarios. Inthis respect, 240x140 at 500 Kbps probably has a better bandwidth/qualityratio.

We can also see that the difference in resource consumption betweenMPEG-1 and MPEG-4 when not decoding using the DSP is slightly in favorof MPEG-1.

7.3.2 Scenario 2: Node-to-node

In this scenario, we wanted to see the result of streaming video over a singlewireless link between two neighboring nodes, without the complicating factorof routing and route management at the mobile ad-hoc network layer.

This was also an opportunity to see how the wireless data transmissionimpacts video playing on the Nokia 770, and test the performance of thevideo streaming software on both the server and the client.

There were some initial difficulties in getting a complete capture of thewireless traffic, but these problems were solved by making sure that theWLAN adapter was not associated to an ESSID upon launching Kismet.

108

0

20

40

60

80

100

00:00 00:30 01:00 01:30 02:00 02:30 03:00 03:30 04:00 04:30 05:00 05:30

CP

U u

tiliz

atio

n (%

)

Time (MM:SS)

CPU utilization

% user% system

Figure 54: CPU utilization: Server node streaming action clip at 400x2401000 Kbps with MPEG-4 encoding.

After redoing most of the second set of measurements, we were able to capturea complete trace of the traffic.

The hardware layer From Figures 54 and 55 on the next page we see thatthe client has about the same CPU load as in the local playback scenario, yetslightly higher, resulting in a total CPU load of 100% at certain moments,leading to somewhat choppy playback in the case of 1000 Kbps bit rate in400x240 resolution.

The server has an average CPU load of about 30%. Unlike the client,where the user CPU time from the playback is the dominating factor, thesystem CPU time is about twice as high as the user CPU time on the server.

The difference in CPU utilization between streaming MPEG-4 and MPEG-1 video was small or non-existent on both the server and the client side.

When we decreased the resolution and bit rate of the video stream, thedifference was most noticeable on the client side, where the CPU utilizationdropped by about 30%. On the server, the CPU utilization dropped by 10%,totalling at about half the utilization in the 1000 Kbps case. See Figures 56and 57.

By comparing the results for client and server, we are beginning to seeevidence that the resources of the streaming client easily can become a bot-tleneck in a MANET video streaming solution.

Just as in the local playback scenario, the content of the video clip did

109

0

20

40

60

80

100

00:00 00:30 01:00 01:30 02:00 02:30 03:00 03:30 04:00 04:30 05:00

CP

U u

tiliz

atio

n (%

)

Time (MM:SS)

CPU utilization

% user% system

Figure 55: CPU utilization: Client node playing action clip at 400x240 1000Kbps with MPEG-4 encoding.

0

20

40

60

80

100

00:00 00:30 01:00 01:30 02:00 02:30 03:00 03:30 04:00 04:30 05:00 05:30

CP

U u

tiliz

atio

n (%

)

Time (MM:SS)

CPU utilization

% user% system

Figure 56: CPU utilization: Server node streaming action clip at 240x144200 Kbps with MPEG-4 encoding.

110

0

20

40

60

80

100

00:00 00:30 01:00 01:30 02:00 02:30 03:00 03:30 04:00 04:30 05:00 05:30

CP

U u

tiliz

atio

n (%

)

Time (MM:SS)

CPU utilization

% user% system

Figure 57: CPU utilization: Client node playing action clip at 240x144 200Kbps with MPEG-4 encoding.

not significantly affect the CPU utilization of the client, with the exceptionof the certain points in the interview clip, noted in 7.3.1. The same thingwas also true for the server.

When looking at the report for block device activity, we can see how datawas read and written to disk during the streaming session. The tall, crossedbars correspond to logging data being written to disk at a set interval, aboutevery 30 seconds. When looking at the graphs for the client, we can seethat this is the only block device activity happening on the system duringthe streaming session. See 61 on page 113 as an example. Graphs for othercombinations of resolutions and bit rates were similar.

From Figures 58, 59 and 60, we see that the server reads the file from diskin bursts of 1000 Kbps, regardless of the bit rate of the stream, or the size ofthe file. On the other hand, when we examine graphs of the network transferstatistics, we see that throughput varies considerably throughout the stream.For 1000 Kbps clips, we can see variations in transmission speed as large as1500 Kbps, while for 500 Kbps and 200 Kbps, we have variations of about700 Kbps and 200 Kbps respectively. The results for MPEG-1 encoding aresimilar to the results for the MPEG-4 streams. Also, the graphs for the clientshowing the amount of data received are similar.

It thus appears that although FFserver reads the clip from disk at analmost constant data rate, it does not transmit it over the network at aconstant rate. Rather, the fluctuations in transmission rate seems to increase

111

0

500

1000

1500

2000

2500

00:00 00:30 01:00 01:30 02:00 02:30 03:00 03:30 04:00 04:30 05:00 05:30

Kbp

s

Time (MM:SS)

Block device activity

readwritten

Figure 58: Block device activity: Server streaming action clip at 400x2401000 Kbps with MPEG-4 encoding.

0

200

400

600

800

1000

1200

1400

1600

1800

2000

00:00 00:30 01:00 01:30 02:00 02:30 03:00 03:30 04:00 04:30 05:00 05:30

Kbp

s

Time (MM:SS)

Block device activity

readwritten

Figure 59: Block device activity: Server streaming action clip at 240x144500 Kbps with MPEG-4 encoding.

112

0

200

400

600

800

1000

1200

1400

1600

00:00 00:30 01:00 01:30 02:00 02:30 03:00 03:30 04:00 04:30 05:00 05:30

Kbp

s

Time (MM:SS)

Block device activity

readwritten

Figure 60: Block device activity: Server streaming action clip at 240x144200 Kbps with MPEG-4 encoding.

0

200

400

600

800

1000

1200

1400

1600

1800

2000

00:00 00:30 01:00 01:30 02:00 02:30 03:00 03:30 04:00 04:30 05:00

Kbp

s

Time (MM:SS)

Block device activity

readwritten

Figure 61: Block device activity: Client streaming action clip at 420x2401000 Kbps with MPEG-4 encoding.

113

0

200

400

600

800

1000

1200

1400

1600

1800

00:00 00:30 01:00 01:30 02:00 02:30 03:00 03:30 04:00 04:30 05:00 05:30

Kbp

s

Time (seconds)

Network transfer statistics

receivedtransmitted

Figure 62: Network activity: Server streaming action clip at 420x240 1000Kbps with MPEG-4 encoding.

with the bit rate of the video stream. This suggests that increasing the bitrate of the video stream increases the bandwidth requirements by more thanthe increase in bit rate. In fact, from our figures, the maximum throughputrequirements seem to be about 150% of the bit rate of the video stream.

The link layer The link quality was reported to be around 60 by both theserver and the client node, throughout the entire session, with only a coupleof exceptions, noted below.

In Figure 65 on page 116 we see how the client reports of a sudden dropin link quality while streaming the action clip at 400x240 1000 Kbps withMPEG-1 encoding. This drop in link quality is not reported by the server.

Such a drop in link quality is also reported again by the client whilestreaming the action clip at 240x144 200 Kbps with MPEG-1 encoding, andagain, the drop in link quality is not reported by the server node. See Fig-ure 66 on page 116. In all other measurements, the link quality is reportedby both server and client to be relatively stable.

These two drops in link quality do not seem to have any impact on thenetwork transmission speed, and analysis of the traces captured by the wire-less network sniffer show that retransmissions at the link layer are almostnon-existent.

114

0

100

200

300

400

500

600

700

800

900

00:00 00:30 01:00 01:30 02:00 02:30 03:00 03:30 04:00 04:30 05:00 05:30

Kbp

s

Time (seconds)

Network transfer statistics

receivedtransmitted

Figure 63: Network activity: Server streaming action clip at 240x144 500Kbps with MPEG-4 encoding.

0

50

100

150

200

250

300

350

400

00:00 00:30 01:00 01:30 02:00 02:30 03:00 03:30 04:00 04:30 05:00 05:30

Kbp

s

Time (seconds)

Network transfer statistics

receivedtransmitted

Figure 64: Network activity: Server streaming action clip at 240x144 200Kbps with MPEG-4 encoding.

115

0

20

40

60

80

100

00:00 00:15 00:30 00:45 01:00 01:15 01:30 01:45 02:00 02:15 02:30 02:45 03:00

Link

qua

lity

Time (seconds)

Figure 65: Link quality: Client streaming action clip at 400x240 1000 Kbpswith MPEG-1 encoding.

0

20

40

60

80

100

00:00 00:30 01:00 01:30 02:00 02:30 03:00 03:30 04:00 04:30 05:00

Link

qua

lity

Time (seconds)

Figure 66: Link quality: Client streaming action clip at 240x144 200 Kbpswith MPEG-1 encoding.

116

0

1000

2000

3000

4000

5000

6000

0 50 100 150 200 250 300

Cum

ulat

ive

num

ber

of p

acke

ts lo

st

Time (seconds)

MPEG-4MPEG-1

Figure 67: Cumulative packet loss as reported by RTCP (client capture):Streaming action clip at 400x240 1000 Kbps

Clip no. Retransmissions Total frames % Retransmissions

1 22 65533 0.032 17 66616 0.033 18 38124 0.054 13 38638 0.035 5 21065 0.026 6 21559 0.037 54 89828 0.068 37 91585 0.049 12 52556 0.0210 24 54430 0.0411 10 32193 0.0312 3 31249 0.01

The transport layer We then analyzed the RTP traffic using Wireshark’sRTP stream analysis. Figures 67 and 68, shows a comparison of the cumulat-ive packet loss for the two different encodings as reported by RTCP packetscaptured on the client. We see that the packet loss for the MPEG-4 streamis consistently much higher than the MPEG-1 stream. The MPEG-4 streamhas about 30% higher packet loss than the MPEG-1 stream of the samevideo.

117

0

1000

2000

3000

4000

5000

6000

7000

8000

0 50 100 150 200 250 300 350 400 450

Cum

ulat

ive

num

ber

of p

acke

ts lo

st

Time (seconds)

MPEG-4MPEG-1

Figure 68: Cumulative packet loss as reported by RTCP (client capture):Streaming interview clip at 400x240 1000 Kbps

The graphs for the interview clip at 400x240 resolution, show the sametrend. For all of the rest of the clips, the packet loss reported by RTCP was0 or close to 0.

Despite the packet loss reported by RTCP, the wireless captures showvery few link layer retransmissions. This is consistent with the results fromthe wireless experiment in 6 on page 68, where we could see that link layerretransmissions almost only occurred when devices transmitted at close tothe maximum possible communication distance.

The network error statistics reported by sar, showed 0 transmission er-rors, collisions. One might expect that since the system was operating atclose to 100%, the packet loss reported by RTCP would be due to an over-flow in the receive buffers on the client. But, as mentioned in the analysisof the hardware layer, sar also reports 0 buffer overflows, so this is not thecase. This leads us to believe that the packet loss is due to the RTP stackin the streaming client software, MPlayer, dropping packets.

RTCP also has a field that reports the fraction of RTP packets lost sincethe last Sender Report or Receiver Report was received. Note that since thereports do not arrive at a set interval, they cannot be directly used to see ifor how the packet loss rate changes during the streaming session. However,the loss rate per second can be obtained by dividing the loss fraction by thedifference in NTP timestamps, expressed in seconds. Unfortunately, timeprevented us from further in-depth analysis of this RTP/RTCP data.

118

The IP bandwidth measurements produced by the RTP stream analysis inWireshark are similar to the network utilization measured by sar, althoughin our case, the measured RTP stream is the only traffic on the wirelessinterface. If we had multiple streams or a lot of other traffic, then this wouldprovide us with a better view of the bandwidth consumed by the streamitself. As a note, these measurements are much more detailed, as they madeper RTP packet and not just sampled once per second, as in our sar loggingsetup.

Unfortunately, it seems that the jitter calculations fail for the MPEG-4streams, as we got results in the 7-digit range. It turns out that reason isthat Wireshark is able to detect the payload of our MPEG-1 streams, butnot the MPEG-4 streams. As the jitter calculations require knowledge of thesampling rate of the RTP payload (Wireshark), MPEG-4 video in this case,the calculations fail.

According to Wireshark, the sampling frequency is 8 kHz for most audiocodecs, and 90 kHz for most video codecs. To be sure, we consulted Kiku-chi et al. (2000), which confirms that the timestamp resolution is set to adefault value of 90 kHz, unless otherwise specified by a parameter duringstream setup. van der Meer et al. (2003) also recommends a sampling rateof 90 kHz for MPEG-4 video streams. The logs from FFserver unfortunatelyonly provides excerpts of the RTSP messages, so we could not see detailedparameters of the stream setup there. We therefore decided to inspect thepacket captures of our RTP streams using Wireshark.

By looking at the contents of the RTSP packet containing the sessiondescription (see Figure 69, we see that the first ”Media Attribute (a)”is set to ”rtpmap:96 MP4V-ES/90000” - in other words an MPEG-4 videoelementary stream at 90 kHz sampling rate.

By dividing the jitter values for the MPEG-4 streams provided by Wire-shark’s RTP analysis by the sampling rate of 90000 Hz, we got the correctjitter values. Unfortunately, we were also unable to perform analysis of thejitter measurements, due to time constraints.

Media layer During the measurements, the playback of the 400x240 1000Kbps clips was choppy. Playback of all other clips was smooth withoutnoticeable glitches or choppiness. Between the MPEG-4 and MPEG-1 versionof the 400x240 clip, there were notable differences in how the quality of thevideo was affected when frames were dropped.

The result of packet loss in the MPEG-4 stream seemed to be more orless limited to the parts of the frame where there were objects in motion, andresulted in these parts being ”smudged” across the imaged as they moved.

119

Frame 81 (471 bytes on wire, 471 bytes captured)

IEEE 802.11 Data, Flags: ........

Logical-Link Control

Internet Protocol, Src: 10.0.0.1 (10.0.0.1), Dst: 10.0.0.2 (10.0.0.2)

Transmission Control Protocol, Src Port: apc-5454 (5454), Dst Port: giop-ssl (...)

Real Time Streaming Protocol

Response: RTSP/1.0 200 OK\r\n

Status: 200

CSeq: 1\r\n

Date: Sun Dec 2 22:29:14 2007 GMT\r\n

Content-type: application/sdp

Content-length: 271

\r\n

Session Description Protocol

Session Description Protocol Version (v): 0

Owner/Creator, Session Id (o): - 0 0 IN IPV4 127.0.0.1

Time Description, active time (t): 0 0

Session Name (s): No Title

Session Attribute (a): tool:libavformat

Media Description, name and address (m): video 0 RTP/AVP 96

Media Attribute (a): rtpmap:96 MP4V-ES/90000

Media Attribute (a): fmtp:96 profile-level-id=1; config=0000000000 (...)

Media Attribute (a): control:streamid=0

Figure 69: Excerpt of the decoded packet headers from Wireshark

On the other hand, packet loss in the MPEG-1 stream resulted in randomlycolored square artifacts at various places all over the video frames. The effecton the MPEG-1 video stream was arguably more objectionable than whatwas visible on the MPEG-4 video.

Using Wireshark, we saved the payload of the captured RTP streamsto file, and then calculated the MD5 checksum for each frame in each of thestreams using MPlayer. We then compared these checksums to the checksumsfor each of the original video clips. Each checksum mismatch then indicatedthat a frame was corrupted in some way.

But when playing the saved streams using MPlayer we quickly noticedthat they looked much worse than when they were played back during theexperiment. This means that the streams somehow got more corrupted whencaptured by the sniffer, and/or that Wireshark corrupted the stream whenextracting it from the captured packets and saved it to file. We thereforedisregarded the results of this analysis.

Summary In this scenario, we see that the streaming server does not reallyconsume a lot of resources per stream. Playback of the video on the client ismuch more expensive. Coupled with the overhead of network transmissionand streaming, playback of the 1000 Kbps streams is choppy.

120

Figure 70: MANET experiment setup

7.3.3 Scenario 3: MANET

The measurement equipment in the third scenario consisted of three Nokia770s, and one Dell laptop. The Nokias formed a three-node mobile ad-hocnetwork, connected as in Figure 70. Please see 7.2.5 for details. To furtherensure that the two end-nodes would be out of radio range of each other, thetransmission power was lowered to 10mW in the end-nodes, while the powerat the intermediate node was kept at 100mW. The Dell laptop was placednext to the intermediate node, to sniff and store all wireless transmissions inthe MANET.

There was no mobility and the network, so the routes were static. Evenso, observing the behavior of the intermediate node, as well as if and how theOLSR daemon affected the streaming performance, was interesting in itself.

As in the second scenario, we streamed all 12 videos in sequence whileperforming measurements on all nodes of the network. Unfortunately therewere issues with the wireless sniffing node. For some reason it would capturea fraction of the packets on the network, and we were not able to rectify thissituation. Hence, we do not have a complete capture of the wireless trafficof the MANET in this scenario.

121

0

20

40

60

80

100

00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00

CP

U u

tiliz

atio

n (%

)

Time (MM:SS)

% user% system

Figure 71: CPU utilization: Server node streaming action clip at 400x2401000 Kbps with MPEG-4 encoding.

The hardware layer Figures 71 and 72 show that CPU utilization forboth server and client are comparable to that in the second scenario. Resultsfor the other clips are also similar to the ones from scenario 2.

In Figure 73 on the next page, we can see the graph of the CPU utilizationfor intermediate node in the 3-node MANET. We see that the user CPU loadis at the idle level, as no extra user processes are running, apart from thebasic services. When looking at the system CPU load, however, we see thatit is even higher than on the server node, sometimes spiking up to 60%.

From Figure 74 on page 124, we see that the results for low bandwidthclip gives a somewhat more positive outlook.

Comparing it to the graph for the server in Figure 75 on page 124 showsthat the CPU utilization when playing the low-bandwidth stream is aboutthe same for the server and the intermediate node.

Figure 76 on page 125 shows that the client is still under quite heavyload, even when playing a low-bandwidth stream.

From the figures, we also see that something happened at about 02:55,which caused the clip to stop playing until 03:25, resulting in a sharp drop inCPU utilization on all nodes in the MANET. The network utilization for allthree nodes also drops at the same point in time. The graph for the serveris shown in Figure 77, and the graphs for the intermediate node and clientlook similar.

122

0

20

40

60

80

100

00:00 00:30 01:00 01:30 02:00 02:30 03:00 03:30 04:00 04:30 05:00 05:30 06:00

CP

U u

tiliz

atio

n (%

)

Time (MM:SS)

% user% system

Figure 72: CPU utilization: Client node streaming action clip at 400x2401000 Kbps with MPEG-4 encoding.

0

20

40

60

80

100

00:00 00:30 01:00 01:30 02:00 02:30 03:00 03:30 04:00 04:30 05:00 05:30 06:00

CP

U u

tiliz

atio

n (%

)

Time (MM:SS)

% user% system

Figure 73: CPU utilization: Intermediate node streaming action clip at400x240 1000 Kbps with MPEG-4 encoding.

123

0

20

40

60

80

100

00:00 00:30 01:00 01:30 02:00 02:30 03:00 03:30 04:00 04:30 05:00 05:30

CP

U u

tiliz

atio

n (%

)

Time (MM:SS)

% user% system

Figure 74: CPU utilization: Intermediate node streaming action clip at240x144 200 Kbps with MPEG-4 encoding.

0

20

40

60

80

100

00:00 00:30 01:00 01:30 02:00 02:30 03:00 03:30 04:00 04:30 05:00 05:30 06:00

CP

U u

tiliz

atio

n (%

)

Time (MM:SS)

% user% system

Figure 75: CPU utilization: Server node streaming action clip at 240x144200 Kbps with MPEG-4 encoding.

124

0

20

40

60

80

100

00:00 00:30 01:00 01:30 02:00 02:30 03:00 03:30 04:00 04:30 05:00 05:30 06:00

CP

U u

tiliz

atio

n (%

)

Time (MM:SS)

% user% system

Figure 76: CPU utilization: Client node streaming action clip at 240x144200 Kbps with MPEG-4 encoding.

0

50

100

150

200

250

300

00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00

Kbp

s

Time (seconds)

Network transfer statistics

receivedtransmitted

Figure 77: Network activity: Server node streaming action clip at 240x144200 Kbps with MPEG-4 encoding.

125

0

20

40

60

80

100

00:00 00:30 01:00 01:30 02:00 02:30 03:00 03:30 04:00 04:30 05:00

Link

qua

lity

Time (MM:SS)

Figure 78: Link quality: Intermediate node streaming action clip at 240x144200 Kbps with MPEG-4 encoding.

The link layer When looking at the link quality reported by each of thenodes, we see that the intermediate node reports of an all-time low in thesame interval (Figure 78).

The graphs of the link quality reported by the server and client can beseen in Figures 79 and 80 respectively. As we can see, the server node re-ports a drop in link quality during the interval at which the streaming wasinterrupted, although it is not as low as on the intermediate node, and notany lower than reported at other times during the streaming session.

The link quality reported by the client node does not show such a pro-nounced drop at the interval in question. This could suggests that the inter-rupted transmission was due to a degraded wireless link between the serverand the intermediate node. Beware though, that as noted in Section 6, thelink quality value reported by iwconfig is undefined when in ad-hoc mode.Nonetheless, at least in this case, there seems to be a correlation.

The network layer As the routes are supposed to be static throughoutour measurements, there is not very much routing-related happening at thenetwork layer most of the time.

By examining the OLSR logs, we could confirm that there did not existat direct link between the server and the client nodes at any point duringthe measurements. But the logs also reveal that the routing table was notvery stable. According to the OLSR log on the server, the route between

126

0

20

40

60

80

100

00:00 00:30 01:00 01:30 02:00 02:30 03:00 03:30 04:00 04:30 05:00 05:30

Link

qua

lity

Time (MM:SS)

Figure 79: Link quality: Server node streaming action clip at 240x144 200Kbps with MPEG-4 encoding.

0

20

40

60

80

100

00:00 00:30 01:00 01:30 02:00 02:30 03:00 03:30 04:00 04:30 05:00

Link

qua

lity

Time (MM:SS)

Figure 80: Link quality: Client node streaming action clip at 240x144 200Kbps with MPEG-4 encoding.

127

the server and the client appears to have timed out and been deleted fromthe routing table 35 times while performing the MANET measurements dueto HELLO timeouts. Still, as only 1 video streams were interrupted duringplayback, it appears that this for the most part has not affected the routingof the video stream.

In fact, the reason for the interruption of clip 6 seems to be that the linkbetween the intermediate node and the client that went down. Just as thelink came back up, as the streaming resumed.

The transport layer Despite the failed link, we note that neither sar,nor RTCP, reports of any packet losses.

We also discovered that in order for Wireshark to perform IP bandwidthcalculation, it requires a complete packet trace of the RTP packets with thepayload. Since we were unable to make the wireless sniffer function correctlyin this scenario, and the nodes only capture the packet headers, we couldunfortunately not perform the bandwidth calculations.

On the other hand, the experiences from scenario 2, show that with ourRTP video stream being the only traffic being transmitted over the network,this bandwidth will be equal to what is reported by sar. However, in thisscenario, we also have some OLSR traffic. Still, we it is reasonably safe toassume that this only accounts for a small fraction of the total data traffic.Thus, the bandwidth figures reported by sar, should be a reasonable approx-imation to the total bandwidth consumed by the RTP stream.

Media layer Subjectively, the quality of the media stream was very sim-ilar, if not indistinguishable from the results in scenario 2. The only excep-tion to this being when the link between the intermediate node and clientnode went down during the streaming of clip number 6, at which point theplayback froze.

As the link came back up, playback resumed at the point where it wouldnormally have been if the streaming had not been interrupted. That is, itappears that the server did not halt the playback of the stream even if theonly client became unreachable.

Because of the trouble with the wireless sniffing in this scenario, we werenot able to compare the actual payload of the RTP streams to the originalvideo clips in order to objectively estimate the quality of the transmittedvideo stream. This also meant that we could not compare this to the resultsfrom scenario 2.

128

Summary Again we see that video playback causes the client to have thehighest CPU utilization of all three nodes in the network, although the inter-mediate node, which has to receive and forward each packet of the stream,also suffers from a pretty high load. While it is easily able to support a singlevideo stream, multiple streams could quite easily cause problems. The client,while able to play a single video stream, does not have the resources to domuch else. One could easily imagine that it would cause trouble if it wasrequired to forward traffic for other nodes in the MANET, for instance. Theload on all nodes also seems rather insensitive towards the encoding scheme.

7.4 Lessons learned

In general, we see that CPU utilization is an obvious issue in all the scenarios,and that the client and intermediate nodes suffer from the highest loads. Thiswill of course continue to improve with the introduction of newer and morepowerful devices, such as the Nokia N800 and N810, but it is clear thatconservation of CPU time must be a priority when designing a streamingsolution for MANETs.

To make sure that the performance of the 1000 Kbps stream was notlimited by the streaming server, we did a quick test by streaming to our laptopcomputer, also using MPlayer as the client. The stream played flawlessly. Infact, the server was able to server a total of 4 (four) 1000 Kbps streams toour laptop without experiencing any degradation in the quality of the stream.This proves that the bottleneck in our streaming experiment was in fact theNokia 770 client.

With regards to the monitoring, we see that sar provides us with largeamounts of resource data which is very helpful in diagnosing performanceissues on the Nokia devices. It was also able to consistently log statisticsat the requested 1 second intervals, unlike our logging results in the wirelessexperiment in Section 6.

As the measurements in this experiment only took about 1.5 hours foreach scenario, there were no issues with battery life as in the wireless exper-iment in Section 6

7.5 Playback on the Nokia N800

During the thesis work, we were also able to borrow one Nokia N800 toperform some test and compare the results to our experiences with the Nokia770. Due to time constraints, we had to limit our testing to a single scenario.We chose to measure the performance of the device during local playback of

129

CPU 320 MHz TI OMAPDisplay 800x480x16 touch-screenConnectivity 802.11g WLAN, Bluetooth 2.0Memory 128 MB DDR DRAMStorage 256 MB flash, two memory card slots (SD,

MicroSD, MiniSD, MMC, and RS-MMC -upgradable to 8 GB each)

Camera 640x480 web cameraDimensions 75 x 144 x 13 mmOther Built-in FM radio

Table 14: Nokia N800 hardware specifications (maemo.org, h)

video, as this turned out to be by far the most resource consuming task onthe 770.

7.5.1 About the Nokia N800

The Nokia N800 is the second generation of devices in Nokia’s Internet Tabletseries, and was released at the end of 2006. It is about the same size as the770, but has a much more robust and finished look. It has an more powerfulCPU and twice the amount of memory as the 770. In addition, it supportstwo memory cards of up to 8 GB capacity. Also, the device has a built-incamera, and an undocumented FM radio receiver. A summary of the N800’shardware specifications is provided in Table 14. The N800 runs OS2007,which is based on the 3.x series of the Maemo platform.

7.5.2 Performing the measurements

Before testing, we upgraded the device with the latest firmware, which atthe time was version 4.2007.38-2. This firmware update reportedly includesa bug fix relating to the memory cards (maemo.org, f).

The monitoring scripts and software worked without modification or re-compilation. FFserver also ran without problems, but was not used in thissmall experiment. The MPlayer we installed on the Nokia N800, was version1.0rc1-maemo.18.n800 armel.

In contrast with the Nokia 770 Video Player, the Nokia N800 MediaPlayer is also able to play videos without audio streams. We were thereforeable to conduct a performance test between MPlayer and the N800 MediaPlayer using our regular experiment videos. It is worth noting that the Nokia

130

Figure 81: The Nokia N800

N800 does not support DSP decoding of any video format. Decoding of mostcommon audio formats is still supported. maemo.org (c)

7.5.3 Results

Compared to the 770 version, MPlayer seems to consume considerably lessresources on the N800. In fact, it even consumes less resources than the NokiaN800 Media Player for both MPEG-4 and MPEG-1 video, the differencebeing the most substantial for MPEG-1 video.

An interesting observation is that the Media Player consumes consider-ably more resources when playing MPEG-1 video clips compared to MPlayer.The performance difference is still present when playing MPEG-4 clips, albeitless significant. This is exemplified in Figures 84, 85, 82 and 83.

We also noticed that playback appeared somewhat choppy when the re-source logging was enabled and writing the log file to the same memorycard as where the videos were stored and played from. The CPU utilizationand I/O logs did not reveal anything, but it could have been a performancelimitation with the memory card.

131

0

20

40

60

80

100

00:00 00:05 00:10 00:15 00:20 00:25 00:30 00:35 00:40 00:45 00:50 00:55 01:00

CP

U u

tiliz

atio

n (%

)

Time (MM:SS)

% user% system

Figure 82: CPU utilization: Playing MPEG-4 video in MPlayer on the N800.

0

20

40

60

80

100

00:00 00:05 00:10 00:15 00:20 00:25 00:30 00:35 00:40 00:45 00:50 00:55 01:00

CP

U u

tiliz

atio

n (%

)

Time (MM:SS)

% user% system

Figure 83: CPU utilization: Playing MPEG-4 in MediaPlayer on the N800.

132

0

20

40

60

80

100

00:00 00:05 00:10 00:15 00:20 00:25 00:30 00:35 00:40 00:45 00:50 00:55 01:00

CP

U u

tiliz

atio

n (%

)

Time (MM:SS)

% user% system

Figure 84: CPU utilization: Playing MPEG-1 video in MPlayer on the N800.

0

20

40

60

80

100

00:00 00:05 00:10 00:15 00:20 00:25 00:30 00:35 00:40 00:45 00:50 00:55 01:00

CP

U u

tiliz

atio

n (%

)

Time (MM:SS)

% user% system

Figure 85: CPU utilization: Playing MPEG-1 in MediaPlayer on the N800.

133

0

20

40

60

80

100

00:00 00:30 01:00 01:30 02:00 02:30 03:00 03:30 04:00 04:30 05:00

CP

U u

tiliz

atio

n (%

)

Time (MM:SS)

% user% system

Figure 86: CPU utilization: Local playback of action clip in 400x240 1000Kbps with MPEG-4 encoding in MPlayer on the N800.

0

20

40

60

80

100

00:00 00:30 01:00 01:30 02:00 02:30 03:00 03:30 04:00 04:30 05:00

CP

U u

tiliz

atio

n (%

)

Time (MM:SS)

% user% system

Figure 87: CPU utilization: Local playback of action clip in 400x240 1000Kbps with MPEG-4 encoding in MediaPlayer on the N800.

134

0

20

40

60

80

100

00:00 00:30 01:00 01:30 02:00 02:30 03:00 03:30 04:00 04:30 05:00

CP

U u

tiliz

atio

n (%

)

Time (MM:SS)

% user% system

Figure 88: CPU utilization: Local playback of action clip in 400x240 1000Kbps with MPEG-1 encoding in MPlayer on the N800.

0

20

40

60

80

100

00:00 00:30 01:00 01:30 02:00 02:30 03:00 03:30 04:00 04:30 05:00

CP

U u

tiliz

atio

n (%

)

Time (MM:SS)

% user% system

Figure 89: CPU utilization: Local playback of action clip in 400x240 1000Kbps with MPEG-1 encoding in MediaPlayer on the N800.

135

7.5.4 Lessons learned

From our measurements, we see that one generation of development hasresulted in considerable improvement in CPU power. This is good news, asthe results from our video streaming experiment with the Nokia 770, suggestthat the CPU is the greatest bottleneck on the device with regards to videostreaming performance.

As a side note relating to the Wireless driver: Although the wireless driverversion used in the N800 is version 1.2, compared to version 0.8.1 in the 770,by looking at the output from iwconfig, it appears to use the same methodof calculating link quality as the 770 (see Section 6.5).

136

8 Conclusions

8.1 Summary

This thesis has presented a working solution for serving and consumingstreaming video using the Nokia 770 Internet Tablet that can serve as astarting point for future work on video streaming in mobile ad-hoc networks.We have also shown how to perform cross-layer monitoring of this videostreaming solution through a strategy of combining hardware resource mon-itoring and different network measurement methods. The complete platformis based entirely on open-source software, and can thus be freely used andmodified for future research.

Through a set of experiments, we have demonstrated our MANET stream-ing solution, and used our monitoring strategies to analyze the performanceof video streaming with the Nokia 770 in three different scenarios. As part ofour experiments, we have shown an example on how to set up a small-scale,real-world testbed for mobile ad-hoc networks. In addition, our experimentsprovided valuable information regarding the Nokia 770’s hardware capabilit-ies. Some of the observations made can probably also be extended to ad-hocnetwork nodes in general.

Results show that the playback of the video stream consumes a largeamount of resources on the client. In the three-node scenario, we could alsosee that the intermediate node consumes about twice as much CPU resourcesper video stream as the server, as forwarding requires both receiving andsending at the same time.

To avoid degrading the normal operation of the devices or the networkduring streaming, conservation of CPU resources must therefore be a prioritywhen designing a video streaming solution for mobile ad-hoc networks. Forthe Nokia 770 and similar devices, this implies that the DSP core shouldbe used for decoding multimedia data, in order to offload the CPU core.Otherwise, one runs the risk that a node playing a video stream does nothave spare CPU resources to perform other important tasks.

While MPlayer did not provide the best performance on the Nokia 770,we have seen that when running on the N800, it performs better than thestandard MediaPlayer that is bundled with the device during local playbackof video files. From our experiments with the 770, we have seen that thedifference between local playback and streaming is very small in terms ofCPU utilization, which suggests that MPlayer also will perform much betterin a streaming solution on the N800.

Also, when comparing the 770 to the N800, we see that one generationof development has resulted in considerable improvement in terms of CPU

137

power. Since our results show that the CPU of the 770 was the greatestperformance bottleneck in the video streaming solution, this strengthens theposition of the Nokia Internet Tablet Series as a good choice of devices forfuture experiments.

8.2 Critical evaluation

During the wireless experiment in Section 6, we could have used a morereliable method of bandwidth measurement, as the performance of the filetransfers are heavily dependant on features of TCP. Also, as multimediastreams are normally transported using unreliable protocols, such as RTP, theresults of these measurements are not very representative for the performanceof video streaming. A more reliable way of measuring available bandwidthcould be performed using a dedicated tool, such as Iperf.

Looking back at the experiences from the video streaming experiment inSection 7 and the results produced, the amount of trouble we experiencedwith the wireless sniffing was very disappointing. Unfortunately, time didnot permit further investigation of the cause of these issues. The traces wewere able to capture in the node-to-node streaming experiment turned outto be very useful, and they would probably have been a greater source of linklayer information in the MANET experiment.

With regards to the video quality evaluation, our method of comparingthe original clips to the stream captured by the wireless sniffer turned out tobe unsuccessful. This could perhaps have been avoided by letting the clientsave the stream to disk while playing. On the other hand, there is a riskof this requiring too much resources, influencing the playback of the streamand affecting the results.

As subjective evaluation of quality, just noting the general impressionof the quality of the video while performing the measurements, turned outto be adequate for the purposes of this thesis, although using a Bluetoothkeyboard would have enabled us to use MPlayer’s edit decision list featureto mark low quality parts.

In conclusion, the hardware measurements performed with sar turnedout to be the most successful. An important hardware related parameterthat was not measured, however, was power consumption.

8.3 Open problems and future work

Due to time constraints, we were not able to properly analyze all staticsgathered by RTP/RTCP. Time also prevented us from computing and ana-lyzing route stability metrics. Other open problems include finding a reliable

138

way of capturing wireless traces so that the link layer mechanics in the smallMANET streaming scenario can be properly analyzed. Also, finding out whatcaused the corruption of the captured video stream and solving this, wouldenable us to compare the captured stream to the original and providing anobjective QoS measurement of the received video stream.

Furthermore, examining the performance of video streaming on the newerNokia N800, as well as the N810, which was released in late 2007 would beinteresting. These devices are faster, more stable and have better software.The possibility of using the standard MediaPlayer on these devices for play-back of the video streams could also be investigated. This would have thebenefit of being able to use a video player that is more integrated into thestandard desktop, and avoiding the installation of extra software. Although,as mentioned, initial trials suggest that, in contrast to the situation on the770, MPlayer may actually outperform the standard MediaPlayer on theN800.

It would also be interesting to devise a solution to stream video from thebuilt-in camera of these devices, instead of just streaming from existing videofiles stored on disk, as this would more closely resemble how the solution isenvisioned to work in e.g. real-world emergency and rescue scenarios. Thecombination of FFmpeg and FFserver should support this, and there existsseveral examples on how set this up on regular desktop computers.

Future work include finding a scalable method of building real-worldMANET testbeds, and incorporating mobility into the testbed. This wouldthen allow us to explore the effects of mobility and route changes during aMANET streaming experiment. The trials we did with a static setup is notvery realistic, so this is very interesting and important work.

As the size of the network increases and mobility is introduced, it willalso become increasingly difficult to obtain complete wireless traces of thenetwork in a reliable manner. One would need to use multiple sniffer nodes,and be able to merge the logs in order to obtain the complete picture. Amethod of capturing link layer information locally on each node would bepreferable, but it is unclear whether this is possible.

139

ReferencesDaniel Aguayo, John Bicket, Sanjit Biswas, Glenn Judd, and Robert Morris. Link-level measurements

from an 802.11b mesh network. SIGCOMM Comput. Commun. Rev., 34(4):121–132, 2004. ISSN0146-4833.

Joshua Bardwell. You Believe You Understand What You Think I Said..., The Truth About 802.11 SignalAnd Noise Metrics, 2004.

G. Bianchi, F. Formisano, and D. Giustiniano. 802.11b/g link level measurements for an outdoor wire-less campus network. World of Wireless, Mobile and Multimedia Networks, 2006. WoWMoM 2006.International Symposium on a, pages 6 pp.–, June 2006.

Oliver Brown. Streaming video to the nokia 770 - oliver brown, January 2007. URLhttp://www.oliverbrown.me.uk/2007/01/22/ streaming-video-to-the-nokia-770/.

Wenli Chen, Nitin Jain, and S. Singh. Anmp: ad hoc network management protocol. Selected Areas inCommunications, IEEE Journal on, 17(8):1506–1531, August 1999. ISSN 0733-8716.

T. Clausen and P. Jacquet. Optimized Link State Routing Protocol (OLSR). RFC 3626 (Experimental),October 2003. URL http://www.ietf.org/rfc/rfc3626.txt.

CX3110x Linux 2.6 driver. garage: Cx3110x linux 2.6 driver, January 2008. URLhttps://garage.maemo.org/projects/cx3110x/.

Saumitra M. Das, Himabindu Pucha1, Konstantina Papagiannaki, and Y. Charlie Hu. Studying wirelessrouting link metric dynamics. In IMC ’07: Proceedings of the 7th ACM SIGCOMM conference onInternet measurement, pages 327–332, October 2007. ISBN 978-1-59593-908-1.

U. Deshpande, T. Henderson, and D. Kotz. Channel sampling strategies for monitoring wireless net-works. Modeling and Optimization in Mobile, Ad Hoc and Wireless Networks, 2006 4th InternationalSymposium on, pages 1–7, April 2006.

Richard Draves, Jitendra Padhye, and Brian Zill. Routing in multi-radio, multi-hop wireless mesh net-works. In MobiCom ’04: Proceedings of the 10th annual international conference on Mobile computingand networking, pages 114–128, New York, NY, USA, 2004. ACM Press. ISBN 1-58113-868-7.

Bernd Eckenfels. Linux Programmer’s Manual, November 2001. netstat - Print network connections,routing tables, interface statistics, masquerade connections, and multicast memberships.

Laura Marie Feeney. A taxonomy for routing protocols in mobile ad hoc networks. Technical ReportT99–07, Swedish Institute of Computer Science, October 1999.

Sana Ghannay, Sonia Mettali Gammar, Farouk Kamoun, and Davor Males. The monitoring of ad hoc net-works based on routing. In MEDHOCNET ’04: The Third Annual Mediterranean Ad Hoc NetworkingWorkshop, June 2004.

Jasminder Grewal and John M. DeDourek. A framework for quality of service in wireless networks. InCNSR ’05: Proceedings of the 3rd Annual Communication Networks and Services Research Conference(CNSR’05), pages 231–236, Washington, DC, USA, 2005. IEEE Computer Society. ISBN 0-7695-2333-1.

GStreamer: open source multimedia framework. GStreamer: open source multimedia framework, January2008. URL http://gstreamer.freedesktop.org.

Stephen R. Gulliver and Gheorghita Ghinea. Real-time monitoring of video quality in ip networks. ACMTransactions on Multimedia Communications and Applications, 2:241–257, November 2006.

Gavin Holland and Nitin Vaidya. Analysis of tcp performance over mobile ad-hoc networks. TechnicalReport 99-004, Texas A&M University - Dept. of Computer Science, February 1999.

140

Mathias Hollick and Ralf Steinmetz. Lecture notes in advanced topics in distributed systems- mobile ad-hoc networking. URL http://www.uio.no/studier/emner/matnat/ifi/INF5090/v06/

undervisningsmateriale/MANETs-2006.pdf. ., March 2006.

IEEE-SA Standards Board. ANSI/IEEE Std 802.11, 1999.

Ikke’s Blog. Ikke’s blog - post details: Maemo/nokia 770 sound streaming, June 2006. URLhttp://blog.eikke.com/index.php/ikke/2006/06/14/.

Sushant Jadhav, Timothy Brown, Sheetalkumar Doshi, Daniel Henkel, and Roshan Thekkekunnel. Lessonslearned constructing a wireless ad hoc network test bed. In First Workshop on Wireless NetworkMeasurements, April 2005.

James T. Kaba and Douglas R. Raichle. Testbed on a desktop: strategies and techniques to support multi-hop manet routing protocol development. In MobiHoc ’01: Proceedings of the 2nd ACM internationalsymposium on Mobile ad hoc networking & computing, pages 164–172, New York, NY, USA, 2001.ACM. ISBN 1-58113-428-2.

S.K. Kaul, M. Gruteser, and I. Seskar. Creating wireless multi-hop topologies on space-constrained in-door testbeds through noise injection. Testbeds and Research Infrastructures for the Development ofNetworks and Communities, 2006. TRIDENTCOM 2006. 2nd International Conference on, pages 10pp.–, March 2006.

Y. Kikuchi, T. Nomura, S. Fukunaga, Y. Matsui, and H. Kimata. RTP Payload Format forMPEG-4 Audio/Visual Streams. RFC 3016 (Proposed Standard), November 2000. URLhttp://www.ietf.org/rfc/rfc3016.txt.

Yevgeni Koucheryavy, Dmitri Moltchanov, and Jarmo Harju. Performance evaluation of live videostreaming service in 802.11b wlan environment under different load conditions. Technical report,Institute of Communication Engineering, Tampere University of Technology, September 2004. URLhttp://www.cs.tut.fi/tlt/npg/icefin/documents/mips2003moltch.pdf.

Tianbo Kuang and Carey Williamson. Realmedia streaming performance on an ieee 802.11b wireless lan.Technical report, Department of Computer Science, University of Calgary, 2002.

Ted Taekyoung Kwon, Mario Gerla, Sajal Das, and Subir Das. Mobility management for voip service:Mobile ip vs. sip. IEEE Wireless Communications, 9:66 – 75, October 2002.

Baochun Li and K.H. Wang. Nonstop: continuous multimedia streaming in wireless ad hoc networks withnode mobility. Selected Areas in Communications, IEEE Journal on, 21(10):1627–1641, December2003. ISSN 0733-8716.

Joshua Lifton. Streaming live audio and video from a nokia n800 to second life, April 2007. URLhttp://web.media.mit.edu/~lifton/snippets/n800 to sl/.

Linux Programmer’s Manual. Linux Programmer’s Manual, December 2003a. iwgetid - Report ESSID,NWID or AP/Cell Address of wireless network.

Linux Programmer’s Manual. Linux Programmer’s Manual, May 2005b. proc - process informationpseudo-filesystem.

Linux Programmer’s Manual. Linux Programmer’s Manual, March 2006c. iwspy - Get wireless statisticsfrom specific nodes.

LIVE555. Rtsp/rtp streaming support for mplayer, January 2008. URLhttp://www.live555.com/mplayer/.

Thomas Lopatic. olsrd Link Quality Extensions, December 2004. URLhttp://www.olsr.org/docs/README-Link-Quality.html.

maemo.org. HOWTO Flash latest Nokia image with Linux, Januar 2008a. URLhttp://maemo.org/community/wiki/HOWTO FlashLatestNokiaImageWithLinux.

141

maemo.org. Maemo 2.x multimedia architecture, January 2008b. URLhttp://maemo.org/development/documentation/how-tos/2-x/multimedia architecture.html.

maemo.org. Maemo 3.x multimedia architecture, January 2008c. URLhttp://maemo.org/development/documentation/how-tos/3-x/multimedia architecture.html.

maemo.org. Maemo 3.x: Transcoding how-to, January 2008d. URLhttp://maemo.org/development/documentation/how-tos/3-x/transcoding how-to.html.

maemo.org. Maemo Connectivity Architecture, January 2008e. URLhttp://maemo.org/development/documentation/how-tos/2-x/howto connectivity guide.html.

maemo.org. Maemo.org, January 2008f. URL http://www.maemo.org.

maemo.org. Nokia 770 Hardware Specification, January 2008g. URLhttp://maemo.org/community/wiki/nokia 770 hardware specification/.

maemo.org. Nokia N800 Hardware Specification, January 2008h. URLhttp://maemo.org/community/wiki/nokia 800 hardware specification/.

maemo.org. Real Video Streams, January 2008i. URL http://maemo.org/community/wiki/

realvideostreams.

maemo.org. Video Encoding, January 2008j. URL http://maemo.org/community/wiki/VideoEncoding.

Aniket Mahanti, Martin Arlitt, and Carey Williamson. Assessing the completeness of wireless-side tracingmechanisms. World of Wireless, Mobile and Multimedia Networks, 2007. WoWMoM 2007. IEEEInternational Symposium on a, pages 1–10, June 2007.

MPlayer for Maemo. MPlayer for maemo (Nokia 770/N800), January 2008. URLhttp://mplayer.garage.maemo.org.

Don Ngo, Naveed Hussain, Mahbub Hassan, and Jim Wu. Wanmon: A resource usage monitoring tool forad hoc wireless networks. In LCN ’03: Proceedings of the 28th Annual IEEE International Conferenceon Local Computer Networks, page 738, Washington, DC, USA, 2003. IEEE Computer Society. ISBN0-7695-2037-5.

Nokia. Internet Tablet 2006 edition User’s Guide, 2006.

Python GStreamer Documents. Python GStreamer Documents, January 2008. URLhttp://pygstdocs.berlios.de.

Krishna Ramachandran, Irfan Sheriff, Elizabeth Belding, and Kevin Almeroth. Routing stability instatic wireless mesh networks. Technical report, University of California, Santa Barbara, 2007. URLhttp://www.cs.ucsb.edu/ isheriff/PAM07.pdf.

Amy R. Reibman, Vinay A. Vaishampayan, and Yegnaswamy Sermadevi. Quality monitoring of videoover a packet network. IEEE Transactions on Multimedia, 6:327–334, April 2004.

K. Rojviboonchai, Fan Yang, Qian Zhang, H. Aida, and Wenwu Zhu. Amtp: a multipath multime-dia streaming protocol for mobile ad hoc networks. Communications, 2005. ICC 2005. 2005 IEEEInternational Conference on, 2:1246–1250 Vol. 2, May 2005.

Norun Christine Sanderson, Katrine Stemland Skjelsvik, Ovidiu Valentin Drugan, Matija Puzar, VeraGoebel, Ellen Munthe-Kaas, and Thomas Plagemann. Developing mobile middleware - an analysisof rescue and emergency operations. Technical Report 358, Department of Informatics, University ofOslo, June 2007.

Ralf Steinmetz and Klara Nahrstedt. Multimedia Systems. Springer, Germany, 2004.

142

Yuan Sun, Irfan Sheriff, Elizabeth M. Belding-Royer, and Kevin C. Almeroth. An experimental study ofmultimedia traffic performance in mesh networks. In WiTMeMo ’05: Papers presented at the 2005workshop on Wireless traffic measurements and modeling, pages 25–30, Berkeley, CA, USA, 2005.USENIX Association. ISBN 1-931971-33-1.

Shu Tao, John Apostolopoulos, and Roch Guerin. Real-time monitoring of video quality in ip networks. InNOSSDAV ’05: Proceedings of the international workshop on Network and operating systems supportfor digital audio and video, pages 129–134, New York, NY, USA, 2005. ACM Press. ISBN 1-58113-987-X.

The ITU Radiocommunication Assembly. Methodology for the subjective assessment of the quality oftelevision pictures, 2002.

Josep Torra. The hitchhiker’s guide to the n770 galaxy, February 2006. URL n770galaxy.blogspot.com.

Jean Tourrilhes. Linux Programmer’s Manual, March 2006. iwconfig - configure a wireless networkinterface.

Jean Tourrilhes. Wireless tools for linux, October 2007. URLhttp://www.hpl.hp.com/personal/Jean Tourrilhes/Linux/Tools.html.

J. van der Meer, D. Mackie, V. Swaminathan, D. Singer, and P. Gentric. RTP Payload Format forTransport of MPEG-4 Elementary Streams. RFC 3640 (Proposed Standard), November 2003. URLhttp://www.ietf.org/rfc/rfc3640.txt.

Jacobus van der Merwe, Ramon Caceres, Yang hua Chu, and Cormac Sreenan. mmdump: a tool formonitoring internet multimedia traffic. SIGCOMM Comput. Commun. Rev., 30(5):48–59, 2000. ISSN0146-4833.

Zhou Wang, Alan Conrad Bovik, Hamid Rahim Sheikh, and Eero P. Simoncelli. Image quality assessment:From error visibility to structural similarity. IEEE Transactions on Image Processing, 13:600–612,April 2004.

Zhou Wang, Hamid R. Sheikh, and Alan C. Bovik. Objective video quality assessment. In B. Furht andO. Marqure, editors, The Handbook of Video Databases: Design and Applications, chapter 41, pages1041–1078. CRC Press, 2003.

Wireshark. The Wireshark Wiki, January 2008. URL http://wiki.wireshark.org.

Peng Xue and Surendar Chandra. Revisiting multimedia streaming in mobile ad hoc networks. In NOSS-DAV ’06. ACM, 2006. ISBN 1-59593-285-2/06/0005.

Jihwang Yeo, Moustafa Youssef, and Ashok Agrawala. A framework for wireless lan monitoring and itsapplications. In WiSe ’04: Proceedings of the 3rd ACM workshop on Wireless security, pages 70–79,New York, NY, USA, 2004. ACM. ISBN 1-58113-925-X.

Jihwang Yeo, Moustafa Youssef, Tristan Henderson, and Ashok Agrawala. An accurate technique formeasuring the wireless side of wireless networks. In WiTMeMo ’05: Papers presented at the 2005workshop on Wireless traffic measurements and modeling, pages 13–18, Berkeley, CA, USA, 2005.USENIX Association. ISBN 1-931971-33-1.

Qingguo Zhou, Shuwei Bai, Rui Zhou, Guanghui Cheng, Nicholas MC Guire, and Lian Li. p3m: A kernelspace tool for multimedia stream monitoring. Pervasive Computing and Applications, 2007. ICPCA2007. 2nd International Conference on, pages 679–684, July 2007.

Michael Zink. Scalable Internet Video-on-Demand Systems. PhD thesis, Technischen Universitt Darm-stadt, 2003.

143

A Configuration of software

A.1 Flashing the latest Nokia image

The flasher utility provided on the product page for the Nokia 770 on theNokia web site is for Windows only. However, a flasher for Linux and MacOSX can be found on http://tablets-dev.nokia.com/. Note that for the 770,both version 2.0 and version 3.0 of the flasher utility can be used. For theN800 (and the N810), version 3.0 is required.

Download the latest image from http://tablets-dev.nokia.com/. Atthe time of writing, this was U-18 2006SE 3.2006.49-2 PR F5 MR0 ARM.bin.Switch off the Nokia 770, and connect it to the computer using the USBcable. Then execute as root:

./flasher-3.0 -F SU-18_2006SE_3.2006.49-2_PR_F5_MR0_ARM.bin -f -R

The message ”Suitable USB device not found, waiting” will be displayed.Now, while holding the Home-button on the Nokia 770 pressed, switch it onusing the power button or by connecting the charger. The image should nowbe loaded onto the 770. The device should reboot automatically when it isdone. (maemo.org, a)

A.2 Gaining local root access on the Nokia 770

In order to gain root access on the Nokia 770, one needs to install an SSHserver on the device. One can choose between the two SSH servers OpenSSHand Dropbear, both installable from the repositories listed in Appendix A.5.Also, in order to able to gain root access locally on the device, one mustinstall xterm, which is also available from the listed repositories.

After the installation of the SSH server, connect to the device using anSSH client, and log in as root, with the default password rootme. Oncelogged in, change the root password using passwd.

Then, open the file /usr/sbin/gainroot using the text editor vi, andchange the line that says:

MODE=‘/usr/sbin/chroot /mnt/initfs cal-tool --get-rd-mode‘

so that it just reads:

MODE=enabled

You should now be able to gain root access by opening an Xterm window,and simply executing the command:

144

sudo gainroot

A.3 Setting up Scratchbox

Scratchbox is a toolkit used, among other things, to cross-compile software forthe Maemo platform. It can be downloaded and installed from the ScratchboxAPT source. At that time, of writing, the latest version version was 1.0.8.Install the following packages:

• scratchbox-core

• scratchbox-devkit-cputransp

• scratchbox-devkit-debian

• scratchbox-libs

• scratchbox-toolchain-cs2005q3.2-glibc2.5-arm

• scratchbox-toolchain-cs2005q3.2-glibc2.5-i386

Set up a scratchbox user account for an existing Linux user by running (asroot):

/scratchbox/sbin/sbox_adduser <username> yes

As root, start the Scratchbox control daemon with the command:

/scratchbox/sbin/sbox_ctl start

Users with Scratchbox user accounts can now log in to the Scratchbox envir-onment with the command:

/scratchbox/login

To configure the compilation target, log in to Scratchbox and run the com-mand:

sb-menu

Choose Setup, <NEW> and enter a name for the compilation target, e.g.armel. Select the cs2005q3.2-glibc2.5-arm compiler, and then the devkitscputransp and debian-lenny, and select DONE. For CPU-transparency method,select qemu-arm-0.8.2-sb2.

145

When you are asked to extract a rootstrap on the target, choose No. Whenyou are asked if you wish to install files to the target, choose No. When youare asked if you wish to select the target, select Yes.

Download the ARMEL SDK rootstrap from the Maemo repositories athttp://repository.maemo.org/stable/gregale/armel/

Maemo Dev Platform v2.2 armel-rootstrap.tgz, and copy it to the direct-ory /scratchbox/packages.

Finally, install the rootstrap by logging into Scratchbox, and running thecommand:

sbox-config -er /scratchbox/packages/Maemo_Dev_Platform_v2.2_armel-rootstrap.tgz

A.4 Compiling and running FFserver

Checkout FFmpeg from SVN. FFmpeg does not follow the convention ofhaving official release versions, but maintains a stable trunk version. TheFFmpeg team encourages everyone who needs to compile from source, tocompile from SVN.

svn checkout svn://svn.mplayerhq.hu/ffmpeg/trunk ffmpeg

At the time we checked out and compiled, the code was at revision 10835.

The compile process was configured using the following configure command:

./configure --arch=armv41 --enable-pp --enable-gpl --disable-ipv6

In order for FFmpeg to compile, we had to specify the architecture armv41

(”1” is the number and not the lowercase letter ”l”).A bug in FFserver required disabling IPv6 support at compile-time to

allow streaming through RTP, with the configure option --disable-ipv6.Otherwise, FFserver reported the error ”Bind: port already bound...” whentrying to set up an RTP connection.

A patch has been submitted on the FFserver mailing list. However, sincewe do not need IPv6 support in our experiments, we found it easier to justcompile FFserver with IPv6 disabled.

Some of the post-processing filters are not enabled by default, and mustbe enabled with the option --enable-pp. These libraries are licenced underthe GPL, and in order to use these, you therefore also need to include theoption --enable-gpl.

Afterwards, the code could successfully be compiled by running make.The resulting ffserver executable could then be copied to the Nokia 770.

146

A sample ffserver.conf to configure the server is included with the sourcecode.

A.5 Software repositories

The Nokia 770 software used in this thesis work can be installed from thefollowing repositories:

URL Distribution Components

http://catalogue.tableteer.nokia.com/certified/ mistral userhttp://catalogue.tableteer.nokia.com/non-certified/ mistral userhttp://repository.maemo.org mistral free non-freehttp://repository.maemo.org/extras mistral free non-freehttp://www.mulliner.org/nokia770/repository maemo2 freehttp://maemo-hackers.org/apt mistral mainhttp://mg.pov.lt/770 mistral user other experimentalhttp://www.math.ucla.edu/ jimc/nokia770 mistral userhttp://scratchbox.org/debian stable main

147

B Source code

B.1 wlantest.sh

1 #!/ bin /sh23 # Author :4 # Magnus E. Halvorsen ( magnuseh@ifi . uio . no)56 p r i n t h e l p ( )7 {8 echo ”Usage : ‘ basename $0 ‘ i n t e r f a c e i n t e r v a l ” ;9 }

1011 # Check f o r cor r e c t number o f command l i n e arguments .12 i f [ ”$#” != ”2” ]13 then14 p r i n t h e l p ;15 exit 1 ;16 f i1718 INTERFACE=$1 ;19 INTERVAL=$2 ;2021 # Star t the l o g g i ng process .22 LOG HOSTINFO=” hos t i n f o . l og ” ;23 LOG SCANNING=” scanning . l og ” ;24 LOG IWCONFIG=” iwcon f i g . l og ” ;25 LOG WIRELESS=” w i r e l e s s . l og ” ;26 LOG DEV=”dev . l og ” ;27 LOG IFCONFIG=” i f c o n f i g . l og ” ;2829 # Get some informat ion about the hos t .30 COMMANDLINE=”$0 $1 $2 $3” ;31 IPADDRESS=‘ i f c o n f i g | grep $INTERFACE −A1 | grep ” i n e t addr : ” | \32 cut −d : −f 2 | cut −d ’ ’ −f1 ‘ ;33 OSPLATFORM=‘uname −srm ‘ ;34 STARTTIME=‘date ‘ ;35 HOSTNAME=‘hostname ‘ ;3637 # Create and cd in to l og d i r e c t o r y38 LOGDIR=” l og $ {HOSTNAME} ‘ date +”%Y%m%d %H%M%S” ‘ ”39 mkdir $LOGDIR40 cd $LOGDIR4142 # Print and l og hos t informat ion .43 p r i n t f ”Command l i n e : ’$COMMAND LINE’\n” ;44 p r i n t f ”Command l i n e : ’$COMMAND LINE’\n” >> $LOG HOSTINFO;45 p r i n t f ”IP/Hostname : $IPADDRESS ($HOSTNAME)\n” ;46 p r i n t f ”IP/Hostname : $IPADDRESS ($HOSTNAME)\n” >> $LOG HOSTINFO;47 p r i n t f ”OS/Platform : $OSPLATFORM\n” ;48 p r i n t f ”OS/Platform : $OSPLATFORM\n” >> $LOG HOSTINFO;49 p r i n t f ”Logging s ta r t ed at : $STARTTIME\n\n” ;50 p r i n t f ”Logging s ta r t ed at : $STARTTIME\n\n” >> $LOG HOSTINFO;5152 # Print and l og scanning o f w i r e l e s s f r e quenc i e s to de t e c t o ther networks .53 # EDIT:54 # This w i l l o f t en di sconnec t or crash the Nokia dev i ce s , so we s k i p t h i s par t .55 #OUTPUT SCANNING=‘ i w l i s t $INTERFACE scanning ‘56 #pr i n t f ”${OUTPUT SCANNING}\n\n” ;

148

57 #pr i n t f ”${OUTPUT SCANNING}\n\n” >> $LOG SCANNING;5859 # Star t l o g g i ng the r e s u l t s .60 while true61 do62 # Timestamp every l og entry .63 TIME=‘date +”%F %H:%M:%S” ‘ ;64 LOGLINE PREFIX=”Time : ${TIME}\n” ;6566 # Run the commands and s t o r e the output .67 OUTPUT IWCONFIG=‘ iwcon f i g $INTERFACE‘ ;68 OUTPUT IFCONFIG=‘ i f c o n f i g $INTERFACE‘ ;69 OUTPUT WIRELESS=‘cat /proc /net / w i r e l e s s | grep $INTERFACE‘ ;70 OUTPUT DEV=‘cat /proc / net /dev | grep $INTERFACE‘ ;7172 # Print output to t e rmina l and l og f i l e s .73 p r i n t f ”${LOGLINE PREFIX}${OUTPUT IWCONFIG}\n\n” ;74 p r i n t f ”${LOGLINE PREFIX}${OUTPUT IWCONFIG}\n\n” >> $LOG IWCONFIG;7576 p r i n t f ”${LOGLINE PREFIX}${OUTPUT IFCONFIG}\n\n” ;77 p r i n t f ”${LOGLINE PREFIX}${OUTPUT IFCONFIG}\n\n” >> $LOG IFCONFIG ;7879 p r i n t f ”${LOGLINE PREFIX}${OUTPUT WIRELESS}\n\n” ;80 p r i n t f ”${LOGLINE PREFIX}${OUTPUT WIRELESS}\n\n” >> $LOG WIRELESS;8182 p r i n t f ”${LOGLINE PREFIX}${OUTPUT DEV}\n\n” ;83 p r i n t f ”${LOGLINE PREFIX}${OUTPUT DEV}\n\n” >> $LOG DEV;8485 s l e ep $INTERVAL;86 done8788 # Remember to cd back out o f t he l o g d i r e c t o r y .89 cd . .

149

B.2 generate plotdata.py

1 #!/ usr / bin /python23 # Author :4 # Magnus E. Halvorsen ( magnuseh@ifi . uio . no)56 # Parses l o g f i l e s c reat ed by ’ w l an t e s t . sh ’ and output s data f o r p l o t t i n g .78 from datet ime import datet ime9 import r e

10 import sys1112 def get next t imestamp ( f ) :1314 match = None1516 # Search f o r next timestamp .17 while not match :18 l i n e = f . r e a d l i n e ( )1920 i f l i n e == ”” :21 # Reached end of l o g f i l e . Stop pars ing .22 return None2324 # Search l i n e f o r s t a r t o f next l o g entry .25 match = re t imestamp . s ear ch ( l i n e )2627 # Parse and return timestamp .28 return datet ime ( i n t (match . group ( ’ year ’ ) ) , i n t (match . group ( ’month ’ ) ) ,29 i n t (match . group ( ’ day ’ ) ) , i n t (match . group ( ’ hour ’ ) ) , \30 i n t (match . group ( ’ minute ’ ) ) , i n t (match . group ( ’ second ’ ) ) )3132 i f l en ( sys . argv ) != 3 :3334 # Print usage he lp .35 print ”Usage : ” + sys . argv [ 0 ] + ” <regexp> l o g f i l e 1 ”36 sys . e x i t (1)3738 re t imestamp = re . compi le ( r ”Time : (?P<year >\d+)−(?P<month>\d+)−(?P<day>\d+)\ s+”39 ” (?P<hour>\d+): (?P<minute>\d+): (?P<second >\d+)” )40 r e r egexp = re . compi le ( sys . argv [ 1 ] )4142 # Open log f i l e s p e c i f i e d as parameters f o r pars ing .43 l o g f i l e = open ( sys . argv [ 2 ] , ” r ” )4445 # Contains the timestamp of the next l o g entry to be parsed f o r each f i l e .46 current t imestamp = {}4748 par s ing = True4950 # Print a header f o r the output .51 header = ”# Regexp : ” + sys . argv [ 1 ] + ”\n”5253 print header + ”\n”5455 while par s ing :5657 # Line to be output a f t e r the process ing the current entry o f each l og f i l e .58 l i n e t o p r i n t = ””59

150

60 current t imestamp = get next t imestamp ( l o g f i l e )6162 i f current t imestamp == None :6364 # End of f i l e . Stop pars ing .65 break6667 print ”%02d:%02d:%02d\ t ” % \68 ( current t imestamp . hour , current t imestamp . minute , current t imestamp . second ) ,6970 match = None7172 # Find the next l i n e t ha t conta ins a s p e c i f i e d pat t e rn .73 while match == None :7475 l i n e = l o g f i l e . r e a d l i n e ( )7677 i f l i n e == ”” :78 # Reached end of l o g f i l e . Stop pars ing .79 par s ing = Fal s e80 break8182 # Search l i n e f o r the s p e c i f i e d pat t e rn .83 match = re r egexp . s ear ch ( l i n e )8485 i f not par s ing :86 break8788 print match . group (1)899091 l o g f i l e . c l o s e ( )

151

B.3 generate all plots.sh

1 #!/ bin /sh23 p r i n t h e l p ( )4 {5 echo ”Runs gnuplot on a l l . gnuplot f i l e s i n a d i r e c to r y . ” ;6 echo ”Usage : ‘ basename $0 ‘ DIRECTORY” ;7 }89 # Check f o r cor r e c t number o f command l i n e arguments .

10 i f [ ”$#” != ”1” ]11 then12 p r i n t h e l p ;13 exit 1 ;14 f i1516 # Move in to d i r e c t o r y .17 cd ”$1” ;1819 # Run gnup lo t .20 for i i n ‘ l s ∗ . gnuplot ‘ ;21 do22 gnuplot ” $ i ” ;23 done

152

B.4 resourcelogger.sh

1 #!/ bin /sh23 # Author :4 # Magnus E. Halvorsen ( magnuseh@ifi . uio . no)56 p r i n t h e l p ( )7 {8 echo ”Usage : ‘ basename $0 ‘ <l og di r> [ i n t e r v a l ] ” ;9 }

1011 # Check f o r cor r e c t number o f command l i n e arguments .12 i f [ ”$#” = ”1” ]13 then14 INTERVAL=”1” ;1516 e l i f [ ”$#” = ”2” ]17 then18 INTERVAL=$2 ;19 else20 p r i n t h e l p ;21 exit 1 ;22 f i2324 LOG DIR=$1 ;2526 # Star t the l o g g i ng process .27 LOG HOSTINFO=” hos t i n f o . l og ” ;28 LOG SAR=” sar . l og ” ;29 LOG PIDSTAT=” p id s ta t . l og ” ;3031 # Get some informat ion about the hos t .32 COMMANDLINE=”$0 $∗” ;33 INTERFACE=‘ iwcon f i g 2> /dev/ nu l l | grep ”ESSID” | cut −d ’ ’ −f1 ‘ ;34 IPADDRESS=‘ i f c o n f i g | grep $INTERFACE −A1 | grep ” i n e t addr : ” | \35 cut −d : −f 2 | cut −d ’ ’ −f1 ‘ ;36 OSPLATFORM=‘uname −srm ‘ ;37 STARTTIME=‘date ‘ ;38 HOSTNAME=‘hostname ‘ ;3940 # Create l o g d i r e c t o r y41 LOG DIR=”${LOG DIR}/ l o g r e s ou r c e $ {HOSTNAME} ‘ date +”%Y%m%d %H%M%S” ‘ ”42 mkdir −p ${LOG DIR}4344 # Print and l og hos t informat ion .45 p r i n t f ”Command l i n e : ’$COMMAND LINE’\n” ;46 p r i n t f ”Command l i n e : ’$COMMAND LINE’\n” >> ${LOG DIR}/${LOG HOSTINFO} ;47 p r i n t f ”IP/Hostname : $IPADDRESS ($HOSTNAME)\n” ;48 p r i n t f ”IP/Hostname : $IPADDRESS ($HOSTNAME)\n” >> \49 ${LOG DIR}/${LOG HOSTINFO} ;50 p r i n t f ”OS/Platform : $OSPLATFORM\n” ;51 p r i n t f ”OS/Platform : $OSPLATFORM\n” >> ${LOG DIR}/${LOG HOSTINFO} ;52 p r i n t f ”Logging s ta r t ed at : $STARTTIME\n” ;53 p r i n t f ”Logging s ta r t ed at : $STARTTIME\n” >> ${LOG DIR}/${LOG HOSTINFO} ;5455 # Star t l o g g i ng .56 sar −o ${LOG DIR}/${LOG SAR} −Ap ${INTERVAL} 0 > /dev/ nu l l 2>&1 &57 PID SAR=$ ! ;5859 # Stop l og g i ng when a key i s pre ssed .

153

60 read −p ”Press any key to stop . . . ” r ep ly61 p r i n t f ” K i l l i n g l ogg i ng p r oc e s s e s . . . ”62 k i l l $PID SAR63 wait64 p r i n t f ”Done .\n”

154

B.5 networklogger.sh

1 #!/ bin /sh23 # Author :4 # Magnus E. Halvorsen ( magnuseh@ifi . uio . no)56 p r i n t h e l p ( )7 {8 echo ”Usage : ‘ basename $0 ‘ <l og di r> < i n t e r f a c e > <rtp−port> [ i n t e r v a l ] ” ;9 }

1011 # Check f o r cor r e c t number o f command l i n e arguments .12 i f [ ”$#” = ”3” ]13 then14 INTERVAL=”1” ;1516 e l i f [ ”$#” = ”4” ]17 then18 INTERVAL=$4 ;19 else20 p r i n t h e l p ;21 exit 1 ;22 f i2324 LOG DIR=$1 ;25 INTERFACE=$2 ;26 RTP PORT=$3 ;27 RTCP PORT=‘expr ${RTP PORT} + 1 ‘28 OLSR PORT=”698” ;2930 LOG HOSTINFO=” hos t i n f o . l og ” ;31 LOG IWCONFIG=” iwcon f i g . l og ” ;32 LOGTCPDUMP=”tcpdump . pcap” ;3334 # Get some informat ion about the hos t .35 COMMANDLINE=”$0 $∗” ;36 IPADDRESS=‘ i f c o n f i g | grep $INTERFACE −A1 | grep ” i n e t addr : ” | \37 cut −d : −f 2 | cut −d ’ ’ −f1 ‘ ;38 OSPLATFORM=‘uname −srm ‘ ;39 STARTTIME=‘date ‘ ;40 HOSTNAME=‘hostname ‘ ;4142 # Create l o g d i r e c t o r y43 LOG DIR=”${LOG DIR}/ log network $ {HOSTNAME} ‘ date +”%Y%m%d %H%M%S” ‘ ” ;44 mkdir −p ${LOG DIR} ;4546 # Print and l og hos t informat ion .47 p r i n t f ”Command l i n e : ’$COMMAND LINE’\n” ;48 p r i n t f ”Command l i n e : ’$COMMAND LINE’\n” >> ${LOG DIR}/${LOG HOSTINFO} ;49 p r i n t f ”IP/Hostname : $IPADDRESS ($HOSTNAME)\n” ;50 p r i n t f ”IP/Hostname : $IPADDRESS ($HOSTNAME)\n” >> \51 ${LOG DIR}/${LOG HOSTINFO} ;52 p r i n t f ”OS/Platform : $OSPLATFORM\n” ;53 p r i n t f ”OS/Platform : $OSPLATFORM\n” >> ${LOG DIR}/${LOG HOSTINFO} ;54 p r i n t f ”Logging s ta r t ed at : $STARTTIME\n” ;55 p r i n t f ”Logging s ta r t ed at : $STARTTIME\n” >> ${LOG DIR}/${LOG HOSTINFO} ;5657 # Star t l o g g i ng WLAN informat ion .58 wlanmonitor . sh ${INTERVAL} >> ${LOG DIR}/${LOG IWCONFIG} &59 PID WLANMONITOR=$ ! ;

155

6061 # Star t l o g g i ng OLSR, RTP and RTCP t r a f f i c .62 tcpdump −w ${LOG DIR}/${LOGTCPDUMP} − i ${INTERFACE} −s 128 \63 −n port ${OLSR PORT} or port ${RTP PORT} or port ${RTCP PORT} > \64 /dev/ nu l l 2>&1 &65 PID TCPDUMP=$ ! ;6667 # Stop l og g i ng when a key i s pre ssed .68 read −p ”Press any key to stop . . . ” r ep ly69 p r i n t f ” K i l l i n g l ogg i ng p r oc e s s e s . . . ”70 k i l l $PID WLANMONITOR $PID TCPDUMP;71 wait72 p r i n t f ”Done .\n”

156

B.6 wlanmonitor.sh

1 #!/ bin /sh23 # Author :4 # Magnus E. Halvorsen ( magnuseh@ifi . uio . no)56 p r i n t h e l p ( )7 {8 echo ”Usage : ‘ basename $0 ‘ [ i n t e r v a l ] ” ;9 }

1011 # Check f o r cor r e c t number o f command l i n e arguments .12 i f [ ”$#” = ”0” ]13 then14 INTERVAL=”1” ;1516 e l i f [ ”$#” = ”1” ]17 then18 INTERVAL=$1 ;19 else20 p r i n t h e l p ;21 exit 1 ;22 f i2324 while true25 do26 # Timestamp every l og entry .27 p r i n t f ”Time : ‘ date +’%F %H:%M:%S ’ ‘ \n” ;28 iwcon f i g 2> /dev/ nu l l ;2930 s l e ep ${INTERVAL}31 done

157

B.7 start ffserver.sh

1 #!/ bin /sh23 # Author :4 # Magnus E. Halvorsen ( magnuseh@ifi . uio . no)56 p r i n t h e l p ( )7 {8 echo ”Usage : ‘ basename $0 ‘ <l og di r>” ;9 }

1011 # Check f o r cor r e c t number o f command l i n e arguments .12 i f [ ”$#” != ”1” ]13 then14 p r i n t h e l p ;15 exit 1 ;16 f i1718 LOG DIR=$1 ;19 mkdir −p ${LOG DIR} ;2021 f f s e r v e r | tee ${LOG DIR}/ l o g f f s e r v e r ‘ date +”%Y%m%d %H%M%S” ‘

158

B.8 start olsrd.sh

1 #!/ bin /sh23 # Author :4 # Magnus E. Halvorsen ( magnuseh@ifi . uio . no)56 p r i n t h e l p ( )7 {8 echo ”Usage : ‘ basename $0 ‘ <l og di r>” ;9 }

1011 # Check f o r cor r e c t number o f command l i n e arguments .12 i f [ ”$#” != ”1” ]13 then14 p r i n t h e l p ;15 exit 1 ;16 f i1718 LOG DIR=$1 ;19 mkdir −p ${LOG DIR} ;2021 o l s r d > ${LOG DIR}/ l o g o l s r d ‘ date +”%Y%m%d %H%M%S” ‘

159

B.9 playallstreams.sh

1 #!/ bin /sh23 # Author :4 # Magnus E. Halvorsen ( magnuseh@ifi . uio . no)56 p r i n t h e l p ( )7 {8 echo ”Usage : ‘ basename $0 ‘ <l og di r> <s e rver > <rtp−port>” ;9 }

1011 # Check f o r cor r e c t number o f command l i n e arguments .12 i f [ ”$#” != ”3” ]13 then14 p r i n t h e l p ;15 exit 1 ;16 f i1718 LOG DIR=$1 ;19 SERVER=$2 ;20 RTP PORT=$3 ;2122 p r i n t f ”\n\n”23 read −p ”Press any key to s t a r t p l ay ing the f i r s t stream . . . ” r ep ly24 mplayer −r tsp−port ${RTP PORT} \25 r tsp : // ${SERVER} : 5454/ act ion 400x240 1000k mpeg4 . av i > \26 ${LOG DIR}/ log mplayer ‘ date +”%Y%m%d %H%M%S” ‘2728 p r i n t f ”\n\n”29 read −p ”Press any key to s t a r t p l ay ing the next stream . . . ” r ep ly30 mplayer −r tsp−port ${RTP PORT} \31 r tsp : // ${SERVER} : 5454/ act ion 400x240 1000k mpeg1 .mpg > \32 ${LOG DIR}/ log mplayer ‘ date +”%Y%m%d %H%M%S” ‘3334 p r i n t f ”\n\n”35 read −p ”Press any key to s t a r t p l ay ing the next stream . . . ” r ep ly36 mplayer −r tsp−port ${RTP PORT} \37 r tsp : // ${SERVER} : 5454/ act ion 240x144 500k mpeg4 . av i > \38 ${LOG DIR}/ log mplayer ‘ date +”%Y%m%d %H%M%S” ‘3940 p r i n t f ”\n\n”41 read −p ”Press any key to s t a r t p l ay ing the next stream . . . ” r ep ly42 mplayer −r tsp−port ${RTP PORT} \43 r tsp : // ${SERVER} : 5454/ act ion 240x144 500k mpeg1 .mpg > \44 ${LOG DIR}/ log mplayer ‘ date +”%Y%m%d %H%M%S” ‘4546 p r i n t f ”\n\n”47 read −p ”Press any key to s t a r t p l ay ing the next stream . . . ” r ep ly48 mplayer −r tsp−port ${RTP PORT} \49 r tsp : // ${SERVER} : 5454/ act ion 240x144 200k mpeg4 . av i > \50 ${LOG DIR}/ log mplayer ‘ date +”%Y%m%d %H%M%S” ‘5152 p r i n t f ”\n\n”53 read −p ”Press any key to s t a r t p l ay ing the next stream . . . ” r ep ly54 mplayer −r tsp−port ${RTP PORT} \55 r tsp : // ${SERVER} : 5454/ act ion 240x144 200k mpeg1 .mpg > \56 ${LOG DIR}/ log mplayer ‘ date +”%Y%m%d %H%M%S” ‘5758 p r i n t f ”\n\n”59 read −p ”Press any key to s t a r t p l ay ing the next stream . . . ” r ep ly

160

60 mplayer −r tsp−port ${RTP PORT} \61 r tsp : // ${SERVER} : 5454/ interview 400x240 1000k mpeg4 . av i > \62 ${LOG DIR}/ log mplayer ‘ date +”%Y%m%d %H%M%S” ‘6364 p r i n t f ”\n\n”65 read −p ”Press any key to s t a r t p l ay ing the next stream . . . ” r ep ly66 mplayer −r tsp−port ${RTP PORT} \67 r tsp : // ${SERVER} : 5454/ interview 400x240 1000k mpeg1 .mpg > \68 ${LOG DIR}/ log mplayer ‘ date +”%Y%m%d %H%M%S” ‘6970 p r i n t f ”\n\n”71 read −p ”Press any key to s t a r t p l ay ing the next stream . . . ” r ep ly72 mplayer −r tsp−port ${RTP PORT} \73 r tsp : // ${SERVER} : 5454/ interview 240x144 500k mpeg4 . av i > \74 ${LOG DIR}/ log mplayer ‘ date +”%Y%m%d %H%M%S” ‘7576 p r i n t f ”\n\n”77 read −p ”Press any key to s t a r t p l ay ing the next stream . . . ” r ep ly78 mplayer −r tsp−port ${RTP PORT} \79 r tsp : // ${SERVER} : 5454/ interview 240x144 500k mpeg1 .mpg > \80 ${LOG DIR}/ log mplayer ‘ date +”%Y%m%d %H%M%S” ‘8182 p r i n t f ”\n\n”83 read −p ”Press any key to s t a r t p l ay ing the next stream . . . ” r ep ly84 mplayer −r tsp−port ${RTP PORT} \85 r tsp : // ${SERVER} : 5454/ interview 240x144 200k mpeg4 . av i > \86 ${LOG DIR}/ log mplayer ‘ date +”%Y%m%d %H%M%S” ‘8788 p r i n t f ”\n\n”89 read −p ”Press any key to s t a r t p l ay ing the l a s t stream . . . ” r ep ly90 mplayer −r tsp−port ${RTP PORT} \91 r tsp : // ${SERVER} : 5454/ interview 240x144 200k mpeg1 .mpg > \92 ${LOG DIR}/ log mplayer ‘ date +”%Y%m%d %H%M%S” ‘

161

B.10 parse rtcp data.sh

1 #!/ bin /sh23 # Author :4 # Magnus E. Halvorsen ( magnuseh@ifi . uio . no)56 p r i n t h e l p ( )7 {8 echo ”Usage : ‘ basename $0 ‘ { c a p t u r e f i l e }” ;9 }

1011 # Check f o r cor r e c t number o f command l i n e arguments .12 i f [ ”$#” != ”1” ]13 then14 p r i n t h e l p ;15 exit 1 ;16 f i171819 tshark −r $1 −d udp . port==3001, r tcp −R ” r tcp . pt == 201” −T f i e l d s \20 −E ”header=y” −e ” frame . t im e r e l a t i v e ” −e ” r tcp . s s r c . cum nr” \21 −e ” r tcp . s s r c . f r a c t i o n ”

162

B.11 generate resource plots.sh

1 #!/ bin /sh23 sar −f s a r . l og > cpu . data4 sar −f s a r . l og −r > memory . data5 sar −f s a r . l og −d > b l o ckdev i c e s . data6 sar −f s a r . l og −I 10 > dsp . data7 sar −f s a r . l og −n DEV| grep wlan0 > network . data8 sar −f s a r . l og −n EDEV| grep wlan0 > networker ror s . data9

10 # Remove l a s t l ine , which conta ins average values , so i t doesn ’ t show up in the11 # p l o t t e d graph .12 sed − i ’$d ’ ∗ . data1314 # Generate p l o t s .15 gnuplot ˜/UiO/master/Experiments/cpu . gnuplot16 gnuplot ˜/UiO/master/Experiments/memory . gnuplot17 gnuplot ˜/UiO/master/Experiments/ b l o ckdev i c e s . gnuplot18 gnuplot ˜/UiO/master/Experiments/dsp . gnuplot19 gnuplot ˜/UiO/master/Experiments/network . gnuplot20 gnuplot ˜/UiO/master/Experiments/ networker ror s . gnuplot

163