See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/220955607

An architecture for the implementation of Mesh Networks in OMNeT++

Conference Paper · January 2009

DOI: 10.1145/1537614.1537706 · Source: DBLP

CITATIONS READS

3 1,614

3 authors:

Alfonso Ariza Quintana Eduardo Casilari-Pérez

University of Malaga University of Malaga
50 PUBLICATIONS   239 CITATIONS    171 PUBLICATIONS   1,557 CITATIONS   

SEE PROFILE SEE PROFILE

Alicia Triviño
University of Malaga
133 PUBLICATIONS   931 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Flow simulator for testing function cost in high bandwidth network, View project

Mi tesis View project

All content following this page was uploaded by Alicia Triviño on 26 May 2014.

The user has requested enhancement of the downloaded file.

 An architecture for the implementation
of Mesh Networks in OMNeT++
A. Ariza-Quintana E. Casilari A. Triviño Cabrera
Dpto. Tecnología Electrónica, University of Málaga
Campus de Teatinos, 29071 Málaga (Spain),
Tfno.: 34-952132755; FAX 34-952131447
[email protected] [email protected] [email protected]

ABSTRACT coverage area of the network can be expanded with much lower
This paper describes the implementation in OMNeT++ of a transmission power (and consequently with a lower power
versatile protocol architecture for the simulation of 802.11 consumption in the mesh nodes).
Wireless Mesh Networks (WMNs). The developed modules Although there is not a clear border between the concepts of ad
enable the routing at the 802.11 MAC layer as well as a packet hoc and mesh networks, we can emphasize certain differences. In
forwarding technique based on label paths. The performance of contrast with the typical (and ‘academic’) conception of Mobile
the new architecture is compared with that of a typical IP OLSR Ad Hoc Networks (or MANETs), mesh networks are mainly
ad hoc network proving that link layer routing (IP) can be intended for static radio nodes (normally Internet Access Points)
completely substituted by the developed modules. with very reduced or no mobility. Similarly, the classical notion
of an ad hoc network. assumes that routing is executed at network
Categories and Subject Descriptors layer (in essence IP) while mesh networks mainly base routing on
the information at MAC (link) layer [1]. This last feature reduces
I.6.5 [Simulation and Modeling]: Model development
the economical and computational cost of mesh network
C.2.1 [Computer Communication Networks]: Network deployment as it simplifies the hardware and software of the mesh
architecture and design routers (which are not obliged to implement IP layer).
IEEE 802.11s [2] draft has been proposed as an amendment to
General Terms 802.11 standard to enable the formation of WMNs with 802.11
Performance, Design capable-nodes. In this sense, IEEE 802.11s extends 802.11 to
support both broadcast/multicast and unicast communications
through multi-hop self-configuring topologies. IEEE 802.15,
Keywords IEEE 802.16 and IEEE 802.20 working groups have also made
OMNeT++, mesh networks, MAC, routing.
efforts to develop new protocols for WMNs.
This work describes and proposes a simple protocol architecture
for MWNs. The architecture, which has implemented and
1. INTRODUCTION simulated in OMNeT++ [3], permits to perform routing and label
During last years Wireless Mesh Networks (WMN) have become based packet forwarding just employing the 802.11 MAC layer.
an appealing research topic in the field of networking. Industry The implementation does not follow any specific standard or
has also paid attention to WMN and successful ‘mesh companies’ draft. Its main goal is to offer an open platform to emulate mesh
have appeared to offer different mesh networking products to networks and to evaluate the performance of future functionalities
customers. and proposals for this type of communication systems.
As in the case of ad hoc networks, mesh architectures allow the When compared with of 802.11s, our label-based switching
association of peer wireless nodes to conform a network in an architecture presents the following advantages:
adaptive, infrastructureless and self-organizing way. For this -The label based switching process is simpler and faster than
purpose, all the nodes in the network must work cooperatively routing based on addresses (MAC or IP).
and perform routing functionalities (if necessary) to define multi-
-Our implementation of label based switching enables source
hop routes that permit the interconnection of terminals that cannot
routing while 802.11s only permits to employ distributed (hop-by-
communicate directly. Moreover, through multi-hop connections,
hop) routing. Source routing eases the implementation of QoS
policies.
Permission to make digital or hard copies of all or part of this work for -As our architecture defines a special header between layers 2 and
personal or classroom use is granted without fee provided that copies are 3, it is basically independent of 802.11 and can be easily utilised
not made or distributed for profit or commercial advantage and that with other MAC layers (such as 802.15 or 802.16 layers). Label
copies bear this notice and the full citation on the first page. To copy switching enables to route the same packet through interfaces
otherwise, or republish, to post on servers or to redistribute to lists, with different link layers.
requires prior specific permission and/or a fee.
OMNeT++, 2009, Rome, Italy. -The main inconvenience of the label bases switching is the need
Copyright 2009 ICST, ISBN 978-963-9799-45-5. of creating the label paths. If the mobility of the terminals is
reduced, this is not a problem as paths will be stable. As it can be observed from the figure, the developed block
Consequently, the use of label based routes will be more efficient (802.11 Mesh) consists of two intercommunicated sub-blocks: the
than address based routing in static networks. module of Control and Forwarding is in charge of managing and
Paper is structured as follows. Section 2 comments the general creating the paths. This sub-block is also responsible for sending
structure of the architecture and details the functionalities the packets from any node (to the following node in the route) in a
implemented through different fields in a special packet header. transparent and seamless way to the upper layers. The goal of the
Section 3 and 4 describe the techniques that have been second part of the architecture (the Routing Protocol) is to find a
implemented for the forwarding and routing of packets, path to a final destination node when necessary. Next sections
respectively. Section 5 shows some simulation results proving the briefly summarise the structure and functionality of these two
correctness of the implementation. Section 6 discusses the sub-blocks.
benefits of the proposal while section 7 summarizes the main
conclusions. packet LWMPLSPacket
{
2. ARCHITECTURE IMPLEMENTATION fields:
2.1 Block diagram int label;
The protocol architecture for the simulation of 802.11 mesh int labelReturn;
network essentially requires the definition of specific modules
int type;
that implement the routing functionalities at the MAC layer.
Additionally we also considered of interest to include in our bool nextHeader;
implementation a specific packet forwarding mechanism. In this unsigned int counter;
sense, a policy based on label paths such as MultiProtocol Label int byteLength;
Switching (MPLS) [4] can offer a very flexible tool for traffic
engineering. With a MPLS-like strategy, packet forwarding is not MACAddress source;
based on the destination address but on a pre-defined path. The MACAddress dest;
path is identified in every packet by incorporating a special MACAddress vectorAddress[];
header with a simple label. This label (and not the MAC or IP
};
addresses) are analysed and switched in the nodes along the route.
Figure 2. Message header
Figure 1 shows the diagram of the modules used for the
implementation. The figure also represents the links with the rest
of the components of the INET implementation of 802.11
standard. 2.2 Packet header
802.11s draft proposes to perform routing decisions employing
Upper layers the information contained in the typical packet header of 802.11
protocol. However, to enable an alternative label based
forwarding, a specific packet label header has been added in our
802.11 Nic
architecture for WMNs. The format of this new header is
802.11 Mesh presented in the Figure 1 according to the packet definition
language of OMNeT++ simulator.
Control and Routing Protocol
forwarding The header incorporates the following fields aimed at providing a
MPLS-like packet forwarding:
-The label field includes the label that identifies the path that is
being used by the message. The label for the return path is defined
in the labelReturn Path.
802.11 Mac -The type field defines the functionality of the message that is
being transported. 11 different types of messages have been
defined to support forwarding through label paths:

