LoWMob: Intra-PAN Mobility Support Schemes for 6LoWPAN

Mobility in 6LoWPAN (IPv6 over Low Power Personal Area Networks) is being utilized in realizing many applications where sensor nodes, while moving, sense and transmit the gathered data to a monitoring server. By employing IEEE802.15.4 as a baseline for the link layer technology, 6LoWPAN implies low data rate and low power consumption with periodic sleep and wakeups for sensor nodes, without requiring them to incorporate complex hardware. Also enabling sensor nodes with IPv6 ensures that the sensor data can be accessed anytime and anywhere from the world. Several existing mobility-related schemes like HMIPv6, MIPv6, HAWAII, and Cellular IP require active participation of mobile nodes in the mobility signaling, thus leading to the mobility-related changes in the protocol stack of mobile nodes. In this paper, we present LoWMob, which is a network-based mobility scheme for mobile 6LoWPAN nodes in which the mobility of 6LoWPAN nodes is handled at the network-side. LoWMob ensures multi-hop communication between gateways and mobile nodes with the help of the static nodes within a 6LoWPAN. In order to reduce the signaling overhead of static nodes for supporting mobile nodes, LoWMob proposes a mobility support packet format at the adaptation layer of 6LoWPAN. Also we present a distributed version of LoWMob, named as DLoWMob (or Distributed LoWMob), which employs Mobility Support Points (MSPs) to distribute the traffic concentration at the gateways and to optimize the multi-hop routing path between source and destination nodes in a 6LoWPAN. Moreover, we have also discussed the security considerations for our proposed mobility schemes. The performance of our proposed schemes is evaluated in terms of mobility signaling costs, end-to-end delay, and packet success ratio.


