IEEE 802.11s Mesh Networking Evaluation under NS-3

PROJECTE FINAL DE CARRERA
IEEE 802.11s Mesh Networking

Evaluation under NS-3
Estudis: Enginyeria Electrònica

Autor: Marc Esquius Morote
Director: Miguel Catalán Cid
Abril 2011
Abstract
Within the last few years, prevalence and importance of wireless networks increased
significantly. Especially, wireless mesh networks received a lot of attention in both
academic research and commercial deployments. Wireless mesh networks are char-
acterized by wireless multi-hop connectivity and facilitate a simple and cost-effective
establishment of wireless networks while providing large coverage areas.
IEEE 802.11s defines a new mesh data frame format and an extensibility framework
for routing. It defines the Hybrid Wireless Mesh Protocol (HWMP) based on Ad
hoc On-demand Distance Vector Routing (AODV) using MAC addresses for layer 2
routing and Radio-Aware routing metric. HWMP has also a configurable extension
for proactive routing offering various modes of operation that are suitable for different
environments.
In this research, the network simulator NS-3 has been used to perform an accurate
comparison between AODV and HWMP in order to see if this new layer 2 implemen-
tation and routing metric present important benefits. On the other hand, a detailed
simulative evaluation of the reactive and proactive working modes of HWMP allows
for conclusion in which situations each mode should be used.
Keywords: 802.11s, mesh networking, routing protocol, HWMP, AODV, NS-3

Acknowledgments
I would like to thanks professor Josep Paradells for his support and for giving me the
chance to carry out this distance project. Thanks a lot also to Miguel Catalán with
whom I exchanged tons of e-mails while dealing with several problems and debating
about NS-3. Without them, it would not have been possible!
i
Contents
Acknowledgments i
1 Introduction 1
1.1 The need of a new standard . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 State of the art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Aim of this research . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Structure of the report . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 IEEE 802.11s 5
2.1 Network design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Mesh formation and management . . . . . . . . . . . . . . . . . . . . . 7
2.2.1 Mesh Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.2 Mesh creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Path selection mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.1 Airtime Link Metric . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.2 Hybrid Wireless Mesh Protocol . . . . . . . . . . . . . . . . . . 10
2.4 Medium Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5 Frame structure and syntax . . . . . . . . . . . . . . . . . . . . . . . . 15
iii
3 IEEE 802.11s model in NS-3 19
3.1 Network Simulator 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 Model design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.1 Supported features . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.2 Unsupported features . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3 Model implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4 MAC-layer routing model . . . . . . . . . . . . . . . . . . . . . . . . . 22
4 Simulations 25
4.1 Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2 Figures of merit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3 Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.1 Transmission rate . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3.2 Number of hops . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4 Analysis of the interference model . . . . . . . . . . . . . . . . . . . . . 30
5 HWMP vs. AODV 35
5.1 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2 Routing metric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.3 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.3.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6 HWMP Reactive vs. Proactive 49
6.1 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.2 Destination Only flag . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.3 Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.3.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
iv
7 Conclusions and future work 59
A AODV routing protocol 61
B NS-3 802.11s modules 65
B.1 MeshHelper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
B.2 MeshPointDevice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
B.3 HWMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
B.4 Peer Management Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 70
B.5 Peer Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
C NS-3 Scripts 73
C.1 HWMP Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
C.2 AODV Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
C.3 HWMP different modes . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Bibliography 105
List of figures 109
List of tables 111
v
Chapter 1
Introduction
1.1 The need of a new standard
The present 802.11 interconnections rely on wired networks to carry out bridging func-
tions. For a number of reasons, this dependency on wired infrastructure must be
eliminated:
• This dependency is costly and inflexible, as WLAN coverage cannot be extended

beyond the back-haul deployment.
• Centralized structures work inefficiently with new applications, such as wireless

gaming, requiring peer-to-peer connectivity.
• A fixed topology inhibits stations from choosing a better path for communication.
Wireless mesh networks (WMNs) hold the promise to got over these emerging needs.
However, existing WMNs (developed by private companies for example) rely on the
IP layer to enable multihop communication and do not provide an inherently wireless
solution. Since wireless links are less reliable than wired links, a multihop routing
protocol operating in a wireless environment must take this into account.
As 802.11 does not specify the interfaces that the IP layer needs to derive link metrics
from the medium access control (MAC) layer, the ad-hoc routing protocols developed
1
by the Internet Engineering Task Force’s (IETF’s) Mobile Ad-Hoc Networks (MANET)
group are forced to rely on indirect measurements [1] to observe the radio environment.
However, as it is explained in [2], the acquired link metrics are of limited accuracy,
while the MAC layer has adequate knowledge of its radio neighborhood to make its
measurements less outdated and more precise.
To realize the benefits of a MAC-based WMN, an integrated mesh networking solution

is under development in IEEE 802.11 Task Group S. The particular amendment of the
802.11 standard dealing with mesh support, 802.11s [3], describes a WMN concept that
introduces routing capabilities at the MAC layer.
1.2 State of the art
Since 2004 Task Group S has been developing this amendment to the 802.11 standard
to exactly address the aforementioned need for multihop communication. Nowadays
the current draft is the 802.11/D10 and even though no formal standard has been
ratified, there are several companies in the market with their solution, largely based on
draft 802.11s. For example, there is a consortium of companies called open80211s who
are sponsoring (and collaborating in) the creation of an open-source implementation
to be run under Linux [4].
Some research groups are already starting to do some research using network simula-
tors. For example, in [5] and [6] is analyzed the delay, throughput and the performance
of some new features of the 802.11s under a simulation environment. In [7] are also
compared the new type of routing metric proposed by the draft with some other com-
mon metrics, while the new type of routing in the MAC layer is tested in [8].
On the other hand, some testbeds using the current capabilities of the Linux imple-
mentation previously mentioned are also being carried out. In [9] they do a simple
comparison of performance versus the number of hops between the results of a new
implementation of the 802.11s in a network simulator and a real implementation they
built. Similar tests are performed also in [10] and even some extra features not specified
in the draft are also a matter of concern in [11].
2
1.3 Aim of this research
The aim of this research is to evaluate the performance of the wireless mesh structure
defined by the 802.11s draft. Especially, the evaluation of the new routing capabilities
proposed using the MAC layer and its comparison with other common used routing
protocols for multihop ad-hoc networks.
As is presented in the state of the art, some researches and tests related with mesh
networking are been taking place. However, to our knowledge, no detailed and accu-
rate comparison between the routing capabilities of this MAC-based WMN and the
traditional multihop routing capabilities has been performed.
Furthermore, the routing protocol defined for mesh networks is an hybrid protocol, so
an important aspect regarding WMN routing capabilities is to know when to chose
its reactive or its proactive mode (the protocol and its way of working is explained in
2.3.2). The comparison done between both modes can help define some guidelines in
its way of use.
1.4 Structure of the report
First of all, in chapter 2, 802.11s is explained. All its main characteristics (especially the
ones concerning this research) are described: network design, mesh creation, routing
mechanisms, etc. This gives an overview of the 802.11s needed to discuss later the
results.
In order to evaluate the mesh structure and the routing capabilities, the network sim-
ulator NS-3 has been chosen. This simulator presents a widely tested and checked
implementation which allows us to create the environments and applications required.
Chapter 3 explains how the 802.11s is implemented in NS-3: a detailed description of
its functions and supported features as well as the parameters of the several protocols
that can be adjusted. Thus, we can see which characteristics of the draft have to be
considered in the simulations and which not.
3
Since this network simulator and its implementation of the draft are under development,
an exhaustive checking of the simulation environment has been performed in chapter
4. Thereby, we can check how accurate the propagation models are defined or which
kind of interference model is implemented. Furthermore some consideration when
performing simulations are mention and the figures of merit used are defined.
Chapter 5 presents a detailed comparison between the mesh routing protocol (HWMP)
and the one it is based on (AODV). Several scenarios have been analyzed in order to
see how the routing capabilities of each protocol deal with scalability problems. Taking
into account the different figures of merit we can see in which aspects the MAC layer
routing outperforms the standard layer 3 routing and in which not.
The reactive and proactive modes of the hybrid protocol defined in 802.11s are com-
pared in chapter 6 in order to know in which situations they should be used. Finally in
Chapter 7 the conclusions of this research are summarized and future work is discussed.
4
Chapter 2
IEEE 802.11s
In this chapter a detailed explanation of how the IEEE 802.11s works is presented.
First, in section 2.1 the network design including its structure and different node cate-
gories is described. The following section explains how the mesh is created and managed
and which elements characterize a mesh network. Section 2.3 includes the description
of the path selection mechanisms. This is an important part of the standard since it is
described how the metric and routing protocols work at MAC level.
In section 2.4 the function used to coordinate the medium access control of the different
mesh devices is presented. Finally, in section 2.5 are explained the strategies to modify
the frame structure and syntax from the 802.11 one.
Apart from the functions and characteristics explained, in the draft appear few more
such as security or congestion control. These are not described since this chapter is
focused in the ones used in this research and implemented in the network simulator.
2.1 Network design
In 802.11, an extended service set (ESS) consists of multiple basic service sets (BSSs)
connected through a distributed system (DS) and integrated with wired LANs. The DS
service (DSS) is provided by the DS for transporting MAC service data units (MSDUs)
between APs, between APs and portals, and between stations within the same BSS
5
that choose to involve DSS. The portal is a logical point for letting MSDUs from a
non-802.11 LAN to enter the DS. The ESS appears as single BSS to the logical link
control layer at any station associated with one of the BSSs.
As is explained in [12], the 802.11 standard has pointed out the difference between
independent basic service set (IBSS) and ESS. IBSS actually has one BSS and does
not contain a portal or an integrated wired LANs since no physical DS is available.
Thus, an IBSS cannot meet the needs of client support or Internet access, while the
ESS architecture can. However, IBSS has its advantage of self-configuration and ad-hoc
networking. Thus, it is a good strategy to develop schemes to combine the advantages
of ESS and IBSS. The solution being specified by IEEE 802.11s is one of such schemes.
In 802.11s, a meshed wireless LAN is formed via ESS mesh networking. In other
words, BSSs in the DS do not need to be connected by wired LANs. Instead, they
are connected via wireless mesh networking possibly with multiple hops in between.
Portals are still needed to interconnect 802.11 wireless LANs and wired LANs. Nodes
in a mesh network belong to one of the four categories:
• Client or Station (STA) is a node that request services but does not participate
in path discovery mechanism nor forward frames.
• Mesh STA is an 802.11 entity that can support wireless LAN mesh services, so
it participates in the formation and operation of the mesh cloud.
• Mesh Access Point (Mesh AP) is a Mesh STA that can also work as an access
point to provide services for STA.
• Portal is a logical point where MSDUs enter/exit the mesh network from/to other
networks. It acts as a bridge or gateway between the mesh cloud and external
networks.
Figure 2.1 presents this network architecture. Because portals do not have AP func-
tionality but can work as relaying nodes, the meshed wireless LAN is not an ESS
anymore. The 802.11s MAC is developed based on existing 802.11 MAC, and the mesh
routing protocol resides in the MAC layer. In a portal, a layer-3 routing protocol is
also needed for path selection from the mesh network to external network or vice versa.
6
Figure 2.1: The 802.11s network architecture
2.2 Mesh formation and management
2.2.1 Mesh Profile
As is specified in the draft, there are three elements that characterize a mesh network:
• The Mesh ID
• The path selection protocol
• The path selection metric
Together these three elements define a profile. A Mesh STA can support different
profiles, but all nodes in a mesh cloud must share the same profile.
In infrastructured wireless networks, a Service Set Identifier (SSID) is used to dis-

tinguish the set of access points, which maintain a certain functional correlation and
belong to the same local area network. In a mesh network the same need for an iden-
tity exists, but instead of overloading the definition and function of the SSID, the draft
proposes a Mesh identifier or Mesh ID. Similarly to 802.11, beacon frames are used to
announce a Mesh ID and to avoid misleading a non-mesh station, Mesh STAs broadcast
beacons with the SSID set to a wildcard value.
IEEE 802.11s mandatory profile defines the Hybrid Wireless Mesh Protocol (HWMP)
as the path discovery mechanism and the Airtime Link Metric (ALM) as the path
7
selection metric (these are explained in the next section). The draft does not prevent
other protocols or metrics from being used in a mesh cloud, but it advises that a
mesh network shall not use more than one profile at the same time in order to avoid
complexity of profile renegotiation (that may be too expensive for a simple device to
handle).
2.2.2 Mesh creation
A mesh network is formed as Mesh STAs find neighbors that share the same profile.
The neighbor discovery mechanism is similar to what is currently proposed by the
IEEE 802.11 standard: active scanning (probe frame transmission) or passive scanning
(observation of beacon frames). In order to achieve this, every mesh station periodically
sends small one-hop management frames known as beacons.
As beacons are sent strictly periodically (needed for power save), if two beacons from
two neighbor stations have collided, they may collide forever. There is a mechanism
that allows to avoid collisions among beacons: Mesh Peering Management protocol
(PMP). It starts when mesh stations receive beacons from unknown Mesh STAs (found
through active or passive scanning) and decide to open link with them. Peering Open
one-hop management frame containing mesh parameters are sent to a potential peer
station. The Mesh STAs processes the received parameters and if it agrees with them,
it sends a Peering Confirm management frame in response to the Peering Open frame.
The peer link is established only when both stations have sent Peering Open requests
and received Peering Confirm replies. This requirement guarantees that all established
links are bidirectional. Whenever a Mesh STA wants to close a peer link it should send
a Peer Link Close frame to the peer Mesh STA. There is an example of a successful
peer link establishment in figure 2.2.
A mesh peer link is univocally identified by the MAC addresses of both participants
and a pair of link identifiers, generated by each of the Mesh STAs in order to minimize
reuse in short time intervals. Even when the physical link breaks, mesh stations may
keep the peer link status to facilitate a quick reconnection.
8
Figure 2.2: Peer link establishment
2.3 Path selection mechanisms
In this section the two mandatory path selection mechanism that are used to define
a mesh profile are explained: HWMP protocol and ALM routing metric. As it is
explained in the previous section, other mechanisms can be developed and used in a
mesh network, but these ones proposed in the draft are also the ones implemented in
NS-3 model used in this research.
When creating or joining a mesh network, in order to exchange the configuration pa-
rameters, a Mesh Configuration element is transported by beacon frames, Peer Link
Open frames and Peer Link Confirm frames. The Mesh Configuration element contains,
among other sub-fields, an Active Path Selection Protocol Identifier and an Active Path
Selection Metric Identifier.
2.3.1 Airtime Link Metric
The ALM accounts for the amount of time consumed to transmit a test frame and
its value takes into account the bit rate at which the frame can be transmitted, the
overhead posed by the PHY implementation in use and also the probability of re-
transmission, which relates to the link error rate. The draft does not specify how to
calculate the frame loss probability, leaving this choice to the implementation. Nodes
transmitting at low data rates may use all the bandwidth in a network with their long
transmissions the same way a high error rate link can occupy the medium for a long
9
time. The ALM is designed to avoid both problematics and according to the standard
the airtime cost, Ca, is calculated as:

Bt 1
Ca = OcaOp + (2.1)
r 1 − ef
Where Oca is the channel access overhead and Op the protocol overhead which varies
according to the PHY layer implementation. Bt is the test frame size, r is the data rate
in Mbps at which the Mesh STA would transmit a test frame and ef is the measured
test frame error rate. Table 2.1 present the value for the constants Oca, Op and Bt for
each type of 802.11. During path discovery, each node in the path contributes to the
metric calculation by using management frames for exchanging routing information.
Table 2.1: ALM constants

Parameter 802.11a 802.11b Description
Oca 75µs 335µs Channel access overhead
Op 110µs 364µs Protocol overhead
Bt 8224 8224 # bits in test frame
2.3.2 Hybrid Wireless Mesh Protocol
The network infrastructure of 802.11 WMNs tends to have minimal mobility and most
of the traffic is to/from the Internet. However, some nodes such as handset devices,
laptops, etc. can be an Mesh STAs but definitely need mobility support. In order
to meet diverse requirements by making the routing protocol be efficient for different
scenarios, the Hybrid Wireless Mesh Protocol is being specified in 802.11s. In HWMP,
on-demand routing protocol is adopted for mesh nodes that experience a changing
environment, while proactive tree-based routing protocol is an efficient choice for mesh
nodes in a fixed network topology.
The on-demand routing protocol is specified based on Ad-hoc On-demand Distance

Vector (AODV) routing. Its basic features are adopted, but extensions are made for
802.11s. For more information on AODV check appendix A or the RFC of the IETF [1].
10
The proactive tree-based routing is applied when a root node is configured in the mesh
network. By means of the root, a distance vector tree can be built and maintained for
other nodes, which can avoid unnecessary routing overhead for routing path discovery
and recovery. On-demand routing and tree-based routing can run simultaneously.
The extensible framework of this protocol also supports other types of metrics apart
from the ALM (such as QoS parameters, traffic load, power consumption, etc.), but in
the same mesh only one metric shall be used.
Four information elements are specified for HWMP:
• Root announcement (RANN)
• Path request (PREQ)
• Path reply (PREP)
• Path error (PERR)
Except for PERR, all other information elements of HWMP contain three important
fields: destination sequence number (DSN), time-to-live (TTL), and metric. DSN and
TTL can prevent the counting to infinity problem, and the metric field helps to find a
better routing path than just using hop count.
On-demand routing mode
In the on-demand routing mode, an PREQ is broadcast by a source Mesh STA aiming
to set up a path to a destination Mesh STA. When an intermediate Mesh STA receives
this element, it creates/updates a path to the source if the sequence number of the
PREQ is greater than the previous one or the sequence number is the same but the
metric is better. If the intermediate Mesh STA has no path to the destination, it just
forwards the PREQ element further. Otherwise, there are different cases depending on
two flags, destination-only (DO) flag and reply-and-forward (RF) flag:
11
- [DO = 1] This is the default case. The intermediate Mesh STA does nothing but
just forwards the PREQ to the next-hop Mesh STA until the destination Mesh
STA. Once the destination gets this element, it sends a unicast PREP back to
the source. All intermediate Mesh STAs create a route to the destination when
receiving this PREP element. Thus, in this case the routing protocol just ignores
the existing route from the intermediate Mesh STA to the destination and creates
a new one. The RF flag has no effect on the routing protocol in this case.
- [DO = 0 and RF = 0] In this case, if the intermediate Mesh STA has a valid
route, it sends a unicast PREP to the source Mesh STA and does not forward
PREQ. Thus, the routing protocol uses the existing route from the intermediate
Mesh STA to the destination.
- [DO = 0 and RF = 1] In this case the intermediate Mesh STA sends a unicast
PREP to the source Mesh STA. Then, it needs to change the DO flag to 1 and
then forwards the PREQ element to the destination. By doing so, all the subse-
quent intermediate Mesh STAs will not send PREP elements to the source.
In maintenance PREQ, the DO flag is always set to 1 (first case). The third case exists
only when the source Mesh STA has no valid route and also wants to create a new
route to the destination Mesh STA. These procedures are specifically for HWMP and
different from the original AODV. An on-demand route discovery cicle is illustrated in
figure 2.3.
12
Figure 2.3: HWMP on-demand route discovery.
Proactive tree-based routing mode
In the proactive tree-based routing mode there are two mechanism. One is based on
proactive PREQ and the other is based on proactive RANN.
In the proactive PREQ mechanism, the root node periodically broadcasts an PREQ
element. A Mesh STA in the network receiving the PREQ creates/updates the path to
the root, records the metric and hop count to the root, updates the PREQ with such
information, and then forwards PREQ. Thus, the presence of the root and the distance
vector to the root can be disseminated to all Mesh STAs in the mesh. If the proactive
PREP bit in the proactive PREQ element is set to 1, then the receiving Mesh STA
sends a gratuitous PREP to the root so that a route from the root to this Mesh STA
is established.
On the other hand, if the proactive PREP bit is set to 0, the gratuitous PREP is sent
only when there is data to send between the Mesh STA and the root with a bidirectional
route. This proactive discovery cicle is illustrated in figure 2.4.
In the proactive RANN mechanism, the root node periodically floods a RANN ele-
ment into the network. When a Mesh STA receives the RANN and also needs to
create/refresh a route to the root, it sends a unicast PREQ to the root. When the
root receives this unicast PREQ, it replies with a PREP to the Mesh STA. Thus, the
13
Figure 2.4: HWMP proactive PREQ route discovery.
unicast PREQ forms the reverse route from the root to the originating Mesh STA,
while the unicast PREP creates the forward route from the originating Mesh STA to
the root.
2.4 Medium Access Control
Regarding the access to the medium, Mesh STAs implement the mesh coordination
function (MCF). As is described in [13], MCF consists of a mandatory and an optional
scheme. For the mandatory part, MCF relies on the contention-based protocol known
as Enhanced Distributed Channel Access (EDCA), which itself is an improved variant
of the basic 802.11 distributed coordination function (DCF). Using DCF, a station
transmits a single frame of arbitrary length.
Using EDCA, a station may transmit multiple frames whose total transmission du-
ration may not exceed the transmission opportunity (TXOP) limit. The intended
receiver acknowledges any successful frame reception. Additionally, EDCA differenti-
ates four traffic categories with different priorities in medium access and thereby allows
for limited support of quality of service (QoS).
To enhance QoS, MCF describes an optional medium access protocol called Mesh
Coordinated Channel Access (MCCA). It is a distributed reservation protocol that
14
allows Mesh STAs to avoid frame collisions. With MCCA, Mesh STAs reserve TXOPs
in the future called MCCA opportunities (MCCAOPs). An MCCAOP has a precise
start time and duration measured in slots of 32 µs. To negotiate an MCCAOP, a
Mesh STAs sends an MCCA setup request message to the intended receiver. Once
established, it advertise the MCCAOP via the beacon frames.
Since Mesh STAs outside the beacon reception range could conflict with the existing
MCCAOPs, Mesh STAs also include their neighbors’ MCCAOP reservations in the
beacon frame. At the beginning of an MCCA reservation, Mesh STAs other than
the MCCAOP owner refrain from channel access. The owner uses standard EDCA
to access the medium, and does not have priority over stations that do not support
MCCA.
Although this compromises efficiency, simulations (for example in [14]) reveal that
high medium utilization can still be achieved with MCCA in the presence of non-
MCCA devices. After an MCCA transmission ends, Mesh STAs use EDCA for medium
contention again.
2.5 Frame structure and syntax
In order to allow multihop functions at the MAC layer, the IEEE 802.11s emerging
standard extends the original 802.11 frame format and syntax. As is explained in [15],
the new frame format supports four or six MAC addresses and new frame subtypes are
introduced. The first two octets of an 802.11 frame contain the Frame Control field
and the third and fourth bits of this field identify the frame type, as shown in table
2.2.
Table 2.2: Frame types

Frame control 3-4 bits Frame type
00 management frames
01 control frames
10 data frames
11 reserved
15
Besides those two bits, there are also four more bits devoted to a frame subtype. Since
IEEE 802.11s is an amendment to IEEE 802.11, the frames it introduces must fall into
the four pre-existing categories. It was decided to extend the data and management
frames in the following ways:
• Data exchanged between Mesh STAs are transported by Mesh Data frames, de-
fined as data frames (type 0x2). where a mesh header is included in the frame
body.
• Mesh-specific management frames, such as PREP or PREQ, belong to type 0x0

(management) and subtype 0xD (action frames). There is also a new subtype
called Multihop Action frame. This new subtype refers to action frames with
four MAC addresses.
Another characteristic of the new frames is the use of the FromDS and ToDS flags. In
IEEE 802.11, those bits mark frames as being originated from or destined to a distribu-
tion system, which is the infrastructure that interconnects access points. Similarly to
a WDS, IEEE 802.11s also sets FromDS and ToDS flags in frames transmitted inside a
mesh cloud. Notice that both flags (FromDS and ToDS) are set to zero in ad-hoc IEEE
802.11 frames. In an ad-hoc network, peer- to-peer transfers can happen opportunis-
tically in a way that should not be confused with that proposed by a mesh network,
where frame forwarding (multihop forwarding) capabilities are present.
Figure 2.5 shows the general structure of an IEEE 802.11 frame extended by a Mesh
Header (included in the frame body). It defines the following fields:
• Mesh Flags: Only the first two bits are defined. They inform the number of MAC
addresses carried in the Mesh Address Extension field and vary between zero and
three.
• Mesh TTL (Time To Live): this field is decremented by each transmitting node,
limiting the number of hops a frame is allowed to take in the mesh cloud and
avoiding indefinite retransmissions in the case of a forwarding loop.
16
Figure 2.5: IEEE 802.11s frame structure
• Mesh Sequence Number : the three bytes of this field identify each frame and
allow duplicate detection, preventing unnecessary retransmissions inside the mesh
cloud.
• Mesh Address Extension: this field carries extra MAC addresses, since the mesh
network might need up to six addresses (below is explained in which cases this
may happen).
According to IEEE 802.11s, non-mesh nodes (STAs) can participate in the mesh
network through a Mesh STA with Access Point capabilities. STAs communicating
through the mesh cloud are proxied by their supporting Mesh APs and this scenario
constitutes one example where the six-address frame format is employed.
Four-address frames are originally supported by IEEE 802.11 for transmissions using a
WDS, but in order to support non-mesh stations, IEEE 802.11s frames need six MAC
addresses. The following are the six MAC addresses used, where the last two are the
additional ones needed.
1. SA (source address): the address of the node that generated the frame.
2. DA (destination address): the address of the node that is the final destination of
the frame.
3. TA (transmitter address): the address of the node that transmitted the frame.
It can be the same as the source address, or the address of any Mesh STA that
forwards the frame on behalf of the source (intermediate node)
17
4. RA (receiver address): the address of the node that receives the frame. It is the
address of the next-hop node and, on the last hop to the destination, it becomes
the same as DA.
5. Mesh SA: In a six-address frame, the SA is the source communication endpoint

(for example the node outside the mesh cloud that originates the frame). Then,
the Mesh SA is the node that introduces the frame in the mesh cloud (on behalf
of the SA).
6. Mesh DA: as the DA is defined as the final destination of the frame, the Mesh
DA is the address of the last node of the mesh cloud that handles the frame.
18
Chapter 3
IEEE 802.11s model in NS-3
This chapter provides an explanation of how is implemented the 802.11s wireless mesh
networking model in the Network Simulator 3 (NS-3) and which features or charac-
teristics are supported and which not. First, NS3 is briefly explained to see why this
simulator has been chosen.
The model used has been the one developed by the Wireless Software R&D Group of
IITP RAS and included in NS-3 from the release 3.6. Although it is based in the IEEE
P802.11s/D3.0 [16], for the aim of this research, the characteristics used and analyzed
are not different from the ones present in the last draft of 802.11s [3]. For more detailed
information, you can find the complete explanation in [17].
3.1 Network Simulator 3
NS-3 [18] is a discrete-event network simulator for Internet systems, targeted primarily
for research and educational use. NS-3 is free software, licensed under the GNU GPLv2
license, and is publicly available for research, development, and use.
It is a tool aligned with the simulation needs of modern networking research allowing
researchers to study Internet protocols and large-scale systems in a controlled environ-
ment. The following trends is how Internet research is being conducted are responded
by NS-3:
19
1. Extensible software core: written in C++ with optional Python interface and an
extensively documented API (doxygen [19]).
2. Attention to realism: model nodes more like a real computer and support key
interfaces such as sockets API and IP/device driver interface (in Linux).
3. Software integration: conforms to standard input/output formats (pcap trace

output, NS-2 mobility scripts, etc.) and adds support for running implementation
code.
4. Support for virtualization and testbeds: Develops two modes of integration with
real systems: 1) virtual machines run on top of ns-3 devices and channels, 2)
NS-3 stacks run in emulation mode and emit/consume packets over real devices.
5. Flexible tracing and statistics: decouples trace sources from trace sinks so we
have customizable trace sinks.
6. Attribute system: controls all simulation parameters for static objects, so you can
dump and read them all in configuration files.
7. New models: includes a mix of new and ported models.
To sump up, NS-3 tries to avoid some problems of its predecessor, NS-2, which is still
being used by many researchers, but it has some important lacks such as: interoper-
ability and coupling between models, lack of memory management, debugging of split
language objects or lack of realism (in the creation of packets for example).
Mainly, the new available high fidelity IEEE 802.11 MAC and PHY models together
with real world design philosophy and concepts made NS-3 the choice for developing
this 802.11s model as well as for carrying out this research.
20
3.2 Model design
To meet these requirements imposed by 802.11s of supporting multiple interfaces (wire-

less devices) and also different mesh networking protocol stacks, WS R&D Group
designed and implemented a runtime configurable multi-interface and multi-protocol
Mesh STA architecture.
In the next subsections, the supported and unsupported features are presented accord-
ing to the description of the draft presented in chapter 2.
3.2.1 Supported features
The most important features supported are the implementation of the Peering Man-
agement Protocol, the HWMP and the ALM.
A part from the functionality described in section2.3, the PMP includes link close
heuristics and beacon collision avoidance. HWMP includes proactive and on-demand
modes, unicast/broadcast propagation of management traffic and, as an extra function-
ality not specified yet in the draft, multi-radio extensions. However, for the moment
RANN mechanism is implemented but there is no support, so only the PREQ can be
used.
3.2.2 Unsupported features
The most important feature not implemented is Mesh Coordinated Channel Access
(MCCA) described in section 2.4. Internetworking using a Mesh Acces Point or a
Portal is not implemented neither, but this functionality is not needed to evaluate the
performance in the creation of mesh networks.
As other less relevant features not implemented we can point out the security, power
safe mode and although multi-radio operation is supported, no channel assignment
protocol is proposed.
21
3.3 Model implementation
The description of which modules are implemented in C++ and how they intercon-
nect with each other is presented in appendix B. The explanation is in a high-level in
order to see which modules and classes need to be accessed or created when designing
a mesh network, but the low-level code structure is not described. For more infor-
mation on each module and a more detailed low level explanation, please check NS-3
documentation under Doxygen [19].
First is explained the way the MAC-layer routing is implemented presenting the most
important classes. Then are analyzed the class MeshHelper (used to create a 802.11s
network easier) and MeshPointDevice (developed to create mesh point devices). They
provide some functions to configure the different parameters of the network and its
devices, so the main parameters and the way to configure them is studied.
Finally the parameters of the protocols HWMP and PMP are listed to see how can
they be configured according to their description in section 2.3.
3.4 MAC-layer routing model
The main part of the MAC-layer routing model is the specific type of a network
device, class MeshPointDevice. Being an interface to upper-layer protocols, it pro-
vides routing functionality hidden from upper-layer protocols, by means of the class
MeshL2RoutingProtocol.
This model supports stations with multiple network devices handled by a single MAC-
layer routing protocol. MeshPointDevice serves as an umbrella to multiple network
devices (”interfaces”) working under the same MAC-layer routing protocol. Network
devices may be of different types, each with a specific medium access method.
MAC-layer routing can be seen as a two-level model. MeshL2RoutingProtocol and

