Creating Always-Best-Connected Multimedia Applications for ...

LICENTIATE T H E S I S

Luleå University of TechnologyDepartment of Computer Science and Electrical Engineering, Division of Media Technology

:|: -|: - -- ⁄ --

:

Creating Always-Best-Connected Multimedia Applications for the 4th

Generation Wireless Systems

Johan Kristiansson

Creating Always-Best-ConnectedMultimedia Applications for the 4th

Generation Wireless Systems

Johan Kristiansson

Division of Media TechnologyDepartment of Computer Science and Electrical Engineering

Luleå University of TechnologyS-971 87 Luleå

Sweden

November 2004

Supervisor

Peter Parnes, PhD, Luleå University of Technology

Abstract

This thesis describes an application-layer framework for managing network connectivityin 4th generation wireless systems. There is a consensus that the next generation telecominfrastructure will consists of a set of partially overlapping heterogeneous networks, whereeach network provides different coverage, price, and performance. Inexpensive highperformance WLAN connectivity will for example be available with limited range of “hot-spot” areas and will be complimented with more traditional cellular connectivity offeringwide area coverage, but with reduced performance. If multiple access networks are present,users will have a choice of how to access the Internet through the “best” available network,e.g. the network offering the best price-performance ratio.

Today, the main problem is that different wireless networks are not particularly integratedand users in most cases are forced to manually interact with the system when switchingbetween networks, including reconfiguring their terminal, restarting running applications, andmanually adjusting bandwidth utilization. Ideally, Internet connectivity should be easy to useand applications should automatically adapt to current bandwidth and budgetary constraints.

The work presented in this thesis addresses this challenge and describes a framework formanaging IP mobility while considering competing connection speeds and pricing models.By using an application-layer mobility scheme, called the Resilient Mobile Socket (RMS),the thesis shows how applications can manage handovers and seamlessly migrate data streamsbetween different networks. Moreover, by using a method called Competition based SoftHandovers (CSHM), the thesis demonstrates how handovers can be automatically triggeredto select the network currently offering the lowest packet losses and end-to-end delay, whichis important for real-time media such as Voice-over-IP. Finally, the thesis proposes a methodto manage network connectivity and share bandwidth effectively between multiple mediawithin an application. This method is based on microeconomic theory and uses a bandwidthbroker as a centralized supply point that looks for the best available network(s) at all timesand utilizes a virtual spot-market for selling the bandwidth to different media.

As a proof of concept several prototypes have been built into the commercial e-meetingapplication Marratech Pro. The thesis presents real-life results from exploratory experimentsusing these prototypes.

i

Contents

Publications vii

Acknowledgments ix

1 Thesis Introduction and Summary 11.1 Introduction and motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.1 Research issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.1.2 Research methodology . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.1.3 Thesis organization . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.2 Mobility management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.2.1 Application-layer mobility support . . . . . . . . . . . . . . . . . . . 8

1.3 Handover management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.3.1 Competition based Soft Handover Management . . . . . . . . . . . . 11

1.4 Bandwidth management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.5.1 Current status and future work . . . . . . . . . . . . . . . . . . . . . 15

2 Application-layer Mobility support for Streaming Real-timeMedia 17

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.1.1 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.2 Resilient Mobile Socket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.2.1 Packet translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2.2 Maintaining the translation table . . . . . . . . . . . . . . . . . . . . 23

2.2.3 Exchanging location information . . . . . . . . . . . . . . . . . . . . 24

2.3 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

iii

iv Contents

2.3.1 The prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.3.2 The test-bed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.3.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.4.1 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.5 Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3 Providing Seamless Mobility with Competition based SoftHandover Management 31

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.2 Background and related work . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.3 Competition based Soft handover Management . . . . . . . . . . . . . . . . 36

3.3.1 Resilient Mobile Socket . . . . . . . . . . . . . . . . . . . . . . . . 36

3.3.2 Competition based Handover management . . . . . . . . . . . . . . 37

3.3.3 Making proactive handover decisions . . . . . . . . . . . . . . . . . 38

3.3.4 Filtering out duplicate packets . . . . . . . . . . . . . . . . . . . . . 39

3.3.5 Selecting a new default internal socket . . . . . . . . . . . . . . . . . 39

3.4 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.4.1 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.4.2 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.4.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.4.4 CSHM performance . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.6 Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4 Market-based Bandwidth Management for DistributedMultimedia Applications 47

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.2 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.3 Market-based bandwidth management . . . . . . . . . . . . . . . . . . . . . 52

4.3.1 Competitive market models . . . . . . . . . . . . . . . . . . . . . . 52

4.3.2 Calculating the supply . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.3.3 Calculating the demand . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.4 Overview of the framework . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.4.1 Network contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.4.2 The Bandwidth Broker Agent . . . . . . . . . . . . . . . . . . . . . 56

Contents v

4.4.3 The Bandwidth Consumer Agent . . . . . . . . . . . . . . . . . . . . 57

4.4.4 The Network Agents . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.5 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.5.1 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.5.2 Experiment one: Bandwidth sharing between multiple media . . . . . 62

4.5.3 Experiment two: Investigation into the price and supply recalculationrates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.6.1 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Bibliography 65

Publications

This thesis consists of an introduction and three papers, of which two have been publishedand one has been submitted for review. I am the main author of each paper and did all thework except for the third paper, which was written with Jeremiah Scholl as an additionalco-author. The three papers are:

Paper 1 Johan Kristiansson, and Peter Parnes. Application-layer Mobility support forStreaming Real-time Media. In Proceedings of the IEEE Wireless Communicationsand Networking Conference (WCNC), Atlanta, Georgia, USA, March 2004.[Page 19-30]

Paper 2 Johan Kristiansson, and Peter Parnes. Providing Seamless Mobility with Com-petition based Soft Handover Management In Proceedings of the 7th IFIP/IEEEInternational Conference on Management of Multimedia Networks and Services(MMNS), San Diego, California, USA, October 2004. [Page 33-45]

Paper 3 Johan Kristiansson, Jeremiah Scholl, and Peter Parnes. Market-based BandwidthManagement for Distributed Multimedia Applications. Submitted for review to IEEEInfocom 2005 [Page 49-63]

This paper was accomplished while working closely together with Jeremiah Scholl. Iwas the one who proposed the idea originally after writing a research paper for thePricing for Communication Networks course at KTH (Royal Institute of Technology,Sweden), but the idea was later refined by Jeremiah. While each of us contributed toall aspects on the paper, Jeremiah’s contribution was mainly the introduction and thesections about how to calculate the supply and the demand. He also re-wrote parts oforiginal paper in order to make it more readable.

vii

Acknowledgments

First, I would like to thank my supervisor Dr. Peter Parnes. Without your help andencouragement this thesis work would not have been possible. I would also like to thankall my colleagues at Media technology and CDT, I would never have gone this far withoutyour help and discussions. Special thanks to Dr. Kåre Synnes for helping me with the writing.

Most of my research has been funded through the Mäkitalo Research Centre (MRC) andthe Centre for Distance-spanning Technology, CDT, which is a joint venture between LuleåUniversity of Technology and the companies Ericsson Erisoft, Frontec and Telia Research,with financial support from the local government. My research has also been funded throughVINNOVA RadioSphere and the VITAL project supported by the Objective 1 Norra Norrland.

I would also like to thank my beloved family for supporting me in this work. Thanksto my wife Helena for your love and endless patience. Finally, I would like to thank myparents Lennart and Kerstin, and my parents-in-law Olle and Anita for always being therewhen needed.

Luleå, November 2004

Johan Kristiansson

ix

x Acknowledgments

In memory of Valdemar

Part 1

Thesis Introduction and Summary

1

Thesis Introduction and Summary 3

1.1 Introduction and motivation

Today it is clear that no single wireless access technology will be appropriate for allapplication scenarios. In fact, it is expected that many wireless networks will coexist andcompliment each other in an all-IP based heterogeneous wireless network known as the4th generation (4G) wireless system [18]. Inexpensive high performance WLAN (WiFi TM)connectivity will for example be available within limited range of “hot-spot” areas and willbe complimented with more traditional cellular connectivity offering wide area coverage,but with reduced performance. This 4G-environment will provide mobile end-users withseamless Internet access and IP connectivity to third party services at all times, and in allplaces, while using the “best” available network. This concept is known as Always-Best-Connected [19, 26] and is a central part of the 4G vision. Figure 1.1 below shows an exampleof such a 4G wireless landscape.

The Internet

WiFi/Operator 2

WiFi/Operator 1

UMTS/Operator 1

WiFi/Operator 2

Bluetooth/Operator 3

GPRS/Operator 4WiFi/Operator 2

Overlapping WiFinetworks

WiMax

Figure 1.1: The 4G wireless landscape consists of a set of geographically overlappingheterogeneous networks, where each network provides different coverage, price, andperformance.

Despite the vast amount of research in the area of IP mobility and deployment of newwireless systems, the idea of having an Always-Best-Connected Internet connection seemsmore like a vision than reality today. One possible explanation is that current state-of-the-art solutions mainly focus on mobility management instead of considering additionalapplication related issues such as adaptation support and failure recovery in conjunctionwith mobility. For example, even if mobility support is provided, a majority of all Internet-working applications can still not handle longer periods of disconnectivity without having to

4 Thesis Introduction and Summary

be restarted. This becomes a serious issue when many users tend to hibernate their terminalswhen moving rather than always keeping them turned on.

Another explanation for why Always-Best-Connected services is far from being deployedis that it is still unclear whose interests are being served when using this new type of service.Clearly, the word “best” or “better” can have different meaning to different actors. ISPsmight consider Always-Best-Connected as a method for saving investment money throughdeployment of cheap WLAN access points instead of expensive 3G hardware. Unless an ISPcan directly benefit from allowing a user to switch to another operator, they have an incentiveto bind the user to their own networks or service provisioning. In contrast, end-users mightview Always-Best-Connected as a means of saving money by switching to the lowest costoperator. A user who wishes to make an Internet phone call could for example switch froman expensive UMTS connection to a free campus WLAN network and fall back to the UMTSconnection when moving outside the campus area.

While Always-Best-Connected can be viewed from a wide range of divergent viewpointsand implemented in several different ways, this thesis focuses on multimedia applications andpresents a solution with the main technical solutions implemented in the application-layer.One advantage of this approach is that it combines mobility management and applicationadaptation. In addition, as minimal support is required from the network infrastructure, itbecomes possible to switch to any available network without objections from the ISPs, thusallowing greater competition. However, independently of how Always-Best-Connected isimplemented, the resulting complexity must never be exposed directly to either users orapplication developers. The challenge is to integrate wireless and wired networks into a singleentity that can be used efficiently and in a comprehensive way without any complications. Itshould just work.

The next two subsections present the problems addressed in this thesis and the methodol-ogy used to solve the problems.

1.1.1 Research issues

There are several fundamental problems that must be solved in order to allow users tosuccessfully navigate a 4G wireless landscape. While this a broad research area in general,this thesis focuses only on application related issues, which is mainly mobility managementand adaptation support. Other important issues such as radio interfaces, power-control,security management, hot-spot detection, business models etc. are not covered. The problemsthat are discussed in the thesis are described more closely below.

What kind of methods are needed to allow applications to manage multiple networkconnection points?

Applications running on multi-mode terminals1 in a 4G environment must be able to switchbetween different connections without failing. However, the Internet routing model forces

1Multi-mode terminals are devices capable of accessing multiple wireless technology such as WLAN, GPRS, 3Gor Bluetooth from the one device.


mobile hosts to acquire a new IP address for an interface when switching to another network.As many Internet-working applications and protocols (including TCP) uses IP addresses asnon-volatile identifiers in data structures assuming that they never change, many applicationscannot survive an IP address update and must consequently be restarted in order to functionproperly when attached to a new sub-network. This problem becomes more complicatedwhen some media such as Voice-over-IP require seamless handover2 support. In this case, nopackets are allowed to be lost during the handover operation.

Why and when should a handover to another network be initiated?

Assuming that applications can manage mobility some mechanism is still needed to decidewhen a handover should take place as well as picking the best network. Clearly, requiringthat users manually control handovers is not a sustainable solution.

Hence, a well designed handover decision algorithm must be able to evaluate all availablenetworks and to select the best network given some criteria. For real-time communication itis important that the delay caused by the handover operation is as minimal as possible in orderto avoid disruption in the communication. In addition, if it takes time to complete a handoveroperation and if the performance of the networks fluctuates, then there is always a risk thathandovers are triggered back and forth between two or more networks causing instability andseriously degraded performance. This classical problem is known as the ping-pong problem,and the standard solution is to add hysteresis with the drawback of adding even more delayto the handover operation.

How can bandwidth be managed and shared efficiently within (multiple) multimediaapplications?

Assuming that applications can manage mobility and intelligently handover to the bestnetwork, some method is still needed to adapt media streams to the currently availablebandwidth. Media streams suitable for high-bandwidth networks without adaptation supportwill encounter problems when switching to a network with lower bandwidth. Even if thereenough available bandwidth, it is not always the case that the user will want to utilize all thebandwidth. A user might for example only be able to afford to use 80 kbps on a particularnetwork despite there being 2000 kbps of bandwidth available.

In addition, if there is not enough bandwidth for all media, the user will have to manuallyprioritize how much bandwidth each media stream should be given. If there is 120 kbpsof bandwidth available, video might be allocated 100 kbps, with audio being allocated 20kbps, and so on. Apparently, simply being always best connected is not enough as users alsowant to maximize their net benefit in order to make the most of their connections and money.While this is a general problem for most application scenarios, creating useful multimediaapplications in a 4G environment is even more difficult due to the dynamic nature of the linksavailable in the 4G wireless landscape.

2In the rest of the paper, the technical term handover is used to describe the process that transfers a connectionfrom one network to another.


Figure 1.2: Screen-shot of Marratech Pro.

1.1.2 Research methodology

The overall purpose of the research presented in this thesis is to gain a better understandingof the Always-Best-Connected concept and to investigate its implications on distributedmultimedia applications. Throughout the thesis an exploratory research methodology is usedwith focus on solutions that are deployable in the real-world. Marratech Pro [3] was selectedas a platform for prototyping due to its richness in terms of media. Marratech Pro providessynchronous interaction by combining real-time audio and video communication, chat, and ashared white-board. Data distribution is either done using IP-multicast [14] for direct peer-to-peer communication or through a media gateway called the Marratech E-Meeting Portalif IP-multicast is not available. Figure 1.2 shows a screen-shot of a Marratech Pro e-meetingsession.

Integrating research results in to a commercial product such as Marratech Pro gavean unique opportunity to experiment with and evaluate new ideas such as those proposedin this thesis. However, it is important to point out that even though the prototypes arebased on Marratech Pro, they are implemented separately and can easily be used for similarapplications.


1.1.3 Thesis organization

The thesis consists of 4 parts, where the first part is this introduction and all other parts arebased on papers that have been previously published or submitted for review. Each publishedpaper is reproduced in its original form with the following exception.

