DCRP: a scalable path selection and forwarding scheme for IEEE 802.11s wireless mesh networks

Abstract

The IEEE 802.11s standard specifies a mesh technology to be supported by IEEE 802.11 devices. Among the limitations caused by this heritage, we focus on the low scalability of the current IEEE 802.11s standard mechanisms. As a main contribution to the related research field, this article presents the DHT-based Cluster Routing Protocol (DCRP). DCRP addresses IEEE 802.11s’ scalability issues by exploiting both Distributed Hash Tables and Clustering schemes, which have proved to be effective in scaling wireless (e.g., MANETs) and wired (e.g., P2P) networking systems. DCRP was implemented and compared with the HWMP through simulation for different scalability parameters and performance metrics. Simulation results indicate that the proposed scheme improves performance in terms of packet delivery ratio, end-to-end delay, throughput, and overhead.

1 Introduction

Scalability is a well-known issue in multi-hop networking. Network scalability can be defined in many different ways. Network parameters that can affect network scalability are the number of nodes, the number of concurrent connections, the frequency of transmissions, node density, and node mobility. Protocol scalability is also very sensitive to message control overhead.

Current IEEE 802.11s WMN deployments suffer of poor scalability, which is heavily influenced by the unsuitability of standard IEEE 802.11 MAC schemes, usually based on the Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) that was not design for multi-hop environments (with frequent hidden node and exposed node situations). Although many of these issues are related with the medium access control (MAC) layer, the way nodes forward messages is also important. Thus, the efficiency of the path selection and forwarding plays an important role to improve the scalability by reducing medium utilization, and the number of hops in communication paths. The approach proposed in this article works at the level of path selection and forwarding.

IEEE 802.11s [1] is an amendment to the IEEE 802.11-2012 set of standards [1] that enables mesh networking on wireless local area networks (WLANs). The objective is to extend the coverage of traditional WLANs and to allow the support of a wider diversity of wireless technologies [2]. The IEEE 802.11s standard introduces new node rules, as illustrated in Fig. 1, that work together to create a multi-hop wireless relaying infrastructure, where all nodes cooperatively forward data from a originator node to a target node. Briefly, all IEEE 802.11s enabled node (or mesh STAs) autonomously organize themselves to create the mesh basic service set (MBSS). Traditional IEEE 802.11 access point (AP) function can be collocated with a mesh STA, acting as a gate to provide wireless access to the MBSS for non-mesh stations (STA). Moreover, a mesh STA can act as a portal to enable the interconnection between the MBSS and other IEEE 802.x network segment (e.g., wired networks, such as Ethernet). The interested reader may wish to read the chapter 13 of the standard [1] for further background on these mechanisms discussed in this article. Complementary information can be also found in [3–11].

Fig. 1

IEEE 802.11s network elements described in the standard [1]. Reproduced from [2]. Nodes A to J are mesh STAs and form the mesh basic service set (MBSS). Nodes D, J, and H are AP collocated with mesh gates, connecting the BSSs A, B, and C, respectively, to the MBSS. Nodes A and H additionally work as mesh portal, working as gateway to non-802.11 LANs. Note that all functionalities are combined on node H as it provides connectivity to the IEEE 802.11 DS (BSS C)—so, acting as mesh gate—and also connects the MBSS to a non-802.11 LAN, so acting as portal. Note that any mesh gate is also a mesh STA

There are many factors that affect the scalability of the WMNs. A list of the most relevant factors is presented in [12], including the routing protocol overhead, and the communication pattern (locality and number of hops). The path selection and forwarding scheme proposed in this article directly addresses these factors.

According to Carrano et al. [10], unless the path discovery overhead is drastically reduced by increasing the efficiency of flooding mechanisms, the new standard may present a suitable behavior only for small-scale scenarios. Moreover, scalability is one of the major deciding factors for any network to be accepted and industrially deployed [13].

In this article the DHT-based Cluster Routing Protocol is presented. Instead of relying on traditional approaches, the DCRP exploits the traffic contention from hierarchical clustering routing with the key-based lookup provided by DHTs. The architectural design of the DCRP is presented in Section 3. In an overall comparison, the DCRP is clearly more scalable than the standard HWMP protocol. The simulation results are presented and discussed in Section 5. The DCRP produced better results for most of the evaluated performance metrics.

It is important to highlight that the scalability is one of the major deciding factors for any new networking technology to be accepted, to be deployed and to evolve continuously [12]. In this sense, to the best of our knowledge, there is still very scarce conducted research targeting to improve the scalability of the IEEE 802.11s networks.

The remainder of this article is organized as follows. The related work is surveyed in the Section 2. The DCRP design is detailed in the Section 3. The simulation scenario used in the DCRP assessment is described in Section 4. The simulation results are presented and discussed in the Section 5. Finally, the Section 6 reviews the main findings of this work and discusses potential improvements to the DCRP.

2 Related work

As aforementioned, there are very few research works on the scalability of the IEEE 802.11s WMNs. Likewise, there are few works addressing the path selection and forwarding mechanisms in the IEEE 802.11s WMNs. To date, as far as we know, only three schemes have been proposed: the current standard Hybrid Wireless Mesh Network (HWMP) [1], the Radio Aware Optimized Link State Routing (RA-OLSR) [7, 8] and the Transparent Interconnection of Lots of Links (TRILL) [14].

The HWMP is currently the default path selection protocol defined for the IEEE 802.11s standard document. It must be implemented by all 802.11s-enabled stations (mesh STAs). HWMP uses a set of protocol primitives derived from AODV with proactive topology tree extensions to perform routing-related functions and adapted for using MAC addresses and the Airtime Link Metric.

Until draft version 1.06 of the IEEE 802.11s, every MP should support two path selection protocols: the HWMP [1] as the default routing protocol and the RA-OLSR [7, 8] as an optional one. The RA-OLSR protocol is a proactive, link-state wireless mesh path selection protocol based on the OLSR protocol [15]. It also includes extensions like the Fisheye State Routing (FSR) protocol [16] and uses radio-aware metrics. Since draft version 1.07, the RA-OLSR has been removed from the IEEE 802.11s specification to simplify the standardization process. Moreover, the flexibility that arises from the combination of reactive and proactive elements enables HWMP to work in a wide variety of mesh network scenarios, hence the RA-OLSR has been removed from the standard.