MeshPointDevice belong to the upper level. The task of MeshPointDevice is to send,
receive, and forward frames, while the task of MeshL2RoutingProtocol is to resolve
22
routes and keep frames waiting for route resolution. This functionality is independent
from the types of underlying network devices (”interfaces”).
The lower level implements the part of MAC-layer routing, specific for underlying
network devices and their medium access control methods. For example, HWMP
routing protocol in IEEE802.11s uses its own specific management frames.
This level is implemented as two base classes: MeshWifiInterfaceMac and MeshWifiIn-

terfaceMacPlugin. If beacon generation is enabled or disabled, it implements IEEE802.11s
mesh functionality or a simple ad-hoc functionality of the MAC-high part of the WiFi
model.
At present, HWMP with Peer management protocol (which is required by HWMP to

manage peer links) is implemented in this module.
23
Chapter 4
Simulations
4.1 Considerations
Before performing a simulation, four different aspects were considered to establish them
randomly:
• Node position
• Node sender and receiver
• Connection arrival distribution
• Duration of each connection
In ns-3 a global seed can be selected and also which run of this seed to use in the
simulations. Thus, when different protocols or variants of one are compared, it ensures
that the comparison is fair since they use exactly the same values of the four points
stated before.
There is no guarantee that the streams produced by two random seeds will not over-
lap using the ns-3 random generator. The only way to guarantee that two streams
do not overlap is to use the substream capability provided. Therefore, is better to
produce multiple independent runs of the same simulation so we guarantee there is no
25
correlations between them. If we set one seed, then it allows as to generate 2.3 × 1015
independent replications, more than enough if we consider that we usually use around
20 for each scenario.
Furthermore, according to [20], UDP constant bit rate (CBR) traffic must be used
to compare accurately since TCP has a slow start mechanism that can influence the
overall results.
4.2 Figures of merit
For all the protocols tested, the figures of merit taken into account are the followings:
• Average throughput: number of bits received divided by the difference between

the arrival time of the first packet and the last one.
• Average Packet Delivery Fraction (PDF): number of packets received divided by

the number of packets transmitted.
• Average end-to-end delay: the sum of the delay of all received packets divided
by the number of received packets.
• Average routing load ratio: the number of routing bytes received divided by the
number of data bytes received. A value of 1 means that the same amount of
routing bytes and data bytes has been transmitted.
To calculate some of the previous values, the implementation and advices given in [21]
have been used. When is needed, in some scenarios we also analyze the following figures
of merit:
• Number of peer links opened and closed.
• Number of routing packets generated: this concerns RREQ, RREP and RERR
packets.
26
4.3 Environment
The environment used in all the simulations is the one stated below. A log-distance
path loss propagation model has been used. Using this model we predict the loss a
signal encounters in densely populated areas over distance. Its parameters are:
Type: Log-distance path loss

Reference Distance = 1 m
Exponent = 2.7
Reference Loss = 46.7 dB
In all different tests performed, the devices present the following characteristics:
CCA Threshold = -62 dBm

Energy detection Threshold = -89 dBm
Transmission and Reception Gain = 1 dB
Minimum and maximum available transmission level = 18 dbm
Reception Noise Figure = 7 dB
The Clear Channel Assessment (CCA) is a mechanism for determining whether the
medium is idle or not. The CCA includes carrier sensing and energy detection. The
Carrier Sense (CS) mechanism consists of a physical CS and a virtual CS. The physical
CS is provided by the PHY and is a straightforward measuring of the received signal
strength of a valid 802.11 symbol. If it is above a certain level the medium is considered
busy.
The virtual CS is provided by the MAC and referred to as the Network Allocation
Vector (NAV). The NAV works as an indicator for the station when the medium will
become idle the next time and is kept current through the session duration values
included in all frames. The NAV is updated each time a valid 802.11 frame is received
that is not addressed to the receiving station, provided that the duration value is
greater then the current NAV value.
By examining the NAV a station may avoid transmitting even when the physical CS
indicates an idle medium. The energy detection procedure attempts to determine if the
medium is busy by measuring the total energy a station receives, regardless of whether
27
it is a valid 802.11 signal or not. If the received energy is above a certain level the
medium is considered busy. The thresholds for the carrier sense and energy detection
used have been the ones predefined in the 802.11a physical layer (taken into account
that, in the definition of the energy detection threshold of NS-3, the noise figure in
reception has to be considered).
4.3.1 Transmission rate
As explained in the previous sections, the physical model of 802.11a is used. It divides
data up into a series of symbols for transmission (for example at 54 Mbps each symbol
encodes 216 bits). The OFDM encoding used by 802.11a adds six bits for encoding
purposes to the end of the frame and also some more bits are used for the new mesh
frame format (see 2.5). The packet size used is 1024 bytes, the MAC header and Frame
Check Sequence (FCS) are 40 bytes and the mesh header can be up to 24 bytes.
Furthermore, the CSMA/CA network contention protocol is used to listen to the net-
work in order to avoid collisions. In CSMA/CA, as soon as a node needs to send a
packet, it checks if the channel is clear (no other node is transmitting at the time).
If the channel is clear, then the packet is sent. If it is not clear, the node waits for a
randomly chosen period of time and then it checks again. This period of time is called
the backoff factor, and is counted down by a backoff counter. If the channel is clear
when the backoff counter reaches zero, the node transmits the packet otherwise, the
backoff factor is set again and the process is repeated.
Thereby, the data rate available will decrease considerably. With these characteristics
and using the different transmission rates, HWMP can achieve the data rates presented
in table 4.1.
Each date rate presents different modulation and FEC (forward error correction) rates
in order to gain in robustness or in bit rate. That is why, for example, at 54 Mbps each
symbol encodes 216 bits while in 6 Mbps it encodes only 24. Thus, each transmission
rate can achieve the distances presented in figure 4.1.
28
Table 4.1: Data rate for each transmission rate
Transmission Data rate
rate (Mbps) (Mbps)
56 21.7
48 19.1
36 16.4
24 12.9
18 10.7
12 8.1
9 6.5
6 4.7
Figure 4.1: Transmission rate vs. distance
4.3.2 Number of hops
We define the number of hops as the number of nodes we need to go through between a
receiving and a transmitting station. In a wireless network with a half-duplex system,
communication can only go one direction at a time. Thus, if there is one hop between
transmitter and receiver, as the intermediate node cannot receive and send at the same
time, the throughput will decrease around the half.
This effect is seen in figure 4.2 where it presents the PDF and Throughput of HWMP
at different transmission rates according to the number of hops.
29
(a) PDF vs number of hops (b) Throughput vs number of hops
Figure 4.2: HWMP vs number of hops
4.4 Analysis of the interference model
ns-3 uses an additive interference model. In [22] and [23] they recommend this model
and explain and prove that is much more accurate and lead to more trustful results
than other models used in other simulator. This is the case of the capture threshold
model used in ns-2, which inaccurately compares the desired signal strength with only
one interfering signal at a time.
The additive interference model is based on additive interference and SINR (signal-
to-interference-and-noise ratio) thresholding for correct packet reception. Thereby, a
wireless signal is decoded by treating the sum of all the other on-going signal transmis-
sions and environmental disturbances, as noise. Decoding success is probabilistic, and
the success or failure of a signal transmission can be expressed in terms of a bit/packet
error probability which depends on the SINR. For a certain acceptable BER, the SINR
has to exceed an appropriate threshold. Thus, under the additive interference model
a sufficient condition for packet reception is that the SINR remains greater than the
threshold, throughout the duration of the packet transmission.
Furthermore, in ns-3 nodes can have multiple wifi devices on separate channels, and
these devices can coexist with other device types. This removes an architectural lim-
itation found in the other common network simulator ns-2. Presently, however, there
is no model for cross-channel interference or coupling.
30
Some scenarios have been analyzed to evaluate this interference model. In order to
see the effect clearer, the nodes always send packets close to the maximum data rate
available in the link (see table 4.1).
Scenario 1a
90m 90m
node 1 <----------| node 2 - distance - node 3 |----------> node 4
6 Mbps 6 Mbps
Scenario 1a presents the typical situation of 2 nodes content for the channel. As seen
in figure 4.1, the maximum transmission range at 6Mbps is 205m, so when the distance
between nodes is closer, both nodes compete for the channel.
Its variant, scenario 1b, has the same structure as 1a, but the flow between nodes 1
and 2 is now at 12 Mbps. In this case, the packets of the flow 3-4 occupy the channel
for a longer time than flow 1-2 since they are transmitted at a lower rate. Thus, flow
3-4 achieves higher PDF since the load perceived in the channel is higher than the real.
The results for this explanation are printed in figure 4.3.
(a) PDF in Scenario 1a (b) PDF in Scenario 1b
Figure 4.3: Interference Scenarios 1a and 1b
31
Scenario 2a
90m 90m
node 1 |----------> node 2 - distance - node 3 |----------> node 4
6 Mbps 6 Mbps
Scenario 2a presents the hidden terminal situation where the transmitter node 3 is
a hidden terminal for the communication between nodes 1 and 2. A problem with
wireless systems is that every station cannot be expected to hear all other stations as
in a wired network. The problem is referred to as the hidden terminal situation. This
situation occurs when nodes are located such that node 1 cannot hear node 3 and vice
versa, but both 1 and 3 can hear node 2. When 1 attempts to transmit to 2, according
to 1’s CCA, the medium is free and 1 begins a transmission to 2. Unfortunately, the
transmission cannot be received as 2 is occupied by decoding a transmission from 3.
To address this problem the RTS/CTS frames were defined. However, in our case this
feature is disabled because it generates more overhead and is not an efficient mechanism
in mesh networks [24].
In a distance greater than 205m they are far enough to not interfere, thus they achieve
100% of PDF. In the range 110m and 205m, there are collisions between received
packets in node 2 and transmitted packets of node 3 because node 1 does not detect
them. When distance is closer than 110m, transmitters see each other so they start
sharing the medium. As well as in the previous b variant, in scenario 2b the flow 1-2
is set at 12Mbps. Thus, when distance is closer than 110m, it obtains less PDF (see
figure 4.4).
32
(a) PDF in scenario 2a (b) PDF in scenario 2b
Figure 4.4: Interference Scenarios 2a and 2b
33
Chapter 5
HWMP vs. AODV
HWMP is based in AODV but using layer 2 routing instead of layer 3 routing. Thus,
one question could be to know if this new layer 2 routing protocol proposed for mesh
networks will work better than the traditional layer 3 routing.
To answer this question these two protocols were configured to work under the same
conditions and we evaluated their performance in terms of scalability (nodes and con-
nections).
HWMP protocol implemented in this ns-3 version is explained in section 2.3.2 and
appendix B.3. In the appendix A you can find the explanation of the AODV version
on which the ns-3 implementation is based.
5.1 Configuration
First of all, AODV and HWMP had to be configured using the same values for their
parameters taking into account the differences they present. By doing this, we assure
the comparison is fair and the difference in their performances will be caused by their
own ways to route packets (and not because one allows more RREQ packets than the
other, for example).
35
After several tests, HWMP and AODV were configured as shown in table 5.1. In order
to compare accurately both protocols, some default values had to be changed. One
important point was to be sure to activate in both the destination only flag in order
to work as explained in 2.3.2.
The Beacon Collision Avoidance (BCA) mechanism of HWMP is used to detect and
mitigate collisions among beacon frames transmitted by other stations on the same
channel within the range of 2 hops. However, this system produces very limited ad-
vantages when no hidden stations are present and reduces the throughput. Thus, it
was disabled to not drop down the performance of HWMP.
Other important parameters which had to be changed were the Allowed Hello Loss in
AODV and the Max Beacon Loss in HWMP. Especially in the case of this last one, its
initial number was set to 2 (which is extremely low) and sometimes due to the prop-
agation model losses, some connection were set as not valid beforehand. The other
parameters changed were some packets thresholds and retries that can be checked in
the table 5.1.
5.2 Routing metric
One important aspect that must be taken into account is that HWMP uses a radio-
aware routing metric (the Airtime Link Metric, see 2.3.1). On the other hand, AODV
uses the simple hop count metric. So the comparison is being made between a layer
2 routing protocol with a radio-aware metric and a layer 3 routing protocol with hop
count metric.
With the following test, the importance of the routing metric can be observed. Usually
the transmission rate to send control information goes at 6Mbps (this is a broadcast
information, so the most robust modulation is used), while the data transmission can
use higher rates. Fixing the control rate at 6Mbps, the hop count metric will establish
some paths that higher rates of data packets will not be able to use. On the other
hand, while ALM is also affected, as it takes into account the frame error rate, it
selects better routes.
36
Table 5.1: HWMP and AODV parameters
(a) AODV (b) HWMP
Hello interval 3s Random Start 100 ms
Route Request retry 5 Route Request retry 5
Route Request rate limits 10 pkts/s PREQ Min Interval 102.4 ms
Node traversal time 40 ms PERR Min Interval 102.4 ms
Next hop wait 50ms Active path timeout 100 s
Active route timeout 100 s Net transversal time 102.4 ms
Black list timeout 5.599 s Max Queue Length 255
Delete period 15 s PREQ Threshold 10
Timeout buffer 2s PERR Threshold 32
Net diameter 35 Data Threshold 5
Net transversal time 2.799 s DO Flag Enable
Path Discovery Time 5.599 s RF Flag Disable
Max Queue Length 255
Max Queue Time 30 s
Allowed hello loss 20
Gratuitous reply Enable
Destination only Enable
Enable hello Enable
Enable Broadcast Enable
(c) Peer Management Protocol (d) Peer Link
Max Peer Links 32 Retry timeout 40 ms
Max Beacon Shift 15 Holding timeout 40 ms
Beacon Collision Avoidance Disable Confirm timeout 40 ms
Max retries 4
Max Beacon Loss 20
Max Packet Failure 5
A simple test to compare AODV and HWMP using two different constant bit rates (at
6Mbps and 12Mbps) is run under the following characteristics:
• Simulation duration = 180s
• Topology: Randomly distributed in a 600m x 600m region
• Number of nodes = 25
• Number of connections = 5-20
• Connection arrival distribution = Uniform
37
• Duration of each connection = Exponential (mean = 25s)
• Data rate of each connection = 200 Kbps
• Packet size = 1024 bytes
In figure 5.1 the results are plotted. The PDF and Throughput of both protocols
decrease when a higher transmission data rate protocol is used. However, AODV per-
formance decreases considerably more than HWMP one. In average, AODV at 12Mbps
obtains a 35% less of PDF and 38% of throughput compared with its performance at
6Mbps, while in HWMP they decrease in only 10% and 15% respectively.
(a) Throughput (b) PDF
Figure 5.1: Routing metric evaluation
From now on, a constant bit rate at 6Mbps for data packets is used to avoid that this
effect could lead to a fairless comparison.
5.3 Scalability
In this section, the scalability of the protocols is analyzed. A grid topology is used
because it is a common topology for mesh networks and also because is more reliable
when extracting and comparing results than to distribute nodes randomly in a certain
region. Using a random distribution we have an extra variable, the position of the
nodes, making it more difficult to compare results.
38
The grid topologies evaluated are 3x3 (9 nodes), 4x4 (16 nodes), 5x5 (25 nodes) and
6x6 (36 nodes) with 170 meters of separation between nodes. This guarantees that
nodes can only reach directly the closed neighbors and they need to look for a paths
to reach the rest (see results in 4.3.1).
The number of random connections established between the nodes of the scenario is
the same as the number of nodes. They present a uniform arrival distribution with a
duration generated by an exponential variable with a mean of 30 seconds. Using these
parameters we can be sure that with a 300 seconds simulation several connections will
overlap.
The packet size is set to 1024 bytes and the parameter swept is the data rate of each
connection. They start at 50 Kbps until 400 Kbps, so at certain point the network will
be loaded enough to see how each protocol deals with congestion.
5.3.1 Results
As it was explained in 5.2, a different metric can be the reason for important differences.
To be able to see what causes the difference between HWMP and AODV performance,
a third protocol has been tested: HWMP using hop count metric instead of ALM. The
complete results for the figures of merit discussed below are placed at the end of this
chapter in figures 5.5, 5.6, 5.7 and 5.8.
PDF and Throughput
Checking the results for the several scenarios, in smaller grids, the PDF and throughput
are slightly better using HWMP, while in larger grids AODV performs the best. This
is because ALM obtains worse metric values when links are already being used or
interfered (higher error rates in the links) and it tries to find another free path to avoid
collisions (although this is not always the best option). This also explains that, when
selecting a high data rate in a small grid, HWMP is no longer better than AODV (for
example at 400kbps in 4x4). When there is congestion or high load, the error rates
increases due to collision and the metric gets worse.
39
Furthermore, in all cases HWMP hop count performance is between AODV and HWMP
which helps us prove that one of the main reasons of the difference in throughput and
PDF when increasing nodes and connections is the metric.
In average, HWMP outperforms AODV in a 3x3 and 4x4 grid while, in a 6x6 grid,
AODV is the best (in a 5x5 grid they present a similar performance). Thus, AODV
works better than HWMP in terms of PDF and throughput when the number of nodes
and connections are higher. However this difference means a 5% of PDF in the worse
case while usually is less than 3%. Depending on the requirement of the application
used, other figures of merit may present a more significant difference.
End-to-end delay
The end-to-end delays from each protocol present a quite different behavior. In 3x3
and 4x4 grids there is nearly no difference but, in 5x5 and 6x6, AODV obtains larger
delays than HWMP (until 3 times more). The evolution of the delays according to the
grids is presented in figure 5.2.
Figure 5.2: Scalability: delay evolution over the grids
As HWMP hop count has the same delay as HWMP, we can assure that this difference
is not caused by the metric used. Both are distance vector protocols using nearly the
40
same mechanism so a closer look is necessary to determine the reason. By checking the
flows in an scenario, we find out that this delay difference is caused when connections
like the ones presented in table 5.2 appear (flow extracted from a 5x5 grid scenario at
50kbps).
Table 5.2: Scalability: detailed results of a connection

