Quality of Service Manet-Thesis

Quality of Service for Mobile Ad Hoc Networks

Diploma Thesis of Patrick Stüdi

Assistant: Jianbo XueSupervisor: Prof. Dr. Gustavo Alonso

March 2003

ii

Abstract

The fast adaptation of IP-based communications for mobile and hand-held devicesequipped with wireless interfaces is creating a new challenge for Quality of Service (QoS)provision. Due the error-prone nature of wireless links and the high mobility of mobile de-vices, traditional Internet QoS protocols like RSVP cannot be easily migrated to the wire-less environment. This is specially true for Mobile Ad Hoc Networks (MANETs) whereevery node moves arbitrarily causing the multi-hop network topology to change randomlyand at unpredictable times.

In this thesis a new framework coping with the specific issues of MANETs is proposed. Theframework includes a QoS signaling protocol and flexible resource allocation and adapta-tion mechanisms. In order to prove its efficiency the system is implemented and simulatedusing the ns-2 network simulator.

Keywords:MANET, QoS, In-band Signaling, Adaptation, Resource Reservation, ASAP

iv

Contents

1 Introduction 1

1.1 Problem Statement . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Mobile Ad Hoc Networks . . .. . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 Quality of Service . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 QoS Models for MANETs 3

2.1 QoS Models . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 IntServ . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.2 DiffServ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.3 IntServ over DiffServ .. . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Quality of Service in Ac Hoc Networks . . . . . .. . . . . . . . . . . . . 4

2.2.1 Special Issues and Difficulties in MANETS. . . . . . . . . . . . . 4

2.2.2 Drawbacks of the different QoS Models . .. . . . . . . . . . . . . 4

2.3 Conclusion . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Protocol Design Issues 7

3.1 Towards developing a QoS Framework for MANETs . . .. . . . . . . . . 7

3.2 QoS from a Layered Perspective . . .. . . . . . . . . . . . . . . . . . . . 7

3.3 QoS-Signaling and Routing Interaction. . . . . . . . . . . . . . . . . . . . 7

3.4 QoS-Signaling: Design Issues. . . . . . . . . . . . . . . . . . . . . . . . 8

3.4.1 In-band versus Out-of-band Signaling . . .. . . . . . . . . . . . . 8

3.4.2 Reservation Mechanism: One-pass versus Two-pass . . .. . . . . 9

3.4.3 Soft-state versus Hard-state .. . . . . . . . . . . . . . . . . . . . 9

3.4.4 Local Repair .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.5 QoS Adaptation . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.5.1 Application Requirements . .. . . . . . . . . . . . . . . . . . . . 10

3.5.2 Adaptation Strategies .. . . . . . . . . . . . . . . . . . . . . . . . 11

3.5.3 Monitoring Interval and Soft-state Timer .. . . . . . . . . . . . . 12

vi CONTENTS

3.6 Conclusion . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4 Existing Technologies 13

4.1 RSVP . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.1.1 RSVP Extensions . . .. . . . . . . . . . . . . . . . . . . . . . . . 14

4.2 FQMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.3 INSIGNIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.4 Some further Approaches . . .. . . . . . . . . . . . . . . . . . . . . . . . 17

4.4.1 iMAQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.4.2 INORA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5 ASAP Framework 19

5.1 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.1.1 Soft/Hard Reservation. . . . . . . . . . . . . . . . . . . . . . . . 19

5.1.2 Soft-State Management. . . . . . . . . . . . . . . . . . . . . . . . 19

5.1.3 Adaptive QoS Monitoring . .. . . . . . . . . . . . . . . . . . . . 20

5.2 Signaling System . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.2.1 QoS Table . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.2.2 Message Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.2.3 Setup Procedure . . .. . . . . . . . . . . . . . . . . . . . . . . . 21

5.2.4 QoS Monitoring . . .. . . . . . . . . . . . . . . . . . . . . . . . 22

5.3 Implementing ASAP using IPv6 . . .. . . . . . . . . . . . . . . . . . . . 23

5.3.1 IPv6 in a Nutshell . .. . . . . . . . . . . . . . . . . . . . . . . . 23

5.3.2 IPv6 Header Format .. . . . . . . . . . . . . . . . . . . . . . . . 23

5.3.3 Using IPv6 for ASAP Signaling . . . . . .. . . . . . . . . . . . . 24

6 Ad Hoc Extensions for ASAP 27

6.1 Problems of ASAP in MANETs . . .. . . . . . . . . . . . . . . . . . . . 27

6.1.1 Flow Restoration . . .. . . . . . . . . . . . . . . . . . . . . . . . 27

6.1.2 Reverse Path Problem. . . . . . . . . . . . . . . . . . . . . . . . 28

6.1.3 Lost Hard-Reservation Messages . . . . .. . . . . . . . . . . . . 28

6.2 Extensions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6.2.1 QoS Option Field for Soft-Reservation Message .. . . . . . . . . 29

6.2.2 Local Repair .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6.2.3 Dynamic Virtual Path .. . . . . . . . . . . . . . . . . . . . . . . . 30

6.2.4 Adaptation . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.3 Conclusion . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

CONTENTS vii

7 Implementation 33

7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

7.2 NS-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

7.2.1 Nodes . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

7.2.2 Packets . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

7.2.3 Agents . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

7.3 Implementation Requirements. . . . . . . . . . . . . . . . . . . . . . . . 36

7.4 Main Building Blocks .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

7.5 QoS Management Unit. . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

7.5.1 Overview . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

7.5.2 Internal Structure . . .. . . . . . . . . . . . . . . . . . . . . . . . 37

7.5.3 Message Serialization/Deserialization . . .. . . . . . . . . . . . . 38

7.5.4 Reservation Processing. . . . . . . . . . . . . . . . . . . . . . . . 39

7.6 Adaptation Control Unit . . .. . . . . . . . . . . . . . . . . . . . . . . . 42

7.7 Application QoS Request Unit. . . . . . . . . . . . . . . . . . . . . . . . 42

7.8 Some further Components . .. . . . . . . . . . . . . . . . . . . . . . . . 42

7.8.1 Queuing . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

7.8.2 Measurements. . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

7.8.3 Logging . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

7.8.4 Node Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

7.9 Conclusion . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

8 Simulation and Analysis 45

8.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

8.2 Simulation Framework. . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

8.2.1 Flow Objects .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

8.2.2 Measurements. . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

8.2.3 A Remark in Advance. . . . . . . . . . . . . . . . . . . . . . . . 47

8.3 Evaluation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

8.3.1 Local Repair .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

8.3.2 Adaptation . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

8.3.3 QoS Performance . . .. . . . . . . . . . . . . . . . . . . . . . . . 49

8.3.4 Reservation Efficiency. . . . . . . . . . . . . . . . . . . . . . . . 50

8.3.5 Signaling Overhead . .. . . . . . . . . . . . . . . . . . . . . . . . 51

8.4 Conclusion . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

9 Summary and Outlook 53

viii CONTENTS

9.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

9.2 Future Work . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Bibliography 56

Chapter 1

Introduction

1.1 Problem Statement

The introduction of real-time audio, video and data services into wireless networks presentsa number of technical obstacles to overcome. Traditional internet QoS protocols like RSVPcannot be easily migrated to the wireless environment due to the error-prone nature ofwireless links and the high mobility of mobile devices. This is specially true for MobileAd Hoc Networks (MANETs) where every node moves arbitrarily causing the multi-hopnetwork topology to change randomly and at unpredictable times.

In this thesis an existing QoS framework is extended to be suitable for MANETs. In orderto prove its correctness and efficiency the system is implemented and simulated using thens-2 network simulator.

1.2 Mobile Ad Hoc Networks

A mobile ad hoc network is a concept that has received attention in scientific research sincethe 1970s. A clear picture of what exactly is meant by an ad hoc network is difficult topinpoint. In today’s literature the term is used in many different ways. The Internet Engi-neering Task Force (IETF), the body responsible for guiding the evolution of the Internet,provides the definition as given below [23]:

A mobile ad hoc network (MANET) is an autonomous system of mobile routers (and as-sociated hosts) connected by wireless links. The routers are free to move randomly andorganize themselves arbitrarily; thus, the network’s wireless topology may change rapidlyand unpredictably. Such a network may operate in a stand-alone fashion, or may be con-nected to the larger Internet

MANETs are useful in many applications because they do not need any infrastructure sup-port. Collaborative computing and communications in smaller areas (building organiza-tions, conferences, etc.) can be set up using MANETS. Communications in battlefields anddisaster recovery areas are further examples of application environments.

With the evolution of Multimedia Technology, Quality of Service in MANETs became anarea of great interest. Besides the problems that exist for QoS in wire-based networks,MANETS impose new constraints. This is due the dynamic behaviour and the limitedresources of such networks.

2 Chapter 1. Introduction

1.3 Quality of Service

QoS is usually defined as a set of service requirements that needs to be met by the networkwhile transporting a packet stream from a source to its destination. The network needs aregoverned by the service requirements of end user applications. The network is expectedto guarantee a set of measurable prespecified service attributes to the users in terms ofend-to-end performance, such as delay, bandwidth, probability of packet loss, delay vari-ance (jitter), etc. Power consumption is another QoS attribute which is more specific toMANETs.

In the literature, the research on QoS support in MANETs spans over all the layers in thenetwork:

� QoS modelsspecify an architecture in which some kinds of services could be pro-vided. It is the system goal that has to be implemented.

� QoS Adaptationhides all environment-related features from awareness of themultimedia-application above and provides an interface for applications to interactwith QoS control.

� Above the network layerQoS signalingacts as a control center in QoS support. Thefunctionality of QoS signaling is determined by the QoS model.

� QoS routingis part of the network layer and searches for a path with enough re-sources but does not reserve resources.

� QoS MACprotocols are essential components in QoS for MANETs. QoS supportingcomponents at upper layers, such as QoS signaling or QoS routing assume the exis-tence of a MAC protocol, which solves the problems of medium contention, supportsreliable communication, and provides resource reservation.

This document does not treatQoS MACandQoS routingany further and instead focuseson upper layers like QoS models and signaling.

1.4 Outline

After analysing existing QoS models with respect to the dynamic behaviour of ad hoc net-works in chapter 2 this document proceeds presenting some of the fundamental design is-sues to be considered when developing a QoS framework for MANETs. Chapter 4 focuseson some existing approaches classifying each one according to the design issues identifiedin chapter 3. ASAP is a QoS framework developed at the University of Stuttgart and wasoriginally designed to support QoS in last-hop-wireless networks and is proposed in chap-ter 5. The ad hoc extensions to ASAP, the implementation for ns-2 and its simulation arediscussed in chapter 6, 7 and 8. Finally this document concludes with a summary and givesan outlook on potential further work.

Chapter 2

QoS Models for MANETs

2.1 QoS Models

Today’s Internet applies best effort (BE) IP forwarding. The network attempts to deliver alltraffic as soon as possible within the limits of its abilities, but without guarantees relatedto throughput, delay or packet loss. It is left up to the end systems to cope with networktransport impairments.

Although best effort will remain adequate for most applications, QoS support is requiredto satisfy the growing need for multimedia over IP, like video streaming or IP telephony.

The existing QoS models can be classified into two types according to their fundamen-tal operation; the Integrated Services (IntServ) framework provides explicit reservationsend-to-end and the Differentiated Services (DiffServ) architecture offers hop-by-hop dif-ferentiated treatment of packets.

2.1.1 IntServ

The IntServ[7][15] model merges the advantages of two different paradigms: datagram net-works and circuit switched networks. It can provide a circuit-switched service in packet-switched networks. The Resource Reservation Protocol (RSVP) was designed as the pri-mary signaling protocol to setup and maintain the virtual connection. RSVP is also used topropagate the attributes of the data flow and to request resources along the path. Routersfinally apply corresponding resource management schemes to support QoS specificationsof the connection. Based on these mechanisms, IntServ provides quantitative QoS for everyflow.

2.1.2 DiffServ

DiffServ[5][26][10] was designed to overcome the difficulty of implementing and deploy-ing IntServ and RSVP in the Internet backbone and differs in the kind of service it provides.While IntServ provides per-flow guarantees, Differentiated Services (DiffServ) follows thephilosophy of mapping multiple flows into a few service levels. At the boundary of thenetwork, traffic entering a network is classified, conditioned and assigned to different be-haviour aggregates by marking a special DS (Differentiated Services) field in the IP packetheader (TOS field in IPv4 or CLASS field in IPv6). Within the core of the network, packetsare forwarded according to the per-hop behaviour (PHB) associated with the DSCP (Differ-entiated Service Code Point). This eliminates the need to keep any flow state informationelsewhere in the network.

4 Chapter 2. QoS Models for MANETs

2.1.3 IntServ over DiffServ

This model provides a reservation-based QoS architecture with feedback signaling. It usesRSVP to signal resource needs but uses DiffServ as the technology to do the actual resourcesharing among flows.

2.2 Quality of Service in Ac Hoc Networks

This section discusses unique issues and difficulties for supporting QoS in a MANET en-vironment and ends up showing the major drawbacks of each of the two QoS architecturesdescribed above with respect to these characteristics.

2.2.1 Special Issues and Difficulties in MANETS

MANETs differ from the traditional wired Internet infrastructures. The differences intro-duce difficulties for achieving Quality of Service in such networks. The following listitemizes some of the problems:

� Dynamic topologies: Nodes are free to move arbitrarily; thus, the network topology- which is typically multihop - may change randomly and rapidly at unpredictabletimes, and may consist of both bidirectional and unidirectional links.