Both HWMP and RA-OLSR have several scalability shortcomings. In HWMP, the proactive mode is centralized and constrained by the root node. Even when two mesh stations near to each other need to communicate, the proactive routing protocol routes the frames through the root node, which results in poor performance. At the same time, the reactive (on-demand) mode will initiate a path discovery process to search for an optimized path before sending the frames, resulting in an excessive number of broadcasted messages. The problem with RA-OLSR is the overhead of control messages, even when the Fisheye protocol is used.

Ghannay [17] performed a performance comparison of the HWMP and RA-OLSR protocols. The findings of this work confirmed that both protocols present poor scalability. The scalability of HWMP was evaluated in [13] with respect to traffic load and number of nodes. The simulation results show that the protocol is hardly scalable.

Although the mesh topology provides multiple paths, which can be used to improve its performance, HWMP itself does not provide any multi-path selection mechanism. Seeking to explore the multi-path, in 2012, TRILL was proposed as alternative path selection and forwarding protocol for IEEE 802.11s WMNs. Originally, TRILL is a layer 2 solution designed by Internet Engineering Task Force (IETF) to provide redundant/multi-path topology, replacing the spanning tree protocol (STP). TRILL is built on the Intermediate System-to-Intermediate System (IS-IS) link state protocol, applying network layer routing protocols to the link layer. The base protocol specification was published in July 2011 in [14]. Despite very promising in terms of scalability improvements, to date, no further studies or implementations of TRILL for IEEE 802.11s has been published.

WMNs tend to grow in number of connected nodes, which requires maintenance at all times to guarantee connectivity and efficiency. A successful way to deal with the maintenance of WMNs is to partition the network into clusters which will make the network to be more manageable [18]. Clustering approach has been used broadly in computer networking to reduce the control overhead by imposing a sense of locality among nodes within a cluster. In DCRP, the clustering approach is used as a key building block by locally constraining most of the control overhead.

In the design of the DCRP, the clustering concept is taken as a building block for the path selection and forwarding scheme, but mainly for organizational purposes; it is not actively used for relaying. This detail makes a straightforward comparison with other cluster-based solutions in the literature (e.g., the Mesh Cluster Based Routing Protocol (MCBRP) [19]) pointless. Nonetheless, the clustering concept is important to understand our proposed scheme; interesting surveys can be found in [18, 20–24].

The literature provides a few proposals to integrate the routing protocol (physical network) and the DHT structure (overlay network) in order to create a scalable indirect routing functionality at the network level for MANETs [25]. Mobile Ad-Hoc Pastry (MADPastry), proposed in [25], integrates the reactive AODV routing protocol and the Pastry DHT at the routing layer. The Virtual Ring Routing (VRR) [26] is a DHT-inspired routing protocol that works directly on top of the link layer (but still at routing layer, applying a crosslayer approach) providing both point-to-point network routing and DHT functionalities. Ekta [27], like MADPastry, is based on Pastry, but it uses DSR [28] for route discoveries. Actually, Ekta is considered as the first attempt at merging the application and network layers to improve the performance of a DHT. Unlike MADPastry, Ekta does not explicitly consider physical proximity in its DHT. DHT-OLSR [29] is another example of an attempt to merge routing and key-based lookup. DHT-OLSR utilizes MADPastry as a DHT substrate integrated with the OLSR protocol. The Scalable Source Routing protocol (SSR), proposed in [30], which like VRR tries to integrate the overlay network in the network layer. The difference is that whereas VRR does not assume the use of any specific routing protocol, SRR combines the DSR routing protocol in the physical network with Chord routing in the overlay network. A similar approach, called MA-Chord [31], is a DHT substrate particularly designed for mobile ad hoc networks that combines AODV routing and Chord overlay routing at the network layer to provide efficient key-based routing in MANETs. A summary of these approaches is presented in Table 1.

Table 1 DCRP and other DHT-based approaches in the literature

DCRP also integrates the distributed hash tables (DHT) with the path selection and forwarding, but there are some differences to the aforementioned works: in the DCRP, the DHTs operate at the link layer; the DCRP does not route data through the DHT; the “route” protocol used is the HWMP that also operates at the link layer. Regarding the DHT, it is actually based on the basic Chord [32] DHT structures. Therefore, again, a straightforward comparison with the works cited above are not meaningful. DHT is another building block for the DCRP scheme, thereby a solid background on the related concepts are recommended to fully understand the rest of this article. Thus, an interesting survey on scalable DHT-based routing protocols for ad hoc networks and P2P overlay network schemes can be found in [33] and [34].

3 The DCRP protocol

This section introduces the DHT-based Cluster Routing Protocol (DCRP) architecture. DCRP is a path selection and message forwarding protocol explicitly designed for use in IEEE 802.11s mesh networks. DCRP integrates the functionalities of the DHT, the scoped communication provided by the clustering scheme and the HWMP to provide a scalable solution to these networks.

3.1 Architectural overview

The DCRP resorts to a three-layer architecture to provide a scalable solution for IEEE 802.11s wireless mesh networks, as illustrated in Fig. 2. The first layer represents the physical IEEE 802.11s WMN itself. At this layer, nodes (or mesh STAs) are identified by their unique MAC address and implement most of the mechanisms recommended in the standard with a slightly enhanced version of the HWMP protocol (to be further explained). At the second layer, nodes are organized in clusters of k-hop ratio (i.e., by nodes up to k-hops away the central node, the cluster head). Clusters are allowed to overlap and hence share boundary nodes (hereinafter called as border nodes). At the top layer, the DHT layer, nodes are organized into a DHT structure which is used as a lookup service. At this layer, nodes are identified by a virtual unique identifier, created by a hash function applied to its physical address. In other words, the MAC addresses of the underlay network are mapped to the space address of the overlay network (DHT).

Fig. 2

DCRP depicted in a three-layer architecture

DCRP integrates clustering with DHTs to enhance the scalability of routing in 802.11s networks. Clustering allows the use of hierarchical routing and therefore to reduce the amount of routing traffic. The routing information that is not exchanged through the routing protocols is kept in DHTs, which supports a rather efficient access.

Although at a high level, the DCRP architecture can be represented as in Fig. 2, at an operation level all layers are integrated as explained in the following sections.

3.2 The physical layer

At this layer, the nodes perform the tasks recommended in the standard document [1] to create an IEEE 802.11s WMN, such as the peering task. In DCRP, a parameterized timeout is defined before the clustering phase starts. The purpose of this delay is to give time to the nodes peering with their neighbors (i.e., wait until the network topology is stable enough). This is needed because the clustering algorithm uses only neighbor peers rather than all the node’s neighbors.