All figures, tables, sections, and pages have been renumbered in order to provide commonnumbering throughout the thesis. Bibliographic references have been renumbered to utilize acommon bibliography. Finally, cosmetic changes have been made to figures and tables to fitthe format of the thesis.

Part 2: Application-layer Mobility support for Streaming Real-time MediaThe first paper deals primary with mobility management and focuses on the first question. Asolution that allows applications to manage multiple network connection points is presented.

Part 3: Providing Seamless Mobility with Competition based Soft Handover ManagementThe second paper addresses the second problem and presents a solution that allows real-timemedia such as Voice-over-IP to always be connected to the network offering the lowest packetdelay and packet losses.

Part 4: Market-based Bandwidth Management for Distributed Multimedia ApplicationsThe third paper addresses mainly the third problem and proposes a method based onmicroeconomics to manage network connectivity and share bandwidth effectively betweenmultiple media within an application.

1.2 Mobility management

The most straight forward solution to the mobility problem (i.e. the first problem) is perhapsto re-design all applications in such a way that they are not dependent on static IP addresses.However, as this would require a significant amount of work and add extra complexity to theapplications, most mobility management schemes tries to provide compatibility with existingapplications by adding a level of indirection to a layer in the TCP/IP protocol stack. Forexample, in Mobile IP [44] applications are always connected using a home IP address withthe underlying system using a temporary care-of-address to send and receive packets.

While Mobile IP offers several important advantages, it also suffers from some drawbacksthat can be worth to discuss. First, it can be hard to provide good routing performance whenall packets must be tunneled from a home agent to a foreign agent. In reality, it can also bedifficult to require every ISP to deploy Mobile IP agents as they not always want to share theircustomers freely with other ISPs. In addition, it can also be hard to implement an efficienthandover algorithm with the problem of having to consider the requirements of all runningapplications before making the handover decisions.

However, it is important to point out that Mobile IP can still play an important role inproviding mobility management in specific scenarios, for example allowing an operator tosupply users with both WLAN and UMTS connectivity within its own network.


The next subsection discusses how mobility support can be implemented in the application-layer instead of in the network-layer, thus overcoming some of the limitations of Mobile IP,but at the cost of crafting special applications.

1.2.1 Application-layer mobility support

The first paper proposes a UDP-based socket extension called the Resilient Mobile Socket(RMS). The primary purpose of RMS is to preserve network connectivity and to provide amore robust platform by allowing applications to suspend connections and then resume themusing another (or the same) IP address. The main reason why RMS was developed was thatwe needed a technology to support handovers to NAT-enabled networks in order to make real-world tests using commercial GSM/GPRS networks. In other words, we needed a technologythat could perform handovers to any network without requiring dedicated mobility supportfrom the networks itself. An alternative to RMS would have been to use the Stream ControlTransmission Protocol, SCTP [21], but as SCTP targets TCP-based applications specificallyrather than real-time UDP-based applications it was decided to design a new protocol.

Here follows a brief description how mobility support is implemented in RMS. A morecomplete description of RMS can be found in section 2.2. Applications that communicateover the Internet normally use a socket, representing an end-point of a communication linkto another application running on the Internet. By encapsulating multiple sockets into anew socket abstraction (RMS), an encapsulated or internal socket can fail without disturbingthe applications. As each internal socket represents a socket within a connected network,running applications will still be able to communicate even if the currently active internalsocket becomes disconnected as long as another internal socket is available.

Send

Receive

SHO

Redundancy

HHO

RMS

Send

Receive

Internal socket

Default Internal socket

Send

Receive

Internal socket

Send

Receive

Internal socket

Handover manager

Real-time media

application

Suspend

Figure 1.3: An overview of the RMS architecture.

Figure 1.3 shows an overview of the RMS architecture and how internal sockets areencapsulated. Note that besides functionality to send and receive packets RMS also providesmethods to control which internal socket(s) should be used. The handover manager, whichcan be seen to left in figure 1.3, is responsible for monitoring the system and deciding whena handover should take place.


One advantage of RMS compared with Mobile IP is that it is possible to apply specifichandover strategies for individual media streams rather than only for the whole system, thusmaking it possible to develop custom-made applications. For example, assume that a user hasaccess to an expensive UMTS network providing some level of QoS, and a poorly performingbut free WLAN network. In this case, audio packets could be sent over the UMTS connectionwhile other packets such as video are sent over the WLAN connection in order to save money(assuming that video is less important than audio).

Another interesting advantage that can be worth pointing out is that it is relatively simpleto implement soft handover support with the RMS by using multiple sockets simultaneously.The first paper shows experimentally that is possible to use soft handover to migrate a real-time media stream from one network connection to another without loosing any packets atall. Nevertheless, a problem with using soft handovers in general is that it requires thathandovers are initiated proactively, i.e. handovers must be initiated before the currentlyactive encapsulated socket becomes disconnected. A soft handover management schememust consequently be able to predict when a connection is going to be lost. This problemwas further investigated in the second paper.

1.3 Handover management

The second paper addresses the problem of deciding when to initiate a handover as well ashow to select the best network. In general, this is a extremely complex problem and thesecond paper only addresses how to select the network with lowest packet losses and lowestexpected end-to-end delay. In the third paper, the system is extended to consider additionalcriteria such as financial cost in selecting the best network.

Before continuing, it is important to point out that different media can have differenthandover requirements. For example, waiting one or two extra seconds before receiving achat message might not be considered critical while a couple of seconds delay in a real-time media stream, such as Voice-over-IP, may make the voice completely unintelligible.To solve this problem a large amounts of research has been conducted to provide seamlesshandover support in wireless environments. To name just a few efforts, Cellular IP [54] offersimproved handover support in limited geographical areas by incorporating traditional cellularprinciples from telecommunication networks into Mobile IP; another micro-mobility scheme,Hierarchical Mobile IP [52], tries to reduce the home network registration time by using ahierarchical network management structure.

In most mobility architectures, handovers are triggered by monitoring the signal strengthto/from the base-stations in combination with a dwell-timer, hysteresis, or threshold basedcontrol algorithm [7, 42, 57] to decide when to initiate the handover. A general problemwith these algorithms is that they actually tend to increase the handover delay because of theextra delay they introduce in order to avoid the ping-pong problem. To address the ping-pongproblem several location-aided handover algorithms [17, 22, 16, 35] have been proposed inthe literature. By exploiting the user’s current location in combination with a predictionmodel, these algorithms try to make proactive routing decisions, and reduce the handoverfrequency by only initiating handovers when absolutely necessary. However, in reality it can


Packets

Sender

Network 2, e.g WLAN

Network 1, e.g UMTS

Receiver

Duplicated packets

The Internet

Lost packet

n-1

n-1

n-2

n-2

n-3

n-3

n-4

n-4

n-5 n-5 n-6 n-6

Client A Client B

Packets

Sender

Network 2, e.g WLAN

Network 1, e.g UMTS

Receiver

The Internetn-6

n-6

n-5

n-5

n-4

n-4

n-3

n-3

n-2 n-2 n-1 n-1

Client A Client B

Figure 1.4: Redundant packet streams. Note that each client has its own instance of theCSHM algorithm, which means that it will take at least two handover decision rounds beforeboth incoming and outgoing packets are duplicated.

be hard to develop accurate prediction models based on user movement as it is very likelythat surrounding environment also change, for example a bus passed by, somebody closes adoor, or the user touches the radio antenna, thus degrading the radio performance without theuser moving at all.

Another problem with location-aided and signal-strength based handover algorithms isthat there is only a vague relationship between the network performance and the signalstrength. There is no guarantee at all that a client connecting to base-station with good radioquality gets low end-to-end delay to another end-point on Internet. In the worst case the base-station might not even be connected to the Internet, consequently being completely uselessfrom a communication point of view.

Theoretically speaking, many of the problems described above could be solved if ahandover decisions algorithm could simultaneously evaluate the end-to-end performanceof each network, and then pick the best one without negatively affecting the performanceas perceived by the user. One way of implementing such an algorithm is to transmit


redundant packet streams3 over several networks and measure the end-to-end delay for eachconnection. All connections except the best one are then dropped after the sample periodhas been completed. Unfortunately, as this method waste network resources in terms ofboth bandwidth and money, it has been avoided by the research community for some time.Nevertheless, as will be discussed in the next subsection, to use redundancy for makingproactive handover decisions can be a simple and powerful solution, if it done in the rightway.

1.3.1 Competition based Soft Handover Management

The second paper proposes a new handover strategy for real-time media called Competitionbased Soft Handover Management (CSHM), which is plugged into the handover manager asshown in figure 1.3. Here follows brief introduction to the algorithm. The reader is referredto section 3.3.2 for a more complete description.

When the performance of a connection becomes insufficient to meet the user’s needs,for example when the end-to-end delay becomes too large, a soft handover is automaticallyinitiated to all available networks. This means that redundant packet streams are sent throughall available connections and are later merged into one stream when received by the other end-point, which also measures the packet delay and selects the best performing connection. Thisprocess can be viewed as a competition as each connection competes with other connectionsin contributing to the merged stream. The connection that delivers the most packets to themerged streams wins the competition and is selected as the default connection after thehandover. Figure 1.4 illustrates how redundant packet streams are sent over two networks. Ascan be seen in the figure, one of the packets (n-2) is lost over the UMTS network. However,as a copy of the lost packet is also sent over the WLAN connection, the user will not perceivedegraded performance due to this packet loss. In general, the connection that provides thelowest end-to-end delay and few packet losses will contribute to the merged stream more thanother connections.

One difference between traditional handover algorithms and CSHM is that the newnetwork is not decided before the handover is triggered, but instead is determined duringthe handover process. Another difference is that a soft handover can take place over a longperiod of time. If no individual connection can provide sufficient performance, sendingredundant packet streams can also be used to decrease the network jitter without actuallyswitching between the networks. The second paper experimentally shows that it is possibleto merge two badly performing WLAN networks into one good aggregated network. Insteadof repeatedly switching between two badly performing networks, CSHM uses redundancy toimprove the network performance until one or more of the networks become stable again oruntil there is only one working connection left.

To sum up, CSHM is relative simple solution for a difficult problem. The drawback withthe algorithm is that it tends to waste bandwidth for which reason it might not be appropriate

3Sending redundant packet stream requires that network interfaces can be connected to multiple networks, e.g. aWLAN interface associated with multiple access-points. This problem can either be solved by overloading hardware(i.e. using multiple WLAN cards), or by using a virtual interface which continuously switches across multiplenetworks [9].


Audio Video Chat Other

Broker

UMTS/GPRSEthernet/Office

WLAN/LTUOther

The demand

The supply

GSM/GPRS

Figure 1.5: An overview of the marketplace used in the framework.

to use it as general purpose handover algorithm for all media. Nevertheless, this is not aserious issue as RMS allows different handover algorithms to be used for different media.Hence, CSHM can be used for audio while some other algorithm is used for other media.For example, for a MPEG video stream it makes more sense to only send I-frame packets onredundant links rather than duplicating all packets [4]. However, requiring each application ormedia to separately be responsible for managing mobility is only a sub-optimal solution. Thethird paper discusses how mobility can be managed using a bandwidth broker as a centralizedsupply point.

1.4 Bandwidth management

The third paper addresses mainly the third problem, i.e. how to manage and share bandwidthefficiently within and across potentially multiple applications. As mentioned before, simplybeing able to manage handovers is not sufficient to develop useful multimedia applications for4G wireless systems. After a handover has been completed, some mechanism is still needed


to automatically adjust the bandwidth usage and share the bandwidth efficiently betweendifferent media in order to maximize the user’s total net benefit.

The third paper introduces the concept of a virtual marketplace based on using microe-conomic theory to solve this problem. Figure 1.5 shows an overview of this marketplace.The key components of the proposed framework are a bandwidth broker that puts the currentsupply of available bandwidth “on the market” at a particular price, and bandwidth consumerswhich use utility functions for each media to calculate the demand by mapping the relativegain they offer the user at different bandwidth levels. This allows bandwidth to be allocatedefficiently by using a spot-market algorithm where the broker raises the price if the totaldemand from all its customers (the media) exceeds the available supply, or lowers the price ifthe demand is lower than the available supply. Eventually this price fluctuation will reach astate where the demand for bandwidth equals the supply for the bandwidth at that particularprice. When this state is reached, the market is said to be in equilibrium [13].

pn�

1�x �� pn

�x �� d

s(1.1)

Equation (1.1) shows how the price is iteratively calculated based on supply and demandusing a tâtonnement process, with pn

�x � representing the current price, pn

�1�x � next price,

d the aggregate demand of all customers, and s the current supply. Most often the supplywill in be equal to the capacity of the network but for non-flat-rate connections it may alsobe bounded by budget controls set by the user. In this particular case, the user specifies howmuch money that can be spent during some period of time, and the system makes sure thatthe user get maximum benefit from the network given this budget. Section 4.3.2 and section4.3.3 describe more closely how the supply and the demand are calculated.

The advantages with this framework are twofold. The first is that it allows bandwidthmanagement for all media to be handled in a centralized way in order to give the optimalaggregated experience to the user. The second is that it can help applications to managenetwork connectivity by using the bandwidth broker as a centralized supply point that looksfor the best available connection(s) at all times, thus liberating applications from dealing withcomplex issues such as mobility and handover management.

To investigate how the framework works in practise, a proof of concept prototypewas built by integrating the framework into Marratech Pro. This prototype was used inseveral experiments aimed at revealing how different price and supply re-calculation ratesaffected the spot-market algorithm. Experiments were also conducted to investigate howfast the spot-market reacted when a new media was introduced. These experiments showedthat a high price recalculation rate is effective at minimizing the difference between thesupply and demand, allowing the available bandwidth to be allocated more efficiently.Using a high supply recalculation rate on the other hand resulted in better throughput, butunfortunately also larger fluctuations in available supply. For more detailed information onthese experiments see section 4.5.


1.5 Discussion

The thesis has described several fundamental application related problems that must besolved in order to allow the user to successfully navigate a 4G wireless landscape, and it haspresented solutions to some of these problems. In the introduction the following questionswere asked:

1. What kind of methods are needed to allow applications to manage multiple networkconnection points?

2. Why and when should a handover to another network be initiated?

3. How can bandwidth be managed and shared efficiently within (multiple) multimediaapplications?

In relation to the first question, the thesis has presented an application-layer mobilityscheme called RMS, which offers two important advantages over exiting schemes. The firstadvantages is that it can operate on any network, including firewall protected networks such asNAT, which makes it possible to deploy Always-Best-Connected services without negotiatingspecial agreements with ISPs. The second advantage is that different handover strategies canbe used for different media, thus making it possible to develop custom-made multimediaapplications for the 4G wireless systems. For example applying handover algorithms such asCSHM to provide better audio quality over multiple wireless links.