Results AODV HWMP
PDF (%) 39.92 97.58
Average delay (s) 0.7912 0.0094
Rx bitrate (kbps) 33.91 48.87
Tx bitrate (kbps) 50.37 50.37
Time First Tx Packet (s) 68.783 68.783
Time First Rx Packet (s) 86.594 69.636
Time Last Tx Packet (s) 109.252 109.252
Time Last Rx Packet (s) 109.952 109.255
Delay Sum (s) 78.329 2.272
Last Delay (s) 0.7002 0.003
Tx Packets 248 248
Lost Packets 172 6
Time Forwarded 124 0
This example clearly shows that the delay difference is caused by the route discovery
mechanism. Since a node wants to send the first packet until it reaches the destination,
HWMP needs around 1 seconds while AODV needs 18. AODV sends a RREQ and after
a certain time without receiving a RREP it sends again a RREQ (until the maximum
number set, 5 in this case). Not all these packets are lost in collisions, but due to
congestion in some nodes, they are queued and delivered later.
In HWMP this does not happen because the layer 2 control packets have priority and
can cross a link even though this is saturated. This point could make think that
AODV should have less PDF than HWMP. As was explained before, with the airtime
link metric, HWMP tries to avoid links being used and in some occasions it choses a
too long path or even does not find a good route. This effect of the ALM compensates
the other from AODV and this is why the average PDF results are similar.
However, it must be pointed out that this compensation is not always present. The
metric problem of HWMP becomes worse when there are more connections and conges-
tion. Regarding the results using 350-400Kbps in all the scenarios, AODV and HWMP
41
hop count always perform better than standard HWMP using ALM.
In figure 5.3 are plotted the delays of all the connections from the previous example.
Although HWMP routing is usually faster than the AODV one, the responsible for this
high delay difference are the few connections similar to the one in table 5.2. The flow
from the table is number 0 and, as well as flows 13, 20 and 23, the delay generated is
higher than 0.7 seconds. On the other hand, HWMP and AODV have 18 flows out of
25 with a delay smaller than 0.05 seconds and, as HWMP do not present flows with
such a higher delay, the average results are considerably smaller.
Figure 5.3: Scalability: detailed delay of a connection
In all cases we see that HWMP outperforms AODV in terms of delay in a significant
way. This figure of merit is really important in real time application and may be a
crucial aspect when deciding which protocol to use.
Routing Load Ratio
The routing load ratio also presents a significant difference although, depending on the
amount and type of traffic, it may not be as important as the previous one in terms
of QoS. First of all, remember that AODV uses a hello messages mechanism, while
HWMP does not need it. This hello mechanism is the one responsible for the main
42
part of routing load generated by AODV. Thus, since the hello interval is set at 3
seconds, AODV will always presents much more routing load ratio than HWMP.
As the routing load ratio is calculated dividing the routing load bytes received by the
data bytes received (as is explained in 4.2) if more and more data bytes are delivered
without the need of more routing information, the routing load ratio decreases. This
is what happen in the 3x3 grid scenario (figure 5.5). The bit rate of the connections
increases but the PDF does not decrease which means that more packets are delivered
with the same routing information. Thus, the routing load ratio decreases proportion-
ally to the increase of bit rate. Specifically, in AODV it goes from a 0.08 ratio until
0.01 (factor of 8) and in HWMP from 0.02 until 0.005 (factor of 4).
In the other scenarios, when the bit rate is higher, the protocols can not afford it and
the PDF decreases. Thus, the routing load ratio increases because more lost packets
implies the need to generate more routing information. Since AODV always generates
more routing load, this effect can be more clearly seen in the AODV results than in
the HWMP ones. The evolution of the routing load ratio along the bit rate in all the
grids is plotted in figure 5.4.
The routing load ratio in HWMP never reaches more than 0.1 and in the best case can
have a value of 0.005. On the other hand, the minimum value obtained by AODV is
around 0.01, but the maximum one can be almost 5 times the maximum presented by
HWMP. This represents a problem with networks highly congested where this increase
of routing load can deal to even more congestion making the protocol unable to work
properly.
43
Figure 5.4: Scalability: routing load ratio evolution over the grids
(a) Throughput (b) Delay
(c) PDF (d) Routing load ratio (bytes)
Figure 5.5: Scalability results in a 3x3 grid
44
45
46
47
Chapter 6
HWMP Reactive vs. Proactive
As is explained in 2.3.2, the Hybrid Wireless Mesh Protocol can work in a reactive and
in a proactive routing mode. When creating a 802.11s network, something useful to
know could be in which situations the reactive or the proactive mode should be used.
In this chapter the on-demand path selection mode (reactive) and the proactive tree
building mode using PREQ mechanism are analyzed.
The proactive mode ensures that all nodes have a path defined to the root at all time,
so if a node wants to send information to the root there is no need to start a route
discovery procedure. On the other hand, if a node wants to send information to another
node (which is not the root), the sender has to ask to its superior neighbor in the tree
structure if he knows how to reach the target. This action continues until some node
up in the tree knows the way. In the worst case, it will reach the root of the tree (the
root node) who knows a path to all nodes in the network.
This tree mechanism implies that if you want to reach a node member of another
branch of the tree, the chosen path will go through the root node. If the main part
of the traffic of the mesh network is between internal nodes, this mechanism seams
not so good because it generates longer paths and can create congestion in the root
node. However, if the main part of the traffic of the mesh network has an external
destination, this tree mechanism seems a good option because all nodes need to send
the information to the root (which is used as Portal) in order to reach the exterior.
49
To summarize, when there is internal traffic, the reactive mode seems a better option
while in the case of external traffic, the proactive mode should work better.
6.1 Configuration
The configuration of the protocol is also based on the explanations in 5.1. The param-
eters’ values are shown in table 6.1. The main difference is relating the DO and RF
flags.
Table 6.1: HWMP parameters

