Escolar Documentos
Profissional Documentos
Cultura Documentos
March 2003
ii
Abstract
The fast adaptation of IP-based communications for mobile and hand-held devices
equipped 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) where
every node moves arbitrarily causing the multi-hop network topology to change randomly
and at unpredictable times.
In this thesis a new framework coping with the specific issues of MANETs is proposed. The
framework includes a QoS signaling protocol and flexible resource allocation and adapta-
tion mechanisms. In order to prove its efficiency the system is implemented and simulated
using 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
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
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
9.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
9.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Bibliography 56
Chapter 1
Introduction
The introduction of real-time audio, video and data services into wireless networks presents
a number of technical obstacles to overcome. Traditional internet QoS protocols like RSVP
cannot be easily migrated to the wireless environment due to the error-prone nature of
wireless links and the high mobility of mobile devices. This is specially true for Mobile
Ad Hoc Networks (MANETs) where every node moves arbitrarily causing the multi-hop
network topology to change randomly and at unpredictable times.
In this thesis an existing QoS framework is extended to be suitable for MANETs. In order
to prove its correctness and efficiency the system is implemented and simulated using the
ns-2 network simulator.
A mobile ad hoc network is a concept that has received attention in scientific research since
the 1970s. A clear picture of what exactly is meant by an ad hoc network is difficult to
pinpoint. 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 and
organize themselves arbitrarily; thus, the network’s wireless topology may change rapidly
and 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 and
disaster recovery areas are further examples of application environments.
With the evolution of Multimedia Technology, Quality of Service in MANETs became an
area 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 limited
resources of such networks.
2 Chapter 1. Introduction
QoS models specify an architecture in which some kinds of services could be pro-
vided. It is the system goal that has to be implemented.
QoS Adaptation hides all environment-related features from awareness of the
multimedia-application above and provides an interface for applications to interact
with QoS control.
Above the network layer QoS signaling acts as a control center in QoS support. The
functionality of QoS signaling is determined by the QoS model.
QoS routing is part of the network layer and searches for a path with enough re-
sources but does not reserve resources.
QoS MAC protocols are essential components in QoS for MANETs. QoS supporting
components 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, supports
reliable communication, and provides resource reservation.
This document does not treat QoS MAC and QoS routing any further and instead focuses
on 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 focuses
on some existing approaches classifying each one according to the design issues identified
in chapter 3. ASAP is a QoS framework developed at the University of Stuttgart and was
originally 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 are
discussed in chapter 6, 7 and 8. Finally this document concludes with a summary and gives
an outlook on potential further work.
Chapter 2
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 to
propagate the attributes of the data flow and to request resources along the path. Routers
finally apply corresponding resource management schemes to support QoS specifications
of the connection. Based on these mechanisms, IntServ provides quantitative QoS for every
flow.
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 the
philosophy of mapping multiple flows into a few service levels. At the boundary of the
network, 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 packet
header (TOS field in IPv4 or CLASS field in IPv6). Within the core of the network, packets
are 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 information
elsewhere in the network.
4 Chapter 2. QoS Models for MANETs
Dynamic topologies: Nodes are free to move arbitrarily; thus, the network topology
- which is typically multihop - may change randomly and rapidly at unpredictable
times, and may consist of both bidirectional and unidirectional links.
Bandwidth-constrained, variable capacity links: Wireless links will continue to have
significantly lower capacity than their hardwired counterparts. In addition, the re-
alized throughput of wireless communications - after accounting for the effects of
multiple access, fading, noise, and interference conditions, etc.- is often much less
than 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 will
likely 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 will
demand similar services. These demands will continue to increase as multimedia
computing and collaborative networking applications rise.
Energy-constrained operation: Some or all of the nodes in a MANET may rely on
batteries or other exhaustible means for their energy. For these nodes, the most
important system design criteria for optimization may be energy conservation.
DiffServ in MANETS
Soft QoS guarantees: DiffServ uses a relative-priority scheme to map the quality of
service requirements to a service level. This aggregation results in a more scalable
but also in more approximate service to user flow.
SLA (Service Level Agreement): DiffServ is based on the concept of SLA’s. In the
Internet an SLA is a kind of contract between a customer and its Internet Service
Provider (ISP) that specifies the forwarding service the customer should receive. The
Administration of a DiffServ domain must assure that sufficient resources are provi-
sioned to support the SLA’s committed by the domain [2]. Moreover, the DiffServ
boundary nodes are required to monitor the arriving traffic for each service class and
to 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 a
completely ad hoc topology where there is no concept of service provider and client
and where there are only clients it would be quite difficult to innovate QoS, since
there is no obligation from somebody to somebody else what makes QoS almost
infeasible.
Ambiguous core network: The benefit of DiffServ is that traffic classification and
conditioning only has to be done at the boundary nodes[26]. This makes quality of
service provisioning much easier in the core of the network. In MANETs though
there 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 the
IntServ 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 between
scalability and level of QoS performance assurance. Neither a pure IntServ nor a pure
DiffServ model is suitable for Ad Hoc Networks. In order to make use of advantages
of both models and avoid the disadvantages, a combination of DiffServ and IntServ as
described in section 2.1.3 could be an interesting approach.
6 Chapter 2. QoS Models for MANETs
Chapter 3
link error rate, let’s say by including the use of au- Network
tomatic repeat-request technique. QoS-Routing and QoS Routing
Layer
QoS-Signaling operate at the network layer in or-
der to search for routes with sufficient resources Link
Layer QoS MAC
or to allocate and release bandwidth respectively.
Finally, QoS-adaptation hides all the environment-
related features from the awareness of multimedia
applications. 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, according
to these requirements. This document does not treat MAC layer or physical layer issues any
further, but instead concentrates on the issue of end-to-end QoS control over IP, meaning
QoS-Signaling in particular.
The de-coupled option 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 routing
protocol. Changes in the network topology have to be handled by actively monitoring the
network (for example by sending periodic monitoring messages).
In a loosely coupled approach QoS-Signaling and routing interact with each other. Inter-
action can be understood as bi-directional. Some routing protocols allow upper layers for
installation 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 reservation
for a flow rerouted. On the other hand QoS-Signaling could provide feedback information
to the routing layer regarding the route chosen and ask the routing protocol for alternate
routes if the route provided doesn’t satisfy the QoS requirements. Another example is to
let signaling query the forwarding table directly. Pre-allocation would be an appliance for
such an approach. Despite of these benefits any kind of interaction between QoS-signaling
and routing may lead to a solution which is dependant on the specific routing protocol. This
shortcoming can be minimized by designing a generic interface to access the routing layer
and to develop adapters for a concrete routing protocol implementing this interface.
In a closely coupled approach, the same signaling mechanism is used to propagate the rout-
ing and QoS information, what mostly refers a unique QoS-routing protocol. QoS-routing
tries 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 very
fast flow restoration but also has some major drawbacks. First the solution is dependent on
the routing protocol used. This is currently not suitable because routing in MANETs still
underlies heavy research and there is no ’one’ routing protocol to be used in future. Second
the route computation with this strategy may take too long[4] or be too complex. The next
few sections discuss QoS-Signaling as well as different strategies for bandwidth allocation
and adaptation.
QoS-Signaling is used to reserve and release resources, set up, tear down, and renegotiate
flows 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 carried
along with data and how the flow path is established.
The term ’in-band signaling’ refers to the fact that any control information is piggybacked
into 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 data
path, 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 can
be characterized as ’heavyweight’ because extra information is carried in the network and
consumes more network bandwidth. Moreover in out-of-band signaling systems, signaling
packets 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. The
benefit of this approach is that it is more scalable since the control messages don’t rely
on the transmission of data packets. Furthermore the supported services can be rich and
powerful.
3.4 QoS-Signaling: Design Issues 9
using a route over node C. It is assumed that accurate quality of service is already provided
along this path. Now at a certain time node C starts moving and finally gets out of node
A’s transmission range, routing then finds a new path from A to D over node B. Local
Repair is now in charge to detect the route change and to restore the best possible quality of
service on the new path as well as to delete the old reservation. The goal is to re-establish
reservation 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 given
flow 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 movement
tracking or transmission quality measurements, or by excessive resource allocation. In
the latter case signaling just reserves resources on every possible path, eventually through
inspecting the routing forwarding table. Both strategies do have the shortcoming that they
potentially 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 to
react to route changes as fast as possible. The easiest way to achieve this goal is to be
triggered by the routing layer whenever a route changes. Another possible solution is to
detect route changes for a certain flow by periodically sending monitoring messages. It is
assumed that the performance of such an approach hardly depends on the interval by which
monitoring messages are sent.
a binary "admit/fail" decision for each flow. Applications request QoS by specifying the
minimum level of service they are willing to accept and the maximum level of service
they are able to utilize, and then adapt to the specified point within this range that the
network commits to provide, which may change with time. Changes in allocation have to
be 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.
Greedy Strategy
The Greedy adaptation strategy is the simplest possible. Regardless of any end-to-end
information every node tries to allocate the bandwidth requested. Suppose a scenario with
4 nodes A, B, C and D with the corresponding bandwidth resources of 200K, 300K, 200K
and 300K. Furthermore assume a bandwidth request for the path A, B, C, D of within a
range of 200K minimum and 300K maximum, also written as [200K,300K]. Using a greedy
adaptation strategy node B allocates 300K although node A is only able to grant 200K of
bandwidth. Nodes C and D act the same. If for some reason the available bandwidth on
node C increases, according to the greedy adaptation strategy node C immediately allocates
additional 100K to have 300K reserved in total. This is done even though node A still is
a bottleneck and the end-to-end bandwidth still is 200K. The idea is that it might be quite
hard to reach maximum reservation in one pass, so bandwidth is increased stepwise. Maybe
at some point node A as well gains further 100K of bandwidth and the whole end-to-end
reservation will be 300K which finally can be adapted by the application.
In a bottleneck driven strategy each node would only try to allocate as much bandwidth
as has been allocated already by previous hops for a certain flow, except the first node
in the path of course which always tries to allocate maximum bandwidth. This avoids
temporarily 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 reserve
200K of bandwidth in a first step, which is the same as the end-to-end bandwidth for this
flow. But imagine the available bandwidth of node A and B would toggle between 200K
and 300K. If they never reach 300K at the same time end-to-end bandwidth will never be
increased.
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 strategy
attempts 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 fraction
which is proportional to the requested bandwidth range. Suppose a scenario of a few nodes
where each of them provides 300K of bandwidth. Assume a QoS request for a range of
150K 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 the
same path or just a part of it, not even the minimum bandwidth could be granted. In case
12 Chapter 3. Protocol Design Issues
of a fair strategy the first flow would be adjusted to run with its minimum of 150K, what
would allow the second flow to run with its minimum as well. The remaining bandwidth
of 50K (300 - 150 - 100) could be shared between both flows according to their bandwidth
range, which would result in a final reservation of 190K for the first flow and 110K for the
second.
The major drawback of a fair adaptation strategy is its signaling overhead due to adjusting
active flows. However it would be interesting to test such an approach within a simulation
environment.
3.6 Conclusion
During this chapter several design issues concerning QoS-Signaling and QoS-adaptation
were discussed in more detail. These concepts are not distinct from each other, often they
can be combined. As in the example of soft state and hard state, one could use explicit
reservation release messages in a soft-state based framework even though it is a hard-state
concept. However these concepts should facilitate classifying existing technologies as it is
done 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 IP
networks 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 router
states 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 are
the Path message, which originates from the traffic sender, and the Resv message[6], which
originates from the traffic receivers. The primary roles of the Path message are first to
install reverse routing state in each router along the path, and second to provide receivers
with information about the characteristics of the sender traffic and end-to-end path so that
they can make appropriate reservation requests. Resv messages finally carry reservation
requests to the routers along the distribution tree between receivers and senders. RSVP state
is "soft-state", after a certain expire time, the state of the path and the reserved resource is
released. Periodical issuing of Path or Resv messages are necessary to keep the reservation
alive. Additional signaling information allows the soft state timeout to adapt to the refresh
period. Furthermore RSVP provides a routing triggered local repair [8] mechanism to
overcome 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 for
a fast adaptation to QoS changes can be provided. To solve this problem reservation
requests 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 is
not 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 to
fail.
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 and
processing overhead. Although the scalability problem may not be likely to happen
in current MANETs due to the limited size of the network and the bandwidth of
wireless links, one could argue that it will occur with the development of fast radio
technology and potential large number of users in the near future.
Forced by the shortcomings of RSVP in Wireless networks, some approaches were made
to enhance the signaling protocol[18]. Most of them intend to solve micro-mobility issues
in infrastructure based wireless networks and do not address MANET problems directly.
However MRSVP and DRSVP, two extension of RSVP to support mobility and dynamic
network environments, try to overcome some of the disadvantages of RSVP mentioned
above and are discussed in the following sections.
MRSVP
MRSVP[24] addresses mobility issues of a mobile node changing the point of attachment
to the fixed network and follows a Pro-Active approach as discussed in section 3.4.4. Two
types 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 allowed
to use the reserved resource. Passive reservation is different, it makes resource reservation
in advance before the flow uses it. These passive resources are open to any other traffic
until the flow actually needs the reservation. In order to make reservations in advance, it
is necessary to specify the set of locations the mobile host may visit in future. The mobile
node 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 particular
point of attachment, the path to that attachment becomes active and the path to the previous
one passive, so that the data can still be delivered effectively.
Even though MRSVP ensures good QoS provision in case of route change it suffers from
many drawbacks when used in ad hoc networks.
MRSVP is designed for mobile wireless access networks not for MANETs. The
concept of a mobile node and attachment points is not given in ad hoc networks
where every node is a mobile having many attachment points. Adapting MRSVP to
MANETs 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 available
for other requests it requires the nodes to maintain a lot of state information regarding
active and passive reservations.
It may be very difficult to accurately determine the set of nodes to which a certain
flow eventually is routed.
Like RSVP it does not support any QoS adaptation, relying on the reservation in the
initial 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 path
to all the possible neighbours. This causes a huge overhead and makes the approach
almost unusable.
4.2 FQMM 15
DRSVP
4.2 FQMM
FQMM[14] (Flexible Quality of Service Model for Mobile Ad Hoc Networks) combines
the IntServ and the DiffServ model discussed in the first chapter. Three kinds of nodes are
defined, exactly as in DiffServ. An ingress node is a mobile node that sends data. Interior
nodes 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 the
service differentiation of DiffServ. This is achieved by preserving per-flow granularity for
a small portion of traffic in the MANET, given that a large amount of the traffic belongs
to per aggregate of flows, that is, per-class granularity. A traffic conditioner is placed at
the ingress nodes where the traffic originates. It is responsible for re-marking or discarding
packets according to the traffic profile, which describes the temporal properties of the traffic
stream such as transmission rate and burst size.
FQMM is an interesting attempt at proposing a QoS model for MANETs, however it suffers
of major problems:
FQQM aims to tackle the scalability problem of IntServ. But without an explicit
control 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 satisfy
hard QoS requirements[26]. It could be difficult to code the PHB in the DS field
if the PHB includes per-flow granularity, considering the DS field is at most 8 bits
without extension.
4.3 INSIGNIA
INSIGNIA[22][21] is a signaling protocol designed explicitly for MANETs. It supports
fast flow reservation, restoration and adaptation algorithms that are specifically designed to
deliver 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 is
now called INSIGNIA option. Furthermore flow state information is kept in every node of
16 Chapter 4. Existing Technologies
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 to
INSIGNIA IP option.
INSIGNIA offers a one-pass reservation (3.4.2). When a source node wants to establish a
reservation to a destination node it sets the reservation (RES) mode bit in the INSIGNIA IP
option 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 are
committed and subsequent packets are scheduled accordingly. In contrast, if the reservation
is denied, packets are treated as best effort (BE) mode packets.
In the case where a RES packet is received and no resources have been allocated, the
admission controller attempts to make a new reservation. This is a re-active local repair
mechanism (3.4.4) and commonly occurs when flows are rerouted during the lifetime of an
ongoing 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 indicator
bit set to MAX indicates that all nodes encountered have sufficient resource to support the
maximum 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 a
bottleneck node and the maximum bandwidth requirement may not be met.
When a reservation is received at the destination node, INSIGNIA checks the reservation
establishment status. The status is determined by inspecting the IP option field service
mode, which should be set to RES. If the bandwidth indication is set to MAX, this implies
that all nodes between a source-destination pair have successfully allocated resources to
meet the QoS requirements of the source node. In contrast if the bandwidth indication is
set to MIN this indicates that only the minimum bandwidth can be currently supported. As a
result "partial reservations" will exist between source and bottleneck node, these resources
remain 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. The
INSIGNIA system supports two QoS report commands in order to provide some kind of
adaptation. A scale-down command requests a source either to send with the rate speci-
fied as MINIMUM instead of MAXIMUM or to send its packets as best effort instead of
MINIMUM depending on the current sending rate of the source node. This will have the
effect of clearing any partial reservation. A scale up requests a source node to initiate a
reservation 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
Max. Reserved
Min. Reserved
INSIGNIA’s bandwidth usage is not efficient. The extra reservation on the path from
the sending node to the bottleneck is a waste of bandwidth until an explicit release
message is sent. Although this waste won’t last long, topology changing of MANET
will make this reservation waste propagate frequently. Furthermore releasing partial
reservations using QoS reports enforces source nodes either to set the bandwidth
indicator of the INSIGNIA option field to MINIMUM or to send the packets as best
effort depending on the actual flow state. In both cases the opportunity to scale up is
lost.
INSIGNIA does not provide any mechanism to dynamically change the frequency
by which control signals are inserted into the data packets. This imposes a major
processing overhead on the network.
Only two bandwidth levels to be used are offered, MINIMUM and MAXIMUM. A
more fine-grained approach would be needed in order to satisfy application require-
ments and to fully exploit the resources available.
4.4.1 iMAQ
iMAQ[1] is a cross-layer architecture to support the transmission of multimedia data over a
MANET. They use a location-based pro-active QoS-Routing. Neither hard QoS guarantees
can 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 considered
any 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 TORA
to provide multiple routes between a given source and destination. While INSIGNIA does
18 Chapter 4. Existing Technologies
not take any help from the network with regard to redirecting the flow along routes which
are 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 QoS
requirements of the flow.
Beyond doubt the concept of ’loosely coupling’ QoS-signaling and routing is a very
promising 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 as
possible in order to guarantee portability.
Chapter 5
ASAP Framework
5.1 Concepts
Flow ID
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 provide
in-band signaling will be described section 5.3. What follows is a brief explanation of each
field shown in figure 5.2.2.
Message Type Indicator: The reservation indication (RI) field specifies the actual
message 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
H ardR eservation Ms g
SetBW ActualBW
Src Address
RI QoS Option Flow ID Option
Flow Label
types are defined: NON means the packet is normal data, SOFTRES and HARDRES
correspond 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.
SoftReservation Message
An SR message sets the RI field to SOFTRES and defines the QoS Option to be as shown
in figure 5.2.2. Three fields are provided within the QoS option: MinBW corresponds to
the minimum bandwidth requirement for the particular flow. MaxBW is defined to be the
maximum amount of bandwidth the application asks for and ActualBW finally represents
the actual reserved bandwidth for the flow at a certain time including the soft and the hard
reservation part.
HardReservation Message
On the other hand an HR message sets the RI field to HARDRES and defines the QoS
option as shown in figure 5.2.2. The option field provides two parameters to be set. SetBW
contains the amount of soft reserved bandwidth to be switched into hard reservation and
ActualBW is defined to be the actual bandwidth reserved, exactly as the SR message does.
SoftReservation Msg
0 200
100 300 100 300 100 300
HardReservation Msg
Real-time Real-time
Application SetBW ActualBW Application
Bottleneck
200 200 200 0
SR message arrives at a receiver node, the ActualBW field corresponds to the end-to-end
bandwidth availability. The receiver then replies with an HR message setting the SetBW
field equal to ActualBW, so that each node on the path switches its soft reserved bandwidth
into hard reservation and releases any potential extra reservation. As soon as the sender host
receives the HR message, the necessary QoS support for this particular flow is established
and the real-time flow can start running.
After a flow path is established, SR messages are periodically inserted into data packets.
These messages collect QoS information and eventually perform soft reservations. The
algorithm executed when receiving a SR message on a intermediate node is actually the
same 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 ( AvailableBW > = 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 ( AvailableBW > 0 ) {
SoftResvBW = SoftResvBW + AvailableBW ;
s o f t _ r e s e r v i n g ( AvailableBW ) ;
}
TotalResvBW = SoftResvBW + HardResvBW ;
}
5.3 Implementing ASAP using IPv6 23
Due to the information provided by SR messages, the receiver host is capaple to keep track
of the QoS situation on an end-to-end basis and therefore can immediately adapt to any
QoS change by sending an appropriate hard reservation. Adaptation means to upgrade
whenever 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 ;
s e n d i n g _ m e s s a g e (HR ) ;
IPv6[20] is the "next generation" protocol designed by the IETF to replace the current
version Internet Protocol, IP Version 4 ("IPv4"). Basically IPv6 provides the following
enhancements:
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 version
has 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 as
upcoming mobile devices like PDA’s and cell phones.
When mentioning mobile devices and IP, it’s important to note that a special protocol is
needed to support mobility - called "Mobile IP". IPv6 provides built-in mobility support
and thus allows for roaming between different networks using global notification when
leaving one network and entering the other one.
IPv6 defines a base header, which is mandatory, and a few optional extension headers to be
inserted in between base header and upper-layer headers in a packet. In order to connect
these headers the common NEXT HEADER field can be used. This actually forms a daisy
chain of headers.
24 Chapter 5. ASAP Framework
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 are
added instead: FLOW LABEL and CLASS.
FLOW LABEL is a 20-bit field to be used by a source to label sequences of packets for
which it requests special handling by the IPv6 routers, such as non-default quality of service
or "real-time" service. Although the concrete usage of the field is still under discussion, it
is believed that in the future, FLOW LABEL will be used as flow identifier mainly for the
IntServ model[9].
The CLASS field is an 8-bit field evolved from the TOS field in IPv4. It is available for use
by originating nodes and/or forwarding nodes to identify and distinguish between different
classes or priorities of IPv6 packets. Like in the case of FLOW LABEL, the concrete usage
of the CLASS field is still under experiment and discussion. However the field seems
to be destined for DiffServ QoS support. RFC2474 proposes a renaming of the CLASS
field 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 suggestion
of how to use it is defined yet.
Extension Headers
Routing header
Fragment header
Authentication header
The Routing header is used to specify a list of intermediate nodes to be visited on the way
to 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 by
every node along a packet’s delivery path.
In contrast, the destination options header will only be examined by the packet’s destination
node.
Authentication header, Encrypted payload and Fragment header will not be discussed here.
DSCP RI
Ver Class Flow Label Next Header Hdr Ext Len Option Type Option Len
Payload Length Next Header Hop Limit QoS Option FlowID Option
The whole structure of an ASAP message embedded within an IPv6 header is shown in
figure 5.3.3
Up to now it was never mentioned how ASAP aims to build a virtual path between sender
node and receiver. This has to happen somehow because an HR message intends to switch
soft reservation into a hard bandwidth reservation for a given flow. To achieve this, an
HR message must follow the reverse path of the corresponding SR message. There are
two basic opportunities to do this: One possible approach would be to store previous hop
information in every node, related to a particular flow. Another solution would be to use
the IPv6 routing header. Both approaches collect path information during soft reservation
to be used by the HR message later on.
26 Chapter 5. ASAP Framework
Chapter 6
ASAP as it is described in the previous chapter is designed for infrastructure based wireless
IP networks, in particular for a last-hop-wireless topology. To achieve seamless handover
the 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 for
MANETs.
D
SR Message
B
HR Message
F
A C E G
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 (hard
reservation leak). This happens whenever a path is rerouted on a new node that is able to
provide the actual end-to-end reservation. Bandwidth will be soft reserved on the node but
there is no reason to change the ActualBW field of the message because the field represents
the sum of both hard and soft reservation part. As a consequence an end node will not
detect any QoS change and will therefore not send any hard reservation to switch the soft
reserved 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 to
achieve 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 other
in one hop distance that does not mean routing also behaves like this. This could result in a
big 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 message
takes a much longer way using G, F, E, D, C, A. The third problem related to reverse paths
occurs when wireless links are not symmetric. Even if a node A can reach B in one hop
distance it is not given that node B is able to reach A as well. As a consequence there may
be 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 demands
of mobile ad hoc networks. The topology is just too dynamic and requires an approach
which is more simple.
H ardR eservation Ms g
SetBW ActualSoft ActualHard
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 already
did update his ActualBW value. This state is kept until the end-to-end bandwidth for the
flow 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 no
node 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 be
triggered until the reservation is actually done.
6.2 Extensions
Based on the shortcomings described in the previous section ASAP has to be redesigned
in order to provide fast flow restoration and short reaction times to topology changes. To
achieve this some new mechanism are developed: Local Repair and Dynamic Virtual Path.
Furthermore the adaptation algorithm is slightly changed.
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 bandwidth
within the specified range and updates table entries as usual. Before passing the message
to the next hop the node checks whether its actual hard reservation corresponds to the hard
reservation specified within the received message or not. If both values are equal nothing
has to be done and the soft reservation message is sent along the path. Otherwise the node
releases any additional reservation if the actual hard reservation specified is smaller than its
own hard reservation for that flow or tries to allocate additional resources if the specified
value is greater than its own. Both releasing and allocation of bandwidth has to be done
with respect to the range and the amount of soft reserved bandwidth for that flow. That
means, a node must only allocate additional hard reservation if enough soft reservation is
available 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 ) ;
}
}
else {
h a r d _ r e l e a s i n g ( HardResvBW SR . HardBW ) ;
}
...
As each soft reservation message represents a potential claim for local repair, a monitoring
message and even a flow setup message at the same time no further features are needed to
provide a base service for fast flow restoration. It depends now on the refresh period how
fast local repair can be. Monitoring based local repair can be seen as a base service which
is always available due to its independence from any underlying routing protocol.
It was mentioned in chapter 3 that some routing protocols allow upper layers for installation
of upcall procedures to be called whenever a route changes. One should take advantage of
this feature if available. Suppose a route change occurs on a certain node and the signaling
layer receives a corresponding upcall. All that has to be done is to send out a soft reservation
message for each flow affected by this change.
Routing triggered local repair should be considered as an enhancement to monitoring based
local repair if the necessary support can be provided.
D SR Message
B HR Message
HC = 2
F
MAXHOPCOUNT = 2
HC = 1
HC = 1
HC = 2 HC = 1
A C E G
vious soft reservation. The idea is to add a hopcount field to the hard reservation message
that 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 but
sent directly to the source node specified within the flowID of the message, regardless of
the route the message will take. Temporary there may be a partial reservation on the path
while some nodes stay untouched. But as the hard reservation message is received by the
sender, the node updates its QoS entry for that flow by setting actualSoft and actualHard
to the corresponding values within the message. The subsequent soft reservation message
will then trigger a local repair as described in the previous section in order to switch any
soft 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 adaptation
process 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 now
able to treat changes in soft and hard reservation separately. A slight modification on
the 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 ;
s e n d i n g _ m e s s a g e (HR ) ;
}
i f ( SR . HardBW < HardResvBW ) {
c r e a t e _ m e s s a g e (HR ) ;
HR . SetBW = SR . HardBW ;
s e n d i n g _ m e s s a g e (HR ) ;
}
HardResvBW = SR . HardBW ;
Each adaptation process holds information about the actual end-to-end hard reservation
for each flow. Upon receiving a SR message the node checks whether there is some soft
reservation available to be switched into real reservation or not and sends hard reservation
32 Chapter 6. Ad Hoc Extensions for ASAP
message out if necessary. Otherwise the adaptation process compares the end-to-end hard
reservation with the value it is keeping. If the received one is smaller a hard reservation
message 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 the
value specified within the message sent.
This mechanism is tolerant to lost hard reservation messages and even provides detection
of 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 of
this 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 treating
soft and hard reservation separately. A local repair mechanism is used to overcome the
problems related to the inertness of two-pass based reservations like the big latency during
flow 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 of
signaling 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 network
simulator [3] (from now on referred to as ASAP/ns). The chapter starts giving a brief
introduction to ns-2 with respect to protocol development in mobile environments. After
defining the basic implementation requirements an architectural overview of ASAP/ns is
presented. 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
Ns-2 has gained popularity among participants of the research community, mainly because
of its simplicity. It allows simulation scripts to be easily written in a script-like program-
ming language, OTcl. More complex functionality relies on C++ code that either comes
with ns-2 or is supplied by the user. This flexibility makes it easy to enhance the simulation
environment as needed, although most common parts are already built-in, such as wired
nodes, 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 can
be applied to a simulation in order to increase its reality. Simulations in ns-2 can be logged
to trace files, which include detailed information about received and transmitted packets
and allow for post-run processing with some analysis tools.
The following sections intend to outline some of the basic components of ns-2 - in particular
those that are important for the implementation of the ASAP framework described later on
in this chapter.
Generated Packets
Agent
Port
Classifier
Address
Link
Classifier
Entry
Point
Queue Link
Queue Link
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 of
ns-2. The internal architecture of a node differs depending on whether the node is mobile
or not.
Wired node
A wired node is a compound of a node entry object and two classifiers, as shown in figure
7.2.1. The node entry is where packets first arrive. The address classifier examines the
address 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 the
packet.
If the packet is not destined for the current node, the address classifier decides on which
link the packet should be sent. This is possible because routing constantly updates the
address 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 a
link. Also, mobile nodes may be moved within a topography, as opposed to wired nodes
which remain stationary. The mobile node itself is a compound object, built from the
following parts:
7.2 NS-2 35
Generated Packets
Agent
Port
Classifier
Routing
Agent
Address
Link
Classifier
Entry
Point
Link
ARP
Layer
Interface
Queue
MAC
Propagation Network
Model Interface
Wireless Channel
an address classifier like seen in the wired node right before. It is used for handling
packets to port classifier or routing agent.
A routing agent.
A link layer responsible for converting network address to hardware addresses with
the help of an ARP module
an interface queue used for storing and scheduling of packets with respect to some
well defined policies.
a network interface that sends and receives packets over the wireless channel.
a radio propagation model determining the signal strength of received packets, and
hence, whether a packet can be received by a network interface or not.
7.2.2 Packets
Packets are the unit of exchange between objects in a simulation. They are built up of
packet 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 packet
headers may be turned off to save memory during simulations. The only mandatory packet
header in ins-2 is the common header, hdr_cmn, mainly used for tracing and for measuring
other 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 examples
of agents that are frequently used in simulations.
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 routing
protocols 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 possible
as well as the extension of the existing message format by adding additional option
objects.
QoS management unit (QMU): The core unit of ASAP/ns residing on every node
of a MANET dealing with all around signaling processing.
Adaptation control unit (ACU): Upon receiving periodic monitoring messages the
ACU 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 application
requesting QoS.
7.5 QoS Management Unit 37
Real-time
Server
Core
Application
AQRU Client
Intermediate
Node
ACU ACU
QoS Signaling
QMU QMU QMU
LL LL LL
Queue Queue Queue
MAC MAC MAC
Phy PHY PHY
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 for
adjusting the bandwidth of a given flow according to the feedback gained from the
adaptation control unit (ACU).
The following part of this chapter intends to describe each of these building blocks in more
detail.
Upcall
Generated Packets
QMU
Address
Link
Classifier
Entry Routing
Point Agent
Bandwidth
Reservation
Link
Layer
Interface
Queue
MAC
Network
Interface
ACU
Upcall
SoftResv
Deserialization Serialization
Receive Forward
HardResv
Packet Packet
Reservation
on Queue
Upon receiving a signaling packet the QMU first transforms the raw byte stream into a
c++ message object. According to the message type, the object is dispatched to soft- or
hard 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 is
serialized 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.
extends
Flow ID
extends
extends
Previous Hop
contains
contains
Extension HopByHopHeader
Count field as described in section 6.2.3. For any additional information the concept of
Extension is provided. An Extension is a container object for additional headers. Headers
are 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 but
using a routing header might be interesting once too (see section 5.3.3). A Hop-by-Hop
option header includes a QoS option object, a FlowID object and in case of a soft reser-
vation message even a PreviousHop object. In order to construct a signaling message the
Extension object has to be serialized and copied into the message payload. This is done
by calling the getContents method of the extension which recursively collects the contents
of all the objects within the container. Upon receiving a signaling message the payload
has to be deserialized to get the Extension object. The container constructor can be used
for doing this. To retrieve a certain object out of a container the getObject(int) method is
called using the object’s ID as a parameter. Therefore calling getObject(HOPBYHOP) on
Extension returns the Hop-by-Hop option header. Retrieving QoS option or FlowID out of
a HopByHopHeader is in a similar way.
Figure 7.5.3 shows the framework’s class hierarchy. ASAPObject serves as a base class
to all other classes like Extension, HopByHopHeader or QoSOption. All the container
functionality (addObject(ASAPObject), getObject()) is provided by ASAPObject (so every
object is a potential container then). Subclasses only have to implement their own con-
structor and their getContents method in order to provide serialization and deserialization.
QoS Table
As mentioned in chapter 5 each node holds a QoS table containing entries for all the flows
having a reservation on that specific node. In ASAP/ns this table is indexed by the so-called
sessionID, which is actually the same as the flowID except that it is a single integer value
instead of a struct.
40 Chapter 7. Implementation
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 having
several 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. On
the other hand, whenever a soft reservation message arrives at a node not having an entry
for the particular flow, a new entry is built.
Resource Object
Reservations for a certain flow are performed by modifying the appropriate flow entry of
the QoS table. If some hard reservation has to be done then even the network interface
queue 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 having
such a Resource object is to clearly separate the reservation framework from the underlying
queue that is part of the network stack.
Actually neither QoS tables nor Resource objects are accessed directly. All the operations
manipulating reservation states are managed by SessionCtrl and AdmissionCtrl objects re-
spectively. Mainly these objects provide some kind of permission control, but they also
offer extended functionality like transforming relative values into absolute ones. Moreover
the AdmissionCtrl object provides an admitFlow() method to check whether a particular
bandwidth allocation can be granted for a given flow or not.
ReservationCtrl
As SessionCtrl and AdmissionCtrl both modify the flow’s soft and hard reservation, calls
to these objects have to be synchronized somehow in order keep consistency. It must be
guaranteed 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 special
ReservationCtrl unit is used, coordinating all the reservations on a certain node.
AdmissionCtrlManager
ACU Upcall
10
11 Forward
AdmissionCtrl Message
0
Manager
8
SessionCtrl QoS Table
6
Soft/Hard
ReservationCtrl
Resv 4 5
7 Resource
QMU AdmissionCtrl
Object
2 3
9
1
Allocation
Strategy Reservation
on Queue
As discussed in 3.5.2 there are many possible bandwidth allocation strategies like the
Greedy strategy or the Fair strategy. The decision which strategy to use may depend on the
certain network condition. ASAP/ns therefore provides a plug-in interface for bandwidth
allocation strategies. It is then up to the actual allocation strategy to determine how much
bandwidth to reserve according to a given request.
Figure 7.5.4 illustrates the whole reservation process performed upon receiving a signaling
message. Comments to the numbers can be found below.
1. The AdmissionCtrlManager is consulted to get the right AdmissionCtrl object for the
given session.
3. In order to compute a reasonable bandwidth proposal with respect to the given re-
quest, the AllocationStrategy has to consulted the AdmissionCtrl to check for avail-
able QoS bandwidth.
4. After verifying the bandwidth request proposed by the AllocationStrategy, the re-
quest is taken over by the ReservationCtrl controlling the actual reservation process.
6. AdmissionCtrl
9. The Resource Object finally maps the reservation to the underlying Queue
42 Chapter 7. Implementation
7.8.1 Queuing
As shown in figure 7.5.1, actual hard reservations are performed on the network’s interface
queue. Queues are networks components storing and forwarding packets according to some
7.8 Some further Components 43
Timer
Data
Entry
Signaling
Entry
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 satisfies
the 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 based
Queue (FBQ). If a bandwidth reservation is performed on an FBQ, a separate subqueue
is created for the given flow. The subqueue is responsible for properly forwarding any
packets belonging to that flow; properly means according to the bandwidth reserved. A
best-effort subqueue is available in every FBQ treating all the packets not belonging to any
reservation.
Queues in ns-2 are objects implementing the built-in queue interface, which basically has
two methods, that is, a method to enque and one to deque a packet. When a packet is enqued
into 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 passed
to the appropriate subqueue, otherwise the best-effort queue is used. Packet forwarding in
subqueues is triggered by a special timer object. The timer inspects the first packet in the
queue and schedules an event to happen at t = now + packetSize/bw. As the event occurs the
packet is dequeued and placed into the outgoing queue of the FBQ object. This procedure
is kept looping. If at some point the subqueue is empty the timer changes to sleeping mode
and 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 is
described in chapter 5 is an in-band signaling system. In ASAP/ns this behaviour is simu-
44 Chapter 7. Implementation
lated using some special treatment for soft reservation messages. If such a packet arrives
at 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 particular
subqueue, 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 faster
than the subqueue reservation.
7.8.2 Measurements
In order to keep track of several important parameters during simulation, a measurement
system 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 the
particular node. The queues periodically update parameters upon packet reception. On the
other 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 special
Logger 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 be
turned off or on.
Because a Logger object can be shared among different objects or even nodes logging in
ASAP/ns can be handled very flexible. Furthermore logging on a group of objects can
turned on or off at a certain time in simulation.
7.9 Conclusion
This chapter described the implementation of the ASAP framework in ns-2, called
ASAP/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 the
three building blocks (QMU, ACU and AQRU), a container-based messaging framework
and node encapsulation together with an AdmissionCtrl manager.
Chapter 8
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: Primarily
the 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 first
explaining the simulation setup and analysing the result data afterwards.
Like in the previous chapter, all file system references mentioned have to be understood as
relative to the actual ns-2 installation directory.
BEFlow
ASAPFlow
MonoFlow
A BEFlow object represents a best-effort Flow. Transmission rate, source and destination
node 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 are
sent at a fixed rate during On periods, and no packets are sent during Off periods. Both
On and Off periods are taken from an exponential distribution with means of 1s and 0.5
seconds respectively.
An ASAPFlow behaves differently. It needs source node, destination node, minimum and
maximum bandwidth to be specified. Min and Max values are defined as described in
section 5.2.2. Upon creation, an ASAPFlow triggers a QoS setup procedure using the
interface 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 rate
corresponding 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 QoS
support 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 and
cumulated to enable comparisons between different simulations later on. The following
measurement values are used throughout the simulations:
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 .
denotes the QoS packets which are dropped at node and refers to the number
of real-time packets sent on node .
The actual over-reservation defined to be 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 where
the measurement has been done.
8.3 Evaluation
The goal of the evaluation is on the one hand to prove for certain special situations that
ASAP/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, adaptation
or soft reservation.
at 27s: Node 2 starts moving upwards, leaving node 1’s transmission range at 30s.
These events cause both flows to be rerouted twice: Once at 30s where node 2 is finally
getting out of range and once after node 3 is moving in for the second time, this happens at
48 Chapter 8. Simulation and Analysis
250
Best-effort Traffic
QoS Traffic
QoS Traffic treated
200
as Best-effort
Throu gh put
150
100
50
1 51 101
Time
about 85s. The period for which the link between node 1 and 3 remains broken is chosen
to be around 20s to let the reservation on node 3 timeout.
The measured values during simulation are throughput and degraded 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 the
particular flow (in contrast to contract violation where packets arrive at the queue faster
than 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 node
3) has been cached (or has already been computed because node 3 moved into node 1’s
transmission range a while ago) and the available best-effort bandwidth was big enough
to support the real-time flow for the short period of no-reservation (indicated by the red
line). On the second rerouting event the throughput of the ASAPFlow is affected because
a 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 before
happens because BEFlow-packets are stored within the queue during broken-link period
and sent immediately when the new route is established.
8.3.2 Adaptation
During the following experiment the adaptation mechanism of ASAP is investigated. The
key point to figure out is how fast ASAP is able to react to bandwidth vibrations, but also
the prove the correctness of the implementation in a sense that bandwidth vibrations only
affect QoS flows if best-effort is already degraded significantly.
As mentioned in chapter 7 it is due to the application to choose an appropriate adaptation
strategy. The adaptation strategy used during the following simulations is the GreedyStrat-
egy mentioned 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 a
transmission range of [32K,64K] while the BEFlow is sending with a rate of 128K. During
simulation the link bandwidth of node 1 is manipulated. There’s a maximum fraction of
link bandwidth to be used by QoS traffic, this value is fixed to be 0.7.
8.3 Evaluation 49
Link Bandwidth
250 Best-Effort Traffic Received
QoS Traffic Sent
QoS Traffic Received
200
Throu ghp ut
150
100
50
Time
Refresh Period = 4
9000
7000
T hrou gh pu t
6000
5000
4000
3000
2000
1000
Time
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 measured
values 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 to
observe is that link vibrations above 91K (
) do not affect the ASAPFlow, this
proves the correct behaviour of bandwidth reservations in ASAP/ns. Second the adaptation
of the flow is quite agile to the link bandwidth changing. The latency between sent and
received traffic adaptation is caused by the agility of the ASAP protocol, which is strongly
related to the refresh interval by which soft reservation messages are sent (shown in Figure
8.3.2b.
This simulation is to show the QoS performance under different mobility conditions, that
is, from 10 km/h to 100 km/h. The scenario consists of 20 nodes moving randomly within
a 600m x 600m area with the specified maximum speed. 12 ASAPFlow’s are generated by
12 different sender nodes and randomly selected receivers, all running with a transmission
rate of 16k. Furthermore 5 BEFlow are generated introducing background traffic. The soft
50 Chapter 8. Simulation and Analysis
10 20 30 40 50 60 70 80 90 100
Velocity [km/h]
4.5
ASAP 10 km/h
4
ASAP 100 km/h
3.5
Others 10 km/h
Others 100 km/h
O ver-Re servat io n
2.5
1.5
0.5
44 36 30 26 22 18 14 10 8 6 4 2
Timeout [Seconds]
0.35
QoS Degredation
0.3
ASAP Signaling
0.25
Ra tio [ % ]
0.2
0.15
0.1
0.05
1 2 4 8 16
8.4 Conclusion
The simulation result described in the previous sections basically lead to the following
conclusions:
The adaptation behaviour of ASAP is quite promising but depends on the interval
by which soft reservation messages are sent. But as the soft reservation interval
is determined by the application it can be changed adaptively to changing network
conditions.
Frequent route changing caused by fast node movement affects the QoS performance
in a sense that the amount of degraded QoS traffic increases if the topology changes
more frequently.
52 Chapter 8. Simulation and Analysis
Reservation efficiency is correlated to the speed of mobility and the timeout period
of 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
9.1 Summary
Within this thesis the challenge of bringing QoS support to mobile ad hoc networks has
been 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 been
proposed in this thesis and further extended based on some well-defined design criterions.
The framework includes a QoS signaling protocol and flexible allocation and adaptation
mechanisms. 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 shown
that the feature to dynamically change the soft reservation interval and the concept of
soft/hard reservation are the major benefits of ASAP.
However, the network’s highly dynamic characteristics make it very difficult to maintain
QoS support. In order to achieve good QoS performance and adaptation agility, frequent
network monitoring using soft reservation messages is needed, but this increases signaling
overhead 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 necessary
to implement it in a real operating system.
Many simulation variants have not been examined yet, like for example the use of
different 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 if
the 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 group
and especially my assistant Jianbo Xue who offered this interesting thesis and supported
me whenever I needed advice.
I also thank my friends and all the fellows sufferers in HRS G9 who made working very
comfortable.
56 Chapter 9. Summary and Outlook
Bibliography
[4] Andreas Kassler, Teodora Guenkova-Luy, Davide Mandator, Peter Schoo. Enabling
mobile heterogeneous networking environments with end-to-end user perceived qos.
Technical report. IST project IST-2000-28584 MIND.
[7] R. Braden, D. Clark, and S. Shenker. Integrated services in the Internet architecture:
an overview. Technical Report 1633, 1994.
[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.
[12] Kurt Geihs. Analysis of adaptation strategies for mobile qos-aware applictions.
2002. Workshop on Modelling Analysis and Simulation of Wireless and Mobile
Systems.
[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 model
for ad hoc wireless networks.
www.ece-icr.nus.edu.sg/journal1/fqmmhandbook02.pdf.
[15] Alberto López, Jukka Manner, Andrej Mihailovic, Hector Velayos, Eleanor
Hepworth, and Youssef Khouaja. A study on qos provision for ip-based radio access
networks, 1999. IST project IST-1999-10050 BRAIN.
58 BIBLIOGRAPHY
[16] N. Schult M. Mirhakkak and D. Thomson. A new approach for providing quality of
service 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, Eleanor
Hepworth, and Youssef Khouaja. Evaluation of mobility and qos interaction.
[18] Bongkyo Moon and Hamid Aghvami. Rsvp extensions for real-time services in
wireless 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 resource
reservation protocol for an integrated services network with mobile hosts. Wireless
Networks, 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 in
wireless ip network. Master’s thesis, 2002. www.inf.ethz.ch/personal/jxue/.