� Bandwidth-constrained, variable capacity links: Wireless links will continue to havesignificantly lower capacity than their hardwired counterparts. In addition, the re-alized throughput of wireless communications - after accounting for the effects ofmultiple access, fading, noise, and interference conditions, etc.- is often much lessthan a radio’s maximum transmission rate.

One effect of the relatively low to moderate link capacities is that congestion is typ-ically the norm rather than the exception, i.e. aggregate application demand willlikely approach or exceed network capacity frequently. As the mobile network is of-ten simply an extension of the fixed network infrastructure, mobile ad hoc users willdemand similar services. These demands will continue to increase as multimediacomputing and collaborative networking applications rise.

� Energy-constrained operation: Some or all of the nodes in a MANET may rely onbatteries or other exhaustible means for their energy. For these nodes, the mostimportant system design criteria for optimization may be energy conservation.

2.2.2 Drawbacks of the different QoS Models

IntServ in MANETS

IntServ has the following salient shortcomings in MANET environments:

� Scalability: IntServ provides per-flow granularity, so the amount of state informationincreases proportionally with the number of flows. This results in a storage and pro-cessing overhead on routers, which is the well-known scalability problem of IntServ.The scalability problem is less likely to occur in current MANETs considering thesmall number of flows, the limited size of the network and the bandwidth of the wire-less links. On the other hand, as the quality of wireless technology increases rapidly,high speed and large size MANETs may be a matter of fact some day. Though onecould argue that whenever large high-performance MANETs will be developed infuture, processing and storing capabilities will increase as well.

2.3 Conclusion 5

� Signaling:Signaling protocols generally contain three phases: connection establish-ment, connection maintenance and connection teardown. In highly dynamic net-works such as MANETs this is no promising approach since routes may change veryfast and the adaptation process of protocols using a complex handshaking mecha-nism would just be too slow. Furthermore the signaling overhead while maintainingthe connection is a potential problem as well.

DiffServ in MANETS

The main drawbacks of a DiffServ approach in MANETs are listed below:

� Soft QoS guarantees:DiffServ uses a relative-priority scheme to map the quality ofservice requirements to a service level. This aggregation results in a more scalablebut also in more approximate service to user flow.

� SLA (Service Level Agreement):DiffServ is based on the concept of SLA’s. In theInternet an SLA is a kind of contract between a customer and its Internet ServiceProvider (ISP) that specifies the forwarding service the customer should receive. TheAdministration of a DiffServ domain must assure that sufficient resources are provi-sioned to support the SLA’s committed by the domain [2]. Moreover, the DiffServboundary nodes are required to monitor the arriving traffic for each service class andto perform traffic classification and conditioning to enforce the negotiated SLA’s.Generally speaking if someone acquires QoS parameters and he pays for such pa-rameters then of course there must be some entity which will assures them. In acompletely ad hoc topology where there is no concept of service provider and clientand where there are only clients it would be quite difficult to innovate QoS, sincethere is no obligation from somebody to somebody else what makes QoS almostinfeasible.

� Ambiguous core network:The benefit of DiffServ is that traffic classification andconditioning only has to be done at the boundary nodes[26]. This makes quality ofservice provisioning much easier in the core of the network. In MANETs thoughthere is no clear definition of what is the core network because every node is a po-tential sender, receiver and router. This drawback would again take us back to theIntServ model where several separate flow states are maintained.

2.3 Conclusion

The merit and limits of both IntServ and DiffServ are reflected in the trade-off betweenscalability and level of QoS performance assurance. Neither a pure IntServ nor a pureDiffServ model is suitable for Ad Hoc Networks. In order to make use of advantagesof both models and avoid the disadvantages, a combination of DiffServ and IntServ asdescribed in section 2.1.3 could be an interesting approach.

6 Chapter 2. QoS Models for MANETs

Chapter 3

Protocol Design Issues

3.1 Towards developing a QoS Framework for MANETs

In the last chapter it was shown that MANETs propose different requirements to qualityof service infrastructures than wired networks do. Neither a pure IntServ nor a DiffServapproach is satisfying. The following sections identify some of the fundamental issues tobe considered when designing a quality of service infrastructure for MANETs and helpsclassifying existing protocols later on.

3.2 QoS from a Layered Perspective

A network’s ability to provide a specific QoS de-

QoSSignaling

QoS Routing

QoS MAC

QoSAdaptation

NetworkLayer

LinkLayer

pends upon the inherent properties of the networkitself which span over all the layers in the network.The physical layer should take care of changes intransmission quality, for example by adaptively in-creasing or decreasing the transmission power. Sim-ilarly, the link layer should react to the changes inlink error rate, let’s say by including the use of au-tomatic repeat-request technique. QoS-Routing andQoS-Signaling operate at the network layer in or-der to search for routes with sufficient resourcesor to allocate and release bandwidth respectively.Finally, QoS-adaptation hides all the environment-related features from the awareness of multimediaapplications. Moreover it provides an interface for applications to submit their require-ments and is responsible to dynamically react to QoS changes for a certain flow, accordingto these requirements. This document does not treat MAC layer or physical layer issues anyfurther, but instead concentrates on the issue of end-to-end QoS control over IP, meaningQoS-Signaling in particular.

3.3 QoS-Signaling and Routing Interaction

In order to improve the performance of the QoS framework in a dynamic environment,QoS-signaling and routing can be coupled. There are three scales of coupling [15][17]which are described as follows:

8 Chapter 3. Protocol Design Issues

Thede-coupledoption refers to the fact that QoS and routing mechanisms operate indepen-dently of each other and the QoS implementation is not dependent on a particular routingprotocol. Changes in the network topology have to be handled by actively monitoring thenetwork (for example by sending periodic monitoring messages).

In a loosely coupledapproach QoS-Signaling and routing interact with each other. Inter-action can be understood as bi-directional. Some routing protocols allow upper layers forinstallation of upcall procedures to be called whenever a route changes. This might sig-nificantly decrease the reaction time of the QoS-Signaling to restore a certain reservationfor a flow rerouted. On the other hand QoS-Signaling could provide feedback informationto the routing layer regarding the route chosen and ask the routing protocol for alternateroutes if the route provided doesn’t satisfy the QoS requirements. Another example is tolet signaling query the forwarding table directly. Pre-allocation would be an appliance forsuch an approach. Despite of these benefits any kind of interaction between QoS-signalingand routing may lead to a solution which is dependant on the specific routing protocol. Thisshortcoming can be minimized by designing a generic interface to access the routing layerand to develop adapters for a concrete routing protocol implementing this interface.

In aclosely coupledapproach, the same signaling mechanism is used to propagate the rout-ing and QoS information, what mostly refers a unique QoS-routing protocol. QoS-routingtries to search for routes to a given destination with respect to the QoS requirements. Hav-ing a such strong coupling between QoS control and Routing does of course lead to veryfast flow restoration but also has some major drawbacks. First the solution is dependent onthe routing protocol used. This is currently not suitable because routing in MANETs stillunderlies heavy research and there is no ’one’ routing protocol to be used in future. Secondthe route computation with this strategy may take too long[4] or be too complex. The nextfew sections discuss QoS-Signaling as well as different strategies for bandwidth allocationand adaptation.

3.4 QoS-Signaling: Design Issues

QoS-Signaling is used to reserve and release resources, set up, tear down, and renegotiateflows in the networks. There are a few issues to be considered when designing a QoS-signaling protocol (especially in MANETs) as to how the control information is carriedalong with data and how the flow path is established.

3.4.1 In-band versus Out-of-band Signaling

The term ’in-band signaling’ refers to the fact that any control information is piggybackedinto the packet header. Hence in-band signaling systems could be more efficient for wire-less networks in case of route adaptation. The signaling path will always follow the datapath, even in cases when the route has changed because of a failure of an intermediate node.This leads to very fast flow state restoration times.

’Out-of-band signaling’ on the other hand uses explicit control packets. This approach canbe characterized as ’heavyweight’ because extra information is carried in the network andconsumes more network bandwidth. Moreover in out-of-band signaling systems, signalingpackets must have higher priority than data packets in order to achieve on-time notification.This can lead to a complex system where performance will degrade substantially. Thebenefit of this approach is that it is more scalable since the control messages don’t relyon the transmission of data packets. Furthermore the supported services can be rich andpowerful.

3.4 QoS-Signaling: Design Issues 9

3.4.2 Reservation Mechanism: One-pass versus Two-pass

If the resource reservation is done by a two-pass mechanism, then in the first pass (senderinitiated) end-to-end information (like bandwidth availability) of the specific connection isgathered. This allows for detection of any bottleneck nodes within the path. The actualreservation is made in a second pass (receiver initiated) considering the available QoS ofthe connection. Suppose a path comprises three nodes A, B and C with correspondingbandwidth 300K, 200K and 300K. In a first pass node B would be detected as a bottleneckdue to its available bandwidth of 200K, which is the minimum on this path. An actualresource reservation in a second pass right after will not try to request more than this 200Kbecause it cannot be provided anyway. Two-pass based reservations avoid wasting of re-sources but their drawback is their latency. The need for two control messages to be sentslows down the reservation process. This could be critical in a highly dynamic environmentwhere paths have to be re-established frequently. In addition two-pass mechanisms assumebi-directional routes between the nodes. That means if A can reach B, it must be giventhat B can reach A as well. This assumption is not automatically true in ad hoc networksfor several reasons. First routing is not guaranteed to by symmetric, second a route maychange between the first and the second pass and last, wireless links often do not showsymmetric behaviour at all.

Reservation schemes based on a one-pass mechanism fix these shortcomings of the two-pass approach using only one control message to do the actual reservation, regardless ofany end-to-end information. This makes the mechanism very stable and flexible in reactiontime but results in a potential bandwidth waste. Given the scenario above and assumingthat there a is a bandwidth request of 300K, nodes A and C would be able to satisfy therequest but node B would not. As a consequence it may happen that for a short period oftime 300K of bandwidth are allocated on these two nodes but never used.

3.4.3 Soft-state versus Hard-state

As to the method of keeping resource reservation, two states can be defined: Soft andHard state. For hard state, once the reservation is established, the reserved resource andthe reservation record is always kept. This happens until an explicit release message issent. Soft state reservation has a lifetime. When a reservation is established, a timer istriggered. Within a certain time period, specific signaling or traffic will update the softstate reservation and reset the timer. Otherwise, when the timer times out without receivingany refreshing messages, the soft state reservation will be released.

Hard state based reservation is simple and efficient. It needs no signaling to keep thereservation alive, and no timing processing has to be done either. Only the release messageis mandatory.

In a mobile ad hoc network, soft state reservation is the more suitable approach. Thewireless connection is unstable, and apt to be broken. Once a mobile node has lost itsconnection with the network, it might not have a chance to send any signaling for hardstate release. So the reserved resource would permanently be kept unused. Soft statemanagement may easily solve this problem because the reservation state just times out.

3.4.4 Local Repair

Local Repair is a mechanism which a signaling protocol should employ in order to achievefast and efficient flow restoration in case of route changes. ’Local’ means that signalingis kept within a very small area, end-nodes must not be involved. Consider the followingscenario: In a network with four nodes A, B, C and D node A sends stream data to node D


using a route over node C. It is assumed that accurate quality of service is already providedalong this path. Now at a certain time node C starts moving and finally gets out of nodeA’s transmission range, routing then finds a new path from A to D over node B. LocalRepair is now in charge to detect the route change and to restore the best possible quality ofservice on the new path as well as to delete the old reservation. The goal is to re-establishreservation as quickly as possible and at the same time keep the signaling overhead low.There are several approaches to do this, which can roughly be classified into ’Pro-Active’and ’Re-Active’.

Pro-Active

Pre-Active local repair mechanisms try to reserve the required quality of service for a givenflow in advance, that means before the old path is broken and a new one is established.This can be done by either trying to guess route changes in advance, using node movementtracking or transmission quality measurements, or by excessive resource allocation. Inthe latter case signaling just reserves resources on every possible path, eventually throughinspecting the routing forwarding table. Both strategies do have the shortcoming that theypotentially waste bandwidth due to their over-reservation, excessive allocation in particular.

Re-Active

Re-active signaling protocols do not reserve any resources in advance, instead they try toreact to route changes as fast as possible. The easiest way to achieve this goal is to betriggered by the routing layer whenever a route changes. Another possible solution is todetect route changes for a certain flow by periodically sending monitoring messages. It isassumed that the performance of such an approach hardly depends on the interval by whichmonitoring messages are sent.

3.5 QoS Adaptation

In contrast to a wired network, the QoS situation in a MANET may change rapidly anddramatically all the time due to wireless link characteristics or mobility. For example evenif the signaling provides a very fast local repair mechanisms it is not guaranteed that aftera path breaks, the same quality of service can be granted on the new path. Under certaincircumstances it may happen that an active flow is rerouted to a bottleneck node whichcauses the end-to-end bandwidth of the flow to decrease. On the other hand, the availablebandwidth will increase if less traffic is in the network or if any application releases its re-served bandwidth. So applications can’t rely on the QoS investigation done during sessionestablishment. To solve the problem the QoS framework has to actively monitor the net-work dynamics and adapt flows in response to observed changes based on some adaptationstrategy. In the following sections a few concepts are discussed which might be helpfuldesigning the adaptation part of a QoS framework.

3.5.1 Application Requirements

As mentioned above, QoS-adaptation provides an interface for applications to submit theirrequirements. Some applications are capable to expand their QoS profile, so that insteadof being a single value indicating the level of service needed by an application, it becomesa range of service levels in which the application can operate, together with the currentreserved value within that range. This provides the network flexibility so that reservationscan be maintained as network conditions change rather than forcing the network to make

