IEEE s Mesh Networking Evaluation under NS-3

Transcription

1 PROJECTE FINAL DE CARRERA IEEE s Mesh Networking Evaluation under NS-3 Estudis: Enginyeria Electrònica Autor: Marc Esquius Morote Director: Miguel Catalán Cid Abril 2011

2

3 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 characterized by wireless multi-hop connectivity and facilitate a simple and cost-effective establishment of wireless networks while providing large coverage areas. IEEE s 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 implementation 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: s, mesh networking, routing protocol, HWMP, AODV, NS-3

4

5 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 Catalán with whom I exchanged tons of s while dealing with several problems and debating about NS-3. Without them, it would not have been possible! i

6

7 Contents Acknowledgments i 1 Introduction The need of a new standard State of the art Aim of this research Structure of the report IEEE s Network design Mesh formation and management Mesh Profile Mesh creation Path selection mechanisms Airtime Link Metric Hybrid Wireless Mesh Protocol Medium Access Control Frame structure and syntax iii

8 3 IEEE s model in NS Network Simulator Model design Supported features Unsupported features Model implementation MAC-layer routing model Simulations Considerations Figures of merit Environment Transmission rate Number of hops Analysis of the interference model HWMP vs. AODV Configuration Routing metric Scalability Results HWMP Reactive vs. Proactive Configuration Destination Only flag Comparison Results iv

9 7 Conclusions and future work 59 A AODV routing protocol 61 B NS s modules 65 B.1 MeshHelper B.2 MeshPointDevice B.3 HWMP B.4 Peer Management Protocol B.5 Peer Link C NS-3 Scripts 73 C.1 HWMP Grid C.2 AODV Grid C.3 HWMP different modes Bibliography 105 List of figures 109 List of tables 111 v

10

11 Chapter 1 Introduction 1.1 The need of a new standard The present interconnections rely on wired networks to carry out bridging functions. 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 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

12 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 Task Group S. The particular amendment of the standard dealing with mesh support, s [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 standard to exactly address the aforementioned need for multihop communication. Nowadays the current draft is the /D10 and even though no formal standard has been ratified, there are several companies in the market with their solution, largely based on draft s. 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 simulators. For example, in [5] and [6] is analyzed the delay, throughput and the performance of some new features of the s under a simulation environment. In [7] are also compared the new type of routing metric proposed by the draft with some other common 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 implementation 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 s 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

13 1.3 Aim of this research The aim of this research is to evaluate the performance of the wireless mesh structure defined by the s 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 accurate 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, s 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 s needed to discuss later the results. In order to evaluate the mesh structure and the routing capabilities, the network simulator 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 s 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

14 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 s are compared 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

15 Chapter 2 IEEE s In this chapter a detailed explanation of how the IEEE s works is presented. First, in section 2.1 the network design including its structure and different node categories 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 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 , 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

16 that choose to involve DSS. The portal is a logical point for letting MSDUs from a non 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 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 s is one of such schemes. In s, 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 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 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 functionality but can work as relaying nodes, the meshed wireless LAN is not an ESS anymore. The s MAC is developed based on existing 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

17 Figure 2.1: The s network architecture 2.2 Mesh formation and management 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 distinguish 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 identity exists, but instead of overloading the definition and function of the SSID, the draft proposes a Mesh identifier or Mesh ID. Similarly to , 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 s mandatory profile defines the Hybrid Wireless Mesh Protocol (HWMP) as the path discovery mechanism and the Airtime Link Metric (ALM) as the path 7

18 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) 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 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

19 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 parameters, 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 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 retransmission, 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

20 time. The ALM is designed to avoid both problematics and according to the standard the airtime cost, Ca, is calculated as: Ca = [ OcaOp + Bt ] 1 r 1 ef (2.1) 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 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 a b Description Oca 75µs 335µs Channel access overhead Op 110µs 364µs Protocol overhead Bt # bits in test frame Hybrid Wireless Mesh Protocol The network infrastructure of 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 s. 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 s. For more information on AODV check appendix A or the RFC of the IETF [1]. 10

21 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

22 - [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 subsequent 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

23 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 element 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

24 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 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 duration may not exceed the transmission opportunity (TXOP) limit. The intended receiver acknowledges any successful frame reception. Additionally, EDCA differentiates 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

25 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 s emerging standard extends the original 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 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

26 Besides those two bits, there are also four more bits devoted to a frame subtype. Since IEEE s is an amendment to IEEE , 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, defined 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 , those bits mark frames as being originated from or destined to a distribution system, which is the infrastructure that interconnects access points. Similarly to a WDS, IEEE s 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 frames. In an ad-hoc network, peer- to-peer transfers can happen opportunistically 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 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

27 Figure 2.5: IEEE s 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 s, 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 for transmissions using a WDS, but in order to support non-mesh stations, IEEE s 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

28 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

29 Chapter 3 IEEE s model in NS-3 This chapter provides an explanation of how is implemented the s wireless mesh networking model in the Network Simulator 3 (NS-3) and which features or characteristics 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 s [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 environment. The following trends is how Internet research is being conducted are responded by NS-3: 19

30 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: interoperability 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 MAC and PHY models together with real world design philosophy and concepts made NS-3 the choice for developing this s model as well as for carrying out this research. 20

31 3.2 Model design To meet these requirements imposed by s of supporting multiple interfaces (wireless 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 according to the description of the draft presented in chapter Supported features The most important features supported are the implementation of the Peering Management 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 functionality 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 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

32 3.3 Model implementation The description of which modules are implemented in C++ and how they interconnect 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 information 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 s 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 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 provides 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 MAClayer 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

33 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 MeshWifiInterfaceMacPlugin. 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

34

35 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 overlap 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

36 correlations between them. If we set one seed, then it allows as to generate 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

37 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 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 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

38 it is a valid 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 a 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) Transmission rate As explained in the previous sections, the physical model of a 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 a 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 network 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

39 Table 4.1: Data rate for each transmission rate Transmission Data rate rate (Mbps) (Mbps) Figure 4.1: Transmission rate vs. distance 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

40 (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 (signalto-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 transmissions 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 limitation found in the other common network simulator ns-2. Presently, however, there is no model for cross-channel interference or coupling. 30

41 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 > 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

42 Scenario 2a 90m 90m node > node 2 - distance - node > 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

43 (a) PDF in scenario 2a (b) PDF in scenario 2b Figure 4.4: Interference Scenarios 2a and 2b 33

44

45 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 connections). HWMP protocol implemented in this ns-3 version is explained in section 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