Introduction
The IEEE 802.15.4 standard [1] has emerged as a strong technology for Wireless Sensor Networks Incorporating mobility in 6LoWPAN [3] can lead to the realization of new and exciting applications.
For example, mobility of 6LoWPAN devices can be exploited in health care applications. In this case, the patients have sensor nodes embedded in their clothes for sensing some of their important health parameters like pulse rate and temperature, etc. These sensor nodes can sense the data and transmit it to a monitoring facility, even when the patient is moving, by using one of the existing communication technologies like WLAN and UWB. However, these technologies are more applicable when the application requires high data rate and often demand complex link and physical layer solutions with complicated hardware. 6LoWPAN has been considered as the most suitable technology for supporting mobility in sensor networks due to their low power and low data rate characteristics. Also, 6LoWPAN enables the integration of IEEE802.15.4 networks with the Internet, thereby increasing the monitoring scope of the patient.
In order to prevent packet losses due to mobility, some of the existing tunnel-based mobility protocols like HMIPv6 [4], FMIPv6 [5], and MIPv6 [5] can be used. These schemes can help a Mobile Node (MN) to maintain its ongoing communication with the outer world and to minimize the packet losses while it is moving. However, the above mentioned schemes are host-based mobility protocols in which the MN actively participates in mobility-related signaling. Moreover, these are network layer data rate, low power, more sleeping time and less complex protocols and hardware for the sensor nodes. Its interaction with IPv6 implies that the sensor nodes should easily be interoperable with all other IP networks, including the Internet. This means that the sensor data can be accessible anywhere from the world.
In [11] the authors have proposed the design of micro mobility support for a sensor node, roaming across several Access Points (AP) of a Bluetooth sensor network. A mechanism to assign IP addresses to an AP and to a sensor node so that a MN would be identified without using the channel number were also proposed. The authors also designed a middleware to carry IP packets over Bluetooth.
However, they assume that the sensor node is capable to perform single hop communication even if the MN is not that close to the AP. Moreover, the MNs are expected to incorporate a middleware layer changes in their stack in order to support their mobility.
Another form of mobility is network mobility or NEMO whereby the whole network moves together and their mobility is handled by MR [8]. When the network moves into a new network, the MR acquires a Care of Address (CoA) on its egress interface and sends a LU to its Home Agent (HA).
The CoA informs the HA that all of the packets destined to any address derived from MR's prefix should be forwarded to the MR's CoA. However, in this scenario, the MR is comparatively more powerful as compared to a single sensor node. Thus special protocols have to be developed in order to handle the mobility of a single mobile sensor node.
The authors in [12] have proposed an interoperable architecture between NEMO and 6LoWPAN in order to support network mobility. They have suggested an extended routing scheme for MRs to support mobility in 6LoWPAN sensor nodes. However, the architecture does not cater for individual node's mobility.
The existing localized mobility-related protocols can be broadly classified into two groups. These are host-based and network-based protocols. Host-based solutions require MN involvement at the IP layer and software changes at the host's stack. The host-based mobility protocols like MIPv6, FMIPv6, and HMIPv6 were proposed by IETF [2]. In the network-based mobility protocols, the local IP mobility is handled without involvement of the MN and also the MN does not have to implement a new mechanism in its stack.
In MIPv6, when a MN moves from one network to the other, it forms a CoA based on the prefix of the foreign link. Thereafter, the node (host) itself sends the Binding Update (BU) to it's HA. When the MN receives a link layer indication of its movement it can solicit a router advertisement. Once the MN knows that IP layer mobility has taken place, it forms a new CoA by using the prefix advertised on the new link and again sends a BU to its HA.
HMIPv6 adds another level on MIPv6 and separates global mobility from local mobility. HMIPv6 was designed so that the MNs can move within a particular domain without having to update their HA or Correspondent Nodes (CNs) when every time they move. It introduces a new entity called Mobile Anchor Point (MAP) which acts as a local HA of the MNs [4]. When  FMIPv6 is another enhancement of MIPv6 that aims to reduce the handoff delays for mobile connections. It is designed to allow MNs to anticipate their IP layer mobility. In other words, the MNs can discover the new router prefix before being disconnected from the current router.
However, as discussed before, the host based mobility protocols involve most of the signaling on the MN's end. This signaling overhead is not appropriate for 6LoWPAN nodes. These protocols are also network layer solutions that provide mobility-related features at the IP layer. Thus mobility-related signaling packets are carried by IP traffic. However, this solution proves to be expensive if they are directly implemented in 6LoWPAN that supports MNs. Moreover, these protocols demand a complex host stack which is not feasible for 6LoWPAN. Additionally, they assume the anchor points of the MN are always available and do not need to go to sleep state. Also, from the security point of view the changes in the temporary local address mean that the MN exposes its topological location to eavesdroppers.
The other host based mobility protocols are HAWAII [7] and Cellular IP [5]. In order to forward MN's packets, these protocols involve establishment of host specific routes in the routers. The creation of host-specific routes is initiated and updated by the MNs. Thus these protocols require an active participation from the MNs that can negatively impact MN's lifetime. Also, in HAWAII, when the routers within the domain receive a packet from another MN; then they forward the packets to a router, named as "the Domain Route Router". This limits the scope of route optimization even if when the corresponding MNs are near to each other.
In the network based localized mobility schemes like PMIPv6 [9], proposed by IETF, the network side performs the mobility-related signaling on behalf of the MN. PMIPv6 introduces several new entities like Localized Mobility Anchors (LMA) and MAG. The mobility entities in the network will track the MN's movements, initiate the mobility signaling and set up the required routing state [9].
However, more specifically, MAG is responsible for tracking the MN's movements to and from the access link and for signaling the MN's LMA [9]. PMIPv6 has several advantages over the host based mobility protocols, thus making it better candidate for 6LoWPAN mobility management. Firstly, PMIPv6 can be compatible with any global mobility management protocols that are not MIPv6, such as Host Identity Protocol (HIP), IKEv2 Mobility, and Multihoming (MOBIKE) [13]. While it is possible that existing localized mobility management protocols could be used with HIP and MOBIKE, some would require additional efforts to implement, deploy, or even in some cases specify in a non-Mobile IPv6 mobile environment [13]. Also demands an extra tunneling overhead between the MAG and LMA.
The authors in [14] proposed a network mobility management scheme for wireless mesh networks.
The wireless mesh network is composed of several Routing Access Points (RAPs) that not only serve as an access point for the MNs, but also route MN's data packets. However, the RAPs are much more powerful devices, in terms of processing power and energy consumption, as compared to the 6LoWPAN SNs.
In [15][16][17], we have introduced mobility management architecture for 6LoWPAN. The architecture considered the mobility of a single 6LoWPAN node within a PAN with multiple GWs and with the help of the existing static nodes. However, the proposed architecture required a SN to send a LU to GW every time a new MN associates with it. This reduced the lifetime of the SNs and eventually the whole PAN. Moreover, the proposed architecture did not consider route optimization between multiple MNs located in the same PAN. This paper aims to reduce the number of LUs sent from SNs to the GW by proposing a distributed version of the architecture presented in [15][16][17]. The proposed scheme further considers route optimization between multiple corresponding MNs, located in the same PAN. 1. Intra-PAN mobility: When a MN moves within a PAN, Intra-PAN mobility occurs. In Figure 1, this kind of mobility occurs when a patient moves within a room.