3.5 QoS Adaptation 11

a binary "admit/fail" decision for each flow. Applications request QoS by specifying theminimum level of service they are willing to accept and the maximum level of servicethey are able to utilize, and then adapt to the specified point within this range that thenetwork commits to provide, which may change with time. Changes in allocation have tobe signaled to the application, which adapts its behaviour to match to what is available.The following three adaptation strategies are based on the concept of bandwidth ranges.

3.5.2 Adaptation Strategies

The adaptation strategy decides how and when QoS of a certain flow has to be investigatedand determines how to react to QoS changes. See [12] for details.

Greedy Strategy

The Greedy adaptation strategy is the simplest possible. Regardless of any end-to-endinformation every node tries to allocate the bandwidth requested. Suppose a scenario with4 nodes A, B, C and D with the corresponding bandwidth resources of 200K, 300K, 200Kand 300K. Furthermore assume a bandwidth request for the path A, B, C, D of within arange of 200K minimum and 300K maximum, also written as [200K,300K]. Using a greedyadaptation strategy node B allocates 300K although node A is only able to grant 200K ofbandwidth. Nodes C and D act the same. If for some reason the available bandwidth onnode C increases, according to the greedy adaptation strategy node C immediately allocatesadditional 100K to have 300K reserved in total. This is done even though node A still isa bottleneck and the end-to-end bandwidth still is 200K. The idea is that it might be quitehard to reach maximum reservation in one pass, so bandwidth is increased stepwise. Maybeat some point node A as well gains further 100K of bandwidth and the whole end-to-endreservation will be 300K which finally can be adapted by the application.

Bottleneck driven Strategy

In a bottleneck driven strategy each node would only try to allocate as much bandwidthas has been allocated already by previous hops for a certain flow, except the first nodein the path of course which always tries to allocate maximum bandwidth. This avoidstemporarily bandwidth waste but on the other hand makes it very difficult to increase end-to-end bandwidth for a flow. In the scenario discussed above each node would only reserve200K of bandwidth in a first step, which is the same as the end-to-end bandwidth for thisflow. But imagine the available bandwidth of node A and B would toggle between 200Kand 300K. If they never reach 300K at the same time end-to-end bandwidth will never beincreased.

Fair Strategy

As the number of application flows competing for resources increases, rather than sim-ply refusing to admit new flows or pre-empting existing flows, a fair adaptation strategyattempts to adjust the allocation for each flow, so that all flows can be accommodated.The strategy attempts to give each flow the minimum bandwidth requested, plus a fractionwhich is proportional to the requested bandwidth range. Suppose a scenario of a few nodeswhere each of them provides 300K of bandwidth. Assume a QoS request for a range of150K to 230K bandwidth. There is no problem for the network to provide maximum band-width for this flow. But as soon as a second request arrives, for say 100K to 120K, using thesame path or just a part of it, not even the minimum bandwidth could be granted. In case


of a fair strategy the first flow would be adjusted to run with its minimum of 150K, whatwould allow the second flow to run with its minimum as well. The remaining bandwidthof 50K (300 - 150 - 100) could be shared between both flows according to their bandwidthrange, which would result in a final reservation of 190K for the first flow and 110K for thesecond.

The major drawback of a fair adaptation strategy is its signaling overhead due to adjustingactive flows. However it would be interesting to test such an approach within a simulationenvironment.

3.5.3 Monitoring Interval and Soft-state Timer

As mentioned in section 3.5.2, an adaptation Strategy not only determines how to react onQoS changes, but also decides when and how frequently the available QoS for a fixed flowhas to be investigated. If QoS investigation is done by periodically sending monitoringmessages the time interval by which these messages are sent is an important factor andshould be dependent on the network condition. For example if node mobility is high ina MANET or the network is unstable, then more frequent monitoring is needed in orderto adapt to bandwidth fluctuations. On the other hand the monitoring interval time shouldalso be dependant on the actual bandwidth of the flow. The aim is to keep the amount ofdata constant which potentially could be sent in case of increased bandwidth availability orwhich could be lost in case of bandwidth degradation. It does not make sense for a flowrunning with 100K to monitor the network as frequently as a flow running width 300K does.But when bandwidth ranges are used then the actual bandwidth of a flow is conditioned bythe adaptation process itself which on his part reacts to QoS changes.

To make it even worse let’s focus on another parameter mentioned in section 3.4.3. In asoft-state based framework the question arises of how large to choose the timeout interval.Actually the size of the timeout interval should be a direct function of the monitoring mes-sages because they update the soft state. The problem is just that the soft state timeout isusually managed by each node within a path while the monitoring interval is specified byend nodes only.

3.6 Conclusion

During this chapter several design issues concerning QoS-Signaling and QoS-adaptationwere discussed in more detail. These concepts are not distinct from each other, often theycan be combined. As in the example of soft state and hard state, one could use explicitreservation release messages in a soft-state based framework even though it is a hard-stateconcept. However these concepts should facilitate classifying existing technologies as it isdone in the next chapter.

Chapter 4

Existing Technologies

This chapter describes some of the currently existing QoS technologies. Based on the con-cepts identified in the last chapter assets and drawbacks of each approach are pinpointed.

4.1 RSVP

As mentioned in chapter 2, RSVP [25][19] is a typical IntServ protocol for the fixed IPnetworks environment. It was designed to enable senders, receivers and routers of commu-nication sessions to communicate with each other in order to set up the necessary routerstates to support the quality of service requested by the application. A communication ses-sion is identified by the combination of destination address, transport-layer protocol type,and destination port number.

RSVP is a classic two-pass protocol using out-of-band signaling. The messages used arethePathmessage, which originates from the traffic sender, and theResvmessage[6], whichoriginates from the traffic receivers. The primary roles of thePath message are first toinstall reverse routing state in each router along the path, and second to provide receiverswith information about the characteristics of the sender traffic and end-to-end path so thatthey can make appropriate reservation requests.Resvmessages finally carry reservationrequests to the routers along the distribution tree between receivers and senders. RSVP stateis "soft-state", after a certain expire time, the state of the path and the reserved resource isreleased. Periodical issuing ofPathor Resvmessages are necessary to keep the reservationalive. Additional signaling information allows the soft state timeout to adapt to the refreshperiod. Furthermore RSVP provides a routing triggered local repair [8] mechanism toovercome the need for a very fast refresh rate in order to react to route changes.

There are many shortcomings of RSVP when used in MANETs:

� The two-pass reservation model employed by RSVP is not suitable for MANETs,specially in case of local repair.

� RSVP is based on a fixed QoS level approach. As a consequence no mechanism fora fast adaptation to QoS changes can be provided. To solve this problem reservationrequests should specify ranges of values instead.

� Due to its out-of-band approach, RSVP produces a significant signaling overhead.This may be of importance if the refresh rate high because the message size isnot negligible in RSVP. A high refresh rate might occur when no route-change-notification service from the routing layer is available. This causes local repair tofail.

14 Chapter 4. Existing Technologies

� As an IntServ based protocol RSVP lacks of scalability. The amount of state infor-mation increases proportionally with the number of flows what causes storage andprocessing overhead. Although the scalability problem may not be likely to happenin current MANETs due to the limited size of the network and the bandwidth ofwireless links, one could argue that it will occur with the development of fast radiotechnology and potential large number of users in the near future.

4.1.1 RSVP Extensions

Forced by the shortcomings of RSVP in Wireless networks, some approaches were madeto enhance the signaling protocol[18]. Most of them intend to solve micro-mobility issuesin infrastructure based wireless networks and do not address MANET problems directly.However MRSVP and DRSVP, two extension of RSVP to support mobility and dynamicnetwork environments, try to overcome some of the disadvantages of RSVP mentionedabove and are discussed in the following sections.

MRSVP

MRSVP[24] addresses mobility issues of a mobile node changing the point of attachmentto the fixed network and follows a Pro-Active approach as discussed in section 3.4.4. Twotypes of reservations are defined in MRSVP: active and passive reservations. Active reser-vation makes the resource exclusively reserved for the flow, no additional traffic is allowedto use the reserved resource. Passive reservation is different, it makes resource reservationin advance before the flow uses it. These passive resources are open to any other trafficuntil the flow actually needs the reservation. In order to make reservations in advance, itis necessary to specify the set of locations the mobile host may visit in future. The mobilenode thus passively establishes paths with sufficient resources to a possibly large set of at-tachment points the mobile host eventually moves to. When the node arrives at a particularpoint of attachment, the path to that attachment becomes active and the path to the previousone passive, so that the data can still be delivered effectively.

Even though MRSVP ensures good QoS provision in case of route change it suffers frommany drawbacks when used in ad hoc networks.

� MRSVP is designed for mobile wireless access networks not for MANETs. Theconcept of a mobile node and attachment points is not given in ad hoc networkswhere every node is a mobile having many attachment points. Adapting MRSVP toMANETs would result in a very large set of possible locations a path for a given flow

� Many resources are reserved that may never be used. Even though they are availablefor other requests it requires the nodes to maintain a lot of state information regardingactive and passive reservations.

� It may be very difficult to accurately determine the set of nodes to which a certainflow eventually is routed.

� Like RSVP it does not support any QoS adaptation, relying on the reservation in theinitial phase. Neither the current QoS is monitored nor bandwidth ranges are used.

� Considering one flow, reservation signaling has to be sent from each node in the pathto all the possible neighbours. This causes a huge overhead and makes the approachalmost unusable.

4.2 FQMM 15

DRSVP

DRSVP[16] aims to overcome the shortcomings of RSVP in terms of QoS adaptation. Bytreating a reservation as a request for service somewhere within such a range, flexibilityneeded to deal with network dynamics is gained. As available resources change, the net-work can readjust allocations within the reservation range. If resources decrease below thelevel currently allocated, the network can offer a more reasonable response than simplydropping the reservation.

In addition DRSVP provides a fair adaptation strategy as discussed in section 3.5.2. Theavailable bandwidth is divided up among admitted flows, taking into account the desiredrange for each flow.

DRSVP definitely addresses one of the major shortcomings of RSVP, namely the adapta-tion process. Using bandwidth ranges is a reasonable approach to tackle the problem ofQoS adaptation. But DRSVP does still not solve all the other problems of RSVP, like localrepair or signaling overhead.

4.2 FQMM

FQMM[14] (Flexible Quality of Service Model for Mobile Ad Hoc Networks) combinesthe IntServ and the DiffServ model discussed in the first chapter. Three kinds of nodes aredefined, exactly as in DiffServ. An ingress node is a mobile node that sends data. Interiornodes are the nodes forwarding data for other nodes. An egress node is a destination node.The basic idea of FQQM is that it uses both the per-flow state property of IntServ and theservice differentiation of DiffServ. This is achieved by preserving per-flow granularity fora small portion of traffic in the MANET, given that a large amount of the traffic belongsto per aggregate of flows, that is, per-class granularity. A traffic conditioner is placed atthe ingress nodes where the traffic originates. It is responsible for re-marking or discardingpackets according to the traffic profile, which describes the temporal properties of the trafficstream such as transmission rate and burst size.

FQMM is an interesting attempt at proposing a QoS model for MANETs, however it suffersof major problems:

� FQQM aims to tackle the scalability problem of IntServ. But without an explicitcontrol on the number of services with per-flow granularity, the problem still exists.

� Due to its DiffServ behaviour in ingress nodes, FQMM may not be able to satisfyhard QoS requirements[26]. It could be difficult to code the PHB in the DS fieldif the PHB includes per-flow granularity, considering the DS field is at most 8 bitswithout extension.

� How to make a dynamically negotiated traffic profile is a well-known DiffServ prob-lem (see 2.2.2) and FQMM seems not to solve it.

4.3 INSIGNIA

INSIGNIA[22][21] is a signaling protocol designed explicitly for MANETs. It supportsfast flow reservation, restoration and adaptation algorithms that are specifically designed todeliver adaptive real-time service. INSIGNIA implements an in-band approach by encap-sulating some control signals in the IP option of every data packet (see figure 4.3), which isnow called INSIGNIA option. Furthermore flow state information is kept in every node of


RES/BE BQ/EQ MAX/MIN MAX MIN

ServiceMode

PayloadType

BandwidthIndicator

BandwidthRequest

1bit 1bit 1bit 16bit

Figure 4.1: ASAP/ns Insignia Option Field

a particular path. This is done in a soft-state manner as explained in section 3.4.3, that is,the flow state information is periodically refreshed by the received signaling information.In the following the basic operation of the signaling system is described with respect toINSIGNIA IP option.

INSIGNIA offers a one-pass reservation (3.4.2). When a source node wants to establish areservation to a destination node it sets thereservation (RES) modebit in the INSIGNIA IPoption service mode of a data packet and sends the packet toward the destination. The band-width request field allows a source to specify its maximum (MAX) and minimum (MIN)bandwidth requirements. On reception of a RES intermediate routing nodes execute ad-mission control to accept or deny the request. When a node accepts a request, resources arecommitted and subsequent packets are scheduled accordingly. In contrast, if the reservationis denied, packets are treated asbest effort (BE) modepackets.

In the case where a RES packet is received and no resources have been allocated, theadmission controller attempts to make a new reservation. This is a re-active local repairmechanism (3.4.4) and commonly occurs when flows are rerouted during the lifetime of anongoing session due to host mobility.