(a) HWMP (b) Peer Link
Random Start 100 ms Retry timeout 40 ms
Route Request retry 5 Holding timeout 40 ms
PREQ Min Interval 102.4 ms Confirm timeout 40 ms
PERR Min Interval 102.4 ms Max retries 4
Active path timeout 100 s Max Beacon Loss 20
Net transversal time 102.4 ms Max Packet Failure 5
Max Queue Length 255
PREQ Threshold 10
PERR Threshold 32
Data Threshold 5
DO Flag Disable
RF Flag Enable
(c) Peer Management Protocol
Max Peer Links 32
Max Beacon Shift 15
Beacon Collision Avoidance Disable
To be able to evaluate all the capabilities of each mode, the direction only flag must
be disabled. If it is enabled, the reactive mode losses efficiency because for each new
connection it can not rely on the information the neighbors provide. The need of a
complete path discovery process each time increases a lot the chances of collisions.
The proactive case is not so affected for this flag, although it causes its performance
to decrease. When DO flag is enabled, the destination is the only one who can answer
but, as the paths between nodes are already established and a node can only ask to
50
the upper branch of the tree, it does not interfere so much in the performance. The
proactive tree structure guarantees a routing order in the uses of paths that the reactive
mode does not provide.
6.2 Destination Only flag
To check the previous discussed effect of the destination only flag, the analysis of an
small rectangular scenario is proposed. In a small scenario where one node can reach
another one with usually one, two or maximum three hops, both protocols should have
a similar performance if the DO flag is disabled. However, with the DO flag enabled, by
forcing always a route discovery in the reactive mode, its performance should decrease.
As explained before, lots of collisions will appear and, in this case, the effect will be
worse because the node density is high. The scenario analyzed presents the following
parameters:
• Number of connections = 20
For each variant of the scenario, N connections are defined and the number of connec-
tion that have as destination the root node is increased. It starts by setting all nodes to
send information randomly to another node of the mesh network and each time more
and more nodes change their destination to the root node (so simulating they send
traffic to the exterior).
51
The results for the PDF of both modes with DO enabled and disabled are presented
in figure 6.1. As the results show, when the DO flag is disabled, both modes present
a similar PDF. The proactive mode works better when all traffic is external, nearly
gains a 3% more of PDF. The reactive mode may present some problems to find routes
for all nodes to the root node, while the proactive guarantees that all the nodes have
always a path to the root.
When the flag is enabled we see the effect previously explained and the PDF of the
on-demand mode is around 5% less than before (independently of the type of traffic
generated). In terms of PDF, the proactive mode obtains similar results. In all the
following tests, the destination only flag will be disabled so the reactive mode can use
its maximum capabilities.
(a) PDF with DO disabled (b) PDF with DO enabled
Figure 6.1: Destination only flag evaluation in HWMP
6.3 Comparison
In this section, several scenarios are defined to evaluate which mode is better depending
on the type of traffic. As in the destination only flag test, N connections are defined
and the number of connections that have as destination the root node is increased,
therefore increasing the amount of external traffic in each step.
To be able to see the difference between both routing modes, the best choice is to use
a random topology so the tree mechanism of the proactive mode can generate different
52
tree structures. Although it was discussed in the previous chapter that a grid topology
was better to compare AODV and HWMP reactive, in this case a grid topology does not
allow to see a substantial difference in the path selection procedures. However, more
scenarios were meant for each results in order to compare the results more accurately.
These simulations present a larger area than the one used before so connections will
require more hops to reach the destination. Furthermore, more connections are estab-
lished to emphasize the behavior of the protocols depending on the type of traffic. The
main parameters are:
• Number of connections = 28
As the amount of connections is high compared to the simulation duration and the
duration of each connection, we ensure several connection occur at the same time. In
each step of the swept parameter (number of connections), 7 connections are redefined
to set their destination to the root node. Thus, each step represents a 25% more of
external traffic.
6.3.1 Results
To do this comparison all the figures of merit explained in 4.2 are taken into account
and presented in figures 6.2 and 6.3.
53
PDF and Throughput
When all or the main part of the traffic is internal, as it was expected the proactive
mode does not perform as well as the reactive mode. Lots of routes use long not optimal
paths following the branches of the tree and sometimes even generate congestion in the
root node. On the other hand, the reactive mode finds faster and better paths between
nodes.
As more and more external traffic is required, the proactive mode performance improves
until the point that it obtains a 8% more of PDF and 13% more of throughput in the
same scenarios when the traffic is external than when is internal (see figure 6.2). The
reason is that using the tree structure all paths connecting all nodes with the root are
established and maintained.
The PDF of the reactive mode also improves when the main part of the traffic is
external. However, this increase is around a 3% of PDF, so not as much as in the other
mode. This is because all nodes need to find a route to the same node, so they can share
routing information, reducing the routing load and increasing the global performance.
If we linearize the behavior of both modes, the PDF of the proactive mode increases
0.4% for each 20% of external traffic required while in the reactive mode this increase
represents a 0.15%. Thus, when the amount of external traffic generated represents
more than the 50% of the total amount, the HWMP should be used in proactive mode.
End-to-end delay
When nodes mainly send traffic to the exterior, the proactive mode presents a smaller
delay because all nodes already know a route to the destination. However, the proactive
routes are not so useful for internal traffic because the nodes need to start a route
discovery and, due to the tree structure, usually they do not find an optimal path.
Thus, the end-to-end delay decreases as the amount of external traffic increases. In
the full external traffic environment, this proactive mode present a 25% less delay (see
figure 6.2).
54
In the reactive mode, the end-to-end delay does not present such a difference depending
on the traffic type, the maximum difference is around 0.7 ms (which represents a 9%).
When more external traffic is generated, nodes share routing information to reach a
common destination, so it seams that smaller delay should be obtained. However,
several nodes uses the same path to reach the destination generating congestion in
some links.
So, for internal traffic situations, reactive mode is a 11% faster while, in external traffic,
the proactive mode outperforms the reactive one in a 27%. As well as in the PDF,
from 50% of external traffic onwards, HWMP proactive is also a better option.
Routing load
As has been pointed out in the analysis of the previous figures of merit, the routing load
decreases when the traffic is external. They share routing information so the amount
of routing packets decrease and this helps to improve the performance of the protocols.
The proactive mode generates continuously routing information. However, the internal
traffic route discovery procedures of this mode represent a few amount of information
compared to the one used to maintain the proactive paths. Thus, the routing load
ratios do not decrease so much and the route request and reply packets (responsible
for the main part of the routing information) are mainly constant with the change of
traffic type (see figure 6.3).
On the other hand, looking at the number of packets generated or the routing loads
ratios, we see that the reactive mode produces around 10 times less of routing traf-
fic than the proactive mode. In this case, there is no routing information needed to
maintain any paths so when all the nodes share a common destination, less routing
information is needed. In external traffic, the route request packets decrease in a 15%.
However it presents a nearly constant value in the routing load ratio as well as in the
number of links created (figure 6.2). Usually this reactive mode in this scenario need
to create the same amount of links for the same amount of connections.
55
(c) PDF (d) Number of links
Figure 6.2: HWMP modes: Comparison results 1
56
(a) Packets types in reactive (b) Packets types in proactive
(c) Routing load ratio (bytes) (d) Routing load ratio (packets)
Figure 6.3: HWMP modes: Comparison results 2
57
Chapter 7
Conclusions and future work
In this research, a detailed studio of HWMP routing capabilities has been presented.
The implementation of mesh networking in NS-3 has been checked and tested in order
to simulate with as much accuracy as possible the different environments.
In chapter 5, a comparison between HWMP and AODV has been performed to know
the benefits of the MAC-based routing capabilities in front of the commonly used
multihop routing protocol in which HWMP is based, AODV. The results show that
layer 2 routing presents an important advantage in terms of end-to-end delay and
routing load. Difference that increases even more when the number of nodes and
connections is high.
On the other hand, both protocols obtain similar results in terms of packet delivery
fraction. However, in some congestion situations the airtime link metric performs
slightly worse than a normal hop count metric. Despite this difference from which the
routing metric is responsible, we can conclude that the routing at MAC layer clearly
shows benefits in front of the conventional layer 3 routing. This benefits could be of a
high importance when real time applications are used.
In chapter 6, both HWMP operation modes have been discussed to determine in which
environments each one is more suitable. Their performances have been tested in differ-
ent situations of internal and external network traffic. It is concluded that when more
than the half of the traffic is internal, the reactive mode is a better option, while when
59
it is external the best choice is to use the proactive tree based mode. This results can
be used to define a guideline in the ways of use of HWMP.
As future work, more possible scenarios for comparison could be analyzed using dif-
ferent applications and mobility models in order to extract more general conclusions.
Also the physical deployment of a mesh network (for example using the open80211s
linux implementation [4]) would help to check the accuracy of the NS-3 simulator and
its mesh modules, and to know in which aspect they should be improved.
An study on different routing metrics to use with HWMP could be also an important
field of research which would help to improve its performance. ALM presents some
interesting features but, as it has been proved in this research, the hop count metric
works better in some situations.
Another possible line of work could be to develop some mesh networking unsupported
features of NS-3. Thus, it will be possible to define a more complete and complex
environment to test a complete system using a mesh structure. The main features to
develop could be the Mesh Coordinated Channel Access or the Mesh Access Point and
Portal capabilities.
60
Appendix A
AODV routing protocol
The AODV (Ad-hoc On demand Distance Vector) is an on-demand reactive protocol

that uses the distant vector routing algorithm. In AODV, the source node and the
intermediate nodes store the next-hop information corresponding to each flow for data
packet transmission. This protocol uses the messages RREQ (Route Request), RREP
(Route Replies) and RERR (Route Errors).
In AODV, nodes discover routes in request-response cycles. A node requests a route

to a destination by broadcasting an RREQ message to all its neighbors. When a node
receives an RREQ message but does not have a route to the requested destination,
it broadcasts again the RREQ message. Also, it remembers a reverse-route to the
requesting node which can be used to forward subsequent responses to this RREQ.
This process repeats until the RREQ reaches a node that has a valid route to the
destination. This node (which can be the destination itself) responds with an RREP
message. This RREP is unicast along the reverse-routes of the intermediate nodes until
it reaches the original requesting node. Thus, at the end of this request-response cycle
a bidirectional route is established between the requesting node and the destination.
When a node loses connectivity to its next hop, the node invalidates its route by sending
an RERR to all nodes that potentially received its RREP.
The major difference between AODV and other on-demand routing protocols is that
it uses a destination sequence number (DSN) to determine an up-to-date path to the
destination. A node updates its path information only if the DSN of the current
61
packet received is greater than the last DSN stored at the node. A RREQ carries
the source identifier (SrcID), the destination identifier (DestID), the source sequence
number (SSN), the DSN, the broadcast identifier (BcastID), and the time to live (TTL)
field. DSN indicates the freshness of the route that is accepted by the source. When
an intermediate node receives a RREQ, it either forwards it or prepares a RREP if
it has a valid route to the destination. The validity of a route at the intermediate
node is determined by comparing the sequence number at the intermediate node with
the destination sequence number in the RREQ. If a RREQ is received multiple times,
which is indicated by the BcastID-SrcID pair, the duplicate copies are discarded.
All intermediate nodes having valid routes to the destination, or the destination node
itself, are allowed to send RREP packets to the source. Every intermediate node, while
forwarding a RREQ, enters the previous node address and its BcastID. A timer is used
to delete this entry in case a RREP is not received before the timer expires. This
helps in storing an active path at the intermediate node as AODV does not employ
source routing of data packets. When a node receives a RREP, information about the
previous node from which the packet was received is also stored in order to forward
the data packet to this next node as the next hop toward the destination.
All nodes active in the network transmit periodically hello messages (considered as
special RREP messages). If one node does not receive a hello from the neighbors it
means that the connection has been lost and they modify their routing table deleting
that path. It also sends a RRER to the other neighbor nodes that used that path.
Advantages and disadvantages
The AODV routing protocol is designed for networks with populations of tens to thou-
sands of mobile nodes and can handle low, moderate and relatively high mobility rates,
as well as a variety of data traffic levels. AODV has also been designed to reduce the
dissemination of control traffic and eliminate overhead on data traffic, in order to im-
prove scalability and performance.
One of the disadvantages of this protocol is that intermediate nodes can lead to in-
consistent routes if the source sequence number is very old and the intermediate nodes
62
have a higher but not the latest destination sequence number, thereby having stale
entries. Also multiple RREP packets in response to a single RREQ packet can lead to
heavy control overhead. Another disadvantage of AODV is that the periodic beaconing
leads to unnecessary bandwidth consumption.
63
Appendix B
NS-3 802.11s modules
In this appendix, the modules implemented in C++ and how they interconnect with
each other is presented following the description in 3.3.
B.1 MeshHelper
void SetSpreadInterfaceChannels
Parameters: (ChannelPolicy)
Set the channel policy which can be SPREAD CHANNELS or ZERO CHANNEL:
Spread or not spread frequency channels of MP interfaces. If set to true different
non-overlapping 20MHz frequency channels will be assigned to different mesh point
interfaces.
void SetStackInstaller
Parameters: (std::string type, std::string n0 = ””, const AttributeValue &v0 = Empty-

AttributeValue (),...)
You need to tell which Mesh stack do you want, in this case Dot11sStack, so you can
use the characteristics of the 802.11s. n0 and v0 are the name and the value of the
65
attribute to set, respectively. For example you can set the root node in the mesh
network.
void SetNumberOfInterfaces
Parameters: (uint32 t nInterfaces)
Set a number of interfaces in a mesh network.
NetDeviceContainer Install
Parameters: (const WifiPhyHelper &phyHelper, NodeContainer c)
Install 802.11s mesh device and protocols on given node list. The phyHelper is the
Wifi PHY helper and c is the list of nodes to install. This function returns the list of
created mesh point devices, see MeshPointDevice (see next section).
void SetMacType
Parameters: ( std::string n0=””, const AttributeValue &v0 = EmptyAttributeValue

(),...)
Uses the class MeshWifiInterfaceMac and n0 and v0 are the name and the value of the
attribute to set, respectively. The values that can be set are the next ones:
• BeaconInterval : Beacon Interval. Initial value: 0.5 seconds
• RandomStart: Window when beacon generating starts (uniform random) in sec-

onds. Initial value: 0.5 seconds
• BeaconGeneration: Enable/Disable Beaconing. Initial value: enabled
• TxOkHeader : The header of successfully transmitted packet.
• TxErrHeader : The header of unsuccessfully transmitted packet.
66
This class uses the RegularWifiMac class where you can set the QoS support which
enable 802.11e/WMM-style (By default is disable). And at the same time this class
has as parent class WifiMac which we can use to modify values like CTS timeout, ACK
timeout, SIFTS, EIFS-DIFS, duration of a slot, PIFS or the Ssid.
void SetRemoteStationManager
Parameters: (std::string type, std::string n0=””, const AttributeValue &v0 = Empty-

AttributeValue (),...)
With this function, using the variable type we define which station manager do we want.
A part from a constant bit rate value, the following rate control algorithms implemented
in NS-3: AARF, AARF-CD, AMRR, ARF, CARA, Ideal, Minstrel, ONOE and RRAA.
The one selected by default is the ARF.
They all use has as parent class WifiRemoteStationManager, and using the n0 and v0
you can set the maximum number of retransmission attempts for an RTS and data
packets as well as the threshold to decide when to use a RTS/CTS handshake before
sending a data packet and the one to decide when to fragment them. As described in
IEEE Std. 802.11-2007, Section 9.2.6. and 9.4. This value will not have any effect
on some rate control algorithms. Here we can also set a wifi mode for non-unicast
transmissions.
void SetNumberOfInterfaces
Parameters: (uint32 t nInterfaces)
Set a number of interfaces in a mesh network.
void SetStandard
Parameters: (enum WifiPhyStandard standard)
67
Allows you to select the following standards: 802.11 with 5 or 10 Mhz, 802.11a and
802.11b. The one set by default is the 802.11a.
B.2 MeshPointDevice
Mesh point is a virtual net device which is responsible for aggregating and coordinating
real devices (mesh interfaces), and hosting all mesh-related level 2 protocols. One
of hosted L2 protocols must implement L2RoutingProtocol interface and is used for
packets forwarding.
From the level 3 point of view MeshPointDevice is similar to a bridge network device,
but the packets, which going through may be changed (because L2 protocols may
require their own headers or tags).
void AddInterface
Parameters: (Ptr< NetDevice > port)
Attach new interface to the station. Interface must support 48-bit MAC address and
only MeshPointDevice can have IP address, but not individual interfaces.
bool SetMtu
Parameters: (const uint16 t mtu)
Set the MAC-level Maximum Transmission Unit in bytes and returns whether the MTU
value was within legal bounds. Override for default MTU defined on a per-type basis.
void SetRoutingProtocol
Parameters: (Ptr< MeshL2RoutingProtocol > protocol)
68
Register the mesh routing protocol to be used by this mesh point. Protocol must be
already installed on this mesh point.
B.3 HWMP
Here a list of all the parameters which can be configure in this implementation of
HWMP and their values by default is presented.
• RandomStart: Random delay at first proactive PREQ. Initial value: 100ms
• MaxQueueSize: Maximum number of packets we can store when resolving route.