Possible Mobility Scenarios in 6LoWPAN
2. Inter-PAN mobility: This kind of mobility occurs when a MN moves from one PAN to another.
For example, in Figure 1, a patient moves from one room to the other, where each room hosts one PAN.
3. WPAN mobility: In this case, the whole PAN changes its point of attachment. This case is similar to NEMO.
In this paper, we limit our discussion to the Intra-PAN mobility category only. In order to support mobility in the resource constrained devices; the IETF specifies some mobility requirements in 6LoWPAN. These include [3]: 1. Providing fast handoff detection.
2. The MNs should be addressable by any CN, irrespective of its whereabouts.
3. The signaling is also required to be minimized by considering the resource constraint characteristic of the LoWPAN devices.
4. Reduced Function Devices (RFDs) should be kept out of the mobility-related signaling.

System Model and Assumptions
Our proposed mobility schemes are based on the following network assumptions: 14. Any of the MAC protocols, synchronous or asynchronous, can be used to ensure the reliability and routing of packets in duty cycle WSN.  When the join_request message reaches the GW, it creates a binding entry for the MN and, assigns MN with a unique 16 bits ID. Also the GW maps the IPv6 address of its CNs to a unique 16 bits address. This is done in order to save the number of bits used in the IP addressing, which might waste useful energy and bandwidth of the SNs when routing the data and mobility-related packets of the MNs. Then the GW sends a join_confirm message to the SN that forwards it to the MN. The

LoWMob Mobility Support Scheme
Join_confirm message contains MN's ID and the short address of its CNs.
If, in future, the MN wants to communicate with a CN for the first time then the MN will request the GW to provide a 16 bits address by sending CN's alias name. Thus the GW will run an Address Resolution Protocol (ARP) and provides a 16-bits address against the CN's IP address or its alias name.
Similarly, when a packet for the MN can arrive from CN that is located outside the PAN, for which the GW does not have a pre-existing binding. In this case, the GW will first create a binding and sends this binding to the MN before sending the data packet.