The bandwidth indicator field of INSIGNIA option plays an important role during reserva-tion setup and adaptation. Reception of a setup request packet with the bandwidth indicatorbit set to MAX indicates that all nodes encountered have sufficient resource to support themaximum bandwidth requested. On the other hand, a bandwidth indicator set to MIN im-plies that at least one of the intermediate nodes between the source and destination is abottleneck node and the maximum bandwidth requirement may not be met.

When a reservation is received at the destination node, INSIGNIA checks the reservationestablishment status. The status is determined by inspecting the IP option field servicemode, which should be set to RES. If the bandwidth indication is set to MAX, this impliesthat all nodes between a source-destination pair have successfully allocated resources tomeet the QoS requirements of the source node. In contrast if the bandwidth indication isset to MIN this indicates that only the minimum bandwidth can be currently supported. As aresult "partial reservations" will exist between source and bottleneck node, these resourcesremain reserved until explicitly released.

QoS reporting message can be sent by destination nodes to inform source nodes of the on-going status of flows. They do not have to travel on the reverse path toward a node. TheINSIGNIA system supports two QoS report commands in order to provide some kind ofadaptation. Ascale-down commandrequests a source either to send with the rate speci-fied as MINIMUM instead of MAXIMUM or to send its packets as best effort instead ofMINIMUM depending on the current sending rate of the source node. This will have theeffect of clearing any partial reservation. Ascale uprequests a source node to initiate areservation for some MINIMUM or MAXIMUM rate, depending on the actual flow state.

Although INSIGNIA presents a quite promising approach to QoS support in ad hoc net-works, the system still lacks of some basic mechanisms:

4.4 Some further Approaches 17

QoS report: bandwidthindicator = MIN

Max. Reserved

Min. Reserved

NodeMobility

Figure 4.2: ASAP/ns Insignia Monitoring

� The most frequently mentioned drawback of INSIGNIA in literature is its scalabilityproblem due to the flow state information which is kept within the nodes of a certainpath. This is an inherent problem of IntServ but it is doubtful whether it will be ofimportance for MANETs in future (see 2.2.2).

� INSIGNIA’s bandwidth usage is not efficient. The extra reservation on the path fromthe sending node to the bottleneck is a waste of bandwidth until an explicit releasemessage is sent. Although this waste won’t last long, topology changing of MANETwill make this reservation waste propagate frequently. Furthermore releasing partialreservations using QoS reports enforces source nodes either to set the bandwidthindicator of the INSIGNIA option field to MINIMUM or to send the packets as besteffort depending on the actual flow state. In both cases the opportunity to scale up islost.

� INSIGNIA does not provide any mechanism to dynamically change the frequencyby which control signals are inserted into the data packets. This imposes a majorprocessing overhead on the network.

� Only two bandwidth levels to be used are offered, MINIMUM and MAXIMUM. Amore fine-grained approach would be needed in order to satisfy application require-ments and to fully exploit the resources available.

4.4 Some further Approaches

4.4.1 iMAQ

iMAQ[1] is a cross-layer architecture to support the transmission of multimedia data over aMANET. They use a location-based pro-active QoS-Routing. Neither hard QoS guaranteescan be provided nor are any resources reserved. Because cross-layer designs and QoS-Routing are not within the scope of this document, the iMAQ approach is not consideredany further.

4.4.2 INORA

INORA[11] is a QoS support mechanism that makes use of the INSIGNIA in-band sig-naling and TORA routing protocol for MANETs. INORA represents a QoS-signaling ap-proach in a loosely coupled kind of manner. The idea is based upon the property of TORAto provide multiple routes between a given source and destination. While INSIGNIA does


not take any help from the network with regard to redirecting the flow along routes whichare able to provide the required QoS guarantees, INORA gives feedback to the routing pro-tocol on a per-hop basis to direct the flow along the route that is able to satisfy the QoSrequirements of the flow.

Beyond doubt the concept of ’loosely coupling’ QoS-signaling and routing is a verypromising approach and the shortcomings of INORA mostly are the shortcomings of IN-SIGNIA. However, the interface for signaling to access routing should be as generic aspossible in order to guarantee portability.

Chapter 5

ASAP Framework

ASAP[27] (Adaptive ReServation And Pre-Allocation QoS Architecture) provides adaptiveQoS support to real-time applications in infrastructure based wireless IP networks. Thegoal of this thesis is to extend the ASAP framework to be used in mobile ad hoc networksand to implement and simulate it on the ns-2 simulator later on. This chapter describesthe ASAP framework by giving a conceptual overview first and explaining the signalingsystem in more detail later on.

5.1 Concepts

5.1.1 Soft/Hard Reservation

In ASAP, a new reservation concept, soft/hard reservation, is created for efficient resourceallocation. The concept is quite similar to the passive/active reservation mechanism pre-sented by MRSVP (4.1.1). Soft reservation can be considered as the claim of a flow for acertain amount of bandwidth to be used in future. Hard reservation instead enables a flowto exclusively reserve some bandwidth.

The actual reservation mechanism is two-pass based. When a new real-time flow is aboutto run, a soft reservation request is sent first. If there are enough resources available, therequested bandwidth will be soft reserved for the flow. Because a soft reservation is onlya claim, the reserved bandwidth is still open to any other flow for temporary usage. Aftera soft reservation is established, the end-node sends a HR message requesting the sameamount of bandwidth. This hard reservation will remove all the traffic occupying the cor-responding soft reserved bandwidth. So after a hard reservation, the QoS traffic can imme-diately start running with its necessary QoS support.

The goal of introducing two kinds of reservations is to achieve good performance in QoSmonitoring and stream upgrading/downgrading.

5.1.2 Soft-State Management

ASAP follows the concept of reserving resources in a soft-state manner as described inchapter 3. That means, reservations have to be refreshed periodically in order to preventtimeouts, which would cause the resource to be released. Currently, ASAP does not provideany dynamic coupling of soft-state interval and refresh period, instead the timeout intervalcan be set up on a per-node basis. Because of the different characteristics of soft- and hardreservation, both timeout intervals are configurable separately.

20 Chapter 5. ASAP Framework

Flow Label SrcAddress SoftResv HardResv0 Host1 100 1001 Host1 50 1000 Host2 150 0

Flow ID

Figure 5.1: QoS Table

5.1.3 Adaptive QoS Monitoring

QoS monitoring packets will periodically investigate the QoS situation on every nodewithin a certain path. HR messages are sent whenever the end-to-end QoS changes. Inorder to adapt to various network conditions the monitoring interval can be set dynami-cally. For example if the network is unstable, then more frequent monitoring is needed inorder to adapt to bandwidth fluctuations. In contrast, if the network is stable, processingoverhead can be saved by keeping the monitoring rate low.

5.2 Signaling System

ASAP provides efficient in-band signaling for the purpose of resource reservation, man-agement, adaptation and releasing. The signaling is designed to produce as little overheadas possible and at the same time provides most flexibility.

5.2.1 QoS Table

Every node within the network stores information for each real-time flow having a reser-vation on that specific node. The per-flow information stored comprises a flowID uniquelyidentifying the flow and the actual soft and hard reservation for the flow. The set of alltuples stored within a node is called QoS table. Table updates are triggered upon receivingsignaling messages.

5.2.2 Message Types

There are two types of messages in the ASAP architecture: SR (soft reservation) and HR(hard reservation). These two messages correspond to the two types of reservations men-tioned above. But not only resource reservation, also QoS monitoring and adaptation arerealized by these messages.

Generic Message Format

Figure 5.2.2 illustrates the generic message format to be used by both, SR and HR message.How exactly this control information is carried by a normal data packet in order to providein-band signaling will be described section 5.3. What follows is a brief explanation of eachfield shown in figure 5.2.2.

� Message Type Indicator: The reservation indication (RI) field specifies the actualmessage type. When a packet passes the network, routers first check its RI field.According to its type, corresponding processing will be triggered. Currently three

5.2 Signaling System 21

RI QoS Option Flow ID Option

MinBW MaxBW ActualBW

SetBW ActualBW

Src Address

Flow Label

Har

dR

ese

rva

tion

Ms

g

So

ftR

ese

rva

tion

Msg

Figure 5.2: Generic Message Format

types are defined:NON means the packet is normal data,SOFTRESandHARDREScorrespond to soft and hard reservation message.

� QoS Option: The QoS option carries all the QoS information needed by the signal-ing. The internal structure is message type specific.

� FlowID Option: The FlowID Option contains information to uniquely identify aflow. In ASAP, a flow is identified by the combination of source address and flowlabel. The source address is globally unique and the flow label is randomly generatedby the source node, so it is unique within all the flows generated by that particularnode.

SoftReservation Message

An SR message sets the RI field to SOFTRES and defines the QoS Option to be as shownin figure 5.2.2. Three fields are provided within the QoS option: MinBW corresponds tothe minimum bandwidth requirement for the particular flow. MaxBW is defined to be themaximum amount of bandwidth the application asks for and ActualBW finally representsthe actual reserved bandwidth for the flow at a certain time including the soft and the hardreservation part.

HardReservation Message

On the other hand an HR message sets the RI field to HARDRES and defines the QoSoption as shown in figure 5.2.2. The option field provides two parameters to be set. SetBWcontains the amount of soft reserved bandwidth to be switched into hard reservation andActualBW is defined to be the actual bandwidth reserved, exactly as the SR message does.

5.2.3 Setup Procedure

To setup a new real-time flow, the sender host first generates an SR message for somespecific MinBW/MaxBW values. Upon receiving a such a message, an intermediate nodecreates an entry in its QoS table, reserves as much bandwidth as possible within the scope ofMinBW/MaxBW and updates both, the QoS table and the ActualBW field of the message(this is done only if the reserved bandwidth is less than the original value). When an


Real-timeApplication

Host1

300K 0K

Host2

200K 0K

Host3

300K 0K

Host4

300K 0K


100 300

300

100 300

200

100 300

200

Bottleneck100 300

200

MinBW

ActualBW

MaxBW

SoftReservation Msg

100 300

0

Figure 5.3: Soft reservation setup


Host1

0K 200K

Host2

0K 200K

Host3

0K 200K

Host4

0K 200K


Bottleneck

HardReservation Msg

SetBW ActualBW

200 0

200 200200 200200 200

200 200

Figure 5.4: Hard Reservation

SR message arrives at a receiver node, the ActualBW field corresponds to the end-to-endbandwidth availability. The receiver then replies with an HR message setting the SetBWfield equal to ActualBW, so that each node on the path switches its soft reserved bandwidthinto hard reservation and releases any potential extra reservation. As soon as the sender hostreceives the HR message, the necessary QoS support for this particular flow is establishedand the real-time flow can start running.

5.2.4 QoS Monitoring

After a flow path is established, SR messages are periodically inserted into data packets.These messages collect QoS information and eventually perform soft reservations. Thealgorithm executed when receiving a SR message on a intermediate node is actually thesame as used during setup and is shown below in code style:

r e c e i v i n g _ m e s s a g e (SR ) ;TotalResvBW = SoftResvBW + HardResvBW ;i f ( TotalResvBW < SR .MaxBW){

i f ( Avai lableBW > = SR .MaxBW � TotalResvBW ){SoftResvBW = SR .MaxBW � HardResvBW ;s o f t _ r e s e r v i n g (SR .MaxBW� TotalResvBW ) ;

}e l s e i f (Avai lableBW > 0 ) {

SoftResvBW = SoftResvBW +Avai lableBW ;s o f t _ r e s e r v i n g ( Avai lableBW ) ;

}TotalResvBW = SoftResvBW + HardResvBW ;

}

5.3 Implementing ASAP using IPv6 23

SR . ActualBW = Min (SR . ActualBW , TotalResvBW ) ;send ing_message (SR ) ;

Due to the information provided by SR messages, the receiver host is capaple to keep trackof the QoS situation on an end-to-end basis and therefore can immediately adapt to anyQoS change by sending an appropriate hard reservation. Adaptation means to upgradewhenever additional resources get available and to downgrade under degraded conditions.The following code illustrates how a receiver host reacts to a SR message:

r e c e i v i n g _ m e s s a g e (SR ) ;i f ( SR . ActualBW ! = HardResvBW ){

c r e a t e _ m e s s a g e (HR) ;HR. SetBW = SR .SoftBW + SR .HardBW ;HR. ActualBW = 0 ;send ing_message (HR ) ;

}

5.3 Implementing ASAP using IPv6

5.3.1 IPv6 in a Nutshell

IPv6[20] is the "next generation" protocol designed by the IETF to replace the currentversion Internet Protocol, IP Version 4 ("IPv4"). Basically IPv6 provides the followingenhancements:

� Bigger address space

� Mobility

� Built-in security

The bigger address space IPv6 offers is the most obvious enhancement it has over IPv4.While today’s Internet architecture is based on 32-bit wide addresses, the new versionhas 128-bit technology available for addressing. Thanks to the enlarged address space,workarounds like NAT (Networks Address Translation) do not have to be used anymore.This allows full, unconstrained IP connectivity for today’ IP-based machines as well asupcoming mobile devices like PDA’s and cell phones.

When mentioning mobile devices and IP, it’s important to note that a special protocol isneeded to support mobility - called "Mobile IP". IPv6 provides built-in mobility supportand thus allows for roaming between different networks using global notification whenleaving one network and entering the other one.

5.3.2 IPv6 Header Format

IPv6 defines a base header, which is mandatory, and a few optional extension headers to beinserted in between base header and upper-layer headers in a packet. In order to connectthese headers the common NEXT HEADER field can be used. This actually forms a daisychain of headers.


Base Header