In relation to the second question, a novel handover decision algorithm for real-timemedia has been presented. This algorithm allows applications to always be connected tothe network providing the lowest end-to-end delay and lowest packet loss without the usersperceiving downgraded performance due to handover delay or the ping-pong problem. If noindividual network can alone provide enough performance to support the media, the thesishas experimentally shown that it is possible to aggregate multiple networks into one goodperformance network.

In relation to the third question, the thesis has presented an application-layer frameworkfor bandwidth management in distributed multimedia applications that is based on themicroeconomic principal of supply and demand. The main advantage of this framework isthat it creates a centralized place where solutions to problems related to bandwidth allocation,IP mobility, and congestion control can be integrated effectively into an application.

While there are many advantages with the work presented in this thesis, there are alsosome drawbacks that are worth to be point out. One limitation with RMS is that only UDP-based applications are supported, which means that some other mobility scheme must beused for other applications. This raises the question whether or not is better to use a general-purpose mobility scheme that can transparently support any application. An alternative toRMS would be to develop a virtual network driver that provides general mobility support andAPIs similar to RMS for developing custom-made multimedia applications. However, as thegoal of the research was not to find an optimal mobility solution, but rather to investigate theAlways-Best-Connected concept and explore problems beyond mobility management, it wassufficient to use the RMS.


1.5.1 Current status and future work

This section presents the current status of the work proposed in this thesis and discussesfuture research directions.

All the work that has been presented in the thesis has successfully been integrated andverified with Marratech Pro. The RMS is implemented in both Java and C++ and uses aNDIS protocol driver for Windows XP to access the routing table and to utilize policy-basedrouting. The RMS prototype has been refined a couple of times and even if it not completelyoptimized the work can still be considered as finished.

The CSHM algorithm has been implemented as a plug-in to the handover manager shownin figure 1.3. A problem that was encountered when using this prototype was that differentnetwork cards and different codecs produced different jitter. Hence, to provide optimalperformance, CSHM must be able to dynamically adapt to new conditions without havingto be re-calibrated for each new setting. It would also be interesting to see how the algorithmperforms in more heterogeneous environments than the one used in the experiment presentedin this thesis. For example, how will the performance be affected if there is a significantdifference in round-trip-time between the networks?

The framework presented in the third paper is viewed as less complete for various reasons.In the current implementation the bandwidth broker can only emulate different types ofconnections and only two clients are allowed to be active at the same time. The first thing thatneeds to be done it to implement a more sophisticated bandwidth broker and integrate RMSwith the network agent discussed in section 4.4.4. The second thing that needs to be done is tointegrate the framework into the E-meeting Portal to be able support multiple users. It wouldalso be interesting to compare the spot-market algorithm used in the current implementationwith other market-based algorithms. In particular, a comparison with an auctioning systemseems to be an interesting experiment.

Finally, in the future we plan to investigate more effective utility functions for the variousmedia contained in Marratech Pro and integrate some other related prototypes developed byour research division into the system, as well as making tests with real-users.

Part 2

Application-layer Mobilitysupport for Streaming Real-time

Media

17

Application-layer Mobility support for Streaming Real-time Media 19

Application-layer Mobility support forStreaming Real-time Media

Johan Kristiansson, Peter ParnesDepartment of Computer Science & Electrical Engineering

Division of Media TechnologyLuleå University of Technology, 971 87 Luleå, SwedenEmail: {Johan.Kristiansson, Peter.Parnes}@sm.luth.se

Abstract

This paper presents an UDP-based socket extension called the Resilient Mobile Socket(RMS), which provides application-layer mobility support by encapsulating other sockets intoa new aggregated socket abstraction. Encapsulated sockets can then be added or removedwithout disturbing running applications. RMS also provides a method for soft handoverswhere several encapsulated sockets are used simultaneously during a handover.

As a proof of concept, a working prototype has been built by integrating RMS withMarratech Pro, a commercially available E-meeting application. This prototype has beenused to evaluate RMS and to investigate how GSM audio quality is affected by handovers.The result from the investigation shows that soft handovers can be executed without loosingpackets or causing extra latency, while a hard handover in average took around 200 ms tocomplete. This indicates that proactive handovers and redundancy are important, but thatmore work must be done to predict disconnections.

2.1 Introduction

The future wireless landscape will be rich in carriers and in competing technologies. Cheaphigh-speed wireless connectivity provided by universities, Internet cafes or even regular userswill be available with limited range in hot-spots areas. This new type of wireless connectivitywill be complemented by traditional cellular networks offering reduced performance but overa much wider area.

Today, many Internet users are already using Voice-over-IP or E-meetings such asMarratech Pro [3] or Netmeeting to communicate. If these applications could efficientlyoperate in a rich wireless environment, mobile users will not only save money by beingable to connect to the cheapest available network but also experience a more rich form ofcommunication than traditional cellular phones.

When designing such a system, it is important that a handover to another network cantake place anytime, without user intervention and without notable quality degeneration. If itis difficult or expensive in terms of quality to handover to another network, there is a risk that

20 Application-layer Mobility support for Streaming Real-time Media

Send

Receive

SHO

Redundancy

HHO

RMS

Send

Receive

Internal socket

Default Internal socket

Send

Receive

Internal socket

Send

Receive

Internal socket

Handover manager

Real-time media

application

Suspend


many users would still prefer to stay on a wide area network that is always available, even ifit is more expensive.

Many solutions have been suggested to deal with macro-mobility [27, 44, 39, 60, 58], i.e.how to change network or provider without restarting already running applications. However,only very few solutions [58, 27, 41] focus on interactive real-time media as their primarytarget.

During or immediately after a handover, packet losses and extra delay may occur dueto signaling propagation of new location updates. For most applications, such as HTTP orFTP, handover latency is not of vital importance, e.g. waiting one or two second extra whendownloading a web page is not critical. For real-time media on the other hand, latency andpacket losses are extremely important and even a small disturbance can make a media streamunintelligible. For that reason, dedicated schemes capable of acting more semantically tomobility must be developed.

This paper describes an UDP-based socket extension called Resilient Mobile Socket(RMS), which can be used as a building block when implementing mobile real-timeapplications. As a proof of concept, a working prototype has been built by integrating RMSwith Marratech Pro [3], a commercially available E-meeting application providing tools forsynchronous interaction via either audio, video, chat or a shared white-board. This prototypehas been tested in various wireless scenarios and been used in an investigation aimed atrevealing how audio quality is affected by handovers. The result from this investigation ispresented in section 2.3. In section 2.4, the paper is finally concluded with a discussion andfuture work.

2.1.1 Related work

Mobile IP [44] is the current Internet Engineering Task Force (IETF) standard for hostmobility. Unfortunately, all derivates of Mobile IP, including Mobile IPv6, requires supportfrom the infrastructure and deploying foreign agents all over the Internet or requiringeverybody to migrate to IPv6 is a difficult task.


To overcome this restriction, extensive work has been done to add mobility support intooperating systems or directly into applications. Most work in this area focuses on TCP,which is used by the majority of all Internet-working applications today. Many of theseapplication-layer scheme works by inserting a session-layer between the application and thetransport layer. A common implementation is to replace or modify the socket, which is usedby applications to send and receive packets. Such schemes are for example described in[39, 60, 61, 50].

RMS differs from previous mobile sockets since it operates on-top of UDP rather thanTCP. This allows RMS to be used by real-time media applications, which normally requireUDP for packet delivery.

An alternative to RMS would be to use the Stream Control Transmission Protocol,SCTP [21], which is a new general purpose transport protocol for the TCP/IP protocol suit.However, since SCTP is mainly designed to replace TCP and does not support multicast1, itwas decided to build a new protocol completely customized for real-time media. Besides,even though SCTP supports multi-homing it can only use one connection at once, i.e.redundancy and soft handovers are not supported yet.

2.2 Resilient Mobile Socket

An important goal in distributed systems is to design systems in such a way that they canautomatically recover from partial failures. A classical way to build such a system is to useredundancy and hide any occurrence of failures from other components.

By encapsulating multiple sockets into a new socket abstraction, the RMS, any encapsu-lated socket or internal sockets can fail without disturbing applications using the RMS. Aseach internal socket represents an entry point to each connected network, running applicationswill still be able to communicate if the current active internal socket becomes disconnectedand another internal socket is available. This will for example happen when a host gets outof coverage from a WLAN network and has an active connection to an overlay service likeUMTS/GPRS.

Figure 2.1 shows an overview of the RMS architecture and how internal sockets areencapsulated. Note that RMS besides functionality to send and receive packets also providesmethods to control which internal sockets that should be used.

The SUSPEND procedure is used to hibernate on-going communication and is automati-cally called when all network connections are lost, i.e. no internal sockets can be used. Whena RMS becomes suspended it will still try to act as network connectivity exists even thoughno packets are sent nor received. To gracefully handle disconnections is important since everyuser will get disconnected sometimes, either by limited battery power or simply by lack ofmoney.

The HHO (hard handover) procedure provides the opposite operation and is used torecover from a disconnection or to handover to another network. During a HHO, the current

1RMS can also be used to switch between unicast and multicast. In this case, both unicast and multicast socketsare encapsulated inside the RMS. This technique will however not be addressed in this paper.


addr port33 payload

Packettranslator

In-coming packet

addr port44 payload

addr port 11 payload

addr port 22 payloadInternal

socketReceive

SendSend

RMS (id=1)

Out-going packet

Receive

Last heard from

X

X1

2 timetime

Translation table

ID CLHL

addr : port 11

addr : port 22

addr : port 33

addr : port 44

Figure 2.2: A packet translation process.

active internal socket is first removed before a new internal socket is created. A HHOis typically reactive or unplanned and occurs when something unexpected happens to thesystem. For example, when a connection is suddenly lost.

The SHO (soft handover) procedure provides in contrast to the HHO, functionality to useredundancy during a handover. In this case, multiple internal sockets are used simultaneouslyto receive and send packets. This technique eliminates handover latency and prevents packetsfrom getting lost, but must be proactively initiated to be effective, i.e initiated before thecurrent active internal socket becomes disconnected.

The REDUNDANCY procedure provides similar functionality but enables only redun-dancy. This can for example be useful when it is a high probability that the current connectionwill be lost or to compare the end-to-end performance of two or more active connections.

The handover manager, which can be seen to left in figure 2.1, is responsible formonitoring the system and deciding when a handover should take place. Ideally, it will predictdisconnections, use redundancy when the quality is bad, and quickly decide which networkthat is best. A well-implemented handover manager also tries to minimize redundancywithout degrading the quality. The current handover manager is quite simple and worksonly by scanning which network interfaces that are available and initiate a handover whena network interface with better priority becomes available. However, since the handovermanager is completely separated from RMS, more advanced algorithm can easily be pluggedinto the architecture in the future.

2.2.1 Packet translation

Packet translation is a key mechanism used by RMS to hide a change of an internal socketfrom applications and to ensure that packets are correctly routed. The idea is to re-stampall in-coming packets so that it looks like they are coming from their original location andre-stamp all out-going packets so that packets are redirect to hosts visiting foreign networks.From this point of view, the RMS almost works like a Network Address Translator (NAT),but on an application basis.


In the example in figure 2.2, a RMS has changed point of attachment from addr1 : port1to addr3 : port3 and the connected end-point has moved from addr2 : port2 to addr4 : addr4.In this case, the following translation must be done to preserve the communication.

Send�p � : T

�p � addr2 : p � port2 � � � p � addr4 : p � port4

Receive�p � : T

�p � addr3 : p � port3 �� p � addr1 : p � port1

Obviously, to do correct translations, each RMS must maintain a dedicated translationtable containing both the home location (HL) and the current location (CL) of each connectedend-point. As IP addresses and port numbers no longer uniquely identifies a connection, it isalso necessary to use a new socket identifier to recognize remote end-points.

A problem with packet translation is how to ensure consistency with the routing table. Ingeneral, the routing table is always used to determine the next hop for a given destination.As many operating does not support policy based routing, it becomes impossible to sendpackets to a destination via two or more routes. As a result, packets will always be sent fromthe network interface with the lowest metric, independently to which IP addresses internalsockets are bound to. Binding a socket to an IP address only specifies which source addressthat should set in the IP datagram and not which network interface that should be used. Inaddition, packets that are sent from the wrong network interface will be dropped by routersimposing ingress filtering rules and never reach their final destination.

One way of solving this problem, is to allow RMS to manipulate the routing table and addhost routes for each connected end-point. This method allows packets to be correctly routed,but requires that the receiver is assigned multiple IP addresses.

While it may be unrealistic to require that every host on the Internet is assigned multipleIP addresses, it is important to point out that RMS is primarily design with the assumptionthat one end-point is either a media gateway or a multicast/unicast reflector, having a fixlocation to the Internet. This means that only the media gateway or the reflector must beassigned multiple IP addresses in order to support redundancy or SHO.

A more permanent and cleaner solution to this problem, which does not pollute the routingtable, is to use a policy based routing scheme similar to what is suggested in [56]. Another andperhaps even more cleaner solution may simply be to provide applications with more controlby allowing internal sockets to bypass the network layer and send raw packets directly to thelink layer.

2.2.2 Maintaining the translation table

When a host changes point of attachment to the Internet, i.e. switches internal socket, itmust inform the remote end-points about its current location so that they can update theirtranslation tables.

As in almost every other mobility management scheme, maintaining a table over hosts’current locations becomes a key issue. Nevertheless, it is important to recognize and separatelocation management into two distinct operations as also pointed out by Snoeren et al. in


Network C192.168.0.0

WLAN A192.168.2.0

WLAN B192.168.1.0

RMS-enabled Marratech Pro192.168.0.20

RMS-enabled E-meeting Portal192.168.0.21


Figure 2.3: The test-bed. The arrows illustrates the logical packet flow, which always goesthrough the E-meeting Portal.

[51]. The first operation, the location operation is used to locate a host or an end-point whena new connection is established. This can for example be done by using Dynamic DNS [55]to resolve a fully qualified domain name, or SIP [28] to invite a new user to a session. Notethat the location operation is only required if a mobile node is hosting a server, which may notalways be the case. Many group communication applications like Marratech Pro or Vic/Vatuses for example either a multicast group or a multicast reflector as a rendez-vous point andare consequently only operating as clients.

The other operation, which is supported by RMS, is called tracking and is used to preservecommunication across IP address changes during an already established session.

2.2.3 Exchanging location information

Exchanging location information can principally be done in two different ways. One solutionis to use a separate control channel similar to FTP. A drawback is however NAT firewalls,which typically not allows topological information to explicitly be carried as payload inpackets. A better way to exchange location information is to send control packets in-band, i.e.control packets are sent in the same stream as user data. The topological location of a remoteend-point can then implicitly be determined by examining the source address and the sourceport of the received control packet, which also contains the socket identifier of the remoteRMS. This method allows RMS to identify individual packet flows even if IP addresses orport numbers are changed.

The same method is also used to enable redundancy, for example during a soft handover.The only difference it that control packets are sent from several internal sockets instead of