Regarding the protocol operation, in this layer, all mesh STAs run an enhanced version of the HWMP, as further explained below.

3.3 The cluster layer

Although there are several cluster schemes proposed for MANETs, only few proposals can be found for WMNs. A desirable clustering scheme for WMNs should take into account the heterogeneity of node types and most importantly be able to identify and prioritize stable links and nodes. Unfortunately, this requirement cannot be achieved in a few communication rounds, as instability may become observable after some time of network operation (mainly due to the interference caused by multi-hop simultaneous transmissions). For that reason, most proposed clustering approaches to WMNs are adaptations from MANETs.

Recent work in MANETs clustering usually addresses the mobility of nodes, which require sophisticated and complex algorithms. In the design of the DCRP, we assume that nodes have limited or (usually) no mobility at all. This assumption is reasonable and is also taken by the IEEE 802.11s standard and most of the related research work.

The DCRP architecture is very flexible regarding the clustering scheme. It imposes only three main requirements; the cluster scheme must 1) create clusters with more than one-hop size; 2) create overlapped clusters, i.e., in every cluster, at least one node must be in range of one node on another cluster; and 3) use only peers (rather than any neighbor). The first requirement is needed to avoid creating a large number of small clusters as the network size increases. The second is needed to ensure inter-cluster communication. Finally, the third requirement is needed to ensure that a neighbor is reachable according to the IEEE 802.11s mesh peering management protocol.

To create the clusters, DCRP uses a generalization of the cluster algorithm described in [35] so that a cluster contains all nodes that are at distance of, at most, k-hops from the clusterhead (considering that each pair of nodes at 1-hop is a valid IEEE 802.11s peer). Figure 3 illustrates a set of DCRP clustered nodes in a grid topology, using k=2. In our protocol, there are four possible states for the node: MEMBER, ISOLATED, CLUSTERHEAD and BORDER. A cluster head (a node in CLUSTERHEAD state) is the most important node in the cluster and its primary responsibility is to communicate with all the nodes of its own cluster. A border node (a node in BORDER state) is a node in a cluster that is able to communicate directly, i.e., in one hop, with nodes in other clusters and acts as a gateway to other clusters. A member (a node in MEMBER state) is a regular clustered node that is neither a cluster head or a border node (i.e., they do not have neighbors belonging to different clusters). A node is in the ISOLATED state when it does not belong to any cluster. Initially, all nodes are in the ISOLATED state.

Fig. 3

Illustration of a set of DCRP clustered nodes in a grid topology with k = 2

To provide additional reliability and better performance, it is desirable to have cluster heads in adjacent clusters at most 2 k-hops from each other. Although border nodes increase the reliability by providing multiple paths to inter-cluster communication, a high number of border nodes in the same cluster can jeopardize the overall performance. After the cluster formation phase, it is assumed that a node that belongs to a cluster knows both the cluster identifier (CID) and the cluster head. Currently, DCRP uses the MAC address of the cluster head as CID.

3.3.1 Cluster tables

DCRP clustering scheme relies on a set of cluster tables that are used to support both cluster creation and maintenance, and intra-cluster communication, as illustrated in Fig. 4. Each DCRP node maintains at least two tables: a NeighborTable¹ and a MemberTable. The former is used to store information about neighbors in the range of k-hops. This table is mainly used for cluster formation and clusterhead election. Considering that, as aforementioned, in DCRP only peer neighbors are considered, as an optimization, the content of this table can be filled with information from the mesh peering management protocol. The MemberTable stores information of the known neighbor members of the cluster. To avoid the exchange of too many control messages in the cluster, this table stores the direct (1 hop) neighbors. Additionally, to improve the performance of the intra-cluster communication, it can also have entries on other members a node is aware of by overhearing frames from other directly connected peers. That is the case of the entry for node 27 of node 25’s MemberTable, in Fig. 4, which was added by overhearing frames sent through node 26.

Fig. 4

Example of tables kept by DCRP nodes within the cluster which have the node 1d as cluster head

Border nodes must maintain an additional table: the BorderTable. Every time that a border node receives (or simply overhears) a frame from a peer of another cluster, a new entry containing the address of that peer and its cluster ID is added to this table, if it is not there yet. In other words, in this table, the border nodes store information about all clusters that it overlaps with, and the address of the peer belonging to the other clusters (used as next hop in direction to this cluster). It must be noted that this table can store more than one entry for the same cluster. When combined with a metric of link quality, congestion, or distance in hops to the cluster head (in the overlapping cluster), this table can be useful to balance the inter-cluster communication load. These enhancements have not been explored yet.

Cluster head nodes keep a complete version of the ClusterMemberTable, i.e., with one entry per cluster member. Additionally, cluster head nodes maintain a NeighborClusterTable with information about its neighbor clusters. In fact, this table is a compilation of the information kept by all border nodes in their BorderTable, but including also the gateway (the border node address) and the next hop in that path.

3.4 The DHT layer

The current version of DCRP is inspired in Chord [32], one of the earliest P2P algorithm based on a DHT². Therefore, DCRP inherits Chord’s key space structure and its rules for storing/mapping keys among the participant nodes. It must be noted that DCRP does not replicate key values over the DHT due to the prohibitive cost of such operation in a wireless environment. This means that only one DHT node with the closest key on the ring will store this value.

Although the original Chord has been designed to run at the application layer, in the DCRP it is integrated at layer 2.

To assign IDs to the nodes, the MAC address of each node is hashed using SHA-1, thus producing a 160-bit ID. It does not matter where any of the nodes are physically located; they are placed along the ring structure according to their 160-bit address space. For sake of simplicity, hereinafter all figures and descriptions regarding the DHT node IDs will assume the use of a CRC-32 rather than SHA-1 as a hash function, thus leading to smaller IDs.

Whenever a node in the network searches for the key k using a LOOKUP operation, the network address (physical address in the underlay network) associated with the successor node will be necessary. For this reason, the underlay network runs a routing protocol. In DCRP, the HWMP protocol is used.

3.4.1 DHT tables

According to the IEEE 802.11s standard document [1], mesh STAs only exchange path selection and forwarding information that contain addresses of mesh STAs that belong to the MBSS. However, the destination station may be outside of the MBSS, and therefore a proxy mechanism is required.

The DCRP maintains all information about non-mesh STAs (including information about its proxy mesh STA) in DHTs (see Fig. 5). The main reason is to replace the expensive current standard mechanism (and other proposals found in the literature) by an elegant and efficient mechanism of distributed lookup. Following, the current standard mechanism and other proposals found in the literature are briefly explained.