An IPb6 base header is simpler than an IPv4 header. Some rarely used field like IHL,FRAGEMENT OFFSET and HEADER CHECKSUM are removed and two new fields areadded instead: FLOW LABEL and CLASS.

FLOW LABEL is a 20-bit field to be used by a source to label sequences of packets forwhich it requests special handling by the IPv6 routers, such as non-default quality of serviceor "real-time" service. Although the concrete usage of the field is still under discussion, itis believed that in the future, FLOW LABEL will be used as flow identifier mainly for theIntServ model[9].

The CLASS field is an 8-bit field evolved from the TOS field in IPv4. It is available for useby originating nodes and/or forwarding nodes to identify and distinguish between differentclasses or priorities of IPv6 packets. Like in the case of FLOW LABEL, the concrete usageof the CLASS field is still under experiment and discussion. However the field seemsto be destined for DiffServ QoS support. RFC2474 proposes a renaming of the CLASSfield into DS (Differentiated Service). The DS field should be composed of 6-bit DSCP(Differentiated Service Code Point) field and a 2-bit unused field, for which no suggestionof how to use it is defined yet.

Extension Headers

Six additional extension headers are defined in IPv6:

� Hop-by-Hop options header

� Routing header

� Fragment header

� Authentication header

� Encrypted security payload

� Destination options header

The Routing header is used to specify a list of intermediate nodes to be visited on the wayto a packet’s destination. This function is very similar to IPv4’s Source Route options.

The Hop-by-Hop Options header is used to carry information that must be examined byevery node along a packet’s delivery path.

In contrast, the destination options header will only be examined by the packet’s destinationnode.

Authentication header, Encrypted payload and Fragment header will not be discussed here.

5.3.3 Using IPv6 for ASAP Signaling

As ASAP is an in-band signaling system it uses the packet’s header to carry all its controlinformation. In case of IPv6 this information can be transmitted within the base headerand/or within any extension headers. ASAP uses the two undefined bits of the CLASSfield as discussed in a previous section to transmit its Message Type indicator. Furthermorethe IPv6 Hop-by-Hop options header is perfect container for ASAP’s FlowID option andthe QoS option as these informations are intended to be processed by every node along acertain path.

5.3 Implementing ASAP using IPv6 25

IPv6 Base HeaderNext Header = HopByHop

HopByHop HeaderNext Header = TCP

TCPSegment

Ver Class Flow Label

Payload Length Next Header Hop Limit

Source Address (128 bits)

Destination Address (128 bits)

Next Header

DSCP RI

Hdr Ext Len Option Type Option Len

QoS Option FlowID Option

Figure 5.5: ASAP message embedded in an IPv6 header

The whole structure of an ASAP message embedded within an IPv6 header is shown infigure 5.3.3

Up to now it was never mentioned how ASAP aims to build a virtual path between sendernode and receiver. This has to happen somehow because an HR message intends to switchsoft reservation into a hard bandwidth reservation for a given flow. To achieve this, anHR message must follow the reverse path of the corresponding SR message. There aretwo basic opportunities to do this: One possible approach would be to store previous hopinformation in every node, related to a particular flow. Another solution would be to usethe IPv6 routing header. Both approaches collect path information during soft reservationto be used by the HR message later on.


Chapter 6

Ad Hoc Extensions for ASAP

ASAP as it is described in the previous chapter is designed for infrastructure based wirelessIP networks, in particular for a last-hop-wireless topology. To achieve seamless handoverthe protocol comprises some mechanisms to pre-allocate resources on a potential new ac-cess point. These features were not mentioned because they’re irrelevant within this doc-ument. Instead our focus is on how to modify the ASAP framework to be well suited forMANETs.

6.1 Problems of ASAP in MANETs

As described in chapters 1 and 3 MANETs impose special requirements on QoS. Eventhough ASAP makes use of in-band signaling and fast adaptation, the protocol fails tomeet some MANET specific demands. This section shows several problems of ASAP in amobile ad hoc environment.

6.1.1 Flow Restoration

Imagine the following scenario: In a net-

D

B

A

CNodeMobility

Missing Reservation:Flow Restoration Needed

work with four nodes A, B, C and Dnode A sends stream data to node D us-ing a route over node B. Assume maxi-mum quality of service is provided alongthis path. Now at a certain time node Cstarts moving and finally gets out of nodeA’s transmission range, routing then findsa new path from A to D over node B.Because no reservation is established atnode B the flow is transmitted using besteffort. This state is kept until the next SR message detects the missing reservation and trig-gers node D to send a hard reservation message, which will finally repairs the reservationon node B.

The repair mechanism as described has at least two major shortcomings. First the latencyfor such a two-pass based flow restoration can be quite long, especially when a path com-prises many hops. This is because reparation involves both end nodes and detecting amissing reservation can only be as fast as the soft reservation refresh period. Thus, theworst-case reparation time is twice the end-to-end delay if route change happens right after

28 Chapter 6. Ad Hoc Extensions for ASAP

A C E G

F

D

BSR Message

HR Message

Figure 6.1: Reverse Path

the sending node (in our scenario this would be node A). The second problem is that de-tecting a missing reservation cannot be signaled to the receiving node in some cases (hardreservation leak). This happens whenever a path is rerouted on a new node that is able toprovide the actual end-to-end reservation. Bandwidth will be soft reserved on the node butthere is no reason to change the ActualBW field of the message because the field representsthe sum of both hard and soft reservation part. As a consequence an end node will notdetect any QoS change and will therefore not send any hard reservation to switch the softreserved bandwidth into a real reservation.

To overcome these shortcomings a new flow restoration mechanism has to be designed.The goal is to reduce latency and to guarantee proper restoration.

6.1.2 Reverse Path Problem

As described in the last chapter, a hard reservation message is supposed to follow the re-verse path that is previously established during soft reservation. This could be hard toachieve for several reasons. First, routes may change quickly in MANETs. A path estab-lished during soft reservation may be outdated while hard reservation is going on. Second,routes do not have to be symmetric. Although physically two nodes can reach each otherin one hop distance that does not mean routing also behaves like this. This could result in abig latency for hard reservation messages. See figure 6.1.2 for an illustration. A soft reser-vation is sent along the path A, C, E, G but the corresponding hard reservation messagetakes a much longer way using G, F, E, D, C, A. The third problem related to reverse pathsoccurs when wireless links are not symmetric. Even if a node A can reach B in one hopdistance it is not given that node B is able to reach A as well. As a consequence there maybe no way for a hard reservation to pass through.

The two-pass protocol used in ASAP seems not to be flexible enough to meet the demandsof mobile ad hoc networks. The topology is just too dynamic and requires an approachwhich is more simple.

6.1.3 Lost Hard-Reservation Messages

In case of a hard reservation getting lost some kind of starvation may occur. The followingscenario is used to illustrate this: Assume three nodes A, B and C and some soft reser-vation request sent along this path. Furthermore assume every node to be able to providemaximum service. Upon receiving the soft reservation message node C checks whether theActualBW (includes soft and hard reservation) field within the message corresponds to theend-to-end bandwidth information he is keeping. If both values are unequal the adaptationprocess updates himself and sends a hard reservation message out in order to allocate or torelease bandwidth. Suppose the message gets lost right after sending, what happens? No

6.2 Extensions 29

RI QoS Option Flow ID Option

MinBW MaxBW ActualSoft

SetBW ActualSoft

Har

dR

ese

rva

tion

Ms

g

So

ftR

ese

rva

tion

Msg

ActualHard

ActualHard

Figure 6.2: Extended Message Format

subsequent soft reservation message will trigger any hard reservation if the path condition(bandwidth allocations on the nodes) stays the same because the adaptation process alreadydid update his ActualBW value. This state is kept until the end-to-end bandwidth for theflow changes somehow, that means until a soft reservation message arrives at node C hav-ing an ActualBW value that is unequal to the one stored by the adaptation process. If nonode is moving and bandwidth isn’t fluctuating either this may take a while.

So a concept is needed to overcome this shortcoming. Hard reservation messages must betriggered until the reservation is actually done.

6.2 Extensions

Based on the shortcomings described in the previous section ASAP has to be redesignedin order to provide fast flow restoration and short reaction times to topology changes. Toachieve this some new mechanism are developed: Local Repair and Dynamic Virtual Path.Furthermore the adaptation algorithm is slightly changed.

6.2.1 QoS Option Field for Soft-Reservation Message

In order to support the mechanisms described below the QoS option field is modified to beas illustrated in figure 6.2.1. Instead of having one field indicating the actual bandwidthreserved the soft and hard reservation part is now defined separately.

6.2.2 Local Repair

Local Repair addresses the lack of ASAP to provide fast flow restoration. In section 3.3three scales of coupling between routing and QoS-signaling were discussed. It was shownthat a loosely coupled approach might help to improve flow restoration after rerouting. Onthe other hand any dependencies between routing and QoS-signaling should be avoided.The solution developed within this thesis provides mechanisms that can be used in bothways, in a totally routing-independent manner or as a loosely coupled approach wheneverrouting provides the necessary functionality. The goal was to provide a basic service re-gardless of whatever routing looks like, but to improve the service if routing is able to bringsome support.


Concept

The concept is rather simple. A local repair is triggered by a soft reservation message.Upon receiving a soft reservation message the node tries to soft reserve some bandwidthwithin the specified range and updates table entries as usual. Before passing the messageto the next hop the node checks whether its actual hard reservation corresponds to the hardreservation specified within the received message or not. If both values are equal nothinghas to be done and the soft reservation message is sent along the path. Otherwise the nodereleases any additional reservation if the actual hard reservation specified is smaller than itsown hard reservation for that flow or tries to allocate additional resources if the specifiedvalue is greater than its own. Both releasing and allocation of bandwidth has to be donewith respect to the range and the amount of soft reserved bandwidth for that flow. Thatmeans, a node must only allocate additional hard reservation if enough soft reservation isavailable to be switched.

. . .r e c e i v i n g _ m e s s a g e (SR ) ;s o f t _ r e s e r v i n g _ a n d _ u p d a t i n g _ t a b l e s (SR .MinBW , SR .MaxBW) ;i f ( HardResvBW < SR .HardBW) {

i f ( SoftResvBW > = SR .HardBW � HardResvBW ){h a r d _ r e s e r v i n g (SR .HardBW � HardResvBW ) ;

}e l s e i f (SoftResvBW > 0 ) {

h a r d _ r e s e r v i n g (SoftResvBW ) ;}

}e l s e {

h a r d _ r e l e a s i n g (HardResvBW� SR . HardBW ) ;}. . .

Monitoring based Local Repair

As each soft reservation message represents a potential claim for local repair, a monitoringmessage and even a flow setup message at the same time no further features are needed toprovide a base service for fast flow restoration. It depends now on the refresh period howfast local repair can be. Monitoring based local repair can be seen as a base service whichis always available due to its independence from any underlying routing protocol.

Routing triggered Local Repair

It was mentioned in chapter 3 that some routing protocols allow upper layers for installationof upcall procedures to be called whenever a route changes. One should take advantage ofthis feature if available. Suppose a route change occurs on a certain node and the signalinglayer receives a corresponding upcall. All that has to be done is to send out a soft reservationmessage for each flow affected by this change.

Routing triggered local repair should be considered as an enhancement to monitoring basedlocal repair if the necessary support can be provided.

6.2.3 Dynamic Virtual Path

Dynamic Virtual Path addresses the problem of unsymmetrical routes and links causingdifficulties for hard reservation messages to follow the reverse path established during pre-

6.2 Extensions 31

A C E G

F

D

B

SR Message

MAXHOPCOUNT = 2

HR Message

HC = 1

HC = 1

HC = 2

HC = 2

HC = 1

Figure 6.3: Dynamic Path

vious soft reservation. The idea is to add a hopcount field to the hard reservation messagethat is reset on every node belonging to the path and incremented on every other. Fur-thermore a global MAXHOPCOUNT constant is defined. If hopcount reaches MAXHOP-COUNT on a certain node the hard reservation message is not processed any further butsent directly to the source node specified within the flowID of the message, regardless ofthe route the message will take. Temporary there may be a partial reservation on the pathwhile some nodes stay untouched. But as the hard reservation message is received by thesender, the node updates its QoS entry for that flow by setting actualSoft and actualHardto the corresponding values within the message. The subsequent soft reservation messagewill then trigger a local repair as described in the previous section in order to switch anysoft reserved bandwidth into hard reservation on all the remaining nodes.

The approach as explained solves the problem of unsymmetrical links, the problem occur-ring in case of lost hard reservation messages still exists. Therefore a stable adaptationprocess is needed that is able to deal with such scenarios.

6.2.4 Adaptation

Within this section it is assumed that if there is a path from a node A to another node B,there is also a path back from node B to node A, although the two paths might be different.

Due to the modifications made at the QoS Option field the adaptation process is nowable to treat changes in soft and hard reservation separately. A slight modification onthe adaptation algorithm allows to overcome the problem of lost hard reservation messages:

r e c e i v i n g _ m e s s a g e (SR ) ;i f ( SR . SoftBW > 0 ) {

c r e a t e _ m e s s a g e (HR) ;HR. SetBW = SR .SoftBW + SR .HardBW ;send ing_message (HR ) ;

}i f ( SR . HardBW < HardResvBW ){

c r e a t e _ m e s s a g e (HR) ;HR. SetBW = SR .HardBW ;send ing_message (HR ) ;

}HardResvBW = SR .HardBW ;

Each adaptation process holds information about the actual end-to-end hard reservationfor each flow. Upon receiving a SR message the node checks whether there is some softreservation available to be switched into real reservation or not and sends hard reservation