Figure 2.4: Test scenario 1 (Manual deactivation): Jitter variation during the experiment.

just one. The remote RMS that receives the control packets will then obtain several locationsfor the same socket identifier and can thus forward out-going packets to multiple locations.

A general problem that must be solved when developing an in-band signaling protocol,is how to distinguish control packets from user packets. RMS separates control packets fromuser packets by examining the header of each packet. Packets that start width a unique 32bits random number is treated as control packets and never exposed to applications.

2.3 Evaluation

Extensive use of Marratech Pro has shown that audio is the most sensitive of all involvedreal-time media [53]. Efforts have therefore focused on studying how audio quality isaffected by handovers. This has mainly been done by measuring packet jitter, packet space(delay between two consecutive packets) and packet losses during a GSM conversation. Allcollected data were sampled from Marratech Pro, which uses RTP/RTCP [48] to gatherstatistics about the connections.

The following sections will briefly describe the prototype, the experimental test-bed andpresent the results.

2.3.1 The prototype

The main part of the RMS is implemented in Java JDK 1.4 under Microsoft Windows XP.The Java Native Interface was used to implement functionality not supported by the Javaplatform. The IP Helper API available in Windows was used to access the routing table andto detect new or disconnected network interfaces.


Figure 2.5: Test scenario 1 (Manual deactivation): Packet space variation during theexperiment.

Marratech Pro was modified by replacing the standard Java DatagramSocket with theRMS. Since Marratech Pro clients either uses IP-multicast or a media gateway called theE-meeting Portal for packet distribution, it was also necessary to replace the standard JavaDatagramSocket in the E-meeting Portal.

2.3.2 The test-bed

Even if RMS is primarily designed for heterogeneous interoperability, it was decided to makethe test environment as homogeneous as possible to eliminate factors that could affect theresult.

Figure 2.3 illustrates the test-bed, which consists of three hosts and two WLAN networksconnected to a shared network. WLAN connectivity was provided by two Apple AirPort withbuilt-in NAT routing and two Lucent Orinoco WLAN adapters attached to a laptop. Two ofthe hosts were running Marratech Pro and the third was running Marratech E-meeting Portal.The E-meeting Portal machine was run on a Pentium III 500 MHh based Linux machine andthe others were run on Pentium III 1.2 GHz based Microsoft Windows XP machines.

By assigning one WLAN network higher priority, it was possible study three differenthandover scenarios:

1. Manual deactivation The current used network interface was disabled from the controlpanel in Windows.

2. Unplugged base-station The current used WLAN base-station was disabled byunplugging the power outlet.


Figure 2.6: Test scenario 3 (Manual deactivation): Jitter variation during the experiment.

3. Roaming The user moved away from one WLAN network until connectivity was lost.

Handovers were either initiated proactively when a network with higher priority becameavailable or reactively when a network connection was lost. This setup made it possible tostudy both proactive HHO and SHO as well as reactive HHO.

2.3.3 Results

Figures 2.4 and 2.5 show packet jitter and packet space for a receiver when the currentnetwork interface was temporary disabled. The X-axis represents the elapsed time duringthe experiment. A HHO was for example triggered after 109 seconds and 228 seconds.

Since GSM packets were sent every 20 ms in average, it was possible to measure handoverlatency by detecting abnormal packet space, i.e. divergence in delays between packets (packetspace). Note that the peeks that occurred just before a SHO (after 176 and 297 seconds)is not caused by RMS, which can also been seen in the diagram plotted in the upper leftcorner inside figure 2.5. A theory is that they are caused by the interruption management inWindows. The phenomenon was not encountered during roaming or when the power outletto a base-station was unplugged.

Figures 2.6 and 2.7 show how jitter and packet space variation during the roamingscenario. The first peek in figure 2.6 was caused by a door which was suddenly closed.It was difficult to make a voice conversation when the jitter became higher than 10 ms, whichhappened after 23 seconds.

All experiments except the roaming scenario were repeated 20 times each to get moreaccurate results. Tables 2.1 and 2.2 summarizes the results for both a receiver and a sender.Standard deviations are given within parenthesis.


Figure 2.7: Test scenario 3 (Manual deactivation): Packet space variation during theexperiment.

As can be seen, it took in average around 700 ms to recover when the current networkadapter was disabled. Unexpectedly, it took more than 12 seconds to recover when the base-station was unplugged. No packet losses or extra latency were observed during a SHO.

2.4 Discussion

This paper has presented a mobility scheme, which allows real-time applications to adapt tomobility. RMS does not require any extra support from the network infrastructure and cantherefore be used on any Internet connected network, even today.

The paper has also presented an investigation of using the RMS for audio transport, forwhich reason a prototype version of a commercially available E-meeting software (MarratechPro) was used. The investigation has shown that soft handovers can be executed without lossof packets or handover latencies. A hard handover on the other hand took in average 200 ms tocomplete, which indicates that redundancy during handover is important but that more workneeds to be done to predict failures and disconnections. For example, will soft handoverstill be efficient if there is a significant difference in round-trip-time between the involvednetworks? How long time before a disconnection must at least a soft handover be initiated?And most importantly, how can a disconnection be predicted?

An interesting observation is the difference between a reactive and a proactive HHO. Theresults indicate that a reactive HHO at least takes 700 ms and a proactive HHO around 300ms to complete. This means that it takes 400 ms just to detect that connectivity was lost. If adisconnection can be detected instantly, then it will only take 300 ms to complete a reactiveHHO, which is a significant improvement. This problem prompts for better operating system


Table 2.1: Average handover latency and packet losses during a handover at the receiverend-point.

Handover scenario Handover latency Lost packets

Reactive HHO Disable 735 ms (204) 36 (10)Reactive HHO Unpl. 12330 ms (199) 618 (10)Proactive HHO 226 ms (40) 10 (2)Proactive SHO 0 ms (0) 0 (0)

Table 2.2: Average handover latency and packet losses during a handover at the sender end-point.

Handover scenario Handover latency Lost packets

Reactive HHO Disable 721 ms (267) 36 (13)Reactive HHO Unpl. 12252 ms (266) 612 (14)Proactive HHO 296 ms (50) 14 (3)Proactive SHO 0 ms (0) 0 (0)

support where applications can receive notifications when connections become disconnected.After all, it is often the operating system that knows first or even decides when a connection islost. For example when a cable is unplugged or when the signal strength becomes too weak.

Another interesting observation is audio which became unintelligible when WLANcoverage was low. For that reason, it may be important to use redundancy or proactivelyinitiate a handover to another network even if connectivity is not completely lost. However,for some non-real time media it may still be satisfying to stay connected and make use of acheap WLAN network as long as possible. In addition, for other media than audio it maynot be acceptable from an economical point of view to use redundancy. These observationsindicate that mobility must not be generally solved, but rather semantically for each involvedmedia or application.

To sum up, the paper has shown that handovers can be done fairly efficient and thatapplications can benefit from a more semantic approach to mobility. However, in orderto support seamless mobility, more work must either be done in developing improvedfast handover techniques or soft handover schemes capable of predicting failures anddisconnections.

2.4.1 Future work

First of all, better operating system support for sending packets must be developed. InWindows XP, this can be done by developing a NDIS protocol driver that can be accessedfrom user space. This allows internal sockets to send packets directly to link layer driversindependently how the routing table is configured.


More work must also be done to improve the handover manager. Using RMS to evaluateend-to-end performance seems to be a promising approach when deciding which networkconnection that performs best. Nevertheless, the financial cost of using a network connectionshould not be forgotten in the decision process. The relationship between QoS, charge modelsand handovers needs to be studied more closely.

2.5 Acknowledgment

The work was sponsored by the Centre for Distance-spanning Technology (CDT) andMäkitalo Research Centre (MRC) under VITAL and VINNOVA RadioSphere.

Part 3

Providing Seamless Mobility withCompetition based SoftHandover Management

31

Providing Seamless Mobility with Competition based Soft Handover Management 33

Providing Seamless Mobility withCompetition based Soft Handover Management

Johan Kristiansson, Peter ParnesDepartment of Computer Science & Electrical Engineering

Division of Media TechnologyLuleå University of Technology, 971 87 Luleå, SwedenEmail: {Johan.Kristiansson, Peter.Parnes}@sm.luth.se

Abstract

As host mobility and radio interference in wireless networks cause packet losses and delays,it is difficult to develop useful mobile real-time media applications. This paper describesa new handover strategy for end-to-end mobility called Competition based Soft HandoverManagement (CSHM). During a handover, redundant packet streams are sent throughmultiple connections which are later merged into one stream when received by the otherend-point. As each network connection competes with other connections in contributing tothe merged packet stream, the handover process can be viewed as a competition.

As a proof of concept, CSHM has been implemented in Resilient Mobile Socket, RMS,an application-layer mobility scheme and used together with Marratech Pro, which is acommercially available e-meeting application. By using this prototype, the paper showsthat it is possible to minimize redundant packets as well as decrease packet losses duringhandovers.

3.1 Introduction

The rapidly growing number of Wi-Fi hotspots and worldwide deployment of new wide-areanetworks, such as UMTS have made it possible to develop new wireless multimedia servicesthat can be used anywhere and anytime using any available carrier or operator. Mobile e-meeting applications that are running on portable devices with multi-access capabilities willfor example allow users to stay connected and participate in virtual communities by usingwide-area cellular networks or inexpensive high performance Wi-Fi connections.

Even if multi-access gives users more flexibility in communication, it also imposesnew demands on network management and interoperability. When users move betweendifferent physical locations, it may become necessary due to limited coverage or bad networkperformance to make a handover to another network. Similarly, if a better network becomesavailable, a handover should automatically be initialized to the network offering the bestprice/performance ratio subject to the user’s need.

34 Providing Seamless Mobility with Competition based Soft Handover Management

Today, users must normally take an active part in the handover process and are oftenrequired to manually select which network to use. Moreover, during or immediately after ahandover it is very common that packet losses and delays occur due to signaling propagationof new location updates. For most applications, such as HTTP or FTP, handover delay is notof vital importance, e.g. waiting one or two second extra when downloading a web page isnot critical. For real-time media on the other hand, delays and packet losses are extremelyimportant and even a small disturbance can make a media stream unintelligible.

Research about mobility management has so far mainly focused on how to preservecommunication and manage location updates. Handover management however, i.e. makingfast and low delay handover decisions is still a challenging problem. A handover algorithmmust for example be able to evaluate all available networks and select the best performingnetwork as fast as possible in order to avoid interruptions in communications. This isparticularly difficult as wireless performance can fluctuate rapidly due radio interference,especially if the coverage is bad.

Oscillations are another problem with handover management. If it takes time to completea handover and if the performance of a network fluctuates, then there is always a risk thathandovers are triggered back and forth between two or more networks causing instability andseriously degraded performance.

These problems raise the question of whether or not it is possible to design a handoveralgorithm that can:

1. Automatically select the network that is the most suitable for real-time media, i.e. thenetwork with the least packet losses and end-to-end delay.

2. Make a handover to that network without the users perceiving interruptions in real-timemedia flows.

3. Make handover decisions without the users perceiving degraded performance due tooscillations.

This paper presents a new handover decision algorithm called Competition based SoftHandover Management CSHM, that solves these problems. In the paper it is assumed thatmobile hosts have access to at least two connections simultaneously. It can also be worth topoint out that handover decisions are only based on network performance. Decisions basedon financial costs, such as dynamic charge models (none flat-rate) is left for future work.

The rest of the paper is organized as follows. Section 3.2 gives a brief introduction toprevious work related to handover management. In section 3.3, the RMS is briefly describedfollowed by a more extensive presentation of CSHM. In section 3.4, the algorithm is evaluatedusing the Marratech Pro prototype and in section 3.5, the paper is finally concluded withdiscussion and future work.


3.2 Background and related work

There have been numerous proposals for providing lossless handovers and minimizing thehandover delay to support wireless multimedia. Several micro-mobility schemes have forexample been proposed to complement Mobile IP [44]. Cellular IP [54] provides improvedhandover support in limited geographical areas by incorporating cellular principles foundin traditional telecommunication networks. Another micro-mobility scheme, HierarchicalMobile IP [52], tries to reduce the home network registration time by using a hierarchicalnetwork management structure. A difference between the work presented in this paper andresearch related to Mobile IP, is that CSHM is completely implemented in the application-layer and requires no support from the networks. As mobility is managed end-to-end, CSHMcan provide seamless handovers between any network (e.g. a handover between a Wi-Finetwork and a UMTS network) and not only seamless handovers within a Mobile IP orCellular IP enabled network. Another difference is that the paper focus on handover control,i.e. how to trigger handovers, rather than describing how to implement handover support.

A common way to trigger handovers is to monitor the signal strength to the base-stationsand use some sort of dwell-timers, hysteresis or threshold based control algorithm [7, 42, 57].One problem with these handover strategies is that they tend to increase the handover delay,which makes them unsuitable for real-time media.

To make more accurate handover decisions, several location-aided handover strategieshave been proposed in the literature [17, 22]. These studies have shown that user movementscan be fairly predicted by using a history of recorded user movements, current directionand velocity of the user. However, it has been discussed that mobility prediction algorithmsin general are incapable of adapting to new situations and that a small random variationcan cause many mobility prediction algorithms to fail [11]. Besides, it is unclear if currenttechnologies, for example the 802.11b can provide sufficient positioning precision [30] tomake handover decisions fast enough to support real-time media.

Clearly, if packet loss during handovers could be avoided completely, it would bepossible to perform speculative handovers without degrading the quality. To provide losslesshandovers between heterogeneous networks, some work has recently been done to addsoft handover support in layers above the network layer. RMS [31] provides for examplesoft handover support by allowing simultaneous use of multiple UDP sockets for datacommunication. Similar functionality is provided by the ADD-IP [20] mechanism in theStream Control Transmission Protocol (SCTP) [21].

The major contribution of this paper is a new type of handover management strategy forend-to-end based soft handovers. In contrast to other IP based soft handovers schemes suchas [29], CSHM is designed to use multiple IP connections simultaneously. Rather than usingredundant connections only as passive backup links, the paper shows how redundancy can beused to improve network performance and how to evaluate end-to-end performance duringhandovers.

CSHM can also be compared with other multi-link streaming protocols, for example thework presented in [15] or the Multimedia Multiplexing Transport Protocol [38]. However,


Send

Receive

Redundancy

SHO

RMS

Send

Receive

Internal socket

Send

Receive

Internal socket

Handover manager

Real-time media

application

SuspendCSHM

HHO


it is important to point out that the purpose of CSHM is not to increase the throughput, butrather to minimize packet delay during handovers.

3.3 Competition based Soft handover Management

There is a strong relationship between handover management and mobility management.While the later provides the fundamental architecture that is needed to execute handovers,handover management controls and initializes handovers. To understand how CSHM works,it is necessary to first explain how handover support is implemented in the RMS.

3.3.1 Resilient Mobile Socket