Fig. 5

Illustration of a DHT overlay with the finger table for the node 15 with overlay ID 2E4AF3B

The standard document defines a basic mechanism to carry proxy information that introduces two new IEs, and the corresponding frames: the Proxy Update (PXU) (see Fig. 6) and the Proxy Update Confirmation (PXUC) (see Fig. 7). Briefly, the PXU element contains one or more mappings of an external address to a mesh proxy address. PXUC is used to acknowledge a received PXU. The PXU and PXUC IEs are transmitted in Proxy Update and Proxy Update Confirmation frames, respectively. These frames must be individually addressed and may contain multiple IEs when needed.

Fig. 6

Standard PXU information element format

Fig. 7

Standard PXUC information element format

Although PXU IEs can comprise multiple mappings and can be incorporated in HWMP messages (i.e., proxy information can be conveyed in PREQ/PREP/PERR IEs), the mechanism is still not scalable enough, as it can potentially create a large number of proxy information messages (or simply large HWMP frames for the case of proxy information to be included in the HWMP IE) as the number of external stations increases.

The proxy information maintenance in the 802.11s standard is still an open research question. DCRP addresses this issue by storing and managing proxy information through the use of DHTs. For this purpose, and considering the locality of the information, DCRP proposes the use of two structures: the intra-DHT and the inter-DHT.

3.4.1.1 Intra-DHT Table (intraDHT)

Each mesh STA in a cluster is a node of the intraDHT for that cluster and keeps the entries (as key values) for the non-mesh STAs of which it is the key mesh STA (kMS), in this case the intra-kMS. The values of the (key,value) pairs maintained in the intra-DHT map the ID (i.e., the hash(MAC)) of a node to the MAC address of its proxy MS. An example of intra-DHT for a DCRP cluster is illustrated in Fig. 8.

Fig. 8

Illustration of a DCRP intra-DHT where mesh STAs are virtual nodes in the DHT and routing information for non-mesh STAs are stored as values. In this example, the DHT node with ID F76C0C36 (the mesh STA 16) is responsible for keys ECB7B3A8 and EE4C63CE

3.4.1.2 Inter-DHT Table (inter-DHT)

To enable inter-cluster communication, each bMS is also a node of a mesh-wide DHT overlay: the inter-DHT. In this overlay, nodes maintain entries for nodes (both mesh STAs and non-mesh STAs) of which it is the kMS, more specifically the inter-kMS. The entries of the inter-DHT map the ID of a node to the MAC address of its proxy-bMS, i.e., a bMS in that node’s cluster.

In DCRP, populating these DHTs with entries is very simple. When a mesh STA finishes its cluster membership, it adds itself in its intra-kMS, by sending to that inter-kMS an ADD-ENTRY message. When a non-mesh STA associates with a mesh STA (acting as an AP collocated with a mesh gate, or a mesh portal), the latter adds the entries for proxy mapping to both the intra-DHT and the inter-DHT, by sending an ADD-ENTRY message to each of the intra-kMS and the inter-kMS of that station, respectively.

In order to support the forwarding of messages (e.g., ADD-ENTRY and LOOKUP) in DHT overlay networks, a mesh STA relies on its HWMP instance, setting the appropriate scope (global or local). Most likely, neighbor nodes in the DHT overlay network are several physical hops away. Thus, forwarding of messages between two neighbor nodes in the DHT overlay network is done by forwarding the message from one node to the next along the path between the two DHT nodes in the physical network.

3.5 Path selection

As aforementioned, DCRP implements the principles of HWMP for path selection and forwarding of messages. In the current DCRP version, only the reactive mode of HWMP is used. Further optimizations must be done in order to integrate the DHT scheme with the pro-active mode. The major scalability issue with HWMP in reactive mode is the excessive use of broadcasted control messages.

Excessive broadcast communication is one of the major concerns in large-scale WMN deployments. Although the request/reply scheme used by the HWMP has been shown to be acceptable for a small number of nodes, when it comes to large-scale WMNs, it has a significant impact on the scalability of the network.

As a solution for the overhead caused by the HWMP control messages, DCRP explores the structure provided by the cluster layer to allow query localization and the local repair of the HWMP. Furthermore, instead of introducing new messages to the standard HWMP, an enhancement of these messages is proposed.

The main idea is to control the locality of the messages while striving for minimal modifications. This is achieved by adding fields for the CID and the locality to PREQ (see Fig. 9) and PREP (see Fig. 10) IEs. Actually, to indicate the locality, DCRP uses the Flags field in HWMP messages. More specifically, only one reserved “bit” is used as a flag for locality, where the value 0 indicates a local scope and the value 1 indicates a global one. The PERR IE (see Fig. 11) remains unchanged as any error must be always globally reported. In the current DCRP version, the MAC Address of the cluster head node is used as CID. DCRP uses the CID to control the intra cluster communication instead of the Time-to-Live (TTL) field value as done, for example in [29], because clusters are not a perfect region with ratio of k-hops.

Fig. 9

Enhanced PREQ information element format

Fig. 10

Enhanced PREP information element format

Fig. 11

PERR information element format

These modifications allow to reduce the number of network-wide PREQ messages initiated by the source node, when both the source and destination nodes belong to the same cluster. The control of the HMWP messages scope (local or global) reduces the possibility of having broadcast storms.

In DCRP, only border nodes are allowed to set the locality flag to global value in the path selection. The other nodes within a cluster always set their frames as local. When the locality flag of a message is set to local, mesh STAs only forward the message, if the message’s CID field is the same as its own CID. Otherwise, they just drop the message. Locally scoped messages are constrained to the cluster, minimizing the interference between clusters. From the cluster point of view, using local messages, the physical layer (in DCRP architecture) operates as an isolated IEEE 802.11s WMN.

Global scoped messages are used to cross multiple clusters in wide-range (inter-cluster) communication. A local message becomes global, when a mesh border station receives it, and it does not know any local path to the destination. Thus, global messages create paths between border nodes (possibly with intermediate nodes), allowing inter-cluster communication at the DCRP’s physical layer.

3.6 Forwarding

Forwarding is the process executed by each mesh STA when receiving a frame whose final destination is not itself. In the context of IEEE 802.11s networks, it comprises the modification of the appropriate address fields and the re-transmission of the frame to the next hop in the path to the final destination. In DCRP, to determine the appropriate values of the address fields, a mesh STA must perform a lookup for the destination in any of the forwarding tables it maintains.