802.11 Radio model

1. WMPLS_BEGIN. By this message, a node announces
to the following hop in the path that a label based path
is being created. The header includes the label that the
next hop must employ to forward packets to the path
ChannelControl
source. When the WMPLS_BEGIN is received, the
node responds with a WMPLS_ACK message
informing about the label to employ in the contrary
sense.
2. WMPLS_BEGIN_W_ROUTE. It is a special case of
Figure 1. Block diagram of the proposed architecture
WMPLS_BEGIN as it also enables source routing (the
origin node includes in the message the addresses of all
 the nodes in the path). 3. CONTROL AND FORWARDING
3. WMPLS_NORMAL. This header indicates that the
routing decision must be based on the transported label SYSTEM
(a label based route must have been created previously).
4. WMPLS_REFRESH. This message is sent to keep The goal of this sub-block is to create and keep the virtual paths
active paths that are not in use currently. In normal generated by labels. The module also manages the data
conditions, a path that is not supporting traffic is forwarding and the communication with the higher layer and the
considered to be obsolete after a certain time out. 802.11 MAC layer.
5. WMPLS_END. This message permits to break a path
explicitly (the path is also removed if it is not updated).
6. WMPLS_BREAK. This message informs that the
connectivity in a hop is lost so that the corresponding 3.1 Creation of label based paths
path is not available The actual MPLS protocol defines a specific additional
7. WMPLS_NOTFOUND. This message informs that a mechanism [5][6] for the path creation, the resource reservation
received label is unknown (the packet that contains it and the label assignation in the nodes along the path. Conversely,
cannot be forwarded as no entry is found in the in our proposed architecture, the signalling information to create,
forwarding table for the label). maintain and destroy the label paths can be easily included in the
8. WMPLS_ACK. It is used during the path creation when message headers. Consequently, the path can be created as the
a node informs to the previous node about the label to first packet between the origin and destination nodes progresses
utilise when sending packets through the path. This through the network. For this purpose, this first packet must
message must be sent as an answer when a include the header WMPLS_BEGIN which indicates the next
WMPLS_BEGIN message is received. hope that a virtual label path is being defined. The message
9. WMPLS_SEND. It is employed to send packets when simultaneously defines the label to utilise for the return path by
MPLS-like paths are not created. As for 802.11s, every the receiving node (as an underlying 802.11 physical layer is
node in the route decides the following hop depending assumed, links are considered to be bidirectional). Thus as the
on the destination MAC address. WMPLS_BEGIN evolves, the label path is configured in both
10. WMPLS_BROADCAST, aimed to broadcast packets. senses without requiring to repeat the operation for the return
11. WMPLS_ADDITIONAL (not employed) intended to path. This clearly minimises the time and the bandwidth
extend the protocol and include new functionalities in a demanded by the setup phase of the connection (which in most
future. practical cases will require a bidirectional communication of
-The Boolean nextHeader field is activated if more than one packets). The node receiving the WMPLS_BEGIN message
header exists in the message. As in the case of MPLS, our responds with an acknowledgment (WMPLS_ACK) assigning the
architecture allows to accumulate several headers in the same label that the emitting node will have to use to send packets
message. through the new path. While the acknowledgment is not received,
the following packets will also be sent with a WMPLS_BEGIN
-The counter field is utilised in the messages sent by broadcast header. Conversely after the reception of the acknowledgment
to all the network nodes. The field (together with the origin subsequent outgoing packets will be transmitted with a
address) permits to identify the message in order to guarantee that MPLS_NORMAL header and the corresponding forwarding label.
it is retransmitted by the nodes just the first time that the message The implementation also contemplates the possibility that a node
is received (the packet is retransmitted only if the sequence receives packets with a MPLS_NORMAL header while the path
number in the field is higher than the number of the last broadcast in the following hop is not still created. In that case, the
packet received from the same node). Every node has its own retransmitted packet will change the MPLS_NORMAL header by
counter so this field is incremented in a node as soon as it a WMPLS_BEGIN header. The opposite operation is also
originates a broadcast message. Similarly, all the nodes have to possible.
store in a table the sequence number of the last received broadcast
packet received from each node. The example of a path with 3 hops depicted in Figure 2 illustrates
this exchange of messages during the label path setup.
-The byteLength field defines the total length (in bytes) of the
header. WMPLS_BEGI WMPLS_BEGI
WMPLS_BEGI N
N N
-The vectorAddress fields include the addresses of all the Return Label 3
Return Label 8 Return Label 1
nodes in a route when a label path is being created with the
mechanism of source routing. This field is analysed (or not)
depending on the value of the byteLength field.
Finally the header also includes the MAC address of the source
and destination nodes in the link (MACAddress source and
MACAddress dest fields). Although these values are present WMPLS_ACK WMPLS_ACK
WMPLS_ACK
in the 802.11 header of the packets, they have been included to Label 1 Label 5
Label 7
simplify the processing of the C++ code.
Figure 3. Information Exchange between nodes for the
creation of a label path
Labels are selected from a pool of available labels. This selection In the ‘hop by hop’ operating mode, no label paths are created so
is performed basing on the following criteria: the first found label the packet forwarding and routing is autonomously performed in
that has not been in use during a certain interval is selected. If all every node along the path (in a similar way to typical IP or
the available labels were selected during that interval, the 802.11s routing). Under this mode, when a node receives a packet
algorithm chooses the label that was least recently used. Making with a destination MAC address (set in the MACAddress dest
so, we minimise the probability of selecting a label that has not fields) different from its own, it searches the corresponding entry
been released by the following hop (the node receiving the label) in the routing tables (generated by the routing protocol) to
without exchanging any special release message. Here, we must determine the MAC address of the following hop (the node to
remember that path labels are automatically released (and which the incoming packet will be retransmitted). Under this
removed from the forwarding table) after a time-out without been operating mode, no label paths are created, so the
utilised. Thus, if the age of a label (the time without being routing/forwarding operation is similar to the procedure of the
utilised) exceeds that time-out, we guarantee that it has been 802.11s draft.
released by the corresponding node in the link. The third operating mode is the packet broadcast (or packet
The implemented architecture also allows source routing, that is flooding). This mode is conceived to send the packet to all the
to say, the definition of the whole label path from the source network nodes. To reach the whole network, all the nodes have to
node. In this case the initial message creating the label path rebroadcast any incoming broadcast packet the first time that they
incorporates the addresses of all the nodes that compose the route. receive it. To prevent the retransmission of duplicated packets, a
As when the route is set up hop by hop, once the path is sequence number is included in the counter field of the label
configured, the message with data packets just include the headers of all the broadcast messages.
corresponding label. Obviously source routing can be executed
only if the routing protocol (OLSR in our case) permits the node 4. ROUTING PROTOCOLS
to know the whole network topology so that a route to the For the deployed architecture the routing functionality is executed
destination can be directly defined from the source. at the link layer, as in the proposal of 802.11s standard. In
particular, the routing protocol is a sub-process of the control
3.2 Operating modes system.
The architecture permits three operating modes for the exchange
As routing algorithm, we decided to employ an existing
of information between nodes: label based forwarding mode, the
mechanism for ad hoc networks. Several ad hoc routing protocols
hop-by-hop mode and the broadcast mode.
(including reactive strategies such as AODV, DYMO and
The label based (MPLS) forwarding mode creates label based proactive policies such as OLSR) have already been implemented
paths between the source and destination nodes. Once the path has for Inet in OMNeT++ [7]. These protocols were initially
been created and the labels are assigned to the different links, conceived to work with IP addresses. However, OLSR also
routing decisions are purely based on these (active) labels. Thus, enables to base the routing decision and the path search on the
when a packet arrives to an intermediate node in a path, the MAC addresses [8]. Consequently OLSR was chosen for our
control module searches in the forwarding table the label of this architecture of mesh network. In any case, other future or present
incoming packet. In the table this label is associated to three routing strategies can be easily integrated in our implementation.
values: the return label, the MAC address of the following node in
In order to habilitate OLSR to work at both layers (link and
the route and the outgoing label (these two last values will be
network) a special container class (Uint128) was specifically
inserted in the packet to be retransmitted). Every active label has
created. The class, aimed at managing the node addresses, can
also a lifetime counter. If this counter exceeds a certain timeout
store 128-bit IPv6, 32-bit IPv4 and 40-bit MAC addresses. The
the path is considered to be finished. In that case the label and its
class has overloaded operators that return the container classes of
associated parameters are removed from the table. So, the label is
the corresponding INET address for the different types. Thus, the
considered to be available to create another path. On the other
same code of OLSR (intended for routing at IP layer) can be
hand, whenever an active label is utilised, the label lifetime
utilised at the link layer.
counter is set to zero. If an incoming packet transports an
available label, an error message is transmitted to the emitting Apart from the different addresses utilised for routing (MAC and
node (WMPLS_NOTFOUND). This message will erase the entry IP addresses), the main divergence between the implementations
in the forwarding table corresponding to the missing label. of the routing procedures at link and network (IP) layer resides in
the routing table. IP routing employs tables stored in the
If the MAC layer detects that a packet cannot be delivered to the
RoutingTable class. Conversely, our link layer implementation
following node successfully, the link is considered to be broken.
makes use of the internal tables of OLSR protocol. Thus, the
In this situation, the labels reserved for this link will be removed
control system directly accesses the content of these tables by
from the table and a special error message (WMPLS_BREAK)
executing the getRouteMac method which returns the complete
will be generated and transmitted to the rest of nodes in the
route (a sequence of MAC addresses) to the destination node. The
contrary sense of the paths that use this link. The reception of this
developed code is capable of discriminating if routing is
error message also implies the release of the labels reserved for
performed at link or network layer. Consequently routing will be
the broken path. As part of a path can be active during a certain
based on MAC or IP addresses.
interval after a certain link falls, the labels that are removed from
the routing table because of this reason are kept unavailable for a
time interval. This prevents new paths to employ those labels that 5. SIMULATIONS AND RESULTS
were assigned to paths that may be still in use with broken links. In order to validate the implemented architecture a set of
simulations were carried out. The main goal of the simulations
was to check the performance of the proposed layer-2 routing In any case, the comparison permits to assume that the developed
scheme when compared with the typical network layer (IP) modules have been implemented properly.
routing of a MANET. Under both schemes OLSR was utilised to
define the routes.
Destination node: Randomly chosen
We have simulated networks with 45 and 50 nodes. The nodes
were randomly distributed (according to an uniform random Layer 3 Routing 0.999
distribution) in a simulation area of 1500x1500 m. In the scenario
of 45 nodes, 5 nodes implemented the complete protocol stack Layer 2 Routing 0.999
and assume the role of sources and/or destinations of the Table 3. Mean Packet delivery ratio. 20 sources
generated traffic. The other 40 nodes just implement up to the link
(or network) layer and can only act as traffic routers. Source
nodes are programmed to emit CBR (Constant Bit Rate) traffic at Destination node: Predefined
a rate of 5 packets/second through UDP connections. Packet size
Layer 3 Routing 1.35 ms
was set to 512 bytes. The duration of each simulation was 3000 s.
Two cases for this scenario were considered: in the first one, the Layer 2 Routing 1.78 ms
destination of all the flows is the same (predefined) node. In the Table 4. Mean Packet delay. 20 sources
second case, the destination for each packet is randomly chosen.
In the scenario of 50 nodes, 20 nodes implement the complete
stack and may perform as sources and/or traffic destinations. In Scenario 5 sources 20 sources
this scenario sources generate CBR traffic at a rate of 10
Destination node Predefined Randomly Predefined
packets/second. The destination for each packet is randomly
chosen. The rest of parameters are the same that the previous
chosen
scenario. In all the experiments a packets is considered to be lost Layer 3 Routing 0.83 0.87 0.26
when it does not reach the destination node or when it arrives
with a delay bigger than 1 second. Layer 2 Routing 1.48 1.53 0.30
The simulations were repeated for the two compared policies (IP Table 5. Simulation speed (simulated seconds per real
routing and layer-2 routing) using the same node distribution and simulation second)
the same traffic pattern (the origin and destination node of each
packet was identical for both cases). 6. DISCUSSION
Tables 1, 2, 3 & 4 show that the proposed architecture with layer When compared with typical IP routing, packet forwarding and
2 routing achieves very similar results (in terms of packet delivery routing at the link layer for ad hoc (and mesh) networks presents
ratio and packet delay) to those obtained with classical IP routing. several advantages. Firstly, as it refers to the protocol stack, the
network design is highly simplified: For the network layer all the
internal mesh nodes are only one-hop away. Similarly, the node
Destination node: Predefined Randomly acting as the gateway to fixed Internet (if it exists) is not
chosen compelled to implement two different IP routing protocols (e.g.:
OSPF [9] for communicating with any Internet node and a
Layer 3 Routing 1 1 MANET protocol to interact with the other mesh nodes). Routing
Layer 2 Routing 1 1 at MAC layers also enables an easier expansion of the mesh
network. Thus, the network coverage area can be extended by
Table 1. Mean Packet delivery ratio. 5 sources deploying simple (and cheaper) routing nodes which are not
obliged to implement the network layer (and consequently to have
its own assigned IP address).
Destination node: Predefined Randomly
chosen Figure 4 illustrates a test network with a mesh router. As it can be
appreciated, the routing capacity, which is now located at the
Layer 3 Routing 0.49 ms 0.69 ms MAC layer, makes unnecessary the existence of upper layers in
Layer 2 Routing 0.52 ms 0.70 ms this node. The routing protocol is OLSR although other ad hoc
routing policies could be easily incorporated if IP addressed can
Table 2. Mean Packet delay. 5 sources be substituted by MAC addresses.
Another interesting advantage of mesh networking is that routing
The simulator does not model the processing delay at every layer. at MAC layer can benefit (at least in a easier way than at the IP
Consequently in an actual scenario (with real routers) the lookup layer) from the link information that is available at link and
process at the IP tables would introduce an additional component physical layers (e.g.: received power, signal-to-noise ratio,
in the delay of IP routing, which is not reflected in the shown channel occupation, etc). The utilisation of this information in the
results. This reduction of the packet processing also impacts on metrics employed to make the routing decision can clearly
the simulation time. Table 5 describes the mean number of improve the implementation of QoS policies in wireless self-
simulated seconds per second for both policies. Table shows that organising networks [10].
layer 2 routing clearly reduces the duration of the simulation.
 MAC layer routing also enables the possibility of having several