RMS is an application layer mobility scheme for streaming real time media, developed at thedivision of Media Technology at Luleå University of Technology. The primary purpose ofthe RMS is to preserve the communication and provide a more robust platform by allowingapplications to suspend connections and then resume them using another (or the same) IPaddress.

An application that sends and receives packets over the Internet normally uses a socket,representing an end-point of a communication link to another application running on theInternet. By encapsulating multiple sockets into a new socket abstraction (RMS), anyencapsulated or internal socket can fail without disturbing the applications. As each internalsocket represents an entry point to each connected network, running applications will still beable to communicate if the current active internal socket becomes disconnected and anotherinternal socket is available. In this way, a handover process in RMS refers to migrating dataflows between different internal sockets.

Figure 3.1 shows an overview of the RMS architecture and how internal sockets areencapsulated. Note, that RMS besides functionality to send and receive packets also providesmethods to control which internal sockets that should be used.


The SUSPEND procedure is used to hibernate on-going communication and is automati-cally called when all network connections are lost, i.e. no internal sockets can be used.

The HHO (hard handover) procedure provides the opposite operation and is used torecover from a disconnection or to initiate a handover to another network. During a hardhandover, the currently active internal socket is first removed before a new internal socket iscreated. A hard handover is typically a reactive or an unplanned operation and occurs whensomething unexpected happens to the system, for example when a connection is suddenlylost. Managing handovers in this case is quite simple as there is usually only one connectionto choose from.

The SHO (soft handover) procedure provides in contrast to hard handovers, functionalityto use redundancy during handovers by using multiple internal sockets simultaneously tosend and receive packets. This technique eliminates handover delay and prevents packetsfrom getting lost, but must be proactively initiated to be effective, i.e. initiated before thecurrently active internal socket becomes disconnected. Because the RMS now has access tomultiple connections, a handover management algorithm must be able to evaluate and selectthe best available connection.

An important component in the RMS architecture is the Handover Manager, which canbe seen to the left in figure 3.1. The Handover Manager is responsible for monitoring thesystem and triggering handovers by calling the procedures mentioned above. A differencebetween RMS and other mobility management schemes such as Mobile IP, is that handoverdecisions are always made per packet stream rather than for the whole system. This makesit possible to apply different handover strategies for different media. Audio packets canfor example be sent over a Wi-Fi connection while video packets are sent over a UMTSnetwork. Moreover, for none real-time media it may be sufficient to only use hard handoversas soft handovers usually waste bandwidth. From a handover management point of view, thiskind of flexibility is extremely important as it relieves the Handover Manager from resolvingconflicting handover requirements.

3.3.2 Competition based Handover management

To be able to use soft handovers efficiently several new problems must be solved. The perhapsmost difficult problem is how to decide when to initialize soft handovers. As mentionedbefore, soft handovers must always be initialized proactively, i.e. triggered when at least twointernal socket are available. A soft handover management scheme must consequently beable to predict when a connection is going to be lost.

Another difficult problem with soft handovers is how to minimize redundancy. Asredundancy wastes resources, both in terms of bandwidth and computer resources, an efficientsoft handover management algorithm should strive to minimize redundant packets and in thesame time keep the network performance as good as possible.

The rest of this section discusses how CSHM addresses these problems and how handoverdecisions can be made by using a competition based evaluation between internal sockets.


3.3.3 Making proactive handover decisions

Even if it would be possible to make proactive handover decision based on mobilityprediction, it is important to point out that real-time media such as Voice-over-IP requiresthat handover decisions are made within a couple of hundreds of milliseconds, before theplayout buffer is exceeded. Considering the precision of current technologies and how muchthe network performance can fluctuate during a couple of hundreds of milliseconds, location-aided handovers do not seem to be a very promising approach. Besides, it is very likely thatthe performance of a radio network gets degraded even if the user is not moving at all, e.g.somebody closes a door or the user touches the radio antenna.

A more realistic alternative to location-aided handover is to make handover decisionsbased on jitter interruptions in media streams. When radio conditions are bad it is verycommon that packets get lost over the air interface. Link-layer approaches such as automaticrepeat request (ARQ) attempt to hide channel losses from the network layer by re-transmittinglost packets. However, as it takes time to retransmit lost packets, i.e. ARQ will increasepacket delay, and since packets cannot be retransmitted forever some packets will still getlost.

When a user moves away from a network physically, it is very likely due to limitedcoverage that packet losses and delay occur just before a connection is completely lost. Thisinformation is used by the CSHM algorithm to proactively initialize a soft handover.

When an RMS end-point receives a packet stream from another RMS, it calculates apacket delay based on the arrival time of the current packet and the previous packet. If thepacket delay exceeds a threshold value, Φ, it will send a SHO request to the other end-point,asking it to initialize a soft handover. In this way, the receiver sends feedback1 to the sender,which makes the final handover decision. If an RMS is both sending and receiving packets,it will take at least two handover decision rounds before both incoming and outgoing packetsare duplicated. Note that CSHM does not make any difference between a severely congestednetwork and a network with bad radio performance. If an access network becomes congestedsomewhere, it may also be reasonable to initiate a handover to another network, assumingthat the congested network is not shared with the other available access networks. In thiscase, there is a risk that redundancy makes the congestion even worse, which will negativelyaffect the performance of all internal sockets.

It is important to point out that triggering handovers based on interruptions in mediastreams can only be applied if packets are sent with regular intervals, i.e. packets are sentin a specific pattern. To manage handovers for other (none real-time) media, the HandoverManager periodically scans the routing table for changes. In case a soft handover has notalready been initialized, the Handover Manager will for example trigger a hard handover ifthe currently used network adapter disappears from the routing table. Similarly, to determineif a new network adapter performs better than the current one, the CSHM algorithm can beconfigured to automatically trigger a soft handover when a new network adapter appears inthe routing table.

1RMS provides an in-band signaling protocol, which can be used to exchange control information between peers.


3.3.4 Filtering out duplicate packets

If packets are not lost over the network, the receiver will get duplicate copies of eachpacket when redundancy is enabled. Even if many multimedia applications are designed tohandle forward error correction (FEC) and duplicate packets, it can dramatically decrease theperformance of the applications. In group communication applications, like Marratech Pro,it is very common due to lack of ubiquitous multicast to use a server/reflector to re-distributepackets to other participants. Hence, sending multiple copies of each packet will undesirablyincrease the load on the server.

To prevent this from happening, a mechanism is needed to filter out duplicate packetsand automatically turn off redundancy when performance becomes satisfactory again. Byencapsulating all redundant packets into a new packet containing a sequence number, thefirst packet received for a given sequence number is forwarded to the application and allother copies are dropped. One advantage of using this first-come-first-serve scheme is thatit can significantly improve the network performance during a handover. If for example twonetworks are performing badly, it may still be possible to merge the bad networks into onegood network.

Algorithm 1 Competition based Soft Handover ManagementEnsure: the best performing internal socket is always used

1: dwellTimer � 02: loop3: if packetDelay � Φ then4: enableRedundancy()5: dwellTimer � 06: end if7: if dwellTimer � ∆ then8: isocketde f ault � selectWinner

�Contributionisocket1 � � � � ContributionisocketN �

9: disableRedundancy()10: end if11: increase(dwellTimer)12: end loop

3.3.5 Selecting a new default internal socket

To minimize redundant packets, CSHM uses a dwell-timer that expires after a predefinedamount of time, ∆. Assuming that a new SHO request has not been received, i.e. the dwell-timer has not been reset, redundancy will be disabled after the dwell-timer has expired.

The CSHM algorithm is summarized in algorithm 1. One important difference betweenCSHM and other handover algorithms [7, 42, 57] is that the new default connection is notdecided before the handover. During the handover, each receiver calculates in percent howmuch each duplicated stream (internal socket) contributes to the merged stream. This newmetric is called packet contribution and can be viewed as a combination of packet losses and


delay in respect to all other duplicated streams. The internal socket that got the highest packetcontribution is selected as the new default internal socket after the dwell-timer has expired.

The whole handover process can be viewed as a competition where the threshold, Φ,determines when the competition starts, the dwell-timer, ∆, when the competition ends, andpacket contribution who the winner is. A competition may not necessarily result in a handoveras it is possible that the currently selected internal socket wins. This means that CSHM canalso be used to improve network performance without actually switching networks.

3.4 Evaluation

To evaluate CSHM, a working prototype has been built by integrating RMS with MarratechPro [3], a commercially available e-meeting software providing tools for synchronousinteraction by combining audio, video, chat and a shared white-board.

Extensive use of Marratech Pro has shown that audio is the most sensitive of all involvedreal-time media [53]. This evaluation has therefore focused on exploring the relationshipbetween different Φ and ∆ settings and the effect on GSM audio quality. The followingsections describes the prototype, the experimental test-bed and present the results.

Network C192.168.0.0

WLAN A192.168.2.0

WLAN B192.168.1.0


RMS-enabled E-meeting Portal192.168.0.21


Figure 3.2: The test-bed. The arrows illustrates the logical packet flow.

3.4.1 Implementation

The main part of the RMS is implemented in Java JDK 1.4 under Microsoft Windows XP.The Java Native Interface was used to implement functionality not supported by the Javaplatform. The IP Helper API [1] available in Windows was used to access the routing tableand to detect new or disconnected network adapters.


0

50

100

150

200

250

300

0 100 200 300 400 500 600

Pac

ket d

elay

[ms]

Time [s]

Marratech Pro side, id=isocket1, nic=ORiNOCO Wireless LAN, ipaddr=192.168.2.4, ap=home.net

(a) Packet flow at internal socket 1.

0

50

100

150

200

250

300

0 100 200 300 400 500 600

Pac

ket d

elay

[ms]

Time [s]

Marratech Pro side, id=isocket2, nic=Dell TrueMobile 1150, ipaddr=10.0.1.3, ap=sky.net

(b) Packet flow at internal socket 2.

0

50

100

150

200

250

300

0 100 200 300 400 500 600

Pac

ket d

elay

[ms]

Time [s]

Marratech Pro side, id=RMS, nic=Dell TrueMobile 1150, ipaddr=192.168.2.23, ap=home.net

(c) Merged packet flow.

Figure 3.3: Packet flows during the experiment.

Marratech Pro was modified by replacing the standard Java DatagramSocket with theRMS. Since Marratech Pro clients either uses IP-multicast or a media gateway called thee-meeting Portal to distribute packets, it was also necessary to replace the standard JavaDatagramSocket in the e-meeting Portal. The CSHM algorithm was implemented as a partof the Handover Manager mentioned in section 3.3.1.

3.4.2 Methodology

The Marratech Pro based prototype has been tested and used together with a commercialGSM/GPRS network and several 802.11b Wi-Fi networks. Unfortunately, as the GSM/GPRSnetwork performed badly2, it was impossible to transmit real-time media over it. Besides,

2The round-trip time was larger than one second.


Table 3.1: Data from the experiment at the Marratech Pro end-point.

Int. socket 1 Int. socket 2 Merged stream Emulated

Packets received 23448 27699 30557 30557Total packet contribution 26.5% 73.5% - -Packet delay � 50 ms 286 290 114 132Packet delay � 125 ms 57 53 22 22Lost packets 7468 3217 359 359

Table 3.2: Data from the experiment at the Portal end-point.

Int. socket 1 Int. socket 2 Merged stream Emulated

Packets received 24867 29319 30909 30909Total packet contribution 5.1% 94.9% - -Packet delay � 50 ms 350 280 166 166Packet delay � 125 ms 68 27 27 27Lost packets 6049 1597 7 7

as the network was shared with other users, it was hard to interpret the results and makerepeatable experiments. It was even difficult to repeat the experiment by moving aroundbetween purely isolated 802.11b networks as it was impossible to move exactly the same ineach experiment. One solution to this problem would be to repeat the experiment until astatistical certainty is obtained. However, as this can be very time consuming, it was decidedto use some other method.

Another possibility would be to use a network simulator, but as this would require a re-implementation of both CSHM and RMS in the simulator it was finally decided to emulatedifferent traffic flows instead. By saving a trace file for each internal socket and then replaythe trace files it was possible to test how different Φ and ∆ settings affected the merged stream.It was particularly interesting to investigate packet losses and how many redundant packetsthat were received as well as how many times the playout buffer3 was exceeded.

Figure 3.2 illustrates the test-bed that was used to generate the trace files. The test-bedconsists of three hosts and two partly overlapping Wi-Fi networks connected to a sharednetwork. Wi-Fi connectivity was provided by two Apple AirPort with built-in NAT routingand two Lucent Orinoco Wi-Fi adapters attached to a laptop. Each Wi-Fi adapter wasassociated with different Wi-Fi network. The E-meeting Portal was run on a AMD Athlon 1.2GHh computer and the others were run on Intel Pentium III 1.2 GHz computers. MicrosoftWindows XP Professional was used as the operating system on all computers.

3Marratech Pro uses a dynamic playout buffer between 0 and 125 ms.


Table 3.3: Relationship between Φ, duplicated packets and lost packets. ∆ = 100 ms.

Φ=Infinity Φ=21 ms Φ=25 ms Φ=50 ms Φ=100 ms

Packets received 30909 30885 30868 30862 30799Delay � 125 ms 22 22 22 22 22Lost packets 7 31 48 54 117SHO requests 0 2498 1924 1104 541Duplicated packets 23306 3103 1882 870 363

3.4.3 Results

The trace files were generated by moving around physically with one laptop in the test-bedand sending GSM audio between the two Marratech Pro clients. By disabling the CSHMalgorithm temporarily and using redundancy during the whole experiment, it was possible toget full trace files for both internal sockets.

Figure 3.3 shows the packet delay for each internal socket at the Marratech Pro side aswell as the packet delay for the merged packet stream. Similar results were obtained for thePortal end-point.

As can be seen in figure 3.3(a) and 3.3(b), internal socket 1 lost connectivity three timeswhile internal socket 2 lost connectivity only one time. Since all disconnections occurred atdifferent times, it was possible to merge internal socket 1 and internal socket 2 to one packetstream without the user noticing any disconnections at all. Moreover, note that the packetdelay for the merged stream is significantly reduced compared with internal socket 1 andinternal socket 2. Apparently, all copies of a specific packet were not always lost even if thepacket loss rate was high for both internal sockets.

Table 3.1 and table 3.2 summarize statistics from the experiment for the Marratech Proand the Portal end-point. At the Marratech Pro side, internal socket 1 contributed in totalwith 73.5% of all packets received and at the Portal side internal socket 1 contributed with94.9% of all packets sent to the Portal end-point. Note that the Portal end-point only had onenetwork connection during the experiment and hence only one internal socket. The resultpresented in table 3.2 shows how the internal socket 1 and the internal socket 2 located at theMarratech Pro side were perceived at the Portal side.

As can be seen in table 3.1 and table 3.2, the emulated stream corresponds quite well withthe merged stream obtained from the experiment. The merged stream can also be viewed asthe base case or the optimal case as redundancy was always used. Ideally, a Φ and ∆ settingshould result in a similar stream, but with less redundant packets.