Handoff Support
The proposed handoff support for MN considers the sleep state of SNs. Thus, as shown in Figure 3, once the current SN observes that its link quality with the MN has degraded beyond a certain threshold value, it then concludes that the MN is moving. Hence the current SN needs to activate the next appropriate SN for the handoff process. In order to activate the next appropriate SN, the associated SN In order to determine the direction of movement, we propose to use AoA method [21]. AoA is defined as the angle between the propagation direction of an incident wave and some reference direction, which is known as orientation. Orientation, defined as a fixed direction against which the AoAs are measured, is represented in degrees in a clockwise direction from the North. When the orientation is 0 o or pointing to the North, the AoA is absolute otherwise it is relative. As shown in Figure 3, 'the star' shows MN position at time-stamps TS 1 , TS 2 , and TS 3 respectively.
The associated SN measures the AoA from the signal that it receives from the MN. Moreover, the associated SN also estimates the distance between the MN and itself by using received signal strength of the packets.
As shown in Figure 3, let α 1 , d 1 ; α 2 , d 2 ; α 3 , d 3 be the angles (in degrees) and the distances between the SN1 and the MN, at time-stamps TS 1 , TS 2 and TS 3 respectively. Based on the angle and distance information, the SN can obtain the MN's location coordinates. At the time-stamp TS 3 , the SN1 awakes the next SN2 for the handoff. Also SN1 sends a new_node message to SN2 that contains MN's ID. When the next SN receives the new_node message, it transmits a hello_packet at some intervals. the SN switches to the sleep mode after a short interval of time. The handoff support mechanism is depicted in Figure 4. If the next SN does not detect the MN within a certain amount of time, it will consider that the MN is lost. So the next SN will request, by sending a radio triggered broadcast, to all of its neighboring SNs to suspend their duty cycle and keep awake until the MN is found.

Proposed Message Formats
This section introduces some of the mobility-related signaling message formats needed to support a MN within the PAN. The message formats make use of 6LoWPAN's adaptation layer's reserved dispatch values, in order to differentiate between different kinds of mobility messages exchanged between SNs and GW [20]. Every adaptation layer packet begins with a dispatch value that identifies the type of header to be followed next. The dispatch value, an 8 bits value, indicates what kind of packet is it. For example, a dispatch value of 01 000001 indicates that the following header is an uncompressed IPv6 header. The pattern 01 000010 represents that the following header is fully compressed from 2 bytes to 40 bytes. When there are more than one LoWPAN headers, they should appear in the following order: Mesh header, Fragmentation header, and Header Compression header.
Also the dispatch headers appear before each header [20]. Moreover, 16 bits addressing scheme is used in order to route the data packets to and from a MN. The proposed message formats which utilize the adaptation layer reserved dispatch values and 16 bits addressing scheme are given below. 1. σ = observed link quality with MN and α 2.
α determines AoA of the signal 5.
determine the angle 'θ' between MN and itself 6.
determine distance 'd' between MN and itself 7.
send       In DLoWMob, the PAN is assumed to be partitioned into multiple regions, as shown in Figure 10.
Each region has one MSP and its associated SNs which are managed by the MSP. Hence there exists a hierarchy in the PAN. The GW manages MSPs only, while each MSP manages its associated SNs in its region.
The main functions of the MSP are two-fold; firstly, it limits the number of LUs to the GW by managing the binding information between MNs and SNs in its region locally. That is, it reports LUs to the GW only when a MN enters in its own region. While a MN moves in its region, from a SN to another SN in the region, no LU is required to be sent to the GW. Consequently, MSPs could reduce significant network bandwidth and the energy consumption. Secondly, it enables the data packets between MNs and its CNs in a PAN to be routed between their corresponding MSPs. That is, it removes the need of having every data packets passing through the GW, thus making route optimization possible. The next two subsections describe each function in detail.

The Handoff Process in DLoWMob
The   an LU to the GW because the movement is within intra-region, and the binding information is managed by the MSP itself.

Route Optimization for Intra-PAN Communication in DLoWMob
We propose a Route Optimization scheme for an Intra-PAN communication in order to reduce the traffic concentration at the GW. This could extend the lifetime of the nodes near the GW, thereby extending the network lifetime also. We also propose a handoff mechanism for Route Optimization scheme. The mechanism could support the handoff for the communication even when the source and destination are mobile. The next two subsections describe routing of data packets between source and destination MN and the handoff process in more details.

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

