Design approach

Chapter 5. Implementation in QualNet

5.1. Design approach

This chapter presents architectural aspects related to the implementation of our mesh protocol in the QualNet simulator, version 4.0. QualNet is an event-driven simulator [48] for wireless, wired and mixed-platform network; it has the ability to model for network devices, transmitters, antennas, and all network components with a very high scalability that puts it as a simulator of choice for complex mesh network analysis. It is organised in layers just like ISO/OSI or TCP/IP standard; a different protocol with associated logic can be simulated at each layer.

As already shown in the previous chapter, the new protocol for mesh network could be organized in three sub-layers within the MAC layer. It is possible to identify some fundamental elements with different networking functions at each sub-layer. The mesh control sub-layer presents two blocks that implement a list structure. The first block is used to save the mesh portal discovered while the other block is used to save the next hop for the switch/routing protocol. On the other hand, the mesh MNGM sub-layer presents the peer link table where all direct neighbours are saved. These elements are produced using a dynamic double linked list data structure.

The last sub-layer is the Mesh MNGM Controller which is responsible of managing different concurrent wireless interfaces in the same wireless mesh node. Due to the presence of multiple interfaces in a single node, multiple instances of this sub-layer will be invoked in a mesh node. In Figure 16, a state machine illustrates the mesh controller behaviour, and highlights the main logic behind our mesh protocol design.

Figure 16: state machine for mesh management layer.

For an easier analysis, the state machine can be divided into two logical parts. In the first part, on the left side, the state machine handles the channel selection. In the second part, the state machine is involved in three different operations: create Peer Link (PL), send beacon, propagate data frame.

The following states are involved in the channel selection procedure:

• IDLE: this is the starting point for the state machine; no actions are performed in this state.

• SCAN: in this state the scan process is started, and the first channel is selected.

• WFSCAN: the next channel to be scanned is selected, and the information concerning the beacon received is being saved.

• SCAN_FINISHED: this state represents the end of the scanning cycle.

• CHAN_SELECTION: the best channel is being selected.

The states involved in the peer link creation procedure are:

• PL_FIRST_CREATION: the system starts the procedure to create a new PL.

• PL_FIRST_FINISCHED: this state identifies the end for the first PL procedure, allowing beacon propagation.

• PL_CREATION the system starts the procedure to create a new PL (but after the first PL has been created).

In the send beacon part only two states are used.

• W_SEND_BEACON: represents a state of transition between beacons.

• BEACON: in this state the mesh controller requires the lower layer to send a beacon.

In the propagate data frame part only one state is present:

• DATA_TO_SEND: represents a request to forward a data frame.

When the channel selection period is finished, from the “CHAN_SELECTION” state the controller can move on to the state “PL_FIRST_CREATION” to start the peer link procedure, providing that a beacon has been detected,. Otherwise, it moves to

“W_SEND_BEACON” and starts to transmit periodically a beacon frame allowing other mesh nodes to join its network tree. In general, the system spends its time moving between the states “W_SEND_BEACON” and “BEACON” waiting to detect neighbour or data frame. The controller remains in this state until a beacon frame has been sent; after that it returns to the previous state to begin a waiting cycle before sending another beacon frame.

The implementation of this beacon management mechanism requires a memory at the W_SEND_BEACON state in order to compare the current state with the previous one;

a special variable has been used for this purpose. The Figure 17 below gives a time representation for this mechanism.

Figure 17: temporal shame for beacon interval and its transmission.

As shown in the Figure 17, the system can stay in the “W_SEND_BEACON” state for a short or long period: the short one represents an internal interval required to change the state, the other is the inter-beacon interval. In other words, the “pending beacon variable” is used to distinguish, on the event of time out, if it is the moment to send a beacon or instead to start a new timer for simulating the interval between two beacons.

The “DATA_TO_SEND” state is another important state where a data frame from the management layer requires service. The data frame reception is an asynchronous event for the state machine, causing an interruption in the beacon cycle. Figure 16 also shows other states: in particular there are two different methods to perform the peer link procedure. The reason for this double method is related to the beacon sending

procedure. In fact, if the system enters in the “PL first creation” state, no information concerning the mesh network is available due to the lake of PL so the node can transmit an empty beacon (only to extend or start the mesh network). When the first PL is created, all the available information received from the sender can be used to update the beacon information. In the “PL creation” state even if beacons are not sent, information concerning the network are available.