3.4.4 CSHM performance

The CSHM parameter space was explored by locking one parameter, either ∆ or Φ and tuningthe other parameter. The goal with this investigation was not to obtain an optimal parametersetting, but rather to get a better understanding of the CSHM algorithm.


Table 3.4: Relationship between ∆, duplicated packets and lost packets. Φ = 50 ms.

∆=Infinity ∆=50 ms ∆=100 ms ∆=200 ms ∆=0.5 s ∆=2 s

Packets received 30909 30725 30862 30871 30868 30891Delay � 125 ms 22 22 22 22 22 22Lost packets 7 191 54 45 48 25SHO requests 0 1131 1104 1078 1075 1016Duplicated packets 23306 237 870 1653 2519 11873

Table 3.3 and 3.4 show the relationship between, ∆, Φ, lost packets and duplicated packetsfor the Marratech Pro end-point. Similar results were obtained at the Portal end-point. Thenumbers presented in table 3.3 and 3.4 are average values from six test runs. As can be seenin table 3.3, a small Φ value resulted in many SHO requests, which consequently resultedin more duplicated packets and hence less lost packets. Each GSM packet was sent withapproximately 20 ms delay and setting Φ close to 20 ms resulted in 2498 SHO requests.When Φ was set in the range between 0 and 100 ms, the playout buffer was exceeded 22times, which is exactly the same performance as the base-case, i.e. the optimal performance.

The relationship between ∆, lost packets and duplicated packets was investigated bylocking Φ to 50 ms and adjusting the ∆ parameter. As expected, a large ∆ value resultedin more duplicated packets and hence less lost packets. Since redundancy improved theperformance during the experiment, a large ∆ also resulted in fewer SHO requests.

By studying the trace files it was observed that if the packet arrival jitter was low andpacket losses were concentrated in terms of time, it was efficient to use a low Φ value and abig ∆ value. If on the other hand the packet arrival jitter was high, then it made more senseto use a higher Φ value to prevent the CSHM algorithm from always being active.

3.5 Discussion

In the introduction it was asked whether or not it is possible to develop a handover decisionalgorithm that can:

1. Automatically select the network that is the most suitable for real-time media, i.e. thenetwork with the least packet losses and end-to-end delay.

2. Make a handover to that network without the users perceiving interruptions in real-timemedia flows.

3. Make handover decisions without the users perceiving degraded performance due tooscillations.

In brief, the key to solve all these problems is to utilize multiple network connectionssimultaneously. The first problem is for example solved by using redundancy to compare


each network connection and automatically select the connection with the least packet lossesand end-to-end delay. As the use of a new internal socket does not affect the performanceof the currently used socket, there is no risk that the performance gets degraded because of ahandover. As an implication, it is no longer important to reduce the handover frequency, i.e.the users will not perceive any performance degradation when trying a new network.

The second problem is solved by merging multiple packet streams into one stream.This technique can also be used to decrease packet delay and reduce packet losses withoutperforming a handover to another network. The results presented in the paper indicate thatCSHM can be used to merge badly performing networks to one good network. However, ifredundancy is going to be used as proposed in the paper, it is important to be able to controland minimize redundant packets. The results suggest that CSHM can be used to solve thisproblem or at least to reduce redundant packets for GSM audio traffic.

Regarding the oscillations, i.e. the third problem, the CSHM algorithm does not directlyeliminate the oscillations as it is still possible that handovers are triggered back and forthbetween several networks, i.e. multiple SHO requests are triggered. However, the userswill not perceive degraded performance due to the oscillations as the host receives packetsfrom both the old and the new network during the handover. Rather than repeatedlyswitching between two badly performing networks, CSHM uses redundancy to improvethe performance until some of the networks become stable again or until there is only oneworking connection left.

3.6 Acknowledgment

This work was done within the VITAL project, which is supported by the Objective 1 NorraNorrland - EU structural fund programme for Norra Norrland. Support was also provided bythe Centre for Distance-spanning Technology (CDT) and Mäkitalo Research Centre (MRC).

Part 4

Market-based BandwidthManagement for Distributed

Multimedia Applications

47

Market-based Bandwidth Management for Distributed Multimedia Applications 49

Market-based Bandwidth Management forDistributed Multimedia Applications

Johan Kristiansson, Jeremiah Scholl, and Peter ParnesDepartment of Computer Science & Electrical Engineering

Division of Media TechnologyLuleå University of Technology, 971 87 Luleå, Sweden

Email: {Johan.Kristiansson, Jeremiah.Scholl, Peter.Parnes}@sm.luth.se

July, 2004

Abstract

This paper presents a framework that applies microeconomic theory in order to create avirtual marketplace for the buying and selling of bandwidth within a multimedia application.The key components of the framework are a bandwidth broker that puts the current supply ofavailable bandwidth "on the market" at a particular price, and bandwidth consumers whichuse utility functions for each media to calculate the demand by mapping the relative gain theyoffer the user at different bandwidth levels. This allows bandwidth to be allocated efficientlyby using basic supply and demand principles where the broker raises the price if the totaldemand from all its customers (the media) exceeds the available supply, or lowers the priceif the demand is lower than the available supply.

The framework offers two separate advantages. The first is that it allows bandwidthmanagement for all media to be handled in a centralized way in order to give the optimalaggregated experience to the user. The second is that it can help applications moreintelligently navigate 4th generation wireless networks by using the bandwidth broker asa centralized supply point that looks for the best available connection(s) at all times.

As a proof of concept, a prototype using the framework has been integrated intoMarratech Pro, a commercially available e-meeting application.

4.1 Introduction

Distributed multimedia applications generally offer a wide variety of media, which worktogether in order to provide users with a rich aggregate experience. The combination of allthese separate media into one application brings up a rather complex problem, which is howto best divide resources between the different media in an optimal way. Early solutions to thisproblem were fairly simple and thus inflexible and inefficient. For example, the classic wayof allocating bandwidth for tools on the MBone was to keep aggregate bandwidth usage forall users below a static limit while dealing with each media separately. For example, videomight be allocated 500 kB/s, with audio being allocated 100 kB/s and so on.

50 Market-based Bandwidth Management for Distributed Multimedia Applications

There are various problems that this approach does not take into consideration includinghow to handle congestion, how to deal with situations where not all users in a session needthe same amount of resources, and also how to best allocate any available bandwidth whena media is not being fully utilized. For example, it would be useful to give the 100 kB/sof bandwidth allocated for audio to some other media when nobody is speaking during amultimedia conferencing session.

Over the past several years a lot of progress has been made on how to solve the variousproblems mentioned above, with effective congestion control getting the most attention.However, designers are now faced with a relatively new problem that seems to be equallycomplex with those mentioned above. The rapidly growing number of Wi-Fi hot-spots andworldwide deployment of new wide-area networks, such as UMTS have made it possibleto develop new wireless multimedia services that can be used anywhere, anytime with anyavailable carrier or operator. This means that when navigating this heterogeneous 4th-generation wireless landscape applications will not only need to manage multiple usersand multiple media, but they will also need to manage multiple connection points whileconsidering competing connection speeds and pricing models.

This paper presents an application-layer framework for network-service management indistributed multimedia applications that is based on the microeconomic principal of supplyand demand. The goal of this framework is to create a centralized place where solutions to allproblems related to bandwidth allocation, including those mentioned above, can be integratedeffectively into an application. Thus, it is not intended to replace any existing scheme forcongestion control, method for sharing bandwidth between different users, or always-best-connected service, but instead seeks to connect these and other services together using thepower of the marketplace to manage network usage in an efficient way while maximizing thebenefit to the user.

As a proof of concept a prototype using the framework has been built into the commerciale-meeting product Marratech Pro and was used in several experiments that are described insection 4.5.

The rest of the paper is organized as follows. Section 4.2 covers previous work done inthe area. Section 4.3 gives a brief introduction to microeconomics in relation to the problemof bandwidth allocation within a multimedia application. Section 4.4 gives an overview theframework and section 4.5 presents a prototype we have built using the framework as wellas some experimental results. In section 4.6 a summary and conclusions are given and isfollowed up by future work.

4.2 Related work

Bandwidth management at the network level has been investigated for some time. The readeris referred to the monograph by Fulp [24] for a full summary of this work.

Microeconomic theory has frequently been considered as a resource management methodat the network level [5, 36, 37]. The main advantage with using microeconomics in thissituation is that it can provide for optimal resource allocation without requiring the provider


Audio Video Chat Other

Broker

UMTS/GPRSEthernet/Office

WLAN/LTUOther

The demand

The supply

GSM/GPRS

Figure 4.1: An overview of the marketplace used in the framework.

to know anything about the relative importance of various packets, keeping in tradition withthe layered IP model [24]. For example, adjusting the price for bandwidth depending on thelevel of congestion in the network will give users an incentive to adapt their applications ontheir own, thus preventing over-utilization.

However, a drawback of congestion pricing in general is that it requires dynamic chargingmodels, which are typically not used by Internet service providers today. Additionally, froma user’s point of view, it is important that the prices are predictable [12], which is not the casewith dynamic pricing where the cost continuously changes.

Even if market based resource allocation can be unsuitable at the network level from adeployment point of view, it has been applied in virtual economies in order to allocate CPUtime in operating systems [10, 25, 33, 43]. Our work differs from this work in that it focusesmore specifically on topics related to bandwidth allocation within a multimedia applicationrather than allocation of CPU time in an operating system.

Thus, the major contribution of this paper is that the framework presented allowsmicroeconomic theory to be used in a novel way in order to make it easy to combine variousnetwork services available to an application, such as IP-mobility and congestion control whilemaintaining the efficient use of resources and maximizing the benefit to the user.


4.3 Market-based bandwidth management

Microeconomic theory deals with production, purchase and sales of commodities that are inlimited supply [13]. In our case the commodity on the market is bandwidth and as usualthere are two key players: consumers and suppliers. Consumers attempt to optimize theirgain by purchasing commodities that give them the maximum gain at the lowest price, andsuppliers try to sell commodities the highest price they can get in order to maximize theirown profit. This leads to a variable pricing system that works like an “invisible hand” [49] inorder to distribute and allocate resources efficiently despite the selfish actions of each player.Eventually this price fluctuation will reach a state where the demand for goods at the goingprice equals the supply for goods at that price. When this state is reached, the market is saidto be in equilibrium [13].

4.3.1 Competitive market models

Equilibrium prices can be difficult to calculate because both demand and supply will varyover time. In our case the supply will vary depending on for example the type of connectioncurrently available, congestion in the network, or because of wireless interference, and thedemand may vary due to a wide variety of factors unique to every application. For example,if a user in an audio conference stops speaking then this user’s audio media may reduce itsdemand for bandwidth.

One way of solving this problem is to use a tâtonnement process [13] in order to adjust theprice iteratively until an equilibrium price is obtained. In this way, the producers decrease theprice if their production is not sold and increase the price if the demand exceeds the supply.The advantage of the tâtonnement method is that it is easy to implement without requiringmuch specific knowledge about the individual consumers or suppliers that will ultimatelyeffect the market price, making it easy to develop and integrate the different components thatcontribute to the equilibrium price separately.

Spot-markets: A spot market is a real-time market for the immediate sale and deliveryof commodities. It was first used by E.W. Fulp [24] to manage bandwidth at the networklevel and is based on a modified tâtonnement process to determine the price. In our currentimplementation of the framework the Bandwidth Broker Agent shown in figure 4.1 modelsa spot market, but in practice it would be possible to model other market based approachessuch as an auctioning system [25].

pn�

1�x �� pn

�x �� d

s(4.1)

Equation (4.1) shows how the price is iteratively calculated based on supply and demandusing the tâtonnement process, with pn

�x � representing the current price, pn

�1�x � next price,

d the aggregate demand of all customers, and s the current supply. More information on howto calculate supply and demand is given in the next two subsections. In section 4.5 we willshow that the performance and the stability of the spot-market algorithm is mainly affectedby two factors, the price recalculation rate and the supply recalculation rate.


4.3.2 Calculating the supply

The total supply that the broker can put onto the market is directly related to the amount ofbandwidth available to the application and can be bounded by a variety of factors. Most oftenthis supply will be equal to the capacity of the network but for non-flat-rate connections itmay also be bounded by budget controls set by the user or provider.

Due to the varying requirements for individual applications and media, there is no one-size-fits-all way of calculating available network resources. A large amount of research hasbeen done over the past few years on how to calculate the bandwidth limit for non-TCPtraffic and this has resulted in the creation of numerous protocols to serve applications withdifferent characteristics. For unicast traffic the most notable of these is the TCP-FriendlyRate Control Protocol [23], which uses an equation based send rate in order to deliver TCP-friendly traffic at a smoother rate than is provided by TCP. For multicast traffic the problem isa bit more complex and has thus resulted in the creation of a wider variety of protocols.In general, these protocols follow one of two strategies, either relying on the sender toadapt its send rate in a way that serves the needs of the entire receiver set [45, 59, 47](sender-based congestion control), or relying on the sender to make many quality levelsavailable concurrently through separate channels, allowing each receiver to "sign up" forthe appropriate channel(s) independently [40, 8] (receiver-based congestion control).

This means that the type of bandwidth being supplied will change somewhat dependingon the underlying congestion control scheme in use by the application. When using purelysender-based congestion control the broker will supply bandwidth for media that wish tosend out packets on the network, whereas the broker will supply bandwidth for packetsto be received when a receiver-based congestion control scheme is in use. Similarly, ifa combination of sender-based and receiver-based congestion control is being used by theapplication then the broker will sell both bandwidth to be sent, and bandwidth to be received.

An analysis of the exact congestion control scheme that should be used by each individualapplication in order to calculate the available network resources is outside the scope of thispaper. Instead, the framework we present is intended to help solve the orthogonal problem ofhow to leverage this available bandwidth in the way that gives the user the most benefit.

To accomplish this goal with a market-based approach it is necessary to map the relativedemand for each media so that the competition for available resources will result in the usergetting the greatest net benefit from the aggregate use of available bandwidth. A discussionon modeling the demand for each media is given in the next subsection.

4.3.3 Calculating the demand

In order for a media to decide just how much bandwidth it wants to buy at price P thereneeds to be a way for it to measure the relative gain it can offer the user when allocatedthe bandwidth. This is done by creating utility functions for each media. Each media’sutility function is a mathematical function, u

�x � , which can map to an infinite variety of

shapes. However, concave utility functions are the type most commonly used in classicalmicroeconomic theory, and are useful in our case since they give a fairly accurate model of


media that are less sensitive to bandwidth changes when allocation reaches some maximumrequirement [34].

Video is a good example of a media that falls into this category since human beings canonly notice a difference in the frame rate up until about 25 frames-per-second and tend to bemore more sensitive to changes below 15 frames per second. For example, they tend to gainmore when raising the frame rate from 1 to 6 frames per second than from 20 to 15 framesper second.

Utility function, u(x)