The following subsections detail how DCRP forwards frames.

3.6.1 Intra-cluster forwarding

Intra-cluster forwarding is the process of transmitting a frame, in a multi-hop fashion, towards its target, when both originator and target mesh STAs (or non-mesh STA associated to a proxy-MS) belong to the same cluster.

Figure 12 illustrates intra-cluster forwarding in the case where the proxy-MS of the target is different from the one of the originator station. Solid arrows are paths followed by the frame in its end-to-end path from station STA1 to station STA2. The meaning of the dashed arrows is provided below. The numbers associated with some of the arrows are meant to help follow the description of the forwarding process. The general intra-forwarding process is described by Algorithm 1.

Fig. 12

Illustration of a DCRP intra-forwarding

• In step 1, a non-mesh STA1 (previously associated with the mesh STA 1c that acts as an AP, providing access to the WMN) sends a frame addressing non-mesh STA2 as target;

• In step 2, mesh STA 1c looks up its HWMP-routing table but its does not find a path to the target. Then it starts the lookup process in its intra-DHT. After hashing the target address, based on its intra-DHT entries (key-based routing), the resultant ID (ECB7B3A8) is mapped to mesh STA 2d (4DA3F235) in the overlay. Thus, mesh STA 1c sends a LOOKUP message to mesh STA 2d. This LOOKUP message is forwarded towards mesh STA 2d by other mesh STAs in the cluster using HWMP.

• In step 3, upon receiving the LOOKUP message, mesh STA 2d identifies the target ID as one of its related key values. Then, after storing the mapping for the originator (for further communication), it sends back to the source mesh STA (1c) a LOOKUP-RESULT message with the target address and its proxy-MS address;

• In step 4, after receiving a successfully LOOKUP-RESULT message, the mesh STA 1c starts the transmission on the mesh network using the six-addresses frame format (acting as proxy-MS to STA1).

It must be noted that the dashed arrows in Fig. 12 represent a key-based routing in the intra-DHT. Each communication hop in the overlay network may comprise several hops in the underlay network. In case of intra-cluster forwarding, all messages exchanged in the DCRP’s physical layer are flagged as local.

In the case of pure intra-cluster forwarding, the lookup operation never fails in step 4. If the target is unknown, an inter-cluster forwarding is started as explained in the following subsection. Therefore, the major benefit of the proposed intra-cluster forwarding scheme is that all the exchanges of messages involving nodes within the same cluster are constrained to the cluster.

3.6.2 Inter-cluster forwarding

Inter-cluster forwarding is the process of transmitting a frame, in a multi-hop fashion, towards its target, when the originator and target mesh STAs (or non-mesh STA associated to any proxy-MS) are in distinct clusters. The general inter-forwarding process is described by the Algorithm 2. It must be highlighted that this algorithm is started only after a previous intra-forwarding process for the destination has been failed.

Figure 13 illustrates this type of forwarding. Solid arrows are hops of the frame in its end-to-end path from station STA1 to station STA3. As in the previous example, dashed arrows are hops of DHT-related messages.

Fig. 13

Illustration of a DCRP inter-forwarding

• In step 1, a non-mesh STA1 (previously associated with mesh STA 1c that acts as an AP, providing access to the WMN) sends a frame addressing non-mesh STA3 as target;

• In step 2, mesh STA 1c looks up its HWMP-routing table, but it does not find a path to the target. Then it starts the lookup process in its intra-DHT. After hashing the target address, based on its intra-DHT entries (key-based routing), the resultant ID (E9E7F4B6) is mapped to mesh STA 1e (29E1D843) in the overlay. Thus, mesh STA 1c sends a LOOKUP message to mesh STA 1e. This LOOKUP message is forwarded towards mesh STA 2d by other mesh STA in the cluster using HWMP.

• In step 3, upon receiving the LOOKUP message, mesh STA 1e looks up the target ID in its intra-DHT, as in the case of intra-cluster routing. However, as non-mesh STA3 is in another cluster, no entry is found. Therefore, it starts a global lookup, using its inter-DHT and setting the locality of the LOOKUP messages to Global;

• In step 4, upon receiving the LOOKUP message through the overlay, mesh STA 2f (2398703C) looks up in its inter-DHT for the entry of the target ID and finds the corresponding entry. Then it relays a LOOKUP-RESULT message back through the source overlay node (the mesh STA 1e);

• In step 5, the border mesh STA 1e that initiated the inter lookup (here the border node represents the cluster as a single entity) relays the LOOKUP-RESULT message to mesh STA 1c, changing the locality of that message to local;

• In step 6, after receiving a successfully LOOKUP-RESULT message, mesh STA 1c relays to the mesh network using the six-addresses frame format the frame sent by STA1 in step 1, therefore acting as its proxy-MS.

The benefits of the proposed inter-cluster forwarding scheme are as follows. First, the use of unicast messages based on the inter-DHT lookup. Second, as the inter-forwarding is performed mainly by border nodes (with a few intermediate nodes), the inter-cluster traffic is also reduced. Therefore, the distributed lookup is much more scalable than the standard mechanism.

4 Simulation assessment: setup

In the previous section, the architectural design of the DCRP was presented. This article claims that DCRP is a potential solution for deploying large-scale IEEE 802.11s mesh networks. In order to support this claim, this section presents a detailed simulation assessment of the DCRP performance, regarding the network scalability in IEEE 802.11s WMN scenarios.

To assess the proposed protocol, a simulation model of the DCRP was implemented using the ns-3 network simulator. A set of simulations were carried out in order to evaluate the DCRP’s scalability properties, claimed in the previous chapter, and to compare it with the standard HWMP. The simulation parameters and the experiment details are also presented. Finally, the assessment results are presented and discussed.

The ns-3 simulator and the mesh module extension The ns-3 simulator has been largely used by researchers to study and evaluate the performance of routing protocols (including their own proposals) in both MANETs and WMNs, including IEEE 802.11s [36–44]. In ns-3, some of the IEEE 802.11s features are modeled in the mesh model (previously called dot11s module), introduced in [45] and now distributed as part of the ns-3 default source code. The most important features are the implementation of the peering management protocol (PMP), the HWMP and the ALM [46]. PMP includes peering establishment and beacon collision avoidance. HWMP includes proactive and on-demand modes, but the RANN mechanism is not supported and hence the proactive PREQ mechanism is used in the proactive mode. The ALM computation is implemented and used as the default metric for HWMP.