message out if necessary. Otherwise the adaptation process compares the end-to-end hardreservation with the value it is keeping. If the received one is smaller a hard reservationmessage is sent in order to release any extra reservation between sending node and bot-tleneck. In any case the adaptation process updates its hard reservation to be equal to thevalue specified within the message sent.

This mechanism is tolerant to lost hard reservation messages and even provides detectionof hard reservation leaks (see section 6.1.1 in case of path rerouting).

6.3 Conclusion

Three major problems of using ASAP in MANETs were presented in the beginning ofthis chapter considering flow restoration, reverse path and lost hard reservation messages.The solution provided within this thesis is based on an extended QoS Option field treatingsoft and hard reservation separately. A local repair mechanism is used to overcome theproblems related to the inertness of two-pass based reservations like the big latency duringflow restorations. The reverse path problem is addressed by using dynamic virtual paths.Finally a slight modification on the adaptation algorithm helps to improve the stability ofsignaling with respect to lost hard reservation messages.

Chapter 7

Implementation

7.1 Overview

This chapter describes the implementation of the ASAP framework using the ns-2 networksimulator [3] (from now on referred to as ASAP/ns). The chapter starts giving a briefintroduction to ns-2 with respect to protocol development in mobile environments. Afterdefining the basic implementation requirements an architectural overview of ASAP/ns ispresented. Subsequent sections then discuss each of the main components in more detail.

All file system references mentioned within this chapter are relative to the actual ns-2 in-stallation directory, which is used to be /ns-allinone-2.1b9a.

7.2 NS-2

The network simulator ns-2 is an object-oriented, discrete event-driven network simulatordeveloped at UC Berkeley and USC ISI. It is a useful tool for conducting networks simula-tions involving local and wide area networks, but its functionality has grown during recentyears to include wireless networks and ad-hoc networking as well.

Ns-2 has gained popularity among participants of the research community, mainly becauseof its simplicity. It allowssimulation scriptsto be easily written in a script-like program-ming language, OTcl. More complex functionality relies on C++ code that either comeswith ns-2 or is supplied by the user. This flexibility makes it easy to enhance the simulationenvironment as needed, although most common parts are already built-in, such as wirednodes, mobile nodes, links, queues, agents (protocols) and applications (i.e. ftp). Most net-work components can be configured in detail, and models for traffic pattern and errors canbe applied to a simulation in order to increase its reality. Simulations in ns-2 can be loggedto trace files, which include detailed information about received and transmitted packetsand allow for post-run processing with some analysis tools.

The following sections intend to outline some of the basic components of ns-2 - in particularthose that are important for the implementation of the ASAP framework described later onin this chapter.

The ns-2 distribution discussed within thesis is ns-allinone version 2.1b9.

34 Chapter 7. Implementation

AddressClassifier

PortClassifier

Agent

Link

EntryPoint

Generated Packets

Queue Link

Queue Link

Figure 7.1: Wired Node

7.2.1 Nodes

Nodes are fundamental in a simulation. They perform processing and forwarding of pack-ets, and are therefore perhaps the most important entities among all network components ofns-2. The internal architecture of a node differs depending on whether the node is mobileor not.

Wired node

A wired node is a compound of a node entry object and two classifiers, as shown in figure7.2.1. The node entry is where packets first arrive. The address classifier examines theaddress field of a packet to check whether the packet is destined for the current node.Finally the port classifier determines which agent (protocol) at the node should receive thepacket.

If the packet is not destined for the current node, the address classifier decides on whichlink the packet should be sent. This is possible because routing constantly updates theaddress classifier.

Mobile node

A mobile node is a node with extra functionality in order to provide mobile networking.Figure 7.2.1 shows the internal structure of such a node.

In contrast to a wired node, a mobile node is connected to a wireless channel instead of alink. Also, mobile nodes may be moved within a topography, as opposed to wired nodeswhich remain stationary. The mobile node itself is a compound object, built from thefollowing parts:

7.2 NS-2 35

AddressClassifier

PortClassifier

Agent

Link

EntryPoint

Generated Packets

RoutingAgent

ARPLinkLayer

InterfaceQueue

MAC

NetworkInterface

PropagationModel

Wireless Channel

Figure 7.2: Wireless Node

� anaddress classifierlike seen in the wired node right before. It is used for handlingpackets to port classifier or routing agent.

� A port classifieras well, passing packets to the corresponding agent.

� A routing agent.

� A link layer responsible for converting network address to hardware addresses withthe help of an ARP module

� an interface queueused for storing and scheduling of packets with respect to somewell defined policies.

� anetwork interfacethat sends and receives packets over the wireless channel.

� a radio propagation modeldetermining the signal strength of received packets, andhence, whether a packet can be received by a network interface or not.

� awireless channelover which packets are distributed.


7.2.2 Packets

Packets are the unit of exchange between objects in a simulation. They are built up ofpacket headers, corresponding to different protocols that may be used, and packet data.New protocols may add their own header types to the available ones, and unused packetheaders may be turned off to save memory during simulations. The only mandatory packetheader in ins-2 is thecommon header, hdr_cmn, mainly used for tracing and for measuringother quantities during a simulation.

7.2.3 Agents

Agents represent endpoints where packets are generated or consumed, and are used for im-plementing protocols at various layers. Routing agents and traffic sinks are some examplesof agents that are frequently used in simulations.

7.3 Implementation Requirements

This section sketches some of the requirements the implementation finally ought to fulfill:

� Modularity: Message transmission, signaling processing, adaptation and applica-tion are separate functional units and therefore should be splitted into different build-ing blocks. Well-defined interfaces have to be provided for these components tointeract with each other.

� QoS Routing decoupling: The implementation must not be dependent on any rout-ing protocol, instead ASAP/ns is expected to run on top of different MANET routingprotocols like AODV or DSR, without need for any special configuration.

� Extensibility: ASAP/ns should provide an extensible framework. Future develop-ment and usage of special allocation or adaptation strategies must be easily possibleas well as the extension of the existing message format by adding additional optionobjects.

� Node independence: Although the implementation is MANET driven it should notbe bound to the mobile node architecture. Simulating ASAP/ns in a heterogeneousnetwork might be of future interest.

7.4 Main Building Blocks

In order to meet the requirements of modularity as indicated right before different protocolmechanisms are split up into separate building blocks. Figure 7.4 gives an architecturaloverview of ASAP/ns from a network layer point of view.

The whole system is mainly divided into the following three parts:

� QoS management unit (QMU): The core unit of ASAP/ns residing on every nodeof a MANET dealing with all around signaling processing.

� Adaptation control unit (ACU): Upon receiving periodic monitoring messages theACU decides how to react to QoS changes for a given flow according to some ap-plication specific strategy. In addition the ACU provides an interface for applicationrequesting QoS.

7.5 QoS Management Unit 37

AQRU

ACU

CoreApplication

Phy

MAC

Queue

LL

QMU

ACU

PHY

MAC

Queue

LL

QMU

PHY

MAC

Queue

LL

Real-timeServer

ClientIntermediateNode

QMUQoS Signaling

Figure 7.3: ASAP/ns Architecture

� Application QoS Request unit (AQRU): The AQRU is actually part of the applica-tion and decides which adaptation strategy to use. Furthermore it is responsible foradjusting the bandwidth of a given flow according to the feedback gained from theadaptation control unit (ACU).

The following part of this chapter intends to describe each of these building blocks in moredetail.

7.5 QoS Management Unit

7.5.1 Overview

The QMU unit maintains path and reservation state on all ASAP nodes and generates andprocesses signaling messages, that means soft and hard reservation messages. Mainly theQMU can be seen as a black box having four connectors that allow for receiving of mes-sages, performing bandwidth reservation and release respectively, upcalling the ACU andsending or forwarding messages. As protocols in ns-2 are implemented by so called agents,embedding the QMU component into a node object results in an architecture as shown infigure 7.5.1.

Packets arriving at the node’s network interface are passed to the QMU by the classifier. Inorder to allocate bandwidth for a certain flow, the QMU performs some reservation on thenode’s interface queue. A packet is sent or forwarded by handing it over to the classifieragain.

All the implementation code corresponding to QMU is located in the directory ns-2.1b9a/asap/qmu/.

7.5.2 Internal Structure

This section provides a deeper look at the internal structure of the QMU. Figure 7.5.2zooms into the black box described above.


AddressClassifier

Link

EntryPoint

Generated Packets

RoutingAgent

LinkLayer

InterfaceQueue

MAC

NetworkInterface

QMU

Upcall

BandwidthReservation

Figure 7.4: QMU Overview

SoftResv

Deserialization

HardResv

Serialization

ReceivePacket

ACUUpcall

ForwardPacket

Reservationon Queue

Figure 7.5: Internal Structure of QMU

Upon receiving a signaling packet the QMU first transforms the raw byte stream into ac++ message object. According to the message type, the object is dispatched to soft- orhard reservation processing where eventually some bandwidth will be allocated/released.In case of an end-node an ACU upcall is made. Otherwise the updated message object isserialized to be sent within a packet.

So basically the QMU logic can be divided into two parts, namely message serializa-tion/deserialization and reservation processing.

7.5.3 Message Serialization/Deserialization

As mentioned in chapter 5 ASAP signaling is designed do be used in combination withIPv6. Unfortunately there is no such support in ns-2. So the approach made in ASAP/nswas to build a messaging framework having similar flexibility [13].

Each signaling message comprises a base header including the message type and ahop-


ASAPObject

Extension HopByHopHeader

QoS Option

Flow ID

Previous Hop

extends

extends

extendsext

end

s

contains

contains

Figure 7.6: Serialization Framework

Countfield as described in section 6.2.3. For any additional information the concept ofExtensionis provided. AnExtensionis a container object for additional headers.Headersare either simple objects or containers themselves. This concept refers to the idea of ex-tension headers in IPv6. Up to now only a Hop-by-Hop option header is implemented butusing a routing header might be interesting once too (see section 5.3.3). AHop-by-Hopoption headerincludes aQoS optionobject, aFlowID object and in case of a soft reser-vation message even aPreviousHopobject. In order to construct a signaling message theExtensionobject has to be serialized and copied into the message payload. This is doneby calling thegetContentsmethod of the extension which recursively collects the contentsof all the objects within the container. Upon receiving a signaling message the payloadhas to be deserialized to get theExtensionobject. The container constructor can be usedfor doing this. To retrieve a certain object out of a container thegetObject(int)method iscalled using the object’s ID as a parameter. Therefore callinggetObject(HOPBYHOP)onExtensionreturns theHop-by-Hopoption header. RetrievingQoS optionor FlowID out ofa HopByHopHeaderis in a similar way.

Figure 7.5.3 shows the framework’s class hierarchy.ASAPObjectserves as a base classto all other classes likeExtension, HopByHopHeaderor QoSOption. All the containerfunctionality (addObject(ASAPObject), getObject()) is provided byASAPObject(so everyobject is a potential container then). Subclasses only have to implement their own con-structor and theirgetContentsmethod in order to provide serialization and deserialization.

7.5.4 Reservation Processing

Reservation processing as it is performed in ASAP/ns forces many components to inter-act. The following sections intend to describe these components and their relations briefly.Finally the whole reservation process is illustrated in a data flow manner.

QoS Table

As mentioned in chapter 5 each node holds a QoS table containing entries for all the flowshaving a reservation on that specific node. In ASAP/ns this table is indexed by the so-calledsessionID, which is actually the same as the flowID except that it is a single integer valueinstead of a struct.


An entry for a certain flow provides the following information:

� the amount of soft and hard reservation belonging to the flow

� the address of the previous hop; used by hard reservations to find the reverse path

� a network interface identifier which is of special interest for wired nodes havingseveral links attached

� an expire time being refreshed by any signaling message arriving for that flow.

Periodically a cleanup-timer iterates over a QoS table removing any expired entries. Onthe other hand, whenever a soft reservation message arrives at a node not having an entryfor the particular flow, a new entry is built.

Resource Object

Reservations for a certain flow are performed by modifying the appropriate flow entry ofthe QoS table. If some hard reservation has to be done then even the network interfacequeue must be updated. This is accomplished by calling the setHardRes(int sessionID)method of a special Resource object wrapping the interface queue. The reason for havingsuch a Resource object is to clearly separate the reservation framework from the underlyingqueue that is part of the network stack.

SessionCtrl and AdmissionCtrl

Actually neither QoS tables nor Resource objects are accessed directly. All the operationsmanipulating reservation states are managed by SessionCtrl and AdmissionCtrl objects re-spectively. Mainly these objects provide some kind of permission control, but they alsooffer extended functionality like transforming relative values into absolute ones. Moreoverthe AdmissionCtrl object provides an admitFlow() method to check whether a particularbandwidth allocation can be granted for a given flow or not.

ReservationCtrl

As SessionCtrl and AdmissionCtrl both modify the flow’s soft and hard reservation, callsto these objects have to be synchronized somehow in order keep consistency. It must beguaranteed that upon any reservation change performed on the Resource object the accord-ing flow entry in the QoS table is immediately updated as well. To achieve this, a specialReservationCtrl unit is used, coordinating all the reservations on a certain node.

AdmissionCtrlManager

There is always a one-to-one binding between controller objects (SessionCtrl, AdmissionC-trl) and controlled objects (QoS table, Resource Object). As a node may have more thanone network interface as in the case of a wired node, several Resource objects and thereforethe same number of Admission Controllers are potentially available. In order to managethese objects a special AdmissionCtrlManager object is provided within each QMU. It isresponsible for returning the right Admission controller for a given flow.