Price function, p(x)

Bandwidth [bytes / s]

Utility [Some unit / s]

x maxx min CSx

CS

Figure 4.2: A model for local optimization.

Figure 4.2 shows the relationship between the utility function, u�x � and the price function,

p�x � , which represents the total price it will cost the media to obtain a particular amount of

bandwidth.

Since each media wants to provide the user with the maximum net benefit (known asthe consumer surplus, CS) at a given price level, it can calculate the amount of bandwidth itshould attempt to purchase by finding the maximum difference between the utility functionand the price function, as shown by equation (4.2), where xmin specifies the minimum amountof bandwidth considered to be useful for the media and xmax specifies the maximum usefulamount. Hence, the media will not sign a network contract for less than xmin or more thanxmax.

CS � max � u � x � � p�x ��

s � t � xmin � x � xmax (4.2)


Media

Bandwidth Consumer

Agents

Bandwidth BrokerAgent

Buy/request bandwidth

Adaptbandwidth

usage

Informationabout supply

NetworkContract

NetworkAgents

Packets

Communicatecontextualinformation

Informationabout

demand

Packets

Adaptutility

function

the Internet

Informationabout available

networks

Packets

(audio, video etc.)

Figure 4.3: Interaction between agents in the framework.

If the utility function is concave, the CS for media m can be found by calculating the xmCS

,where

δ�u�xm

CS� �

δxmCS

� δ�p�xm

CS� �

δxmCS

s � t � xmin � xmCS � xmax (4.3)

The aggregate demand d for all media can be calculated as

d �i � n

∑m � 0

xmCS

(4.4)

,where n is the number of media used in the application. This aggregate demand is used tocalculate the new price during each iteration in equation 4.1.

Creating accurate utility curves for real world use may be a fair challenge, and therefore itis not expected that in most situations the user will be given this responsibility in any explicitway. However, application designers with a fair amount of expertise about the operationand use of their application should be able to create fairly robust utility curves that serve thegeneral needs of users.

In addition, allowing utility curves to dynamically change based on contextual informa-tion available to the application will allow for a high degree of customization in order toserve users in a variety of situations. For example, in a video conferencing session it has beenproposed that the video streams of certain “important” users should be prioritized by passingmessages between the clients in order to find out who each user is “looking at” [6, 46]. Thistype of scheme will integrate fairly natural into a market-based system by having each clientuse the information contained in these messages in order to change the utility curve for itsvideo stream when appropriate.


4.4 Overview of the framework

Figure 4.3, shows an overview of the framework proposed in this paper. In the virtualmarketplace the key player is the Bandwidth Broker Agent (BBA), which acts as a go betweenin order to connect all the buyers and sellers on the market. Thus, the BBA sells bandwidthto all the different media streams used in the application, while also purchasing bandwidthobtained from various Internet service providers (ISP).

4.4.1 Network contracts

Each media buys bandwidth from the BBA in the form of network contracts, which containthe following attributes:

� Price

� Byte limit

� Expire time

� Quality

The Price attribute specifies the cost of obtaining the network contract, in some virtualcurrency. The Byte limit attribute determines how many bytes that are allowed to betransferred using the contract. This may include incoming or outgoing traffic or bothdepending on the congestion control model used by the application. The Expire time attributespecifies the period of time that the contract is valid for. The Quality attribute is used to givethe application a hint of the network quality, e.g. expected packet loss or jitter estimations.For example, a customer buying bandwidth for a Voice-over-IP session might decide not topurchase network contracts if the end-to-end delay is too large.

4.4.2 The Bandwidth Broker Agent

The Bandwidth Broker Agent deals primarily with bandwidth allocation. It sells bandwidthin the form of network contracts that are sold on a first come, first serve basis to the variousmedia. In some cases if the price is set too low then the BBA will receive more requestsfor bandwidth than it can sell. When this happens the BBA simply sends an “out of stock”message to the customer, rather than a message confirming the purchase of a contract andtakes note of the extra demand when calculating the price during the next iteration using thetâtonnement process.

In some situations it will be useful for the BBA to put several different types of bandwidthon the market at the same time. For example, it might be the case that different Quality-of-Service levels are available from the current ISP. In this case the BBA would sell contracts foreach of these levels separately. Another situation where this would occur is if receiver-basedcongestion control is being used, as the BBA would need to sell bandwidth separately foreach sender that the client is receiving data from.


In addition, the BBA is responsible for passing on information about Quality-of-Servicerequests from the various media to the appropriate Network Agents.

4.4.3 The Bandwidth Consumer Agent

The Bandwidth Consumer Agent (BCA) is responsible for purchasing contracts on behalf ofa media. By using an optimization method described in subsection 4.3.3, it calculates thetotal amount and type bandwidth that should be purchased in order to maximize the benefit tothe user. The BCA also communicates information to the media it represents regarding howmuch bandwidth it has purchased. This information is necessary so that the media can adaptbased on the amount of bandwidth currently available. For example, a video encoder will beable to change the interval at which it encodes frames based on this information.

Sometimes a BCA may choose not to buy bandwidth due to a lack of Quality-of-Servicein the contract. In this case the BCA should send a message to the BBA telling it how muchbandwidth it would have wanted to purchase if the correct Quality-of-Service level had beenon offer. The BBA can then try to fulfill this request for future supplies of bandwidth bypassing on the information to the Network Agents.

4.4.4 The Network Agents

The Network Agents provide various tasks related to network management on behalf of theapplication. This includes but is not limited to issues such as congestion control, and mobilitymanagement. It is worth mentioning that many of these tasks can be extremely complex andshould not be taken lightly by designers. However, one of the benefits the framework is thatthey can be inserted into the application in “plug and play” style. For example, if a newcomponent for mobility management is developed that can take advantage of several wirelessbase-stations simultaneously [32] it could be integrated without needing to redesign the othercomponents.

The agents contribute to the marketplace by obtaining the actual supply of bandwidththat will be sold by the BBA. They are also responsible for passing information about thisavailable bandwidth to the BBA so that it can be divided into network contracts to be sold tothe various media. In addition, the agents can obtain information related to current demandlevels from the BBA in order to aid them in making decisions on how best to obtain the futuresupply of bandwidth. For example, if the current network round-trip-time is too high to beuseful for a particular media, it will reject sales offers from the BBA on the grounds that theproduct (bandwidth) is of too low quality. The BBA will then forward this information to theNetwork Agents allowing them to take appropriate action (such as looking for a new networkprovider) if possible.


0

5

10

15

20

25

30

35

100 150 200 250 300 350 400 450 500 550

Virt

ual p

rice

Elapsed time [s]

Experiment 1

Price

(a) Price variation.

0

20

40

60

80

100

120

140

100 150 200 250 300 350 400 450 500 550

Ban

dwid

th [k

B/s

]

Elapsed time [s]

Experiment 1

Video demandAudio demand

(b) Video and audio demand variation.

0

20

40

60

80

100

120

140

100 150 200 250 300 350 400 450 500 550

Ban

dwid

th [k

B/s

]

Elapsed time [s]

Experiment 1

Supply

(c) Supply variation.

0

2

4

6

8

10

12

14

100 150 200 250 300 350 400 450 500 550

Num

ber

of p

acke

ts d

ropp

ed

Elapsed time [s]

Experiment 1

Number of audio packets not served due to over demand

(d) Audio packets not served due to over-demand.

Figure 4.4: Results from experiment one. The figures show the effect of introducing a newmedia into the market. The price is recalculated every 500 ms and the supply every 1200 ms.

4.5 Evaluation

A proof of concept implementation has been built by incorporating the framework withinMarratech Pro [3], a commercially available e-meeting application that provides tools forsynchronous interaction including audio, video, chat and a shared white-board. MarratechPro supports data distribution using IP-multicast or distribution through a media gatewaycalled the Marratech E-Meeting Portal, which can be used when IP-multicast is not available.In the experiments the E-Meeting Portal was used to distribute packets.

Figure 4.5 shows a graphical user interface to the prototype, which can be used toexperiment with different bandwidth and financial settings. The purpose of the prototypewas mainly to demonstrate effective bandwidth sharing between multiple media and also to


Figure 4.5: A screen-shot of Marratech Pro and the graphical user interface to the prototype,which can be used to experiment with different bandwidth and financial settings. For example,using this tool we made an experiment with setting the supply limit based on the maximumburn-rate in $USD specified by the user.

investigate the performance of the spot-market algorithm when changing the price and supplyrecalculation rate.

The prototype was tested by using two Marratech Pro clients. The first client (client A)used the prototype and was responsible for collecting all data during the experiments. Thesecond client (client B) did not adapt bandwidth usage based on the framework, and was onlyused in order to change the level of incoming traffic on the link, as this directly effected theavailable supply as shown in equation 4.7. Both clients sent video traffic at all times duringthe experiments, with audio being used by client A at various intervals in order to investigatethe effects it had on the system. In all experiments the supply was limited to 100 kB/s andclient B sent approximately 25 kB/s video traffic.


Table 4.1: The table shows the effects of varying the price recalculation rate on the efficiencyof the system. The supply recalculation was recalculated every 800 ms. The average demandand the average supply was around 75 kB/s during the experiment.

Recalc. rate Avg. over-demand Avg. under-demand

20 ms 0.25 kB/s 0.25 kB/s50 ms 1.14 kB/s 0.87 kB/s100 ms 2.66 kB/s 2.59 kB/s200 ms 4.09 kB/s 3.98 kB/s400 ms 7.18 kB/s 7.10 kB/s500 ms 7.86 kB/s 7.79 kB/s800 ms 10.63 kB/s 10.53 kB/s1000 ms 11.20 kB/s 11.07 kB/s

Three computers were used during the experiments. The E-Meeting Portal was run aPentium III 1.2 GHz machine running Windows XP. Client A was an Intel P4 2.4 GHzmachine running Windows XP and Client B was an AMD Athlon 1.2 GHz machine runningWindows XP. The computers were connected on a local network using 100Mbit localEthernet.

4.5.1 Implementation

The prototype was implemented in Java JDK 1.4 in order to make it easy to integrate into theMarratech source code. It followed the framework as described in section 4.4 with each ofthe agents contained in figure 4.3 having the following characteristics.

The Bandwidth Broker Agent

The BBA used the tâtonnement process as described in section 4.3.1. In the currentimplementation it provides an API where different BCAs can register and receive call-backswhen the price is updated. The total supply and demand are calculated by using an APIprovided by the Network Agent, which will be discussed later in this subsection.

The Bandwidth Consumer Agent

When the price is recalculated each instance of the BCA receives a price update through acall-back. They then calculate their current demand based on the price set by the BBA andgo forward with trying to sign contracts for bandwidth. The following utility functions wereused for calculating the demand during our experiments.


Table 4.2: The table shows the effects of varying the supply recalculation rate on the efficiencyof the system. The price recalculation was recalculated every 50 ms

Recalc. rate Avg. demand Avg. supply Avg. over-demand Avg. under-demand

200 ms 97.57 kB/s 86.30 kB/s 11.63 kB/s 4.45 kB/s400 ms 88.77 kB/s 80.20 kB/s 7.26 kB/s 3.64 kB/s500 ms 76.51 kB/s 75.20 kB/s 6.87 kB/s 2.10 kB/s600 ms 74.82 kB/s 74.80 kB/s 1.20 kB/s 1.17 kB/s800 ms 74.97 kB/s 74.95 kB/s 1.06 kB/s 1.04 kB/s1000 ms 73.57 kB/s 73.56 kB/s 0.96 kB/s 0.94 kB/s

For audio the utility function was

uaudio � x � ��

0 x � xaudio

∞ x � xaudio

,where xaudio represents the minimum amount of bandwidth needed by the audio codec. Thisutility function was used in order to describe the audio media as something very unadaptive,which is the case with many codecs used today, for example GSM. In the experiment we useda commercial audio codec called EG711 (GIPS) [2], and xaudio was set to 12.2 kB/s.

The utility function for the video was modeled using the logarithmic function

uvideo � x �� ln�1 � x � (4.5)

, which was used in order to create a basic concave function. In reality a more complex andaccurate function will be appropriate, but this was not necessary for running our experiments.

The price function was modeled using the linear function, p�x �� P � x,where P is the price

per kB. Thus, using equation 4.3, the demand for bandwidth by the video media is calculatedas

xvideoCS

� 1P� 1 (4.6)

The Network Agent

During our experimental setup the network agent was responsible for calculating the supplyof available bandwidth and for passing this information on to the BBA. The supply, s,was calculated by using a separate thread and by monitoring the amount of incomingbandwidth obtained from a virtual network driver (NDIS). During each iteration the supplywas calculated as the difference between the supply limit , slimit , and the amount of incomingbandwidth bwreceived , as is shown in equation 4.7.

s � slimit � bwreceived (4.7)

Note that this allowed us to cause large fluctuations in available supply by altering the amountof traffic sent out by the other end-point.


4.5.2 Experiment one: Bandwidth sharing between multiple media

Two experiments using the prototype were conducted. The first experiment was conductedto demonstrate that the prototype could effectively divide the available bandwidth betweenmultiple media. This was done by varying the use of audio at client A in order to show thatvideo would effectively back-off due to price increases in the market.

Figure 4.4 shows results from this experiment. As shown in figure 4.4(a), the price goesup almost immediately when audio is sent. This results in a reduction of the demand forbandwidth by the video media, as shown in figure 4.4(b).

Note that when audio was first sent during the experiment, there was a temporary problemwhere it could not obtain its desired bandwidth from the BBA. This problem is shown infigure 4.4(d) and was most likely the result of a low price re-calculation rate of 500 ms thatforced the audio BCA to wait before it could purchase network contracts. Experiment twowas conducted in order to further investigate this phenomenon.

4.5.3 Experiment two: Investigation into the price and supply recalcu-lation rates

In order to investigate how the price and the supply recalculation rate effected the system wecollected data multiple times while sending video from each client during a period of exactly10 minutes. The price recalculation rate was studied by locking the supply recalculation rateto 500 ms and incrementing the price recalculation rate from a high value of 1000 ms to alow value of 50 ms. The supply recalculation rate was studied in a similar way, but instead oflocking the supply recalculation rate the price recalculation rate was locked to 50 ms.

Table 4.1 shows the benefits of a higher price recalculation rate, in that it leads to a moreefficient allocation of bandwidth, as determined by calculating the average over- and under-demand. A high price calculation rate also eliminated the problem with lost audio packets asthe audio BCA could purchase network contracts almost instantly. An explanation to theseadvantages is that a higher price recalculation rate improved the response time as well asallowed the demand to more closely match variations in supply resulting from the use of avariable bit-rate video codec (H.261) in combination with equation 4.7.