Security Considerations for Proposed Mobility Schemes
This section discusses the security model of the proposed mobility schemes in this paper. The following assumptions and notations are used in order to describe the security processes and cryptographic operations in this paper: 1. In order to establish an individual key shared between the GW and a node, and a pairwise key shared between a node and each of its intermediate one hop neighbors, we can use LEAP [22].  and encrypts it with the shared key between itself and it's HA, i.e., K MH . Then the MN sends this encrypted message to its associated SN. The SN forwards the message to its MSP by encrypting it with the key shared between itself and GW, i.e., K SG . The MSP then forwards the message to the GW.
When the GW receives the message, it decrypts it with the key K SG and gets to know that this message is sent by the legitimate SN and the message is destined for MN's HA. The GW then informs the MN's HA that the MN is currently located in its PAN. Following this, a security association is set up between the GW and HA, using IKE [26]. It should be noted that the legitimacy of the HA can be established during the creation of security association between GW and HA, using IKE. This is because IKE uses public key and certificates signed by a trusted authority [27]. Thereafter, the GW forwards the MN's challenge to the HA, using the newly created security association. The HA then decrypts the number (R1) using K MH and generates a random number (R2) and encrypts the concatenate of R1 and R2 with MN's and its shared key, i.e., K MH . The HA then sends the encrypted concatenation of R1 and R2 to GW. When this information reaches the GW, the GW forwards the in the message. The MN then reverses the concatenation of R1 and R2 and encrypts the concatenation with the K MH and forwards the message to its SN. The SN encrypts the message with K SG and sends to the MSP that then forwards to the GW, as described above. When the GW receives this message, it forwards the message to the MN's HA after decrypting with K SG . The HA then verifies the MN's authenticity by checking whether it received R2 or not. If the HA is satisfied with the authenticity of the MN, it sends a MN_authorized message to the GW, which indicates that MN is a legitimate node.
Moreover, the HA update the binding table entry of the MN with its current CoA. On the other end, GW assigns two keys to the MN. The first one is known as Mobile Key (K m ) and the second key is known as Communication Key (K c ). The GW then sends these keys to the HA. Also it sends K m to the SN by encrypting them with K SG . In order to securely deliver the Mobile Key and Communication Key to the MN, the HA encrypts the K m and K c with K MH and forwards the encrypted keys to the GW. The GW then forwards this message to SN by encrypting it with K SG . The SN in turn sends it to the MN.
The MN decrypts the message and obtains the K C and K m .

Mutual Authentication of MN and its Future SNs
When the MN moves within the PAN, it associates with different SNs in the PAN. In order to provide mutual authentication between the MN and its next SN, the current SN informs the next SN, during handoff, about K m . The current SN achieves this by encrypting the K m with the pairwise key shared between itself and the next SN. The mutual authentication process using K m is shown in Figure 15. In the hello packets, the next SN includes a random number R1. When MN receives this number, it generates another random number R2 and sends R2 to next SN along with the concatenation of R1 with R2 after encrypting the concatenation with K m . Once the next SN verifies that the sender knows the K m , it sends an LU to MSP by encrypting with the shared key K SP . Also it reverses the order of the concatenation of R1 and R2 and encrypts the concatenation with K m before sending it to MN.
Note that as the MN moves on then the Mobile Key, i.e., K m , would be exposed to many of the SNs within the PAN. Thus it is desirable that the GW revoke the key after some time. In order to do that, the GW generates K m after some amount of time. The time interval at which the key is revoked is implementation specific. The GW then sends this key to the MN by encrypting it with K c . At the same time, the GW sends the key to the current SN by encrypting it with the key shared between it and the SN.

Securing MN's Data Packets
When the MN first time sends a data packet to its CN, it encrypts the data packet with K c and forwards it to its SN. The SN then forwards it to its MSP, which in turn forwards MN's packet to the GW. The GW then decrypts the message by K c of the source MN and forwards the data packet to the destination MSP, using the Communication Key (K c ) of the destination MN. Also, at the same time, the GW creates a session key, i.e., K s , for the communication between source MN and destination MN.
Next the GW informs the source MSP about the destination MSP's address. Also it sends the session key to source and destination MNs by encrypting the session key with their respective K c . When the source MN sends a data packet to destination MN, the data packet can be encrypted using the session key as shown below [25]: MN source →MN destination : {data} <Ks> , MAC{ K s , C| {data} <Ks > } Hence using K s , both MNs can communicate securely.

