## 6 Distributed LoWMob (DLoWMob) Mobility Support Scheme
### Route Optimization for Intra-PAN Communication in DLoWMob
#### 6.2.1 Routing of MN's Packet in a Route Optimized Environment  
The MSPs in DLoWMob enables the route optimization between multiple corresponding MNs by creating and storing the routing entries, specific to the MNs in their routing table. Based on the routing table entries, the proposed mobility header facilitates routing between a source and the destination MSP.  
The routing of MN's packets with the help of MSPs has two stages. In the first stage, a source MSP tries to locate a destination MN's MSP on behalf of the source MN. In this process, source and destination MN's specific routing entries are created in the MSPs that fall within the path of the source and destination MSP. In the second stage, the data packets are routed based on the routing entries created in the MSPs and the proposed mobility header and dispatch.  
Figure 11 shows two MNs, as located within the same PAN. MN1 is associated with SN15, whereas MN2 is associated with SN26. When MN1 wants to send a data packet to MN2 for the first time, it first sends it to SN15. The packet format can be the same as described in Figure 7.  
When SN15 receives a data packet from MN1, it forwards the packet to MSP1. MSP1 checks whether it has an entry for the MN2 in its routing table or not. If the source MSP, i.e., MSP1 does not find a routing entry for the destination MN, it takes off the mesh header from the data packet and adds MN-GW dispatch and MN-GW header to the data packet. The source MSP then forwards the data packet to the GW, which in turn advances it to the destination MSP using the packet format as shown in Figure 9. However note that in Figure 9, destination SN address will be replaced by destination MSP address. When the packet reaches the destination MSP, the destination MSP replaces its address with SN's address with which the MN is associated.  
Figure 11: DLoWMob mobility scheme with Route Optimization.  
Also at the same time, the GW sends a _location_MN_ message to the source MSP. The _location_MN_ message contains the address of the destination MSP. Once the source MSP receives the location information of the MN, it sends a _request_pathsetup_ message to the destination MSP, which contains the IDs of both MN1 and MN2. When the destination MSP, i.e., MSP6, receives _request_pathsetup_ message, then it forwards the message to the SN with which the destination MN is associated, i.e., SN26. The destination MSP, i.e., MSP6, then sends a _path_setup_ message back to the MSP1 that contains MN2 and MN1's ID. When forwarding the _path_setup_ message back to MSP1, the MSPs en route records destination and source MSP address, IDs of both MNs, and the MSP from which it has received a _path_setup_ message. Thus each MSP would get a routing table entry in order to route the packets between the MNs. When MSP1 receives _path_setup_ message, it creates a routing entry for the destination MN, i.e., MN2; and forwards _path_setup_ message to SN15 with which MN is currently associated. Moreover, when the _path_setup_ message reaches the source MSP, it immediately stops sending the MN's data packet to the GW. Instead, it attaches MN-MN header and dispatch to the data packets and forwards the packets to the MSP from which it received the _path_setup_ message. The packet format is shown in Figure 12.  
For instance, in Figure 11, the MSP1 forwards MN1's data packet to MSP4. MSP4 confirms, by checking the MN-MN dispatch, that it is a data packet towards a MN. Thereafter, it verifies whether it has any record in its routing table about the possible current location of the destination MN, (MN2 in Figure 11). Since it has already created a record from the _path_setup_ message, it forwards the packet to the next MSP on the route (i.e., MSP5 in Figure 11). This process continues until the packet reaches the destination MSP (i.e., MSP6 in Figure 11). The destination MSP then forwards the data packets to the destination SN (i.e., SN26 in Figure 11) using the packet format of Figure 9. However, in this case the dispatch and the header will be MSP-SN.