Before analyzing the data frame reception in the mesh network a brief description covering the data frame header is necessary for a better comprehension of the following flow chart datagram. Figure 18 shows a simplified frame header for a data packet. It is possible to identify three pair of addresses; the first one is used to identify the next hop that is the next destination and the current source of the frame, the second pair of addresses identify the end to end source and destination of the frame, and finally the last pair of addresses is used for the external node. In other words, address 1 and address 2 correspond to the MP receiver address and the MP transmitter address for a particular mesh link; address 3 and address 4 correspond to the destination and source endpoints in the mesh network and, if used, address 5 and address 6 correspond to the final to-end destination and source addresses, provided that both of the end-points are external to the mesh network but within the same Ethernet network. When the end points are non-mesh node, the connection is bridged via proxy MPs.

Figure 18: Simplified data header structure; in red box are represented the destination address field, and in black box the source address.

The below flow charts describes the data frame reception and processing at mesh layer from the lower layer (physical layer and original MAC layer). Independently from the type of mesh node who receives the data frame; data frame processing starts invoking the method “Mesh hand off successfully Rx unicast” from the original MAC layer (identified in QualNet as dot11). This function has two goals: to check if the mesh profile is enabled and to forward the incoming data frame to the appropriate function according to the type of node (MP, MAP or MPP). The mesh profile describes the network backbone characteristics such as the type of routing protocol used in the mesh network and the metric adopted to validate the PL. A mesh node is able to forward data frames if it has a valid profile. Valid profile means that the node has at least one

neighbour node, one path to MPP is known, the node uses the same routing protocol of the neighbour node in the mesh network and the same metric is used to validate a PL.

When all these conditions are verified it sets its meshProfileState variable to the enable value, so that the node will be able to process the incoming frame.

The method “Mesh hand off successfully Rx unicast” is shown in Figure 19.

Figure 19: reception data frame.

As previously illustrated this function first checks if it is able to process the frame (mesh profile enabled) then the “mesh hand off successfully Rx unicast” function forwards the frame to the appropriate method according to the node type (MAP MP MPP).

Figure 20 shows the flow chart, for data processing, when the receiver node is a MAP.

Figure 21 illustrates the flow chart for the function “MP process data frame” called when the node is a MP.

Figure 20: flow chart for MAP process data frame.

The function “MAP process frame” has two different behaviours due to the fact it has to be an Access Point (AP) for the standard Wi-Fi users and a MP for the mesh backbone. Considering that a MAP has multiple radio interfaces, at list one can be dedicated to AP functionality and the other interfaces can be used in the backbone.

Therefore, “MAP process frame” changes its behaviour depending if the interface receiving the packet is the AP or one of the other interfaces. In the first case, the

“MAP process frame” removes the original MAC header and inserts the new mesh data header with six address fields: afterwards, it calls a function to forward the frame to the next hop (shown on the left side of Figure 20). In the other case, the function checks if the received packet is a multicast/broadcast or a unicast frame; the multicast/broadcast packet are dropped (in this implementation multicast functionalities are not supported). In case of unicast frame, if the destination address (saved in the third address field in the mesh data header) matches with its MAC address, the frame is processed using the function “mngn MAP handle its data frame”, which checks if the fifth address field in the data header (used to save the external

The list of STAs connected with the MAP are saved into the MAP’s switch/routing table during the association procedure. When the destination node is in the MAP’s list, the MAC frame header is changed into the legacy 802.11 frame and bridged to the AP interface which sends the data frame to the STA. Otherwise, the frame is passed at the

“mngm MAP handle no its data frame” function which is responsible of forwarding it to the next hop.

Figure 21: flow chart for MAP process data frame.

Figure 21 deals with the case of data frame received when the node is a MP; it looks similar to the function used when the node was a MAP. Thus, for the unicast frame, when the destination address (saved in the third address field in the mesh data header) matches with the interface MAC address, the frame is sent to the upper layer because the MP is the destination for this frame. The destination for the traffic is not the usually MP in mesh networks, so the “mngm handle no its data frame” function is called.

The “mngm handle no its data frame” function is shown in the right side of the flow chart. This is the main function in the MP because it is responsible of forwarding data frames to the next hop and decreases the Time to Live (TTL) counter in the mesh data header to avoid possible loops. In this procedure there is an additional function to save the reverse path, and a request to the upper mesh control layer to find out the next hop address for the incoming frame.

In the event that the receiver node is a MPP, the function “MPP process frame” is called, which in essence similar to the functions called in case of MAP or MP node. As a first step in this process, the function checks if the incoming packet is a unicast frame, then it checks if the third address in the data header matches with the local MAC address; if this latter test is positive, the mesh data header is removed and the frame is sent to the IP layer that either further forward the packet to upper layers for processing or route the packet to the external network. In the other case, like the MAP, the system tries to forward the frame to the next hop at Layer 2.