Authentication of Messages that Modify a MN's Routing Entry in the MSPs
In the proposed scheme, signaling messages, such as MN_moved and path_setup messages, create or modify the routing state of a MN in an MSP and establish a path between source and destination MSPs. Thus it is necessary to ensure that these signaling messages are sent by an authentic source.
Thus whenever an MSP sends the signaling message (that modifies or creates the routing state) to the next hop MSP; in the path between source and destination MSPs it encrypts the message with the pairwise key of itself and its next hop MSPs. The message format is shown below: MSP i →MSP j : {MN_moved} <Kij,> , MAC{ K ij , C| {MN_moved} <Kij > } When the next MSP receives the packet, it establishes the authenticity of the message by verifying whether or not it has received the messaged from a trusted MSP by computing the MAC using the pairwise key. Also it creates or updates the routing state of the MNs. It then forwards it to its next hop itself and the next hop MSP. This process enables creation or alteration of routing state entries of MNs securely.

Performance Evaluation
We have evaluated the proposed LoWMob scheme by developing a complete simulation in Qualnet v4.5 and through numerical analysis. The terrain area is 2,500 × 2,500 m 2 . A total of 50 SNs are  Some spikes in the graph can also be observed for some early hops. There are several factors which cause these spikes. These include: i) the mobility model (the random way point) -because the MN abruptly changes its position according to the mobility model used [28], ii) the speed of MN -that causes handoff and some nodes might not have routing information, iii) The pause time between movements, and [29] iv) AODV -AODV broadcasts packets bring traffic in the network that not only cause collision but also introduce hidden node problem [28]. The issues could be fixed with different network topologies, different speed, and pause time of the MN; and with the use of static routing etc.

End to End Delay and Packet Success Ratio
The packet success ratio, when the MN is far away from the GW, i.e., 16 hops, is just about 0.4 for a MN moving with the speed of 20 m/s. As the number of hops between the GW and the MN decreases packet success ratio increases. As the MN reaches closer the GW the success ratio approaches to 1, and the end-to-end delay to 0.01 seconds. Moreover, it can be seen from Figure 17 that when the speed of the MN is 20 m/s the packet success ratio is better than when the speed is 25 m/s. This is because as speed increases the number of handoff increases, which can lead to a significant packet loss. Also, when the speed increases exponentially, there is a possibility that the MN will be lost in the PAN. This is because, as the new SN wakes up for the handoff process, the MN may have already crossed the new SN. As shown in Figure 17, when the MN is 5 hop away from the GW, the packet success ratio at the speed of 30 m/s is almost double than that of speed of 25 m/s. It should be noted that this type of anomaly in the graph is observed due to i) the speed of the MN, that triggers routing path discovery more frequently, ii) the link congestion, and iii) the duty cycle of SNs. Note that the link congestion is not caused by the SNs which are relaying packets, but the SNs around the MN which are participating in broadcast messages for AODV. Also note that we have used standard MAC Protocol of IEEE 802.15.4, i.e., CSMA/CA, as underlying MAC protocol. The results of the packet success ratio, and the end-to-end delay could be improved significantly for MAC Protocols, like X-MAC [30], C-MAC [31] or RI-MAC [32].   the GW or to another MSP. As shown in Figure 18 and Figure 19,

Handoff Overhead
The handoff overhead is the signaling overhead that is incurred when the MN breaks off its association with its previous SN and attaches with a next SN. This includes the signaling cost for the handoff, like sending new_node and LU messages. In order to derive the handoff overhead through analytical modeling, we consider Figure   For evaluation purposes, we assume the following: 1. A domain is composed of N equal squares that are equal in size and form a contiguous area.
2. The MNs are moving with an average speed of v, and the direction of their movement is between 0 to 2π.