MANET routing protocols working simultaneously. So, a
proactive strategy (such as OLSR) could be employed to form the 8. ACKNOWLEDGMENTS
‘backbone’ of fixed nodes of the mesh networks. In opposition, if This work was partially supported with public funds by the
fixed nodes implement more than one routing algorithm, a Spanish National Project No.TEC2006-12211-C02-01 (MCyT).
reactive protocol (such as DYMO), which is more appropriate for
a dynamic network, could be employed in the mobile terminals.
9. REFERENCES
[1] Akyildiz, F., Wang, X., Wang, W. 2005. Wireless mesh
networks: a survey, Computer Networks 47, No. 4. (15
March 2005), pp. 445-487.
[2] IEEE P802.11s™/D0.01, Draft amendment to standard
IEEE, 802.11™: ESS Mesh Networking. IEEE, March 2006,
work in progress.
[3] OMNeT++, http://www.omnetpp.org
[4] Rosen, E., A. Viswanathan A., Callon R. L. 2001.
Multiprotocol Label Switching Architecture, IETF RFC
3031, January 2001.
[5] Andersson, L., Minei, I. and Thomas, B. 2007. LDP
Specification, IETF RFC 5036 (October 2007)
[6] Farrel, A., Papadimitriou, D., Vasseur, J.-P. and Ayyangar,
A.. 2006. Encoding of Attributes for multiprotocol Label
Switching (MPLS) Label Switched Path (LSP)
Establishment Using Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE), IETF RFC 4420 (February 2006).
[7] Ariza, A., Casilari, E., and Triviño, A. 2008. Implementation
of MANET routing protocols on OMNET++ , OMNeT++
Workshop, (March 2008).
[8] Clausen T., Jacquet P., 2003. Optimized Link State Routing
Protocol (OLSR), IETF RFC 3626, (October 2003).
Figure 4. Test network with a simple layer-2 only router
[9] Moy, J. 2008. OSPF Version 2. IETF RFC 2328, (April
1998).
7. CONCLUSIONS [10] Campista, M.E.M., Esposito, P.M., Moraes, I.M., Costa,
This work has presented an open architecture to simulate self- L.H.M., Duarte, O.C.M., Passos, D.G.; de Albuquerque,
configuring 802.11 mesh networks in OMNeT++. The C.V.N., Saade, D.C.M., Rubinstein, M.G. 2008. Routing
architecture permits to simulate the routing at MAC layer Metrics and Protocols for Wireless Mesh Networks, IEEE
proposed by 802.11s standard while it also incorporates a label Network 22, 1 (Jan.-Feb. 2008), 6-12.
based forwarding protocol that manages the creation, maintenance [11] Inet code with several Ah-hoc routing protocols,
and removal of label paths. The flexibility of the implemented http://webpersonal.uma.es/~AARIZAQ/
architecture eases its possible extension to emulate more complex
cross-layered designs of new routing and/or forwarding protocols
and it can be easily adapted to another wireless architecture like
802.15.4. . The developed code is publicly available at [11].

View publication stats