Initial value: 255
• Dot11MeshHWMPmaxPREQretries: Maximum number of retries before we sup-

pose the destination to be unreachable. Initial value: 3
• Dot11MeshHWMPnetDiameterTraversalTime: Time we suppose the packet to

go from one edge of the network to another. Initial value: 102.4ms
• Dot11MeshHWMPpreqMinInterval : Minimal interval between to successive PREQs.

Initial value: 102.4ms
• Dot11MeshHWMPperrMinInterval : Minimal interval between to successive PERRs.

Initial value: 102.4ms
• Dot11MeshHWMPactiveRootTimeout: Lifetime of proactive routing information

(PREQ). Initial value: 5120ms
• Dot11MeshHWMPactivePathTimeout: Lifetime of reactive routing information.

Initial value: 5120ms
• Dot11MeshHWMPpathToRootInterval : Interval between two successive proactive

PREQs. Initial value: 2048ms
• Dot11MeshHWMPrannInterval : Lifetime of proactive routing information (RANN).

Initial value: 5120ms
69
• MaxTtl : Initial value of Time To Live field. Initial value: 32
• UnicastPerrThreshold : Maximum number of PERR receivers, when we send a

PERR as a chain of unicasts. Initial value: 32
• UnicastPreqThreshold : Maximum number of PREQ receivers, when we send a

PREQ as a chain of unicasts. Initial value: 1
• UnicastDataThreshold : Maximum number of broadcast receivers, when we send

a broadcast as a chain of unicasts. Initial value: 1
• DoFlag: Destination only HWMP flag. Initial value: false
• RfFlag: Reply and forward flag. Initial value: true
Through this class we can decide if we want to use the root structure or not in th
proactive PREQ mechanism. For this the function SetRoot and UnsetRoot are avail-
able.
B.4 Peer Management Protocol
Here a list of all the parameters which can be configure in this implementation of PMP
and their values by default is presented.
• MaxNumberOfPeerLinks: Maximum number of peer links. Initial value: 32
• MaxBeaconShiftValue: Maximum number of TUs for beacon shifting. Initial

value: 15
• EnableBeaconCollisionAvoidance: Enable/Disable Beacon collision avoidance.

Initial value: true
When we install the PMP in a device, we also define the Mesh ID where it will belong
using the function SetMeshId.
70
B.5 Peer Link
As the last configurable characteristics of HWMP, here is presented the peer link model
for the Peer Management protocol.
• RetryTimeout: Retry timeout. Initial value: 41 ms
• HoldingTimeout: Holding timeout. Initial value: 41 ms
• ConfirmTimeout: Confirm timeout. Initial value: 41 ms
• MaxRetries: Maximum number of retries. Initial value: 4
• MaxBeaconLoss: Maximum number of lost beacons before link will be closed.

Initial value: 2
• MaxPacketFailure: Maximum number of failed packets before link will be closed.