MN moves out of the PAN within K finite movements
In [33] the authors proved that µ(k) is the average number of SNs with which a MN associates with, and it is rarely sensitive to change of K, unless K is much smaller than N. Thus we assume K equals N.
The signaling cost in the LoWMob scheme can be broken down to: 1. The cost incurred in sending LU messages to the GW, and the cost of sending new_node messages when a MN associates with a new SN. 2. The cost incurred in tunneling data packets from the GW to the SNs, for the destination MN.
The default parameter values for calculation of LU and tunneling cost are given in Table 2.
In Table 2, the LU message cost for one hop is 48 bits. Moreover, in order to deliver the data packet to the MN, extra 16 bits are appended that represent the SN's short address. Equation 1 includes both the LU cost to the GW and the cost to send new_node message. Also π0 is the equilibrium probability of the state 0 that represents the probability of MN staying outside a given PAN. In this case, we assume that the probability of MN staying outside the PAN is same as staying inside. For the LoWMob scheme µ(K 1 ) is calculated as 2.8, from the equations derived in [33]. Also it can be seen from [33] that µ(K 1 ) is not affected by the speed. For DLoWMob, µ(K 2 ) is calculated as 0.999969 and is less than µ(K 1 ) as MSPs area of coverage is larger than a single SN. Thus the MN stays within an MSP's region for a longer amount of time; this reduces the number of LUs to the GW.
Also the average number of hops between a MSP and GW is less as compared to the number of hops between SN and GW.

Tunneling Cost
Equation 8 gives the tunneling cost required to tunnel MN's packet from the GW: In the above equation, λ is the average packet arrival rate of a MN, when it is associated with the SN. L is the average number of hops the packet is tunneled from GW to SN. The time for which a MN remains connected to a SN can be referred to as T as [33]: where, A is the area of the square, shown in Figure 22.

Location Update Signaling Cost
The dotted line in Figure 22 shows a possible path followed by a MN when it enters and exits a PAN. Figure 23 shows the LU cost (in bits) incurred due to the MN's movements along the same path, at different speed. It shows that as the speed increases, LU cost does not change. This is due to the fact that even if the speed of the MN increases, it associates with the same number of SNs that lay in its path [34]; and thus these SNs send the same number of LU messages. Also, the signaling cost of DLoWMob to send an LU message is less than that of LoWMob. This is because for DLoWMob, an LU message travels less number of hops to reach the GW. Also the MSPs in DLoWMob limit the frequency of sending LUs to GW.
Moreover, it can be seen that the signaling overhead of the proposed schemes is significantly less as compared with HMIPv6. This is because the adaptation layer packets have been used for sending LU, instead of IP packets (as in the case of HMIPv6). In HMIPv6 the size of the LU message is 68 bytes [33].

Tunneling Cost versus Packet Arrival Rate
From Figure 24, it can be seen that the tunneling cost of both DLoWMob and LoWMob scheme increases linearly as the packet arrival rate increases. This is because the tunneling cost is directly proportional to the packet arrival rate. However, the increase in the tunneling cost for the LoWMob scheme is more, as compared to DLoWMob; because, comparably with DLoWMob, LoWMob involves more number of hops from GW to the MN. The comparison with the proposed scheme also shows that the tunneling cost is less as compared to HMIPv6. This is because in HMIPv6, tunneling cost for a packet is equal to the size of an IPv6 header [33].

Conclusions
This paper discussed a network-assisted mobility support scheme for 6LoWPAN nodes, which are extremely energy and resource constrained devices in nature. The paper proposed the LoWMob mobility support scheme, where a MN associates with the SN, which is responsible for mobility of the MN. The proposed scheme reduces the tunneling overhead between the GW and the SN, without involving MN in a significant amount of signaling. Signaling overhead has been reduced at a greater extent by introducing a special packet format that utilizes the dispatch values of the 6LoWPAN adaptation layer and 16 bits addressing of IEEE 802.15.4. Furthermore, this paper proposed a distributed version of LoWMob, named as DLoWMob. It employs the concept of MSPs and route optimization for intra-PAN communication. Mobility-related packets are handled by the MSPs that route them to and from the CN or the GW. We have shown that at different speed of the MN, DLoWMob shows better performance than LoWMob in terms of end-to-end delay, packet success ratio, and signaling costs.