The ns-3 mesh model code is still incomplete and is no longer maintained by its authors. Therefore, some features where implemented to allow the complete implementation of the DCRP. One of the most important additions made to the existing mesh model was a set of modifications to the HWMP, namely: implementation of six-addresses scheme, and the implementation of the proxy scheme (to allow the internetworking with stations outside the MBSS).

Although already defined in the MeshHeader class, the additional MAC six-addresses scheme is not used in the current ns-3 mesh model implementation. Therefore, an addition to the source code was made to implement this feature to allow non-mesh STAs to use the MBSS as a communication backhaul. Additionally, the mesh gate role with support to mesh portal and collocated access point features was also implemented.

To enable internetworking between MBSS and non-mesh STAs, the ns-3 mesh model was extended with new information elements (IEs) for Proxy Update (PXU) and Proxy Update Confirmation (PXUC). These IEs are used by the mesh gate.

As specified in the standard document [1], only a single active path selection protocol should be used in a single IEEE 802.11s MBSS. As aforementioned, HWMP is the default path selection protocol. In the current standard document, the Active Path Selection Protocol Identifier field value for the HWMP is set to 1, whereas values [0,2..254] are reserved for future use, and 255 is used to indicate that the active path selection protocol is specified in a vendor-specific element (see Table 8–177 in [1]). So, this field value was set to 2, indicating the use of the DCRP as path selection. This information is embedded in the mesh configuration information element. Specific values to identify the action frames used to carry DCRP information (for both DHT and cluster-related messages) were also defined.

4.1 General simulation parameters and assumptions

The definition of a well-defined set of simulation parameters and assumptions aims to ensure the reproducibility of the simulation results. Although the assessment of the DCRP was performed using a set of distinct simulation scenarios in the ns-3 simulator, they still share some common assumptions and simulation parameters, as follows.

All simulations are based on the IEEE 802.11s mesh model, which means that the stack ns3::Dot11sStack is installed in all nodes.

For modeling the wireless channel, in all simulation experiments, the Constant Speed Propagation Delay Model and the Log Distance Propagation Loss Model were used. This propagation model assumes an exponential path loss over the distance from sender to receiver [47].

User Datagram Protocol (UDP) traffic streaming was established between a certain number of senders to a certain numbers of receivers. The traffic transported by UDP was constant bit rate (CBR) traffic which allows simulating real time multimedia applications. The application OnOffApplication was used to generate traffic. CBR was assumed to generate traffic flows between source and destination nodes with a constant data packet size of 512 bytes. In order to create enough traffic, the default data rate value used was set to 1024 kbps.

In all simulation experiments, the nodes were arranged in a N×N grid topology. The value of N in some experiments varies in the set [3,4,5,6,7,8,9,10]. The parameter N is used to scale the IEEE 802.11s WMN in terms of number of nodes that form the backhaul, which means that the network size is scaled from a total of 9 to 100 mesh STAs forming the mesh network. The nodes are equally spaced in the grid, both vertically and horizontally.

Non-mesh STAs (or clients) are randomly distributed along the square area of the grid. Each non-mesh STA connects to its closest mesh STA which will act as mesh gate to the mesh backhaul. It means that all mesh STAs in the backhaul also act as an AP collocated with a mesh gate.

Such backhaul mesh networks in real-world deployments are normally formed neither in a self-organized fashion, nor in a grid shape. Instead, the location and placement of each mesh STA, AP collocated with a STA, and mesh portal is carefully planned, applying network planning [48] or genetic algorithms (GA) [39]. Nevertheless, grid shape has been widely used by researchers to evaluate the scalability of IEEE 802.11s mechanisms [13, 49–52] as it provides a simple and controlled environment, allowing a fair comparison of reproducible results.

For each run, the same number of non-mesh STAs are created and randomly distributed in a square area covering the grid. After a random start time, each non-mesh model associates with a closer mesh STA (the selection criteria follows the normal IEEE 802.11 standard). Moreover, 50 % of the total clients were configured to generate traffic. The choice of the source and destination for the traffic flow is taken randomly at run time to create more realistic scenarios.

Each simulation batch had a duration of 700 s and was repeated 50 times (with distinct seeds) in order to obtain a higher confidence degree. It is important to note that to avoid packet loss due to either network warm-up time or premature ending, in all simulations, the source nodes start to generate data traffic only after StabilizationTime (in seconds) and stop a StabilizationTime before the end of the simulation. This procedure ensures a fair comparison of the protocols, waiting until the mesh network reaches its topological steady state and giving time to late packets to find their way to its destination. The StabilizationTime was set to 50 s.

Three different elements were established in a random manner: sender and receiver node, communication start time and duration of each connection. The procedure to select pairs of sender and receiver nodes ensures that the sender is not the receiver in a pair. The connection start time is given by UniformValue(StabilizationTime,SimTime-StabilizationTime), and the stop time by SimTime-StabilizationTime The random values are generated from a fixed uniform distribution, using the UniformVariable class.

The simulation results were plotted based on average values of all runs. Seeking to obtain highly meaningful results, each run is independent from all others. To ensure that, each set of simulations was conducted using an unique simulation seed and a different seed for each run. The first ensures the repeatability of the experiment, whereas the second ensures the statistical independence of the results.

General simulation parameters are presented in Table 2, while the most relevant parameters for the ns-3 mesh module are presented in Table 3. The beacon collision avoidance 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, the implemented procedure produces very limited advantages and reduces the throughput. Thus, it was disabled to not drop down the performance of HWMP. Other important parameter that had to be changed was the max beacon loss in HWMP. Its default value is set to 2 (which is extremely low) and sometimes due to the propagation loss model, some connections are set as not valid beforehand.

Table 2 General ns-3 parameter values used for the simulations

Table 3 Mesh module parameter values used for the simulations

4.2 Performance metrics

The following metrics were considered to compare both the performance and scalability of DCRP and HWMP.

Packet delivery ratio (PDR) PDR can be defined as the ratio of data packets received by the destinations to those generated by the sources. PDR can be computed using Eq. 1, where n _d is the number of packets successfully delivered and n _s is the number of sent packets. This metric is usually presented in terms of percentage.

$$ \text{PDR} = \frac{n_{d}}{n_{s}}~~,or~~\text{PDR} (\%) = \frac{n_{d}}{n_{s}}*100 $$

((1))