Initial value: 2
After several test, all these parameters were modified to adapt them to the scenario
characteristics and some of them do not use its default value. This is explained in the
next chapter.
71
Appendix C
NS-3 Scripts
C.1 HWMP Grid
#include "ns3/core-module.h"
#include "ns3/simulator-module.h"
#include "ns3/node-module.h"
#include "ns3/helper-module.h"
#include "ns3/global-routing-module.h"
#include "ns3/wifi-module.h"
#include "ns3/mesh-module.h"
#include "ns3/mobility-module.h"
#include "ns3/mesh-helper.h"
#include "ns3/wifi-phy.h"
#include "ns3/flow-monitor.h"
#include "ns3/flow-monitor-helper.h"
#include "ns3/ipv4-flow-classifier.h"
#include "ns3/random-variable.h"
#include <iostream>
#include <sstream>
#include <fstream>
#include <vector>
using namespace ns3;
73
class MeshTest
{
public:
// Init test
MeshTest ();
// Configure test from command line arguments
void Configure (int argc, char ** argv);
// Run test
int Run ();
private:
int m_xSize; //x size of the grid
int m_ySize; //y size of the grid
double m_step; //separation between nodes
double m_randomStart;
double m_totalTime;
uint16_t m_packetSize;
uint32_t m_nIfaces;
bool m_chan;
bool m_pcap;
std::string m_stack;
std::string m_txrate;
//to calculate the lenght of the simulation

float m_timeTotal, m_timeStart, m_timeEnd;
// List of network nodes

NodeContainer nodes;
// List of all mesh point devices
NetDeviceContainer meshDevices;
// Addresses of interfaces:
Ipv4InterfaceContainer interfaces;
// MeshHelper. Report is not static methods
MeshHelper mesh;
private:
// Create nodes and setup their mobility
void CreateNodes ();
// Install internet m_stack on nodes
void InstallInternetStack ();
// Install applications randomly
void InstallApplicationRandom ();
// Print mesh devices diagnostics
void Report ();
};
MeshTest::MeshTest () :
74
m_xSize (5),
m_ySize (5),
m_step (170),
m_randomStart (0.1),
m_totalTime (240),
m_packetSize (1024),
m_nIfaces (1),
m_chan (false),
m_pcap (false),
m_stack ("ns3::Dot11sStack"),
m_txrate ("150kbps")
{
}
void
MeshTest::Configure (int argc, char *argv[])
{
CommandLine cmd;
cmd.AddValue ("m_xSize", "m_xSize", m_xSize);
cmd.AddValue ("m_ySize", "m_ySize", m_ySize);
cmd.AddValue ("m_txrate", "m_txrate", m_txrate);
cmd.Parse (argc, argv);
}
void MeshTest::CreateNodes ()
{
int i, j;
double m_txpower = 18.0; // dbm
// Calculate m_ySize*m_xSize stations grid topology

double position_x = 0;
double position_y = 0;
ListPositionAllocator myListPositionAllocator;
for (i = 1; i <= m_xSize; i++){

for (j = 1; j <= m_ySize; j++){
std::cout << "Node at x = " << position_x << ", y = " << position_y << "\n";
Vector3D n_pos (position_x, position_y, 0.0);

myListPositionAllocator.Add(n_pos);
position_y += m_step;
}
position_y = 0;
position_x += m_step;
}
75
// Create the nodes
nodes.Create (m_xSize*m_ySize);
// Configure YansWifiChannel
YansWifiPhyHelper WifiPhy = YansWifiPhyHelper::Default ();
WifiPhy.Set ("EnergyDetectionThreshold", DoubleValue (-89.0) );

WifiPhy.Set ("CcaMode1Threshold", DoubleValue (-62.0) );
WifiPhy.Set ("TxGain", DoubleValue (1.0) );
WifiPhy.Set ("RxGain", DoubleValue (1.0) );
WifiPhy.Set ("TxPowerLevels", UintegerValue (1) );
WifiPhy.Set ("TxPowerEnd", DoubleValue (m_txpower) );
WifiPhy.Set ("TxPowerStart", DoubleValue (m_txpower) );
WifiPhy.Set ("RxNoiseFigure", DoubleValue (7.0) );
YansWifiChannelHelper WifiChannel;
WifiChannel.SetPropagationDelay ("ns3::ConstantSpeedPropagationDelayModel");
WifiChannel.AddPropagationLoss ("ns3::LogDistancePropagationLossModel","Exponent",
StringValue ("2.7"));
WifiPhy.SetChannel (WifiChannel.Create ());
// Configure the parameters of the Peer Link

Config::SetDefault ("ns3::dot11s::PeerLink::MaxBeaconLoss", UintegerValue (20));
Config::SetDefault ("ns3::dot11s::PeerLink::MaxRetries", UintegerValue (4));
Config::SetDefault ("ns3::dot11s::PeerLink::MaxPacketFailure", UintegerValue (5));
// Configure the parameters of the Peer Management Protocol

Config::SetDefault ("ns3::dot11s::PeerManagementProtocol::EnableBeaconCollision-
Avoidance",BooleanValue (false));
// Configure the parameters of the HWMP

Config::SetDefault ("ns3::dot11s::HwmpProtocol::Dot11MeshHWMPactivePathTimeout",
TimeValue (Seconds (100)));
Config::SetDefault ("ns3::dot11s::HwmpProtocol::Dot11MeshHWMPactiveRootTimeout",
Config::SetDefault ("ns3::dot11s::HwmpProtocol::Dot11MeshHWMPmaxPREQretries",
UintegerValue (5));
Config::SetDefault ("ns3::dot11s::HwmpProtocol::UnicastPreqThreshold",
UintegerValue (10));
Config::SetDefault ("ns3::dot11s::HwmpProtocol::UnicastDataThreshold",
UintegerValue (5));
Config::SetDefault ("ns3::dot11s::HwmpProtocol::DoFlag", BooleanValue (true));
Config::SetDefault ("ns3::dot11s::HwmpProtocol::RfFlag", BooleanValue (false));
// Stack installer creates all protocols and install them to mesh point device
76
mesh = MeshHelper::Default ();
mesh.SetStandard (WIFI_PHY_STANDARD_80211a);
mesh.SetMacType ("RandomStart", TimeValue (Seconds(m_randomStart)));
mesh.SetRemoteStationManager ("ns3::ConstantRateWifiManager", "DataMode",
StringValue ("OfdmRate6Mbps"), "RtsCtsThreshold", UintegerValue (2500));
// Set number of interfaces - default is single-interface mesh point

mesh.SetNumberOfInterfaces (m_nIfaces);
mesh.SetStackInstaller (m_stack);
//If multiple channels is activated
if (m_chan) {
mesh.SetSpreadInterfaceChannels (MeshHelper::SPREAD_CHANNELS);
}
else {
mesh.SetSpreadInterfaceChannels (MeshHelper::ZERO_CHANNEL);
}
// Install protocols and return container if MeshPointDevices

meshDevices = mesh.Install (WifiPhy, nodes);
// Place the protocols in the positions calculated before

MobilityHelper mobility;
mobility.SetPositionAllocator(&myListPositionAllocator);
mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
mobility.Install (nodes);
}
void MeshTest::InstallInternetStack ()
{
//Install the internet protocol stack on all nodes
InternetStackHelper internetStack;
internetStack.Install (nodes);
//Assign IP addresses to the devices interfaces

Ipv4AddressHelper address;
address.SetBase ("192.168.1.0", "255.255.255.0");
interfaces = address.Assign (meshDevices);
}
void MeshTest::InstallApplicationRandom ()
{
// Create as many connections as nodes has the grid

int m_nconn = m_xSize * m_ySize;
int i=0;
77
int m_source, m_dest, m_dest_port;
char num [2];
char onoff [7];
char sink [6];
double start_time, stop_time, duration;
// Set the parameters of the onoff application

Config::SetDefault ("ns3::OnOffApplication::PacketSize", UintegerValue
(m_packetSize));
Config::SetDefault ("ns3::OnOffApplication::DataRate", StringValue (m_txrate));
ApplicationContainer apps [m_nconn];
UniformVariable rand_nodes (0,m_ySize*m_xSize-1);

UniformVariable rand_port (49000,49100);
// 50 seconds for transitori are left at the beginning.

UniformVariable a(50,m_totalTime-15);
for (i = 0; i < m_nconn; i++){
start_time = a.GetValue();
ExponentialVariable b(30);
duration = b.GetValue()+1;
// If the exponential variable gives us a value that added to the start time
// is greater than the maximum permitted, this is changed for the maximum
// 10 seconds are left at the end to calculate well the statistics of each flow
if ( (start_time + duration) > (m_totalTime - 10)){
stop_time = m_totalTime-10;
}else{
stop_time = start_time + duration;
}
// Create different names for the connections

// (we can not use vectors for OnOffHelper)
strcpy(onoff,"onoff");
strcpy(sink,"sink");
sprintf(num,"%d",i);
strcat(onoff,num);
strcat(sink,num);
// Set random variables of the destination (server) and destination port.

m_dest = rand_nodes.GetInteger (0,m_ySize*m_xSize-1);
m_dest_port = rand_port.GetInteger (49000,49100);
78
// Set random variables of the source (client)
m_source = rand_nodes.GetInteger (0,m_ySize*m_xSize-1);
// Client and server can not be the same node.

while (m_source == m_dest){
}
// Plot the connection values

std::cout << "\n\t Node "<< m_source << " to " << m_dest;
std::cout << "\n Start_time: " << start_time << "s";
std::cout << "\n Stop_time: " << stop_time << "s\n";
// Define UDP traffic for the onoff application

OnOffHelper onoff ("ns3::UdpSocketFactory", Address (InetSocketAddress
(interfaces.GetAddress (m_dest), m_dest_port)));
onoff.SetAttribute ("OnTime", RandomVariableValue (ConstantVariable (1)));
onoff.SetAttribute ("OffTime", RandomVariableValue (ConstantVariable (0)));
apps[i] = onoff.Install (nodes.Get(m_source));
apps[i].Start (Seconds (start_time));
apps[i].Stop (Seconds (stop_time));
// Create a packet sink to receive the packets

PacketSinkHelper sink ("ns3::UdpSocketFactory",InetSocketAddress
(interfaces.GetAddress (m_dest), 49001));
apps[i] = sink.Install (nodes.Get (m_dest));
apps[i].Start (Seconds (1.0));
int MeshTest::Run ()
{
CreateNodes ();
InstallInternetStack ();
InstallApplicationRandom ();
// Install FlowMonitor on all nodes

FlowMonitorHelper flowmon;
Ptr<FlowMonitor> monitor = flowmon.InstallAll();
m_timeStart=clock();
Simulator::Schedule (Seconds(m_totalTime), & MeshTest::Report, this);
Simulator::Stop (Seconds (m_totalTime));
Simulator::Run ();
79
// Define variables to calculate the metrics
int k=0;
int totaltxPackets = 0;
int totalrxPackets = 0;
double totaltxbytes = 0;
double totalrxbytes = 0;
double totaldelay = 0;
double totalrxbitrate = 0;
double difftx, diffrx;
double pdf_value, rxbitrate_value, txbitrate_value, delay_value;

double pdf_total, rxbitrate_total, delay_total;
//Print per flow statistics

monitor->CheckForLostPackets ();
Ptr<Ipv4FlowClassifier> classifier = DynamicCast<Ipv4FlowClassifier>
(flowmon.GetClassifier ());
std::map<FlowId, FlowMonitor::FlowStats> stats = monitor->GetFlowStats ();
for (std::map<FlowId, FlowMonitor::FlowStats>::const_iterator i = stats.begin ();
i != stats.end (); ++i)
{
Ipv4FlowClassifier::FiveTuple t = classifier->FindFlow (i->first);
difftx = i->second.timeLastTxPacket.GetSeconds() -
i->second.timeFirstTxPacket.GetSeconds();
diffrx = i->second.timeLastRxPacket.GetSeconds() -
i->second.timeFirstRxPacket.GetSeconds();
pdf_value = (double) i->second.rxPackets / (double) i->second.txPackets * 100;

txbitrate_value = (double) i->second.txBytes * 8 / 1024 / difftx;
if (i->second.rxPackets != 0){
rxbitrate_value = (double)i->second.rxPackets * m_packetSize * 8 /
1024 / diffrx;
delay_value = (double) i->second.delaySum.GetSeconds() /
(double) i->second.rxPackets;
}
else{
rxbitrate_value = 0;
delay_value = 0;
}
// We are only interested in the metrics of the data flows

if ((!t.destinationAddress.IsSubnetDirectedBroadcast("255.255.255.0")))
{
k++;
80
// Plot the statistics for each data flow
std::cout << "\nFlow " << k << " (" << t.sourceAddress << " -> "
<< t.destinationAddress << ")\n";
//std::cout << "Tx Packets: " << i->second.txPackets << "\n";
//std::cout << "Rx Packets: " << i->second.rxPackets << "\n";
//std::cout << "Lost Packets: " << i->second.lostPackets << "\n";
//std::cout << "Dropped Packets: " << i->second.packetsDropped.size() << "\n";
std::cout << "PDF: " << pdf_value << " %\n";
std::cout << "Average delay: " << delay_value << "s\n";
std::cout << "Rx bitrate: " << rxbitrate_value << " kbps\n";
std::cout << "Tx bitrate: " << txbitrate_value << " kbps\n\n";
// Acumulate for average statistics

totaltxPackets += i->second.txPackets;
totaltxbytes += i->second.txBytes;
totalrxPackets += i->second.rxPackets;
totaldelay += i->second.delaySum.GetSeconds();
totalrxbitrate += rxbitrate_value;
totalrxbytes += i->second.rxBytes;
}
}
// Average all nodes statistics

if (totaltxPackets != 0){
pdf_total = (double) totalrxPackets / (double) totaltxPackets * 100;
}
else{
pdf_total = 0;
}
if (totalrxPackets != 0){
rxbitrate_total = totalrxbitrate;
delay_total = (double) totaldelay / (double) totalrxPackets;
}
else{
rxbitrate_total = 0;
delay_total = 0;
}
//print all nodes statistics

std::cout << "\nTotal PDF: " << pdf_total << " %\n";
std::cout << "Total Rx bitrate: " << rxbitrate_total << " kbps\n";
std::cout << "Total Delay: " << delay_total << " s\n";
//print all nodes statistics in files
81
std::ostringstream os;
os << "1_HWMP_PDF.txt";
std::ofstream of (os.str().c_str(), ios::out | ios::app);
of << pdf_total << "\n";
of.close ();
std::ostringstream os2;
os2 << "1_HWMP_Delay.txt";
std::ofstream of2 (os2.str().c_str(), ios::out | ios::app);
of2 << delay_total << "\n";
of2.close ();
os3 << "1_HWMP_Throu.txt";
of3 << rxbitrate_total << "\n";
of3.close ();
Simulator::Destroy ();
m_timeEnd=clock();
m_timeTotal=(m_timeEnd - m_timeStart)/(double) CLOCKS_PER_SEC;
std::cout << "\n*** Simulation time: " << m_timeTotal << "s\n\n";
return 0;
}
void MeshTest::Report ()
{
// Using this function we print detailed statistics of each mesh point device
// These statistics are used later with an AWK files to extract routing metrics
unsigned n (0);
for (NetDeviceContainer::Iterator i = meshDevices.Begin ();

i != meshDevices.End (); ++i, ++n)
{
//os << "mp-report1-" << n << ".xml";
os << "mp-report.xml";
std::ofstream of;
of.open (os.str().c_str(), ios::out | ios::app);
if (! of.is_open ())
{
std::cerr << "Error: Can’t open file " << os.str() << "\n";
return;
}
mesh.Report (*i, of);
82
of.close ();
}
n = 0;
}
int main (int argc, char *argv[])

{
MeshTest t;
t.Configure (argc, argv);
return t.Run();
}
C.2 AODV Grid
#includes are the same as in the previous script
class MeshTest
{
public:
// Init test
MeshTest ();
// Run test
int Run ();
private:
int m_xSize; //x size of the grid
int m_ySize; //y size of the grid
double m_step; //separation between nodes
double m_totalTime;
bool m_pcap;
double m_txrate_dob;

83
// List of all wifi devices
NetDeviceContainer wifiDevices;
//Addresses of interfaces:
WifiHelper wifi_aodv;
private:
};
m_xSize (5),
m_ySize (5),
m_step (170),
m_totalTime (240),
m_pcap (false),
m_txrate ("150kbps"),
m_txrate_dob (150) //needed in kbps for the trace file
{
}
void
{
CommandLine cmd;
cmd.AddValue ("m_xSize", "m_xSize", m_xSize);
cmd.AddValue ("m_ySize", "m_ySize", m_ySize);
cmd.AddValue ("m_txrate", "m_txrate", m_txrate);
cmd.AddValue ("m_txrate_dob", "m_txrate_dob", m_txrate_dob);
}
{
int i, j;
// Calculate m_ySize*m_xSize stations grid topology
84
double position_x = 0;
double position_y = 0;
ListPositionAllocator myListPositionAllocator;
for (i = 1; i <= m_xSize; i++){

for (j = 1; j <= m_ySize; j++){
std::cout << "Node at x = " << position_x << ", y = " << position_y << "\n";
Vector3D n_pos (position_x, position_y, 0.0);

myListPositionAllocator.Add(n_pos);
position_y += m_step;
}
position_y = 0;
position_x += m_step;
}
// Create the nodes

nodes.Create (m_xSize*m_ySize);

wifi_aodv.SetStandard (WIFI_PHY_STANDARD_80211a);
wifi_aodv.SetRemoteStationManager ("ns3::ConstantRateWifiManager", "DataMode",
// Install protocols and return container

NqosWifiMacHelper wifiMac = NqosWifiMacHelper::Default();
wifiMac.SetType ("ns3::AdhocWifiMac");
wifiDevices = wifi_aodv.Install (WifiPhy, wifiMac, nodes);
85
// Place the protocols in the positions calculated before
mobility.SetPositionAllocator(&myListPositionAllocator);
}
{
//configure AODV
AodvHelper aodv;
aodv.Set ("AllowedHelloLoss", UintegerValue (20));
aodv.Set ("HelloInterval", TimeValue (Seconds (3)));
aodv.Set ("RreqRetries", UintegerValue (5));
aodv.Set ("ActiveRouteTimeout", TimeValue (Seconds (100)));
aodv.Set ("DestinationOnly", BooleanValue (true));

internetStack.SetRoutingHelper (aodv);
//Assign IP addresses to the devices interfaces (m_nIfaces)

address.SetBase ("192.168.1.0", "255.255.255.0");
interfaces = address.Assign (wifiDevices);
}
{
// Create as many connections as nodes has the grid

int m_nconn = m_xSize * m_ySize;
int i=0;
char num [2];
char onoff [7];
char sink [6];

Config::SetDefault ("ns3::OnOffApplication::PacketSize",
UintegerValue (m_packetSize));
86
UniformVariable rand_nodes (0,m_ySize*m_xSize-1);

}else{
}
// Create different names for the connections

// (we can not use vectors for OnOffHelper)
strcat(onoff,num);
strcat(sink,num);
// Set random variables of the destination (server) and destination port.

m_dest = rand_nodes.GetInteger (0,m_ySize*m_xSize-1);
// Set random variables of the source (client)


}

87
// Create a packet sink to receive the packets

{
CreateNodes ();

Simulator::Run ();

int k=0;
int totaltxPacketsR = 0;
int totalrxPacketsR = 0;
double totaltxbytesR = 0;
double totalrxbytesR = 0;
88

double RL_rx_pack, RL_tx_pack, RL_rx_bytes, RL_tx_bytes;

{

rxbitrate_value = (double) i->second.rxPackets * m_packetSize * 8
/ 1024 / diffrx;
}
else{
delay_value = 0;
}
// We are only interested in the metrics of the data flows. This AODV
// implementation create other flows with routing information at low bitrates,
// so a margin is defined to ensure that only our data flows are filtered.
if ( (!t.destinationAddress.IsSubnetDirectedBroadcast("255.255.255.0")) &&
(txbitrate_value > m_txrate_dob/1.2) && (rxbitrate_value < m_txrate_dob*1.2))
{
k++;
89

}
else{
totaltxbytesR += i->second.txBytes;
totalrxbytesR += i->second.rxBytes;
totaltxPacketsR += i->second.txPackets;
totalrxPacketsR += i->second.rxPackets;
}
}
//Average all nodes statistics

RL_tx_pack = (double) totaltxPacketsR / (double) totaltxPackets;
RL_tx_bytes = totaltxbytesR / totaltxbytes;
}
else{
pdf_total = 0;
RL_tx_pack = 0;
RL_tx_bytes = 0;
}
RL_rx_pack = (double) totalrxPacketsR / (double) totalrxPackets;
RL_rx_bytes = totalrxbytesR / totalrxbytes;
}
else{
delay_total = 0;
RL_rx_pack = 0;
RL_rx_bytes = 0;
}
90
// Print all nodes statistics
// Print all nodes statistics in files

os << "1_AODV_PDF.txt";
os2 << "1_AODV_Delay.txt";
os3 << "1_AODV_Throu.txt";
os5 << "1_AODV_RL_RxBytes.txt";
of5 << RL_rx_bytes << "\n";
os7 << "1_AODV_RL_RxPack.txt";
of7 << RL_rx_pack << "\n";
of.close (); of2.close (); of3.close (); of5.close (); of7.close ();
m_timeEnd=clock();
return 0;
}

{
MeshTest t;
return t.Run();
}
91
C.3 HWMP different modes
#include "ns3/core-module.h"
#include "ns3/simulator-module.h"
#include "ns3/node-module.h"
#include "ns3/helper-module.h"
#include "ns3/global-routing-module.h"
#include "ns3/wifi-module.h"
#include "ns3/mobility-module.h"
#include "ns3/mesh-helper.h"
#include "ns3/wifi-phy.h"
#include "ns3/flow-monitor.h"
#include "ns3/flow-monitor-helper.h"
#include "ns3/ipv4-flow-classifier.h"
#include "ns3/random-variable.h"
#include "ns3/boolean.h"
#include <iostream>
#include <sstream>
#include <fstream>
#include <vector>
class MeshTest
{
public:
// Init test
MeshTest ();
// Run test
int Run ();
private:
int m_nnodes; // number of nodes
int m_nconn; // number of connections
int m_nconnR; // number of connections to the root
double m_step;
92
double m_randomStart;
double m_totalTime;
uint32_t m_nIfaces;
bool m_chan;
bool m_pcap;
std::string m_stack;
int m_reactive;


NetDeviceContainer meshDevices;
MeshHelper mesh;

NodeContainer nodesC;
NetDeviceContainer meshDevicesC;
Ipv4InterfaceContainer interfacesC;
MeshHelper meshC;
private:
// Print mesh devices diagnostics
void Report ();

void CreateNodesC ();
void InstallInternetStackC ();
};
93
m_nnodes (25),
m_nconn (28),
m_nconnR (0),
m_step (720),
m_randomStart (0.5),
m_totalTime (240),
m_nIfaces (1),
m_chan (false),
m_pcap (false),
m_stack ("ns3::Dot11sStack"),
m_reactive (1),
m_txrate ("120kbps")
{
}
void
{
CommandLine cmd;
cmd.AddValue ("m_step", "Separation", m_step);
cmd.AddValue ("m_nconn", "Number of connections", m_nconn);
cmd.AddValue ("m_nconnR", "Number of root connections", m_nconnR);
cmd.AddValue ("m_reactive", "Mode type", m_reactive);
}
{
std::string m_root;
// Calculate nnodes stations random topology

nodes.Create (nnodes);
// Setup mobility - static rectangle topology

mobility.SetPositionAllocator ("ns3::RandomRectanglePositionAllocator",
"X", RandomVariableValue (UniformVariable (0, m_step)),
"Y", RandomVariableValue (UniformVariable (0, m_step/2)));
94
// Configure the parameters of the Peer Link

Config::SetDefault ("ns3::dot11s::PeerLink::MaxBeaconLoss", UintegerValue (20));
Config::SetDefault ("ns3::dot11s::PeerLink::MaxRetries", UintegerValue (4));
Config::SetDefault ("ns3::dot11s::PeerLink::MaxPacketFailure", UintegerValue (5));
// Configure the parameters of the Peer Management Protocol

Config::SetDefault ("ns3::dot11s::PeerManagementProtocol::EnableBeaconCollision-
Avoidance", BooleanValue (false));
// Configure the parameters of the HWMP

Config::SetDefault ("ns3::dot11s::HwmpProtocol::Dot11MeshHWMPactivePathTimeout",
Config::SetDefault ("ns3::dot11s::HwmpProtocol::Dot11MeshHWMPactiveRootTimeout",
Config::SetDefault ("ns3::dot11s::HwmpProtocol::Dot11MeshHWMPmaxPREQretries",
UintegerValue (5));
Config::SetDefault ("ns3::dot11s::HwmpProtocol::UnicastPreqThreshold",
UintegerValue (10));
Config::SetDefault ("ns3::dot11s::HwmpProtocol::UnicastDataThreshold",
UintegerValue (5));
Config::SetDefault ("ns3::dot11s::HwmpProtocol::DoFlag", BooleanValue (false));
Config::SetDefault ("ns3::dot11s::HwmpProtocol::RfFlag", BooleanValue (true));
// Create mesh helper and set stack installer to it

// Stack installer creates all needed protocols and install them to device
mesh = MeshHelper::Default ();
mesh.SetStandard (WIFI_PHY_STANDARD_80211a);
mesh.SetMacType ("RandomStart", TimeValue (Seconds(m_randomStart)));
mesh.SetRemoteStationManager ("ns3::ConstantRateWifiManager", "DataMode",
95
// Set number of interfaces - default is single-interface mesh point
mesh.SetNumberOfInterfaces (m_nIfaces);
if (m_reactive == 1) {
//If reactive mode is on, we do not use "Root" attribute
m_root = "Reactive mode";
}
else{
//If proactive mode is on, we define node 6 as root
m_root = "00:00:00:00:00:06";
mesh.SetStackInstaller (m_stack, "Root", Mac48AddressValue
(Mac48Address (m_root.c_str ())));
}
std::cout << "\n\t root: " << m_root << "\n";
//If multiple channels is activated

if (m_chan) {
mesh.SetSpreadInterfaceChannels (MeshHelper::SPREAD_CHANNELS);
}
else {
mesh.SetSpreadInterfaceChannels (MeshHelper::ZERO_CHANNEL);
}
// Install protocols and return container if MeshPointDevices

meshDevices = mesh.Install (WifiPhy, nodes);
}
void MeshTest::CreateNodesC ()
{
// We only create the extra node
nodesC.Create (1);
meshC = MeshHelper::Default ();

meshDevicesC = meshC.Install (WifiPhy, nodesC);
// This extra node is placed far away to not interfere

Vector3D n1_posC (m_step*3, m_step*3, m_step*3);
96
ListPositionAllocator myListPositionAllocatorC;
myListPositionAllocatorC.Add(n1_posC);
MobilityHelper mobilityC;
mobilityC.SetPositionAllocator(&myListPositionAllocatorC);
mobilityC.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
mobilityC.Install (nodesC);
}
{
//Assign IP addresses to the devices interfaces (m_nIfaces)

address.SetBase ("192.168.1.0", "255.255.255.0");
interfaces = address.Assign (meshDevices);
}
void MeshTest::InstallInternetStackC ()
{
internetStack.Install (nodesC);
//Assign IP addresses to the extra node is also from another network

address.SetBase ("192.168.2.0", "255.255.255.0");
interfacesC = address.Assign (meshDevicesC);
}
{
int i=0;
int ir=0;
char num [2];
char onoff [7];
char sink [6];
97
Config::SetDefault ("ns3::OnOffApplication::PacketSize",
UintegerValue (m_packetSize));
UniformVariable rand_nodes (0,nnodes-1);


}else{
}
//create different names for the connections

//(we can not use vectors for OnOffHelper)
strcat(onoff,num);
strcat(sink,num);
//set random variables of the destination (server) and destination port.

m_dest = rand_nodes.GetInteger (0,nnodes-1);
//change the destination to the root if more root traffic is required

if (ir < m_nconnR){
m_dest = 5;
ir++;
}
98
// Set random variables of the source (client).
m_source = rand_nodes.GetInteger (0,nnodes-1);

m_source = rand_nodes.GetInteger (0,nnodes-1);
}


// Create a packet sink to receive these packets

}
}
{
CreateNodes ();
// In this mesh implementation when the proactive mode is used, when creating
// the root node this counts as if there was another node. Thus, when using
// the seed for the random variables it gives different values in reactive
// and proactive mode. To solve this, in reactive mode a fake mode that does
// not communicate neither interfere is created.
if (m_reactive == 1) {
CreateNodesC ();
InstallInternetStackC ();
std::cout << "\n Node: Installing extra node to compensate the root\n";
}
99

Simulator::Schedule (Seconds(m_totalTime), & MeshTest::Report, this);
Simulator::Run ();

int k=0;


{

rxbitrate_value = (double)i->second.rxPackets * m_packetSize * 8 /
1024 / diffrx;
100
}
else{
delay_value = 0;
}
// We are only interested in the metrics of the data flows

if ((!t.destinationAddress.IsSubnetDirectedBroadcast("255.255.255.0")))
{
k++;
// Plot the statistics for each data flow


}
}
// Average all nodes statistics

}
else{
pdf_total = 0;
}
}
101
else{
delay_total = 0;
}
//print all nodes statistics