ResourceObject

AdmissionCtrl

AdmissionCtrlManager

ReservationCtrl

SessionCtrl

Soft/HardResv

AllocationStrategy Reservation

on Queue

ACU Upcall

ForwardMessage

0

QoS Table

QMU

1

2 3

54

6

7

8

1011

9

Figure 7.7: ASAP/ns Reservation process

Bandwidth Allocation Strategies

As discussed in 3.5.2 there are many possible bandwidth allocation strategies like theGreedystrategy or theFair strategy. The decision which strategy to use may depend on thecertain network condition. ASAP/ns therefore provides a plug-in interface for bandwidthallocation strategies. It is then up to the actual allocation strategy to determine how muchbandwidth to reserve according to a given request.

Get the Big Picture

Figure 7.5.4 illustrates the whole reservation process performed upon receiving a signalingmessage. Comments to the numbers can be found below.

1. TheAdmissionCtrlManageris consulted to get the rightAdmissionCtrlobject for thegiven session.

2. The retrievedAdmissionCtrlobject is passed to theAllocationStrategytogether withthe QoS request specified.

3. In order to compute a reasonable bandwidth proposal with respect to the given re-quest, theAllocationStrategyhas to consulted theAdmissionCtrlto check for avail-able QoS bandwidth.

4. After verifying the bandwidth request proposed by theAllocationStrategy, the re-quest is taken over by the ReservationCtrl controlling the actual reservation process.

5. TheReservationCtrlpasses the request to bothSessionCtrland

6. AdmissionCtrl

7. TheSessionCtrlupdates the particular session entry in theQoSTable.

8. TheAdmissionCtrlperforms the specified bandwidth reservation on a genericRe-source Object

9. TheResource Objectfinally maps the reservation to the underlying Queue


7.6 Adaptation Control Unit

The Adaptation Control Unit (ACU) is logically located above the QMU. Information isexchanged between these two entities using theASAPandAdaptationinterface defined file"common.h".

The ACU is mainly concerned with reacting to QoS changes indicated by monitoring mes-sages. It receives upcalls from the QMU whenever a signaling message arrives for whichthe particular node is an end-point. Potential QoS changes can be classified into two parts:Either a flow gains more end-to-end soft reservation (this may happen if more bandwidthgets available on a bottleneck node) or the actual end-to-end hard reservation for a flowdecreases (caused by bandwidth vibrations in wireless links). Reactions to such changesare performed by a special adaptation strategy object that is supposed to be plugged in bythe application. This reflects the idea of application-defined adaptation policies.

Besides controlling the adaptation

AdaptationControl

Unit

QoSManagement

Unit

AdaptationInterfaceASAP Interface

AdaptationStrategy

process, the ACU provides an in-terface to be called by applications.The interface comprises functions tocreate sessions, starting and stop-ping monitoring or changing the re-fresh period for a given flow. More-over the ACU allows applicationsto install a procedure to be calledwhenever the hard reservation stateof a flow is changed.

The implementation code for theAdaptation Control Unit can be found under ns-2.1b9a/asap/acu/.

7.7 Application QoS Request Unit

The Application QoS Request Unit (AQRU) is part of the real-time application. It is incharge of translating the QoS requirements from the application to the format provided bythe underlying ACU. Furthermore AQRU reacts to ACU upcalls by changing the flow’stransmission rate according to actual end-to-end hard reservation.

As mentioned in the previous section, it is up to the application to decide which adaptationstrategy to use. ASAP/ns only implements one, calledGreedy Adaptation. The GreedyAdaptationstrategy immediately hard reserves any newly gained end-to-end soft reserva-tion for a given flow.

Implementing AQRU has been done in OTcl. The corresponding file is asap-simulation.tcland can be found under ns-src/asap/.

7.8 Some further Components

This section describes some additional components not mentioned in the last three sectionsbut building a not unimportant part of the whole implementation.

7.8.1 Queuing

As shown in figure 7.5.1, actual hard reservations are performed on the network’s interfacequeue. Queues are networks components storing and forwarding packets according to some

7.8 Some further Components 43

Packet enque deque Packet

DataEntry

SignalingEntry

Timer

Figure 7.8: Flow based Queue

well-defined policies. Ns-2 ships with a few built-in queues like FIFO (First In First Out),CBQ (Class based Queue) or DropTail, but it turned out that none of these really satisfiesthe requirements needed by ASAP/ns, which mainly are:

� Flow-based treatment

� Exact Bandwidth warranties

� Detecting Contract Violation

Hence a special queuing system has been developed within this thesis, called Flow basedQueue (FBQ). If a bandwidth reservation is performed on an FBQ, a separate subqueueis created for the given flow. The subqueue is responsible for properly forwarding anypackets belonging to that flow; properly means according to the bandwidth reserved. Abest-effort subqueue is available in every FBQ treating all the packets not belonging to anyreservation.

Queues in ns-2 are objects implementing the built-in queue interface, which basically hastwo methods, that is, a method to enque and one to deque a packet. When a packet is enquedinto an FBQ its flowID is first computed using the IP header’s source address and flow label.If there is some bandwidth reservation available for the particular flow the packet is passedto the appropriate subqueue, otherwise the best-effort queue is used. Packet forwarding insubqueues is triggered by a special timer object. The timer inspects the first packet in thequeue and schedules an event to happen at t = now + packetSize/bw. As the event occurs thepacket is dequeued and placed into the outgoing queue of the FBQ object. This procedureis kept looping. If at some point the subqueue is empty the timer changes to sleeping modeand is first waked up when a new packet is enqued to that particular subqueue.

There is one last issue to be mentioned according to this queuing thing. ASAP as it isdescribed in chapter 5 is an in-band signaling system. In ASAP/ns this behaviour is simu-


lated using some special treatment for soft reservation messages. If such a packet arrivesat an FBQ it is not enqueued into the appropriate subqueue, but stored at a special signal-ing queue within that subqueue. If later on a normal data packet arrives for the particularsubqueue, the data packet is dropped and the previous signaling packet is sent instead.

This Flow based queuing system is well suited to be used in ASAP/ns. It allows for flow-based reservations, provides in-band signaling and guarantees exact bandwidth warranties.Furthermore contract violation is detected in a sense that a flow cannot transmit data fasterthan the subqueue reservation.

7.8.2 Measurements

In order to keep track of several important parameters during simulation, a measurementsystem has been developed. A measurement object including evaluation parameters is cre-ated by the QMU agent on start-up and passed to all the network interface queues of theparticular node. The queues periodically update parameters upon packet reception. On theother hand, the measurement object can be read and reset from the agent at any time.

7.8.3 Logging

ASAP/ns provides a special Logging mechanism, which has been very useful for debug-ging. Every object in ASAP/ns extends the class Loggable that allows to install a specialLogger object. Any log calls (having exactly the same signature as a printf command)within a certain object are redirected to this Logger object. Logger objects can either beturned off or on.

Because a Logger object can be shared among different objects or even nodes logging inASAP/ns can be handled very flexible. Furthermore logging on a group of objects canturned on or off at a certain time in simulation.

7.8.4 Node Interface

One major problem to be tackled during implementation was to let ASAP/ns run on allthe different ns-2 node architectures. This turned out to be rather complex because besidesseparation of wired and wireless nodes the node’s architecture in ns-2 is defined by therouting protocol. A node using DSR has a completely different structure than one usingAODV for example. Hence the approach made in ASAP/ns was to encapsulate all thenode and routing specific details into one class called NodeInterface. This class providesadapters for each node architecture and all the MANET routing protocols, that is, AODV,DSDV, DSR and TORA.

7.9 Conclusion

This chapter described the implementation of the ASAP framework in ns-2, calledASAP/ns. Four major goals to be achieved were outlined at the beginning of the chap-ter: Modularity, Extensibility, Routing Decoupling and Node architecture independence.ASAP/ns meets these demands by using the following concepts: Clear separation of thethree building blocks (QMU, ACU and AQRU), a container-based messaging frameworkand node encapsulation together with an AdmissionCtrl manager.

Chapter 8

Simulation and Analysis

8.1 Overview

This chapter describes the evaluation of the ASAP framework using the ns-2 implementa-tion ASAP/ns presented in the last chapter. The chapter is organized as follows: Primarilythe generic simulation framework is outlined. The second part discusses the actual evalu-ation and is splitted among the several test scenarios. Each scenario is described by firstexplaining the simulation setup and analysing the result data afterwards.

Like in the previous chapter, all file system references mentioned have to be understood asrelative to the actual ns-2 installation directory.

8.2 Simulation Framework

To unify the various simulations later on, some kind API has been created including severalflow object and a some measurement procedures.

8.2.1 Flow Objects

Three different flow objects are defined:

� BEFlow

� ASAPFlow

� MonoFlow

A BEFlow object represents a best-effort Flow. Transmission rate, source and destinationnode have to be specified upon creation of such an object. Best-effort flows produce EX-POO traffic with an average packet size of 500 bytes. EXPOO traffic means packets aresent at a fixed rate duringOn periods, and no packets are sent duringOff periods. BothOn andOff periods are taken from an exponential distribution with means of 1s and 0.5seconds respectively.

An ASAPFlow behaves differently. It needs source node, destination node, minimum andmaximum bandwidth to be specified. Min and Max values are defined as described insection 5.2.2. Upon creation, an ASAPFlow triggers a QoS setup procedure using theinterface provided by the node’s ACU 7.6. After receiving an upcall indicating that the

46 Chapter 8. Simulation and Analysis

reservation is properly set up the flow object starts a CBR traffic with a transmission ratecorresponding to the bandwidth reserved. The packet size is fixed to be 125 bytes.

MonoFlow’s are similar to ASAPFlow’s, but they provide a separate treatment of reser-vation setup and packet transmission. This allows the flow to be started without any QoSsupport first and to start and stop bandwidth reservation periodically later on.

8.2.2 Measurements

A record function is provided retrieving and cleaning the measurement 7.8.2 values con-stantly every 1s. The values are both written to files to allow for over-time analysis andcumulated to enable comparisons between different simulations later on. The followingmeasurement values are used throughout the simulations:

� Thetotal throughput

� � ��

� � ��

measured on a certain node�. �� is the total amount of traffic received (in Bytes) at anode� and� denotes the interval during which the measurement has been done.

� Thedegraded throughput

� ��

��

� � ��

defined as the part of throughput on a node� that is caused by QoS traffic not havingany reservation on the certain node.� �� is the amount of QoS data which has beensent using best-effort treatement and� is the measurement interval.

� The fraction of all packets belonging to some ASAPFlow but beeing treated as best-effort, which is defined as

��

��

��

��

where�� is the number of QoS packets treated as best-effort on node� and� �� refers

to the number of real-time packets sent on node�.

� The ratio of QoS packets dropped:

��

��

��

��

�� denotes the QoS packets which are dropped at node� and� �� refers to the number

of real-time packets sent on node�.

� The total QoS packets violating ’Guaranteed QoS’:

� � ��

� The actualover-reservationdefined to be as

��

��

��

��

��

where� refers to the amount of bandwidth hard reserved on a node�, � �� is total

number of bytes according to QoS packets received at a node i and� is the timeinterval where the measurement has been done

8.3 Evaluation 47

� The actualover-reservation including soft reservationwhich is defined as

��

��

��

��

��

where� and� refer to hard and soft reservation on a node�, � �� is total number of

bytes according to QoS packets received at a node i and� is the time interval wherethe measurement has been done.

8.2.3 A Remark in Advance

Readers of the following section will notice that the flow transmission rates used duringsimulations are mostly quite slow compared to what is usual for real-time flows. This hasbeen done to isolate the different reasons for which packets might be dropped. In order tosimplify post-analysis of simulation experiments, QoS degradation should not be causedby wireless link interferences or packet collisions.

8.3 Evaluation

The goal of the evaluation is on the one hand to prove for certain special situations thatASAP/ns functions properly. On the other hand the evaluation intends to show the perfor-mance and efficiency of some of the concepts used in ASAP/ns like local repair, adaptationor soft reservation.

8.3.1 Local Repair

In the following experiment the impact of rerouting on

3

1

0

2

NodeMobility

4

NodeMobility

QoS flows is investigated. Rerouting involves local re-pair to restore the actual reservation state. A key chal-lenge for restoration is the speed at which flows can berestored. This is dependant on the speed at which newroutes can be computed by the routing protocol if no al-ternative routes are cached and the speed at which thesignaling system can restore reservations.

The simulation scenario consists of 5 nodes arrangedas illustrated in the figure beside. Two flows are beingsent: ABEFlowwith a sending rate of 64K from node0 to node 4 and anASAPFlowfrom node 1 to node 4 having a transmission range of[16K,32K]. The monitoring refresh rate used is 2s, the soft state timeout is fixed to be 16s.

In order to induce rerouting the following movement events are triggered:

� at 20s: Node 3 starts moving towards node 2

� at 27s: Node 2 starts moving upwards, leaving node 1’s transmission range at 30s.

� at 50s: Node 3 moves back to its origin

� at 80s: Node 3 starts moving upwards again

These events cause both flows to be rerouted twice: Once at 30s where node 2 is finallygetting out of range and once after node 3 is moving in for the second time, this happens at


0

50

100

150

200

250

1 51 101

QoS Traffic

Best-effort Traffic

QoS Traffic treatedas Best-effort

Thro

ugh

put

Time

Figure 8.1: Localrepair

about 85s. The period for which the link between node 1 and 3 remains broken is chosento be around 20s to let the reservation on node 3 timeout.