System throughput (ST) It can be defined as the cumulated throughput for all flows in the network. In other words, it is the ratio between the amount of packets successfully received over the activity time for all flows. In this work, the throughput is computed using Eq. 2, where n _d,f is the number of packets successfully delivered to the flow f, Size() is a function which returns the size (in bytes) of each packet p _i,f , F _i,f is the arrival time of the first packet successfully received (in seconds), and L _i,f the arrival time of the last packet successfully received (in seconds) for the flow f.

$$ ST = \sum_{f=1}^{n_{f}} \frac{\sum_{i=1}^{n_{d,f}}\text{Size} (p_{i,f})*8}{L_{i,f}-F_{i,f}} $$

((2))

End-to-end delay (EED) This metric can be defined as the average transmission delay of all delivered packets. It includes all possible delays caused by buffering during path discovery latency, queuing at the interface queue, retransmission delays at the MAC, propagation and transfer times. EED is computed using Eq. 3, where n _d is the number of packets successfully delivered, T _{r x(i)} is the time that the packet was received at the destination and T _{t x(i)} is the time that the packet was transmitted (or the first attempt of) by the source.

$$ \text{EED} = \sum_{i=1}^{n_{d}} \frac{T_{rx(i)}~-~T_{tx(i)}}{n_{d}} $$

((3))

Normalized Routing Overhead (NRO) The routing overhead is usually defined as the number of routing bytes required by the routing protocol to construct and maintain its routes. Although this metric has its significance, it is disconnected from the data delivery. For example, in a comparison of two protocols, a high overhead of one protocol seems to be undesirable, but it can compensate this by increasing the amount of delivered data. Therefore, the Normalized Routing Overhead is a better metric to analyze the protocol overhead. This metric represents the total number of routing packets divided by total number of delivered data packets. In other words, it indicates the extra bandwidth consumed by overhead to deliver data traffic. NRO is computed using Eq. 4, where n _rs is the total number of routing packets sent by the nodes, n _rf is the total number of routing packets forwarded by the intermediate nodes and n _d is the total number of data packets successfully delivered.

$$ \text{NRO} = \frac{n_{rs}~+~n_{rf}}{n_{d}} $$

((4))

Equation 4 is quite unbalanced if different packet sizes are considered. In other words, a protocol A that generates a large number of small routing messages would be penalized by NRO metric in comparison to another protocol B that uses less but larger routing messages. Therefore, alternatively, the NRO can be analyzed in term of bytes using Eq. 5, where n _rs is the total number of routing packets sent by the nodes, n _rf is the total number of routing packets forwarded by the intermediate nodes, Size() is a function which returns the size (in bytes) of each packet p _x and n _d is the number of data packets successfully delivered.

$$ \mathrm{{NRO}_{[bytes]}} = \frac{\sum_{i=1}^{n_{rs}}~\text{Size}(p_{i})~+~\sum_{i=j}^{n_{rf}}~\text{Size}(p_{j})}{\sum_{k=1}^{n_{d}}~\text{Size}(p_{k})} $$

((5))

The performance metrics listed above were collected by using a double-checked approach: first, the FlowMonitor [53] module was applied to generate the metrics’ values, and then these values were compared with the values recorded during the simulation using the tracing subsystem of ns-3, and callbacks. This approach aims to ensure the reliability of the data analyzed in the following subsections.

5 Simulation assessment: results

In this section, the results for the comparative simulation assessment between the DCRP and the HWMP, regarding their scalability properties, are presented and discussed.

5.1 Scaling the number of nodes

In a first and obvious experiment, the scalability of the protocols was evaluated regarding the number of nodes. This study was set out to investigate the effects of varying the network size (number of mesh STAs) over the set of performance metrics previously defined. The simulation results regarding this experiment are plotted in Figs. 14, 15, 16, and 17.

Fig. 14

The effect of the number of nodes over the PDR. a HWMP. b DCRP

Fig. 15

The effect of the number of nodes over the Delay. a HWMP. b DCRP

Fig. 16

The effect of the number of nodes over the throughput. a HWMP. b DCRP

Fig. 17

The effect of the number of nodes over the Normalized Routing Overhead. a HWMP. b DCRP

The results of the effect of the number of nodes over the PDR are plotted in Fig. 14. The PDR values for both the HWMP (see Fig. 14a) and DCRP (see Fig. 14) protocols decrease as the number of nodes increase. This is an expectable result, as the number of mesh STAs has a significant impact upon the PDR due to the increasing inter-flow interference caused by the number of concurrent connections. However, regarding the PDR values, DCRP scales much better than HWMP. In average, in the simulated scenario DCRP provides PDR values 60 % higher than the related HWMP values. The difference becomes even higher for a large number of nodes, where DCRP overcomes HWMP in up to 73 %. This behavior can be explained by the use of HWMP messages with local scope for many communications in the DCRP protocol.

Figure 15 illustrates the effect of scaling the number of nodes over the delay. Analyzing the obtained results, both DCRP (see Fig. 15 b) and HWMP (see Fig. 15 a) presented a close tendency curve in terms of delay. A closer look at the Fig. 15b reveals that the DCRP is more resilient to the increasing of the network size, presenting slightly lower delay values with a lower standard deviation. Therefore, the DCRP also reduces the communication jitter.

Figure 16 illustrates the effect of scaling the network size over the throughput and normalized overhead metrics, respectively. Checking DCRP throughput results (Fig. 16 b), it clearly outperforms HWMP (Fig. 16 a). The descendent exponential curve behavior for the throughput can be explained by the increase of simultaneous connections among the non-mesh STAs that increases the interference. The low throughput of HWMP is partially explained by the high number of transmission outages due to concurrent flows generating traffic at higher data rates, which leads to long transmission queues (in some cases resulting in the dropping of the packet). As the network load increases, the channel condition and interference varies with time, and this cannot be captured with the standard ALM metric.

Finally, Fig. 17 illustrates the effect of scaling the network size over the normalized overhead metric and revels an interesting finding. Considering a small network with 9 or 16 nodes, for a DCRP clustering scheme with k=3 in a grid topology, a single cluster will be created. In such a case, it would be expected a network behavior very similar to the HWMP case (or even worse), because of the increased overhead of the cluster and DHT maintenance. Instead, Fig. 17 shows that even for small size networks, DCRP presents smaller values for NRO. The explanation is that the addition of 6 bytes used to identify the CID in the HWMP messages (the locality bit is already part of the standard frame), and the overhead associated with the DHT is compensated by the efficiency of the intra-cluster forwarding, which proved to be less costly than exchanging proxy messages (PXU and PXUC).

5.2 Scaling the data rate