//print all nodes statistics in files

os << "1_HWMP_PDF.txt";
of.close ();
os2 << "1_HWMP_Delay.txt";
of2.close ();
os3 << "1_HWMP_Throu.txt";
of3.close ();
m_timeEnd=clock();
return 0;
}
void MeshTest::Report ()
{
// Using this function we print detailed statistics of each mesh point device
// These statistics are used later with an AWK files to extract routing metrics
unsigned n (0);
for (NetDeviceContainer::Iterator i = meshDevices.Begin ();

i != meshDevices.End (); ++i, ++n)
102
{
//os << "mp-report1-" << n << ".xml";
os << "mp-report.xml";
std::ofstream of;
of.open (os.str().c_str(), ios::out | ios::app);
if (! of.is_open ())
{
std::cerr << "Error: Can’t open file " << os.str() << "\n";
return;
}
mesh.Report (*i, of);
of.close ();
}
n = 0;
}

{
MeshTest t;
return t.Run();
}
103
Bibliography
[1] C. Perkins, E. Belding-Royer, and S. Das, “Ad hoc on-demand distance vector
(AODV) routing,” IETF RFC 3561, 2003.
[2] I. Akyildiz and X. Wang, “A survey on wireless mesh networks,” Communications

Magazine, IEEE, vol. 43, pp. S23 – S30, sept. 2005.
[3] “IEEE Draft Standard for Information Technology-Telecommunications and in-

formation exchange between systems-Local and metropolitan area networks-
Specific requirements-Part 11: Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) specifications-Amendment 10: Mesh Networking,” IEEE
P802.11s/D10.0, March 2011, pp. 1 –379, 29 2011.
[4] open80211s, “www.open80211s.org/.”
[5] M.-X. Hu and G.-S. Kuo, “Delay and throughput Analysis of IEEE 802.11s Net-
works,” in Communications Workshops, 2008. ICC Workshops ’08. IEEE Inter-
national Conference on, pp. 73 –78, may 2008.
[6] J. Yan, S. Zhang, Y. Sun, and H. Feng, “Performance Analysis of the IEEE
802.11s Common Channel Framework,” in Wireless Communications, Networking
and Mobile Computing, 2008. WiCOM ’08. 4th International Conference on, pp. 1
–4, oct. 2008.
[7] S. Ghannay, S. Gammar, and F. Kamoun, “Performance comparison of hop count

and radio aware path selection protocols in IEEE 802.11s WLAN mesh networks,”
in Wireless Days, 2008. WD ’08. 1st IFIP, pp. 1 –5, nov. 2008.
105
[8] K. Yang, J. feng Ma, and Z. hui Miao, “Hybrid Routing Protocol for Wireless
Mesh Network,” in Computational Intelligence and Security, 2009. CIS ’09. In-
ternational Conference on, vol. 1, pp. 547 –551, dec. 2009.
[9] L. J. S. Cuenca, “802.11s based wireless mesh network (WMN) test-bed,” 2010.
[10] Y.-D. Lin, S.-L. Tsao, S.-L. Chang, S.-Y. Cheng, and C.-Y. Ku, “Design issues and
experimental studies of wireless LAN Mesh,” Wireless Communications, IEEE,
vol. 17, pp. 32 –40, april 2010.
[11] P. Pandey, S. Satish, J. Kuri, and H. Dagale, “Implementation of IEEE 802.11s

mesh nodes with enhanced features,” in Mobile Adhoc and Sensor Systems, 2009.
MASS ’09. IEEE 6th International Conference on, pp. 639 –644, oct. 2009.
[12] X. Wang and A. O. Lim, “IEEE 802.11s wireless mesh networks: Framework and
challenges,” Ad Hoc Networks, 2007.
[13] G. Hiertz, D. Denteneer, S. Max, R. Taori, J. Cardona, L. Berlemann, and

B. Walke, “IEEE 802.11s: The WLAN Mesh Standard,” Wireless Communica-
tions, IEEE, vol. 17, pp. 104 –111, february 2010.
[14] Y. Chen and S. Emeott, “MDA simulation study: Robustness to non-MDA inter-
ferers,” IEEE 802 Plenary Meeting, 2007.
[15] R. Carrano, L. Magalha andes, D. Saade, and C. Albuquerque, “IEEE 802.11s

Multihop MAC: A Tutorial,” Communications Surveys Tutorials, IEEE, vol. 13,
pp. 52 –67, quarter 2011.
[16] “Draft STANDARD for Information Technology-Telecommunications and infor-

mation exchange between systems-Local and metropolitan area networks-Specific
requirements-Part 11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) specifications Amendment 10: Mesh Networking,” IEEE Unapproved
Draft Std P802.11s/D3.0, Mar 2009, 2009.
[17] K. Andreev and P. Boyko, “IEEE 802.11s mesh networking NS-3 model,” 2009.
[18] “NS-3 network simulator official website, www.nsnam.org.”
[19] “NS-3 doxygen documentation, www.nsnam.org/doxygen-release/index.html.”
106
[20] J. B. et al., “A performance comparison of ad-hoc multihop wireless networks
routing protocols,” Proc. IEEE/ACM MOBICOM, 1998.
[21] G. Carneiro, P. Fortuna, and M. Ricardo, “Flowmonitor - a network monitoring

framework for the network simulator 3,” NSTOOLS, 2009.
[22] K. Jain, J. Padhye, V. N. Padmanabhan, and L. Qiu, “Impact of interference on

multi-hop wireless network performance,” Proc. ACM/IEEE MOBICOM, 2003.
[23] A. Iyer, C. Rosenberg, and A. Karnik, “What is the right model for wireless
channel interference?,” Wireless Communications, IEEE Transactions on, vol. 8,
pp. 2662 –2671, may 2009.
[24] S. Ray, J. Carruthers, and D. Starobinski, “RTS/CTS-induced congestion in ad

hoc wireless LANs,” in Wireless Communications and Networking, 2003. WCNC
2003. 2003 IEEE, vol. 3, pp. 1516 –1521 vol.3, march 2003.
107
List of Figures
2.1 The 802.11s network architecture . . . . . . . . . . . . . . . . . . . . . 7
2.2 Peer link establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 HWMP on-demand route discovery. . . . . . . . . . . . . . . . . . . . . 13
2.4 HWMP proactive PREQ route discovery. . . . . . . . . . . . . . . . . . 14
2.5 IEEE 802.11s frame structure . . . . . . . . . . . . . . . . . . . . . . . 17
4.1 Transmission rate vs. distance . . . . . . . . . . . . . . . . . . . . . . . 29
4.2 HWMP vs number of hops . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3 Interference Scenarios 1a and 1b . . . . . . . . . . . . . . . . . . . . . . 31
4.4 Interference Scenarios 2a and 2b . . . . . . . . . . . . . . . . . . . . . . 33
5.1 Routing metric evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2 Scalability: delay evolution over the grids . . . . . . . . . . . . . . . . . 40
5.3 Scalability: detailed delay of a connection . . . . . . . . . . . . . . . . 42
5.4 Scalability: routing load ratio evolution over the grids . . . . . . . . . . 44
5.5 Scalability results in a 3x3 grid . . . . . . . . . . . . . . . . . . . . . . 44
109
6.1 Destination only flag evaluation in HWMP . . . . . . . . . . . . . . . . 52
6.2 HWMP modes: Comparison results 1 . . . . . . . . . . . . . . . . . . . 56
6.3 HWMP modes: Comparison results 2 . . . . . . . . . . . . . . . . . . . 57
110
List of Tables
2.1 ALM constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Frame types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1 Data rate for each transmission rate . . . . . . . . . . . . . . . . . . . . 29
5.1 HWMP and AODV parameters . . . . . . . . . . . . . . . . . . . . . . 37
5.2 Scalability: detailed results of a connection . . . . . . . . . . . . . . . . 41
6.1 HWMP parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
111

IEEE 802.11s Mesh Networking Evaluation under NS-3

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IEEE 802.11s Mesh Networking Evaluation under NS-3

Uploaded by

Copyright:

Available Formats

PROJECTE FINAL DE CARRERA

IEEE 802.11s Mesh Networking

Estudis: Enginyeria Electrònica

Keywords: 802.11s, mesh networking, routing protocol, HWMP, AODV, NS-3

1.1 The need of a new standard . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 State of the art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Aim of this research . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4 Structure of the report . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Network design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Mesh formation and management . . . . . . . . . . . . . . . . . . . . . 7

2.2.1 Mesh Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.2 Mesh creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 Path selection mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3.1 Airtime Link Metric . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3.2 Hybrid Wireless Mesh Protocol . . . . . . . . . . . . . . . . . . 10

2.4 Medium Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.5 Frame structure and syntax . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1 Network Simulator 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2 Model design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.1 Supported features . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.2 Unsupported features . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3 Model implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.4 MAC-layer routing model . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.2 Figures of merit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.3.1 Transmission rate . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.3.2 Number of hops . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.4 Analysis of the interference model . . . . . . . . . . . . . . . . . . . . . 30

5 HWMP vs. AODV 35

5.2 Routing metric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6 HWMP Reactive vs. Proactive 49

6.2 Destination Only flag . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

A AODV routing protocol 61

B NS-3 802.11s modules 65

B.4 Peer Management Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 70

B.5 Peer Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

C.1 HWMP Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

C.2 AODV Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

C.3 HWMP different modes . . . . . . . . . . . . . . . . . . . . . . . . . . 92

List of figures 109

List of tables 111

1.1 The need of a new standard

• This dependency is costly and inflexible, as WLAN coverage cannot be extended

• Centralized structures work inefficiently with new applications, such as wireless

To realize the benefits of a MAC-based WMN, an integrated mesh networking solution

1.2 State of the art

1.4 Structure of the report

2.1 Network design

2.2 Mesh formation and management

2.2.1 Mesh Profile

• The path selection protocol

• The path selection metric

In infrastructured wireless networks, a Service Set Identifier (SSID) is used to dis-

2.2.2 Mesh creation

2.3 Path selection mechanisms

2.3.1 Airtime Link Metric

Table 2.1: ALM constants

2.3.2 Hybrid Wireless Mesh Protocol

The on-demand routing protocol is specified based on Ad-hoc On-demand Distance

Four information elements are specified for HWMP:

• Root announcement (RANN)

• Path request (PREQ)

• Path reply (PREP)

• Path error (PERR)