The measured values during simulation arethroughput� � anddegraded throughput� �� .

� �� indicates the local repair performance on node 2. This is reasonable because within

a queue packets are treated as best effort if, and only if, there is no reservation for theparticular flow (in contrast to contract violation where packets arrive at the queue fasterthan their according flow reservation and therefore are dropped).

Figure 8.3.1 shows the simulation results. No throughput degradation can be noticed dur-ing the first rerouting event at 30s. This is because the new route (from node 1 to node3) has been cached (or has already been computed because node 3 moved into node 1’stransmission range a while ago) and the available best-effort bandwidth was big enoughto support the real-time flow for the short period of no-reservation (indicated by the redline). On the second rerouting event the throughput of the ASAPFlow is affected becausea short burst of be-effort traffic consumes lot of bandwidth. But after the reservation is re-established, the flow runs with its original rate of 64K again. The burst mentioned beforehappens because BEFlow-packets are stored within the queue during broken-link periodand sent immediately when the new route is established.

8.3.2 Adaptation

During the following experiment the adaptation mechanism of ASAP is investigated. Thekey point to figure out is how fast ASAP is able to react to bandwidth vibrations, but alsothe prove the correctness of the implementation in a sense that bandwidth vibrations onlyaffect QoS flows if best-effort is already degraded significantly.

As mentioned in chapter 7 it is due to the application to choose an appropriate adaptationstrategy. The adaptation strategy used during the following simulations is theGreedyStrat-egymentioned in chapter 3.

The scenario chosen consists of 3 nodes arranged in s straight line. Two flows are be-ing sent, both originating at node 0 and destined to node 2. The ASAPFlow runs with atransmission range of [32K,64K] while the BEFlow is sending with a rate of 128K. Duringsimulation the link bandwidth of node 1 is manipulated. There’s a maximum fraction oflink bandwidth to be used by QoS traffic, this value is fixed to be 0.7.

8.3 Evaluation 49

Best-Effort Traffic Received

Link Bandwidth

QoS Traffic Sent

QoS Traffic Received

Thro

ugh

put

Time

0

50

100

150

200

250

1 51 101 151 201 251 301 351 401

Refresh Period =16

Refresh Period = 4

Thr

ough

put

Time

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

1 51 101 151 201 251 301 351 401 451

Figure 8.2: Adaptation and Refresh Period

In order to examine the correlation of adaptation performance and refresh rate, the experi-ment has been done twice with a refresh period of 4s and 16s respectively. The measuredvalues are throughputs�� and�� reflecting the effect of link vibration and adaptation re-spectively.

Figure 8.3.2a shows the simulation result using a refresh rate of 4 seconds. The first thing toobserve is that link vibrations above 91K (�� ) do not affect the ASAPFlow, thisproves the correct behaviour of bandwidth reservations in ASAP/ns. Second the adaptationof the flow is quite agile to the link bandwidth changing. The latency between sent andreceived traffic adaptation is caused by the agility of the ASAP protocol, which is stronglyrelated to the refresh interval by which soft reservation messages are sent (shown in Figure8.3.2b.

8.3.3 QoS Performance

This simulation is to show the QoS performance under different mobility conditions, thatis, from 10 km/h to 100 km/h. The scenario consists of 20 nodes moving randomly withina 600m x 600m area with the specified maximum speed. 12 ASAPFlow’s are generated by12 different sender nodes and randomly selected receivers, all running with a transmissionrate of 16k. Furthermore 5 BEFlow are generated introducing background traffic. The soft


0

2

4

6

8

10

12

10 20 30 40 50 60 70 80 90 100

QoS Packets treatedas best-effort

QoS Packet Dropped

QoS Degredation

Ratio

[%

]

Velocity [km/h]

Figure 8.3: QoS Performance

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

44 36 30 26 22 18 14 10 8 6 4 2

ASAP 100 km/h

ASAP 10 km/h

Others 10 km/h

Others 100 km/h

Ove

r-Re

serv

atio

n

Timeout [Seconds]

Figure 8.4: Overreservation

reservation interval is fixed to be 1 second.

The measured values during simulation areQoS Degradation�, the fraction� � of QoSpackets treated as best effort and��, the QoS packets dropped.

The simulation result is shown in figure 8.3.3. As the flow bandwidth is quite small com-paring to the 2Mbps wireless link throughput, the amount of QoS packets dropped is withina small percentage regardless of node mobility. But packets, which are treated as best effortscale up along with increasing mobility. This is because the high movement speed leads tofrequent path changes what makes it very difficult for ASAP to restore reservation states.

8.3.4 Reservation Efficiency

In order to show the reservation efficiency during a simulation the value of� �� used. The

measured value indicates how much extra bandwidth is reserved than consumed by QoStraffic, for example if��

� � � this means only the half of all the bandwidth reservedfor real-time flows is actually used. One major difference of ASAP compared to otherresource reservation protocols is its hard/soft reservation concept. While hard reservationsbelong to a certain flow and cannot be shared, the soft reserved part is still available to all

8.4 Conclusion 51

Ra

tio [

%]

Soft Reservation Interval

0

0.05

0.1

0.15

0.2

0.25

0.3

0.35

1 2 4 8 16

ASAP Signaling

QoS Degredation

Figure 8.5: Signaling Overhead

other flows. The measured value�� indicates the bandwidth waste in absence of such a

concept. This is especially interesting when comparing ASAP to INSIGNIA for examplewhere over-reservation is a major shortcoming.

The result in figure 8.3.4 states that reservation efficiency is correlated to the speed ofmobility and the timeout period of the reservation state. If routes change frequently duehigh mobility, reservations are propagated in the network but rarely used, this increasesthe wasted bandwidth. The result also shows the advantage of the soft/hard reservationconcept. Comparing to other signaling protocols not having such a mechanism, ASAP’stotal reservation is less, illustrated by the two pairs of parallel curves in figure 8.3.4.

8.3.5 Signaling Overhead

During this simulation experiment the relation of signaling overhead and QoS Degradationis investigated. The result shown in figure 8.3.5 proves what is to be expected. Obviouslythe interval of sending soft reservation messages directly affects signaling overhead, agilityof ASAP and QoS traffic. The smaller the interval is, the more signaling overhead isbrought to network, and the corresponding processing load increases. On the other hand,a small soft reservation keeps ASAP agile to routing changes and QoS vibrations, andminimizes QOS degradation, as illustrated in Figure 8.3.5.

As mentioned in the previous chapter it is up to the AQRU unit to determine the soft reser-vation interval. This is a great benefit and allows for adaptively changing the soft reserva-tion interval corresponding to the various network conditions.

8.4 Conclusion

The simulation result described in the previous sections basically lead to the followingconclusions:

� The adaptation behaviour of ASAP is quite promising but depends on the intervalby which soft reservation messages are sent. But as the soft reservation intervalis determined by the application it can be changed adaptively to changing networkconditions.

� Frequent route changing caused by fast node movement affects the QoS performancein a sense that the amount of degraded QoS traffic increases if the topology changesmore frequently.


� Reservation efficiency is correlated to the speed of mobility and the timeout periodof the reservation state.

� The soft/hard reservation concept introduced by ASAP reduces bandwidth waste sig-nificantly.

� There is a trade-off between signaling overhead and adaptation agility.

Chapter 9

Summary and Outlook

9.1 Summary

Within this thesis the challenge of bringing QoS support to mobile ad hoc networks hasbeen addressed.

After having investigated some of the existing QoS models and protocols like RSVP, IN-SIGNIA or FQMM it turned out that none of these technologies are able to meet the de-mands of QoS in MANETs. Therefore a new QoS framework referred to as ASAP has beenproposed in this thesis and further extended based on some well-defined design criterions.The framework includes a QoS signaling protocol and flexible allocation and adaptationmechanisms. In order to prove the framework’s correctness and efficiency it has been im-plemented and simulated using the ns-2 network simulator.

The results gained during the simulation experiments were quite promising. It has shownthat the feature to dynamically change the soft reservation interval and the concept ofsoft/hard reservation are the major benefits of ASAP.

However, the network’s highly dynamic characteristics make it very difficult to maintainQoS support. In order to achieve good QoS performance and adaptation agility, frequentnetwork monitoring using soft reservation messages is needed, but this increases signalingoverhead and processing load.

The simulations done during this thesis can only roughly reflect the behaviour of ASAP un-der certain scenarios. To see how ASAP performs in the "real world" it would be necessaryto implement it in a real operating system.

9.2 Future Work

There remains some future work to be done. A few ideas are listed below:

� Many simulation variants have not been examined yet, like for example the use ofdifferent adaptation or allocation strategies.

� Running simulations in heterogeneous networks using MobileIP would be very in-teresting.

� Implementing ASAP within a Linux or Windows operating system would show ifthe simulation results could be mapped to the real world.

� Enabling ASAP to support multicast could be a possible future work.

54 Chapter 9. Summary and Outlook

Acknowledgement

I would like to conclude with extending my gratitude to Prof. G. Alonso, his reserach groupand especially my assistant Jianbo Xue who offered this interesting thesis and supportedme whenever I needed advice.

I also thank my friends and all the fellows sufferers in HRS G9 who made working verycomfortable.

56 Chapter 9. Summary and Outlook

Bibliography

[1] imaq: An integrated mobile ad hoc qos framework. http://cairo.cs.uiuc.edu/adhoc/.

[2] Ip qos support in the internet backbone. Technical report, Alcatel.

[3] The network simulator ns-2. http://www.isi.edu/nsnam/ns/.

[4] Andreas Kassler, Teodora Guenkova-Luy, Davide Mandator, Peter Schoo. Enablingmobile heterogeneous networking environments with end-to-end user perceived qos.Technical report. IST project IST-2000-28584 MIND.

[5] D. Black. Differentiated services and tunnels, 2000. RFC2983.

[6] R. Braden. Resource reservation protocol - version 1 message processing rules,1997. RFC2209.

[7] R. Braden, D. Clark, and S. Shenker. Integrated services in the Internet architecture:an overview. Technical Report 1633, 1994.

[8] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin. Resource reservationprotocol (rsvp) - version 1 functional specification. RFC2205.

[9] A. Conta. A proposal for the ipv6 flow label specificatoin, 2001.www.ietf.org/proceedings/02mar/I-D/draft-ietf-ipv6-flow-label-00.txt.

[10] Zeinalipour-Yazti Demetrios. A glance at quality of services in mobile ad hocnetworks. 2001. Seminar in Mobile Ad Hoc Networks.

[11] Dinesh Dharmaraju, Ayan Roy-Chowdhury, Pedram Hovareshti, John S. Baras.Inora - a unified signaling and routing mechanisms for qos support in mobile ad hocnetworks. 2002. Proceedings of the International Conference on Parallel ProcessingWorkshops.

[12] Kurt Geihs. Analysis of adaptation strategies for mobile qos-aware applictions.2002. Workshop on Modelling Analysis and Simulation of Wireless and MobileSystems.

[13] Marc Greis. Rsvp/ns: An implementation of rsvp for the network simulator ns-2.

[14] Kee Chaing Chua Hannan Xiao and Winston K.G Seah. A quality of service modelfor ad hoc wireless networks.www.ece-icr.nus.edu.sg/journal1/fqmmhandbook02.pdf.

[15] Alberto López, Jukka Manner, Andrej Mihailovic, Hector Velayos, EleanorHepworth, and Youssef Khouaja. A study on qos provision for ip-based radio accessnetworks, 1999. IST project IST-1999-10050 BRAIN.

58 BIBLIOGRAPHY

[16] N. Schult M. Mirhakkak and D. Thomson. A new approach for providing quality ofservice in dynamic network environment.http://www.mitre.org/support/papers/tech_papers99_00/thomson_mp_dynamic/thomson_dynamic.pdf.

[17] Jukka Manner, Alberto Lopez, Andrej Mihailovic, Hector Velayos, EleanorHepworth, and Youssef Khouaja. Evaluation of mobility and qos interaction.

[18] Bongkyo Moon and Hamid Aghvami. Rsvp extensions for real-time services inwireless mobile networks.IEEE Communication Magazine, 2001.

[19] Robert Braden, Deborah Estrin, Steven Berson, Shai Herzog and Daniel Zappala.The design of the rsvp protocol.

[20] R. Hinden S. Deering. Internet protocol, version 6 specification, 1995. RFC1883.

[21] Xiaowei Zhang Seoung-Bum Lee, Gahn-Seop Ahn and Andrew T. Campbell.Evaluation of the insignia signaling system.

[22] Xiaowei Zhang Seoung-Bum Lee, Gahn-Seop Ahn and Andrew T. Campbell.Insignia: An ip-based quality of service framework for mobile ad hoc networks.1999.

[23] Brooke Shrader. A proposed definition of ’ad hoc network’, 2002.

[24] Anup Kumar Talukdar, B. R. Badrinath, and Arup Acharya. MRSVP: A resourcereservation protocol for an integrated services network with mobile hosts.WirelessNetworks, 7(1):5–19, 2001.

[25] Paul P. White. Rsvp and integrated services: a tutorial. 1997.

[26] Kui Wu and Janelle Harms. Qos support in mobile ad hoc networks.

[27] Jianbo Xue. Adaptive qos-supporting architecture for real-time application inwireless ip network. Master’s thesis, 2002. www.inf.ethz.ch/personal/jxue/.

Date post:	15-Nov-2014
Category:	Documents
Upload:	rahulmahale84
View:	130 times
Download:	1 times

Quality of Service Manet-Thesis

Documents