A second set of simulation experiments was set up to analyze the effect of varying application data transmission rate in the IEEE 802.11s WMN for both protocols. This second simulation experiments were carried out by varying the CBR traffic with the values 150 kbps, 300 kbps, 600 kbps, 1200 kbps, and 2400 kbps. Seeking to reproduce a fair comparison between these two protocols, for this experiment, the node grid was sized to 8×8 (i.e., 64 nodes). The simulation results are presented in Figs. 18, 19 and 20.

Fig. 18

The effect of the transmission rate (traffic load) over the PDR. a HWMP. b DCRP

Fig. 19

The effect of the transmission rate (traffic load) over the Delay. a HWMP. b DCRP

Fig. 20

The effect of the transmission rate (traffic load) over the Throughput. a HWMP. b DCRP

Figure 18 illustrates the effect of scaling the transmission rate. Checking the results, DCRP (see Fig. 19 b) clearly overcomes HWMP (see Fig. 19 a) in terms of packet delivery. This was an expected result due to the increased number of packets drops caused by the interference and path length (in number of hops). Moreover, by containing local communication within the cluster, DCRP tends to reduce the interference with data flows having other cluster either as source, or destination. The use of unicast messages (through the inter-DHT) to locate and forward messages between distant (in hops) nodes also contributes to achieve better PDR results.

Figure 19 illustrates the effect of scaling the transmission rate over the delay. Although similar, the delay curve for the DCRP (see Fig. 19 b) presents values lower than the HWMP curve (see Fig. 19 a). For both protocols, the standard deviation values are considerable. This variation will affect the jitter values for both protocols.

Similar observations are valid for the effect of varying the transmission rate on the throughput, as illustrated in Fig. 20. Checking the results, it is clear that throughput values for both protocols reduce as the data rate increase. These results are consistent with those from Fig. 18 that highlights the PDR behavior. Even so, DCRP (see Fig. 20 b) clearly outperforms HWMP (see Fig. 20 a) in what concerns its throughput. This can be attributed to several factors. Obviously, the reduction of congestion provided by the reduction of broadcasted messages, and a higher PDR clearly contributes to this result.

Finally, it is important to note that the simulation results observed in this experiment are strongly consistent with those obtained in the previous experiment for the same grid size and data rate.

5.3 Discussion of the results

This section sums up the simulation assessment results and presents the main findings from the experiments described above.

As the network becomes larger by scaling the number of mesh STAs, or increasing the data rate, the PDR decreases for both DCRP and HWMP protocols. However, the PDR value decrease is significantly slower for the DCRP curve than for the HWMP, in both experiments.

Regarding the EED, in the first experiment, besides clearly outperforming the HWMP, the DCRP results also registered a standard deviation consistently smaller than those for the HWMP as the network scales. This is a desirable behavior, as it significantly impacts on the delay jitter. In the second experiment, the opposite was observed. The results reveal that the DCRP (and the HWMP as well) presents a high variation of delay values in response to the increasing of the data rate.

In terms of the ST, the results from the simulation experiments can not be directly correlated. In the first experiment, the network was scaled in terms of number of nodes, but with constant transmission data rate. Obviously, in such a scenario, it was expected that the throughput decreases as the network size increases. The main justifications for this behavior are the increasing of the average path length for the data flows, and the increase of both inter- and intra-flow interferences. Even so, the DCRP provides better results in terms of average values and presents a smoother degradation of its curve.

The NRO is a critical metric to prove the viability of the DCRP design. The results for this metric suggest that the overhead introduced by the creation of the clusters, creation of the DHTs, and the proposed enhanced HWMP messages have payed off, allowing to achieve better performance metrics, as discussed above.

Overall, DCRP achieved significantly better performance metric values for all simulated scenarios with markedly less generated overhead than the standard HWMP. These simulation results provide an initial and encouraging look at the performance of the DCRP.

6 Conclusions

In this article, we have introduced the DHT-based Cluster Routing Protocol (DCRP)—a path selection scheme designed to increase the scalability of 802.11s WMNs. The main features of DCRP are the following. Firstly, the introduction of the notion of locality to the HWMP messages, which is later used to constrain the intra-cluster traffic. Secondly, a distributed management scheme of proxy-related information using DHT concepts. Thirdly, the novel forwarding scheme that integrates both previous features to efficiently forward messages in both local (intra-cluster forwarding) and global (inter-cluster forwarding) scopes. The key benefit of this approach is that it can significantly reduce the number of path selection and forwarding protocol messages. The main reason for this behavior is that local communication (with both originator and target in the same cluster) will not be broadcasted to other clusters. Another improvement is the reduction of the number of messages exchanged among clusters, as it will mainly involve the border nodes. These features were assessed through simulation.

The DCRP model was implemented using the ns-3 simulator. A comparative simulation assessment was made, using the existent HWMP implementation (which is part of the mesh module). Simulation results reported in this article are evidences that the DCRP significantly improves IEEE 802.11s WMNs in terms of scalability, providing a reasonable gain in performance for the conducted experiments and evaluated metrics. These results were expected and can be explained by the use of unicast messages (trough DHT) combined with the reduction of the number of broadcasted messages (by using the notion of cluster locality and inter-cluster lookup).

The reported simulation results are a clear indication that exploiting the properties and synergy of DHT and clustering concepts can provide a promising solution for larger WMN deployments. Further improvements to the DCRP scheme includes to evaluate its performance by testing other DHT substrates in replacement to the current Chord implementation. In this sense, the DHT literature provides interesting options such as Ekta [27], MADPastry [25] and MeshChord [54]. Another research direction to be pursued is to develop a more efficiency peering selection and management mechanism to increase the lifetime of formed clusters. To the best of our knowledge, to date, few works [55, 56] studying or proposing new mesh peering selection mechanisms.

Although in this article was focused in a DHT-based scheme, it must be highlighted that other forwarding strategies can be jointly or separately used to improve our solution. The forwarding strategy chosen will severely affect the protocol design and its performance [2]. Prominent examples are cognitive radio [57–59], network coding [60, 61] and directional routing [62, 63]. Moreover, the spatial reusability of the wireless communication media must be carefully considered in order to improve the end-to-end throughput in multi-hop wireless networks [64–66]. Future work includes some effort in researching the impact of these strategies in the scalability of IEEE 802.11s mesh networks.

7 Endnotes

¹ This table is not illustrated in Fig. 4 to avoid cluttering.

² The DHT scheme, like the clustering scheme, is designed as a building block and can be easily replaced by any other scheme.