A high supply recalculation rate on the other hand did not improve the performance as itresulted in more fluctuation in terms of over- and under-demand, which can be seen in table4.2. This problem can be explained by the fact that the supply was calculated close to thesupply limit (100 kB/s) most of the time, but during the cycles when bursty data was receivedit was suddenly set to zero1. In the experiments this happened quite often as the supply wasrounded off to zero to avoid a negative supply value if the calculated incoming bandwidthwas more than the supply limit. As a result, the BCAs was in some cases trying to buy morebandwidth than there was available, thus causing over-demand and consequently an instable

1Note that there is a significant difference between under- and over-demand when the supply recalculation rateis incremented. This can be explained by the fact that the price was not recalculated (i.e. decreased) when there wasa zero supply.


frame-rate. However, one positive side effect of using a high supply recalculation rate is thatit resulted in a better bandwidth utilization, i.e. it increased the overall throughput.

4.6 Discussion

This paper proposes a framework based on microeconomics that provides bandwidthmanagement for multimedia applications. As a proof of concept we have built a prototypeusing the framework into the commercial e-meeting application Marratech Pro and haveused it to run several exploratory experiments. These experiments demonstrated that theframework can be used in order to share bandwidth effectively between multiple media usinga single centralized supply point.

The prototype was also used in order to investigate the effects of variations in the price andsupply recalculation rate on the performance of the system. These experiments showed thata high price recalculation rate is effective at minimizing the difference between the supplyand demand, allowing the available bandwidth to be allocated more efficiently. Using a highsupply recalculation rate on the other hand resulted in better throughput, but unfortunatelyalso larger fluctuation in available supply. To be able to support both applications that requirea smooth send rate as well as applications that are less sensitive to variation in bandwidth,some degree of flexibility needs to be integrated into the system.

There are various solutions that could be implemented in order to achieve this desiredflexibility. One possibility is to allow the agents that represent the various media to signcontracts with the bandwidth broker for variable lengths of time. This would allow for adegree of flexibility in that media such as video could sign contracts for longer periods oftime in order to obtain a smoother send rate, while allowing media such as file transfersthat are not as sensitive to changes in the send rate to adapt very quickly by signing shortercontracts. Another approach could be to handle this problem in the media themselves bykeeping a small buffer of available bandwidth when a smoother send rate is desired. Finally,one more potential solution may be to implement a buffering system inside the BBA allowingit to deliver a more smooth supply to the media it serves.

4.6.1 Future work

Future work includes exploration into alternatives to the spot-market algorithm used in ourcurrent implementation. In particular, comparing the performance of an auctioning systemto that of a spot-market seems to be an interesting experiment. Another avenue of futurework includes building some intelligence into the bandwidth broker so that it can predict theavailable supply and demand in an attempt to set the price more closely to the equilibriumduring each iteration.

Finally, in the future we plan to investigate effective utility functions for the various mediacontained in Marratech Pro and integrate some other related prototypes developed by ourresearch division into the system so that we can perform “real-world” experiments with moresophisticated Network Agents and methods for collecting contextual information.


4.7 Acknowledgments

This work was done within the VITAL project, which is supported by the Objective 1 NorraNorrland - EU structural fund programme for Norra Norrland. Support was also provided bythe Centre for Distance-spanning Technology (CDT) and Mäkitalo Research Centre (MRC).

The authors would also like to thank Professor Gerald Q. Maguire at Wireless@KTH atthe Royal Institute of Technology for valuable feedback and comments on the paper as wellas Mikael Börjesson at CDT for useful input.

65

Bibliography

[1] Microsoft IP Helper API, 2003. Homepage: http://msdn.microsoft.com.

[2] Global IP Sound AB, 2004. Homepage: http://www.globalipsound.com/.

[3] Marratech AB, 2004. Homepage: http://www.marratech.com.

[4] A. A. El Al, T. Saadawi, and M. Le. Improving Interactive Video in Wireless NetworksUsing Path Diversity. In LNCS 3271, 7th IFIP/IEEE International Conference onManagement of Multimedia Networks and Services, MMNS, pages 1–12, 2004.

[5] T. Alpcan and T. Basar. A Utility-Based Congestion Control Scheme for Internet-StyleNetworks with Delay. In INFOCOM, pages 2039–2048, 2003.

[6] E. Amir, S. McCanne, and R.H Katz. Receiver-driven Bandwidth Adaptation for Light-weight Sessions. In ACM Multimedia, pages 415–426, 1997.

[7] S. Aust, D. Proetel, N. A. Fikouras, and C. Görg. Policy based Mobile IPHandoff Decision (POLIMAND) using Generic link Layer Information. In IEEE5th International Conference on Mobile and Wireless Commonication Networks(MWCN’02), 2003.

[8] J. Byers, M. Frumin, G. Horn, M. Luby, M. Mitzenmacher, and A. Roetter. FLID-DL:Congestion Control for Layered Multicast. In International Workshop on NetworkedGroup Communication NGC, pages 71–82, 2000.

[9] R. Chandra, Paramvir Bahl, and Pradeep Bahl. MultiNet: Connecting to Multiple IEEE802.11 Networks Using a Single Wireless Card. In INFOCOM, 2004.

[10] A. Chavez, A. Moukas, and P. Maes. Challenger: A Multi-agent System forDistributed Resource Allocation. In Proceedings of the First International Conferenceon Autonomous agent, 1997.

[11] R. Chellappa, A. Jennings, and N. Shenoy. A Comparative Study of Mobility Predictionin Fixed Wireless and Mobile Ad Hoc Networks. IEEE International Conference onCommunications (ICC 2003), 26(1):891–895, 2003.

[12] D.D. Clark, J. Wroclawski, K.R. Sollins, and R. Braden. Tussel in Cyberspace: DefiningTomorrow’s Internet. In ACM SIGCOMM, 2002.

[13] C. Courcoubetis and R. Weber. Pricing Communication Networks;Economics,Technology and Modelling. Wiley, 2003.

[14] S. E. Deering. Multicast Routing in a Datagram Internetwork. PhD thesis, StanfordUniversity, USA, 1991.

[15] S. Dhananjay and P.T. Goff. Multiple IP Links for Improving Throughput andReliability in Mobile Environments. In INFOCOM, 2002.

http://msdn.microsoft.com

http://www.globalipsound.com

http://www.marratech.com

66 Bibliography

[16] R. C. Doss, A. Jennings, and N. Shenoy. A Review of Current work on MobilityPrediction in Wireless Networks. In ACM SIGMOBILE 3rd Asian International MobileComputing Conference, Asian International Mobile Computing Conference (AMOC),2004.

[17] F. Erbas, J. Steuer, K. Kyamakya, D. Eggesieker, and K. Jobmann. A Regular PathRecognition Method and Prediction of User Movements in Wireless Networks. In VTCFall 2001, Mobile Technology for Third Milenium, 2001.

[18] A. Bria et al. 4th-Generation Wireless Infrastructures: Scenarios and ResearchChallenges. IEEE Personal Communications, 8(6):25–31, 2001.

[19] M. O’Droma et al. Always Best Connected Enabled 4G Wireless World. In IST Mobileand Wireless Communications Summit, pages 710–716, 2003.

[20] R. Steward et al. Stream Control Transmission Protocol (SCTP) Dynamic AddressReconfiguration, 2003. Internet Draft, IETF. Work in progress.

[21] R. Stewart et al. Stream Control Transport Protocol, 2001. IETF RFC2960.

[22] F. Feng and D.S. Reeves. Explicit Proactive Handoff with Motion Predicition for MobileIP. In IEEE Wireless Communications and Networking Conference (WCNCt’04), 2004.

[23] S. Floyd, M. Handley, J. Padhye, and J. Widmer. Equation-Based Congestion Controlfor Unicast Applications. In ACM SIGCOMM, pages 43–56, 2000.

[24] E.W Fulp. Resource Allocation and Pricing for QoS Management in ComputerNetworks. PhD thesis, Noth Carolina State University, USA, 1999.

[25] R. A. Gagliano, M. D. Fraser, and M. E. Schaefer. Auction allocation of computingresources. Communications of the ACM, 38(6):88–102, 1995.

[26] V. Gazis, N. Houssos, A. Alonistioti, and L. Merakos. Evolving Perspectives of4th Generation Mobile Communication Systems. In The 13th IEEE InternationalSymposium on Personal, Indoor, and Mobile Radio Communications (PIMRC), 2002.

[27] R. Hsieh, Z.G. Zhou, and A. Seneviratne. S-MIP: A Seamless Handoff Architecture forMobile IP. In INFOCOM, 2003.

[28] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M.Handley, and E. Schooler. SIP: Session Initiation Protocol, June 2002. IETF RFC3261.

[29] S. Kashihara, K. Iida, H. Koga, Y. Kadobayashi, and S. Yamaguchi. End-to-EndSeamless Handover using Multi-path Transmission Algorithm. In Internet Conference2002 (IC’02), 2002.

[30] C. Komar and Ersoy C. Location Tracking and Location Based Service Using IEEE802.11 WLAN Infrastructure. In European Wireless, 2004.

Bibliography 67

[31] J. Kristiansson and P. Parnes. Application-layer Mobility support for StreamingReal-time Media. In IEEE Wireless Communications and Networking Conference(WCNCt’04), 2004 (this is also Paper 1 in the thesis).

[32] J. Kristiansson and P. Parnes. Providing Seamless Mobility with Competition basedSoft Handover Management. In LNCS 3271, 7th IFIP/IEEE International Conferenceon Management of Multimedia Networks and Services, MMNS, pages 295–307, 2004(this is also Paper 2 in the thesis).

[33] W. Lee and J. Srivastava. A Market-based Resource Management and QoS SupportFramework for Distributed Multimedia Systems. In Ninth International Conference onInformation and Knowledge Management (CIKM), 2000.

[34] Raymond R.F. Liao and A. T. Campbell. A Utility-Based Approach for QuantitativeAdaptation in Wireless Packet Networks. Wireless Networks, 7(5):541–557, 2001.

[35] G. Liu and G. Maguire Jr. A class of mobile motion prediction algorithms for wirelessmobile computing and communication. Mobile Networks and Applications, 1(2):113–121, 1995.

[36] J.K. MacKie-Mason and H.R. Varian. Pricing the Internet. In The second InternationalConference on Telecommunication Systems Modelling and Analysis, pages 378–393,1994.

[37] J.K. MacKie-Mason and H.R. Varian. Pricing Congestable Network Resources. IEEEJournal on Selected Area in Communication, 13(7):1141–1149, 1995.

[38] L. Magalhaes and R. Kravets. MMTP: Multimedia Multiplexing Transport Protocol.ACM SIGCOMM Computer Communication Review, 31(2):220–243, 2001.

[39] Tadashi Okoshi Masahiro. MobileSocket: Toward Continuous Operation for JavaApplications. In IEEE 8th International Conference on Computer Communicationsand Networks 1999 (IC3N’99), pages 50–57, 1999.

[40] S. McCanne, V. Jacobson, and M. Vetterli. Receiver-driven Layered Multicast. InSIGCOMM, pages 117–130, 1996.

[41] G. A. Mills-Tettey and David Kotz. Mobile Voice over IP (MVOIP): An Application-level Protocol for Call Hand-off in Real Time Applications. In IEEE 21th InternationalPerformance, Computing and Communication Conference (IPCCC’02), pages 271–279, 2002.

[42] Y. Min-hua, L. Yu, and Z. Hui-min. The Mobile IP Handoff Between HybridNetworks. In IEEE 13th International Symposium on Personal, Indoor and MobileRadio Commonication (PIMRC’02), 2002.

[43] R. Neugebauer and D. McAuley. Congestion Prices as Feedback Signals: An Approachto QoS Management. In ACM SIGOPS European Workshop: Beyond the PC: Newchallenges for the Operating system, 2000.

68 Bibliography

[44] C. Perkins. IP Mobility Support, 1996. IETF RFC2002.

[45] Luigi Rizzo. pgmcc: a TCP-friendly single-rate multicast. In SIGCOMM, pages 17–28,2000.

[46] J. Scholl, S. Elf, and P. Parnes. User-interest Driven Video Adaptation forCollaborative Workspace Applications. In International Workshop on Networked GroupCommunication NGC, pages 3–12, 2003.

[47] J. Scholl and P. Parnes. Low-Weight Congestion Control for Multi-sender Applications.In LNCS 2496, 5th IFIP/IEEE International Conference on Management of MultimediaNetworks and Services, MMNS, pages 315–327, 2002.

[48] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson. RTP: A Transport Protocolfor Real-Time Applications, 1996. IETF RFC1889.

[49] A. Smith. An Inquiry into the Nature and Causes of the Wealth of Nations. Onlineversion: http://www.ebbemunk.dk/misc/smith.pdf, first published 1776.

[50] Alex C. Snoeren and Hari Balakrishnan. An End-to-End Approach to Host Mobility. InProc. 6th International Conference on Mobile Computing and Networking (MobiCom),pages 155–164, 2000.

[51] Alex C. Snoeren, Hari Balakrishnan, and M. Frans Kaashoek. Reconsidering InternetMobility. In Proc. 8th Workshop on Hot Topics in Operating Systems (HotOS-VIII),pages 41–46, 2001.

[52] H. Soliman, C. Castelluccia, K. Malki, and L. Bellier. Hierarchical MIPv6 MobilityManagement, 2002. Internet Draft, IETF. Work in progress.

[53] Kåre Synnes, Peter Parnes, and Dick Schefström. Robust Audio Transport usingmAudio. Research Report, ISSN 1402-1528, ISRN LTU-FR–99/04–SE, LuleåUniversity of Technology, 1999.

[54] A. Valkó. Cellular IP: A New Approach to Internet Host Mobility. ACM SIGCOMMComp. Commun. Rev., 29(1):50–65, 1999.

[55] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates in the Domain NameSystem, 1997. IETF RFC2136.

[56] Ryuji Wakikawaa, Susumu Koshiba, Keisuke Uehara, and Jun Murai. Multiple NetworkInterfaces Support by Policy-Based Routing on Mobile IPv6. In Proc. of the 2002International Conference on Wireless Networks (ICWN), 2002.

[57] H.J. Wang. Policy-Enabled Handoffs Across Heterogeneous Wireless Networks.Technical Report CSD-98-1027, 1998.

[58] E. Wedlund and H. Schulzrinne. Mobility Support Using SIP. In WOWMOM, pages76–82, 1999.

http://www.ebbemunk.dk/misc/smith.pdf

Bibliography 69

[59] Jörg Widmer and Mark Handley. Extending Equation-Based Congestion Control toMulticast Applications. In SIGCOMM, pages 275–286, 2000.

[60] David K. Y. Yau and Simon S. Lam. Migrating sockets - End System Supportfor Networking with Quality of Service Guarantees. IEEE/ACM Transactions onNetworking, 6(6):700–716, 1998.

[61] Victor C. Zandy and Barton P. Miller. Reliable Network Connections. In Proc.8th International Conference on Mobile Computing and Networking (MobiCom) ACMMobiCom, pages 95–106, 2002.

Creating Always-Best-Connected Multimedia Applications for ...

Documents

Transcript of Creating Always-Best-Connected Multimedia Applications for ...