A cluster-based proxy mobile IPv6 for IP-WSNs

Abstract

The Sensor Proxy Mobile IPv6 (SPMIPv6) has been designed for IP-based wireless sensor networks mobility to potentially save energy consumption by relieving the sensor nodes from participating in the handoff process. However, SPMIPv6 is dependent on a single and central Local Mobility Anchor (LMA), and thus, it inherited most of the problems observed in the Proxy Mobile IPv6 (PMIPv6) protocol, including long handoff latency, non-optimized communication path, and bottleneck issues. In addition, SPMIPv6 extends the single point of failure to include both the authentication and network information. This study presents an enhanced architecture for SPMIPv6 called Clustered SPMIPv6 (CSPMIPv6) to overcome the problems above. In the proposed architecture, the Mobility Access Gateways (MAGs) are grouped into clusters, each with a distinguished cluster Head MAG (HMAG). The HMAG is mainly designed to reduce the load on LMA by performing intra-cluster handoff signaling and providing an optimized path for data communications. The proposed architecture is evaluated analytically, and the numerical results show that the proposed CSPMIPv6 outperforms both SPMIPv6 and PMIPv6 protocols in terms of LMA load, local handoff delay, and transmission cost performance metrics.

1. Introduction

Wireless sensor networks (WSNs) consist of a large number of small devices that sense and collect information from their immediate environment. The collected data are transmitted hop-by-hop through the network and then to the sink node, which is where these data are analyzed. These types of networks pose many challenges because of their limited energy, low computational capabilities, low memory, unattended operation, and dynamic environmental changes [1].

With the advent of the Internet of Things (IoT) and ubiquitous computing, the need has emerged to design protocols which connect the WSN to Internet. Ubiquitous computing, where computers interact with and make decisions on behalf of the user, needs sensing data to make the respective decisions. Since the Internet is the most widespread network, connecting WSNs to the Internet to disseminate sensed data is essential for making ubiquitous computing into reality [2]. Integrating the Internet Protocol (IP) with WSNs can facilitate WSNs to interconnect with other IP networks and capitalize the existing Internet infrastructure and IP-applications for cohesive connectivity with sensor networks [3]. Two main approaches, namely, the proxy-based and the sensor node stack-based approaches, are used for connecting WSNs to IP networks [2]. In the proxy-based approach, the sink node serves as the gateway between the sensor nodes and the Internet. In the sensor node stack-based approach, the IP protocol is implemented in each sensor as a routing protocol to allow data exchange inside the sensor network and enable Internet connectivity with other networks [2].

Lightweight protocol becomes a critical requirement when the benefits from an IP-enabled architecture and the limitations of WSNs are considered because it allows the possibility of connecting WSNs to IP networks. The Internet Engineering Task Force (IETF) 6LoWPAN working group plays a significant role in making the use of IPv6 over the standard IEEE802.15.4 possible. 6LoWPAN [4] is a lightweight protocol that allows connectivity among devices with limited power by importing IPv6 capabilities into low-power devices. 6LoWPAN adopts the physical (PHY) and Media Access Control (MAC) layer protocols defined in IEEE 802.15.4 to make them as its PHY and MAC layer protocols. The IPv6 protocol is used as the network layer protocol in 6LoWPAN. Since the IPv6 network layer maximum transmission unit is not compatible with the MAC layer of IEEE 802.15.4, a network adaptation layer has been added between the network and MAC layers to perform fragmentation, reassembling, perform IPv6 header compression, and handle mesh addressing.

Mobility management protocols are essential in the growing research area of IoT because the static attributes of nodes are no longer dominant in the current environment. Mobility management protocols should provide users with full access to information regardless of their locations. Nodes may move locally within one domain or extend their movements outside their domains. Movement can also be viewed from the constituting number of nodes (i.e., a single node or as a group of nodes) [5]. Mobility management protocols may be implemented in the host itself (i.e., host-based mobility) or in the proxy router (i.e., network-based mobility). Network-based mobility is more suitable in low-power sensor nodes because it relieves the sensor nodes from participating in any mobility operation, thereby prolonging network lifetime [6].

The IETF has standardized the host-based Mobile IPv6 (MIPv6) [7] and Network Mobility (NEMO) [8] protocols to address the management needs of the global mobility of mobile nodes (MNs) and mobile networks, respectively. Both protocols enable the continuity of the communication session for hosts while they are moving. However, these host-based protocols suffer from high signaling overhead, long handoff latency, and high packet loss ratio [9].

The IETF has standardized the Proxy Mobile IPv6 (PMIPv6) [10] to solve problems associated with host-based protocols. PMIPv6 adds two functional entities, namely, Local Mobility Anchor (LMA) and Mobility Access Gateway (MAG). LMA maintains the reachability of the MN address while it moves within the local PMIPv6 domain. The MAG detects MN movements and initiates the required authentication signals with the Authentication, Authorization, and Accounting (AAA) server to register the MN with LMA. The MAG requires the LMA address, the network prefix of the MN, and the allowed address configuration modes to accomplish the registration. All these information are stored in the AAA server in either a centralized or distributed manner [11].

The main feature of PMIPv6 is its network-based mobility management protocol, in which the network detects the node mobility and initiates the required mobility signals. Thus, PMIPv6 relieves the MN from participating in the handoff process. The features of PMIPv6 described above have motivated the adoption of PMIPv6 in WSN mobility management. Islam and Huh [6] proposed the Sensor Proxy Mobile IPv6 (SPMIPv6) protocol, which is an adaptation of the PMIPv6 protocol. SPMIPv6 has substantially reduced signaling and mobility costs, as well as the level of energy consumption. However, SPMIPv6 inherited the drawbacks of the standard PMIPv6 because of its dependence on a central LMA. The single and central entity architecture of the SPMIPv6 leads to a single point of failure, making it vulnerable to the bottleneck problem and long handoff latency. In addition, the mobility-related signaling and communication messages pass through a non-optimized routing path, increasing the handoff latency, end-to-end delay time, and the packet loss ratio. Moreover, the authentication and registration signals, which are frequently exchanged between LMA, AAA, and MAGs, significantly affect the handoff latency and packet loss during handoff [12].

Several studies in literature have attempted to enhance PMIPv6, including the Fast Proxy MIPv6 (PFMIPv6) [13] protocol, which has been standardized by the IETF to reduce the handoff latency. However, the PFMIPv6 protocol introduces false handoff initiation because the serving network predicts the new network where the MN moves to [14]. Nguyen and Bonnet [15] developed a cluster-based PMIPv6 for wireless mesh networks, wherein LMA serves as the cluster head and MAGs represent the access routers (ARs). However, they proposed a multi-LMA environment, where LMAs are involved in all the binding and communication processes. Hwang et al. [16] proposed a localized management support for PMIPv6 to solve the bottleneck problem by providing a localized handoff and route optimization using a reactive fast handover and hierarchical architecture. Their proposed architecture performed handoffs without the participation of the LMA with a short handoff latency time. However, the MAGs managed the communications and handoffs of their attached MAGs and MNs, resulting in additional functions that may lead to a long end-to-end delay time. Moreover, their proposed method requires multiple updates as the nesting level becomes larger, especially during the initial MN registration.

This study presents an enhanced architecture of SPMIPv6, named Cluster-based SPMIPv6 (CSPMIPV6), to solve the bottleneck, long handoff latency, and route optimization problems.

The main contributions of this study are as follows:

• (a) Providing a detailed preview and analysis of the multitudes of the methods currently used for connecting WSN to the Internet. Then, analyzes the manner in which the mobility protocols have evolved to position themselves for WSN.

• (a) Identification of the demerits of SPMIPv6, which serves as the underlying motivation of the proposed architecture.

• (c) Proposal and development of the architecture called CSPMIPv6 to enhance the SPMIPv6 protocol.

• (d) Presentation of the mathematical analysis and respective numerical results to evaluate the efficiency of the proposed CSPMIPv6 architecture.

The rest of this article is organized as follows: Section 2 presents the mobility management protocols used in IP-WSN. Section 3 shows the proposed CSPMIPv6, including its signaling, messaging, and binding tables. Section 4 presents the performance evaluations of the proposed CSPMIPv6. Section 5 presents the numerical results. Section 6 concludes the study, including some ideas for future investigations.

2. IP-WSN mobility-related study

Mobility plays an important role in realizing IoT in its ability to achieve "anywhere, anytime" communications. Mobility management involves two main functions, namely, location management and handoff management [17]. Location management refers to the procedure needed for tracking the location of the MN, whereas handoff management refers to the procedure needed to allow the MN to remain connected as it moves from one access point to another [5, 17].

WSNs were originally designed for static sensors. However, this assumption is no longer valid for current WSN applications [18]. Mobility is essential for WSNs because users need to retrieve information from sensors while they are on the move, such as in cases of health care and mobile vehicles. MNs can be exploited to compensate for dead nodes and improve network coverage. Additionally, mobility helps solve node localization problems [19].

Host-based mobility protocols, such as MIPv6 and its derivatives, involve MNs in all mobility signaling. An MN is designed to exchange numerous mobility messages, including binding updates and binding acknowledgments when it changes its network link, thereby quickly depleting its energy. Thus, the use of host-based mobility in low-power WSN devices is very inefficient [20–22]. Moreover, a WSN consists of a huge number of sensor nodes that may perform handoffs nearly simultaneously, leading to a large handoff signaling overhead that further increase energy consumption [19]. Thus, researchers have been motivated to continuously design new mobility management protocols suitable for sensor group mobility.

2.1. Sensor group mobility

Group mobility comprises a set of sensor nodes that move together as a single unit and can be found in many applications, such as patient health status monitoring, military application, and vehicle movement, among others. These applications are exactly similar to the NEMO protocol, where the mobility of the entire network is viewed as a single unit.

The NEMO protocol reduces the handoff signaling overhead and shortens handover latency because only a Mobile Router (MR) is needed to perform the handoff procedure. Thus, the network mobility is transparent to all mobile network nodes within the network.

Only few studies in literature aimed to prove the applicability of NEMO in WSNs and compared its efficiency to the host-based MIPv6 protocol. For example, Kim et al. [23] presented the Sensor NEMO (SNEMO) protocol, which is the first interoperable architecture between 6LoWPAN and NEMO protocols. They enhanced the LOAD routing protocol to support mobility in 6LoWPAN by improving the default gateway discovery, mobile network discovery, and path optimization. SNEMO is beneficial to mobile 6LoWPAN, but it does not allow the mobility of individual nodes. Kim et al. [22] devised a lightweight NEMO that supports 6LoWPAN by designing a mobility header compression format to minimize signaling cost. However, they did not assign a unique address for each sensor node and they did not consider node mobility. Chai et al. [24] investigated the application of the NEMO protocol in WSNs using several types of protocols that support IP packet transmission, including 6LoWPAN, IPv6 over ZIGBEE, and the packet translation scheme. They concluded that NEMO can easily be applied to WSN using 6LoWPAN and IPv6 over ZIGBEE, but the characteristics of WSNs exhibit difficulties upon implementation. On the other hand, packet translation can support NEMO without adopting IP protocol in the network layer by introducing the mobile gateway node. Chai et al. [25] discussed the application of the NEMO protocol for supporting group mobility in WSN, proposed a network architecture that supports the integration of NEMO and 6LoWPAN, and presented the related the signaling process, including the registration at the home network, association negotiation, handoff between different ARs, and packet routing. They compared the node remaining energy and the handoff time of MIPv6 and NEMO protocols with each other. Their results show that the handoff signaling of NEMO was 1/N times smaller than that of MIPv6, where N is the number of MNs, consequently making the remaining energy of MIPv6 much less than that of NEMO. However, the selected node as a sensor router consumed more energy because its signaling and data transmission are larger compared with those of other sensors. Thus, they suggested the use of non-power aware devices as sensor routers.

The NEMO protocol inherits the drawbacks observed in MIPv6, such as the long signaling delay and movement detection time, because the exchange of the signaling between the MN/MR and the distant home agent requires a long time. In addition, the delay caused by the movement of MR affects all the attached MNs and the NEMO does not support mobility in the MN movement. Moreover, both MIPv6 and NEMO use the mobile entity (MR or MN) during the mobility process.

2.2. Sensor proxy mobile IPv6

Proxy mobility protocols, such as PMIPv6, are preferred for solving problems associated with host-based MIPv6 and NEMO protocols. PMIPv6 meets energy efficiency demands, particularly in reducing signaling and mobility costs, because it relieves the MN from participating in any mobility signaling.

Islam et al. [6, 26, 27] proposed the SPMIPv6 for a localized mobility management in IP-WSN, which is the first work on IP-WSN localized mobility with a special consideration of energy efficiency. The SPMIPv6 architecture inherited from the PMIPv6 architecture consists of the sensor localized mobility anchor (SLMA), a sensor mobile access gateway (SMAG), and several fully functional IP sensor nodes. Maintaining reachability to the mobile sensor node address while it moves within the SPMIPv6 domain by maintaining a Binding Cache Entry (BCE) for each registered MN is the main function of SLMA. In addition, AAA is integrated with SLMA to reduce the number of messages needed for sensor node registration. The SMAG mainly detects mobile sensor node movements and initiates the required mobility signals with LMA on behalf of the mobile sensor node. The respected authors proposed and developed the architecture and message formats of SPMIPv6 and evaluated its performance by analyzing the signaling and mobility costs. Their simulated results show that SPMIPv6 reduces both signaling and mobility costs compared with MIPv6 and PMIPv6.

2.3. WSN mobility protocols taxonomy

This section proposes the taxonomy of the comparison of the mobility management protocols in WSNs. The taxonomy of MIPv6 as a host mobility, SNEMO as a group mobility, and SPMIPv6 as a network-based mobility management protocol is shown in Table 1.

Table 1 A comparison among mobility management protocols

As can be seen in Table 1 SPMIPv6 is more suitable for low-power WSNs because of the following reasons: First, it reduces the power consumption of the sensor because of the short-range single-hop communication between the sensor node and SMAG; the sensor node is free from acquiring new Care of Address (CoA) and performing Duplicate Address Detection (DAD); the low signaling overhead as the mobility functions are handled by SMAG; the reduction of packet loss ratio which decreases the need for the re-transmission of lost packets; and the sensor nodes need not implement complex mobility protocols. Second, it offers a short signaling delay because the delay of sending signaling to LMA is lower than that observed in sending signaling to a remote home agent. Third, it offers a low tunneling overhead since the tunnel required in traffic handling is terminated at the SMAG rather than at the MN. Finally, the localized mobility is independent from the global mobility management, and thus, the sensor node can have its own global mobility management since it is not aware of the local one.

2.4. Demerits of the SPMIPv6

Despite all the benefits gained by introducing the SPMIPv6 to WSNs, SPMIPv6 inherited most of the demerits of PMIPv6 as follows:

• (a) Bottleneck: The LMA in PMIPv6 maintains a BCE for each MN to keep its binding information, and this BCE should be updated at each MN movement. In addition, all the mobility-related signaling messages and data packets should pass through and be processed by the LMA. This extensive access will significantly increase the load of LMA, eventually leading to a bottleneck in LMA [16].

• (b) Handoff Latency: The MN experiences a long handoff delay in PMIPv6 because the handoff signaling messages pass through the LMA, which may be located far from the MAGs. In addition, the handoff includes accessing the AAA server for authentication, thereby increasing the signaling cost required for performing the MN handoff [16].

• (c) Route Optimization: In PMIPv6, all communications between MN and CN go through LMA even if both nodes are located in the same PMIPv6 domain, leading to a non-optimized path between MN and CN [16].

• (d) Load Balancing: The MAGs in PMIPv6 are responsible for performing mobility-related signaling with LMA on behalf of the MNs. However, MAGs can be overloaded when a large number of MNs are attached to it because of the absence of a load-balancing strategy [28].

• (e) Binding Requests Scheduling: The LMA in PMIPv6 receives numerous requests from MAGs to register or update BCE information. However, the way by which these requests are served is not specified in the PMIPv6 standard. Thus, designing an efficient algorithm that serves the registration and binding requests depending on some priorities, such as the traffic type or the number of buffered packets, is necessary.

3. Proposed CSPMIPv6 protocol

CSPMIPv6 is proposed to overcome the common disadvantages of PMIPv6 and SPMIPv6 by dividing the proxy domain into a number of local sub-domains. Each sub-domain is represented as a cluster that constitutes a group of MAGs with one Head MAG (HMAG), which is one of the PMIP MAGs that functions as a cluster head. HMAGs are selected during network installation and configuration. The method used for creating the optimum clusters is beyond the scope of this study. This section discusses the architecture, signaling, binding tables, and messages of the proposed CSPMIPv6. For simplicity, the terms MAG, LMA, and MN will be used hereinafter to unify the terms among PMIPv6, SPMIPv6, and the proposed CSPMIPv6.

3.1. Proposed CSPMIPv6 architecture

The proposed CSPMIPv6 architecture consists of an LMA, HMAGs, MAGs, and a number of MNs, as shown in Figure 1. The main roles of the LMA and MAGs in CSPMIPv6 are similar to those in SPMIPv6, i.e., to maintain node reachability while users are on the move and to detect and initiate the mobility signaling, respectively. The HMAG provides a local mobility management for each cluster, reduces the signaling cost by integrating the functions of the AAA, provides a route optimization strategy for intra- and inter-cluster communications, and reduces handoff latency for the MNs intra-cluster movements. In addition, the HMAG may be used to provide sufficient buffering schemes for MNs during the handoff process, and it may also be used to deploy strategies that can balance the MAG's load and schemes for scheduling the MAG's binding requests.

Figure 1

CSPMIPv6 architecture.

3.2. The CSPMIPv6 messages

In CSPMIPv6, a number of messages should be exchanged among the CSPMIPv6 entities to perform the registration, handoff, and communication processes. These messages include Proxy Binding Update (PBU), Proxy Binding Acknowledgement (PBA), Local PBU (LPBU), Local PBA (LPBA), Proxy Binding Query (PBQ), and Proxy Query Acknowledgement (PQA). In addition, all the LMA, HMAGs, and MAGs should maintain their respective binding list to store the required information of the MN's current location.

The PBU and PBA are used for registering MNs with the LMA in the same manner as the PMIPv6; their detailed description can be found in the Request for Comment 5231 [3]. Figure 2 shows the new proposed messages and mobility options. The proposed messages are differentiated using two new flags, namely, "N" and "Q". The LPBU and LPBA [29], which are specified by the "N" flag, are used between MAGs and their HMAGs for the registration of local MNs. The definition and descriptions of the other flags are described in [10]. The PBQ and PQA messages [15, 30], which are indicated by the "Q" flag, are used during the communication between MNs that belong to different clusters. The HMAG sends PBQ to the entire HMAGs multicast group or to the LMA to find which HMAG is currently serving the destination node. The destination HMAG then replies using a PQA message that contains the HMAG option.

Figure 2

New messages format and option.

3.3. CSPMIPv6 signaling

This section presents the new CSPMIPv6 signaling, including the MN registration and the intra- and inter-cluster handoff operations.

3.3.1. MN registration signaling

Figure 3 shows the MN attachment, authentication, and registration operations in the CSPMIPv6, including their required message flow. Each step is described as follows:

Figure 3

CSPMIPv6 registration signaling.

• Steps 1 and 2: Once the MAG detects an MN attachment, it sends an LPBU request to the corresponding HMAG that contains the MN identifier (MN-ID).

• Step 3: The HMAG performs MN authentication. Upon successful authentication, the HMAG sends a PBU to the LMA that contains the MN's identifier and the requesting HMAG.

• Step 4: The LMA now has all the information needed to register the MN. The LMA adds a new BCE for the MN and sends a PBA message back to the requesting HMAG. The PBA message contains the MN's home network prefix (HNP), which will be used by the MN to maintain its IPv6 address. The LMA then sets up a bi-directional tunnel with the corresponding HMAG for the routing of traffic to and from the MN.

• Step 5: The HMAG registers the MN in its BUL table and sends an LPBA back to the corresponding MAG that contains the MN prefix. The HMAG then configures the required routing information needed to reach MN.

• Step 6: Once the requesting MAG receives the LPBA, it registers the MN in its BUL table and sends a router advertisement message to the requesting node.

Notably, the MN information is registered into the LMA, HMAG, and the MAG tables during the registration process, as shown in Figure 1. In addition, the MN information is exchanged between the HMAG and MAGs to configure the required routing information for the MN, and thus, establishing a tunnel between the HMAG and MAGs is unnecessary [31]. Moreover, the AAA is integrated within the HMAG to reduce the signaling cost during the registration and handoff operations. The idea of integrating the AAA with the HMAG is inspired by the work of Islam and Huh [6], who integrated the AAA with LMA to reduce signaling overhead. However, they extended the single point of failure to include both the authentication and binding information.

3.3.2. Intra- and inter-cluster handoff signaling

Figure 4 shows the signaling messages needed for the intra- and inter-cluster handoff processes. In the intra-cluster handoff, the HMAG of the cluster performs the handoff process, and updating the LMA binding table is unnecessary when the MN moves from one MAG to another inside the same cluster. MAG2 sends an LPBU message to HMAG1 when it detects the MN attachment. Upon receiving the LPBU, HMAG1 searches its binding table for an entry for MN. Since the MN moves from one MAG to another within the same cluster, HMAG1 updates the binding entry for MN by modifying the MAG field to the new MAG (MAG2) and configures the new routing information for MN.

Figure 4

CSPMIPv6 handoff signaling.

On the other hand, the LMA must be involved in the inter-cluster handoff because the MN changes its cluster and connects to a new HMAG. In this study, MAG1 and MAG2 were assumed to be attached to HMAG1 and HMAG2, respectively. Once MAG2 detects the MN attachment, it sends an LPBU to its HMAG2. Once HMAG2 receives the LPBU, it searches for a matched entry for MN in its binding table. Since the MN comes from another cluster, HMAG2 will not find any entry for this specific MN. HMAG2 then sends a PBU to the LMA to update the BCE of the MN. The LMA updates the HMAG field for the MN and replies via a PBA to the requesting HMAG2. Once HMAG2 receives the PBA, it creates an entry for the MN and replies by sending an LPBA back to the requesting MAG2. The MAG2 consequently creates the required entry for the MN in its binding table and advertises the HNP to the MN.

3.4. CSPMIPv6 applications

The IP-WSN can be deployed for a wide range of applications, including industrial monitoring, structural monitoring, health care, connected home, vehicle telematics, and agricultural monitoring [6]. In this section, the health care application proposed by Islam and Huh [6] is considered and enhanced using CSPMIPv6 as a mobility management protocol.

3.4.1. Healthcare application

Consider a specialized hospital with state-of-the-art technology, where a patient can get healthcare and monitoring both at the hospital and at home. Specialist doctors can monitor patient cases while they are in the patient room, in different rooms within the same ward, in different floors, and even outside the hospital. The healthcare application scenario proposed in [6] is modified according to the proposed architecture.

As shown in Figure 5, the proposed hospital contains four floors, each with two wards. The hospital is considered as a one CSPMIPv6 domain, in which sensor nodes are deployed on the patient body as well as over the environment, MAGs are used to control wards, and each floor is controlled by one HMAG. Patients can get real-time care while moving between rooms, wards, and floors, or when the patient moves to another branch of the hospital.

Figure 5

CSPMIPv6 healthcare application.

3.4.2. CSPMIPv6 communication and movement scenarios

This section presents three communications scenarios, including the Intra-HMAG, Inter-HMAG, and Inter-domain communications.

A. Intra-HMAG communication scenario

In this scenario, both the communicating MNs reside in the same cluster, such as in the case when both the specialist doctor and the patient are located in different wards of the same hospital floor. As shown in Figure 6, HMAG controls the communication process from MN1 to MN3 as follows:

Figure 6

Communication scenarios.

• 1. MN1 sends the data packet to its MAG1.

• 2. Once MAG1 receives the packet, it checks the network prefix of the destination MN (MN3) to check if the destination node belongs to the same MAG1. If there is an entry in the BUL of the MAG1, the packet is forwarded directly to MN3.

• 3. Since MN3 address belongs to another network, MAG1 sends the packet to its cluster head HMAG1.

• 4. Once HMAG1 receives the packet, it checks its BUL to search for the destination address. Since MN3 belongs to MAG2, HMAG1 sends the packet to MAG2 to be forwarded to the MN.

B. Inter-HMAG communication scenario

This scenario deals with the communication between two MNs that belong to different clusters, such as in the case when both the specialist doctor and the patient are located in different floors. As shown in Figure 6, the communication between MN4 and MN5 is performed as follows:

• 1. Once MAG2 receives a packet from MN3, it forwards the packet to the HMAG1.

• 2. Upon receiving the packet by HMAG1, it searches its BUL for an MN5 entry. Since MN5 belongs to another HMAG, HMAG1 sends a PBQ message to the entire HMAGs multicast group.

• 3. Once the HMAG2 receives the PBQ, it replies immediately via a PBA to HMAG1. HMAG1 then creates the required tunnel for data transmission.

C. Inter-domain communication scenario

In this scenario, the CN resides outside the CSPMIPv6 domain, such as in the case when both the specialist doctor and the patient are in different branches of the hospital. As shown in Figure 6, LMA controls the communication between the MN8 and CN as follows:

• 1. When the data packet reaches the HMAG2, HMAG2 sends a PBQ to the entire HMAGs multicast group. However, HMAG2 will not receive any PQA because the destination node (CN) belongs to another domain.

• 2. The HMAG2 forwards the packet to the LMA through the bidirectional tunnel.

• 3. The LMA forwards the data packet to its destination.

On the other hand, if the LMA receives a data packet destined to the MN from a CN outside the CSPMIPv6 domain, it searches for an entry in its binding cache table for this particular MN. If LMA locates the required entry, it encapsulates and forwards the packet to the corresponding HMAG. Once the HMAG receives the encapsulated packet, it decapsulates the packet and searches for an entry in its BUL. Then, the HMAG uses the routing information to forward the packet to the respective MAG, which forwards the packet to the MN.

The communication scenarios above show that LMA is involved only during the inter-domain communication process when the CN resides outside the CSPMIPv6 domain.

4. Performance evaluation

In this section, the superiority of the proposed CSPMIPv6 is shown by analyzing its efficiency in solving PMIPv6 problems including the LMA bottleneck, handoff latency, and route optimization. The load-balancing and request scheduling problems are set as future work. The performance notations used by Jung et al. [30], with the addition of some new notations for the analysis of the proposed CSPMIPv6, are shown in Table 2.

Table 2 Parameters for the performance analyzing

4.1. Network model

Figure 7 shows the network model used for the performance analysis. For simplicity, we consider the intra-domain communication and handoff operations. In addition, we assume that all the clusters are created in a static manner during the networks installation. Moreover, all costs are symmetric, i.e., T_MN-TMAG = T_MAG-MN.

Figure 7

Network model.

4.2. Cost analysis

In this section, the total cost (TC) is derived depending on the model presented in [30] with some modifications to make it suitable for comparison with the proposed CSPMIPv6. These modifications consider both the authentication cost and the distance between HMAGs and their attached MAGs. The TC is calculated as the sum of the Binding Update Cost (BUC) and the Packet Delivery Cost (PDC).

4.2.1. PMIPv6 cost analysis

In PMIPv6, the binding update process includes setting up the connection between the MN and the MAG which requires roughly T_Setup, performing the MN authentication which takes 2T_MAG-AAA + 2T_LMA-AAA[32], and exchanging the PBU and PBA with the LMA which takes 2T_MAG-LMA + P_LMA. Accordingly, the BUC can be expressed as

$$\begin{array}{cc}\hfill \mathsf{\text{BU}}{\mathsf{\text{C}}}_{\mathsf{\text{PMIP}}}& =T_{\mathsf{\text{Setup}}}+S_{\mathsf{\text{Ctrl}}}\times \left(\mathsf{\text{2}}{T}_{\mathsf{\text{MAG}}-\mathsf{\text{LMA}}}+\mathsf{\text{2}}{T}_{\mathsf{\text{MAG}}-\mathsf{\text{AAA}}}+\mathsf{\text{2}}{T}_{\mathsf{\text{LMA}}-\mathsf{\text{AAA}}}\right)+P_{\mathsf{\text{LMA}}}\hfill \\ =T_{\mathsf{\text{Setup}}}+S_{\mathsf{\text{Ctrl}}}\times \left(\mathsf{\text{2}}t{C}_{\mathsf{\text{MAG}}-\mathsf{\text{LMA}}}+\mathsf{\text{2}}t{C}_{\mathsf{\text{MAG}}-\mathsf{\text{AAA}}}+\mathsf{\text{2}}t{C}_{\mathsf{\text{LMA}}-\mathsf{\text{AAA}}}\right)+alog\left(N_{\mathsf{\text{G}}}\times N_{\mathsf{\text{HM}}}\right)\hfill \end{array}$$

(1)

The packet delivery process in PMIPv6 begins by sending the packet from MN to its LMA through MAG which requires T_MN-MAG + T_MAG-LMA. The LMA then searches its binding cache for the CN's address (P_LMA), and then it sends the packet to the destination MAG (T_MAG-LMA), which in turn forwards it to the CN (T_MAG-CN). The PDC can be derived as follows:

$$\begin{array}{cc}\hfill \mathsf{\text{PD}}{\mathsf{\text{C}}}_{\mathsf{\text{PMIP}}}& \mathsf{\text{ = }}{S}_{\mathsf{\text{Data}}}\left(T_{\mathsf{\text{MN}}-\mathsf{\text{MAG}}}+\mathsf{\text{2}}{T}_{\mathsf{\text{MAG}}-\mathsf{\text{LMA}}}\mathsf{\text{ + }}{T}_{\mathsf{\text{MAG}}-\mathsf{\text{CN}}}\right)\mathsf{\text{ + }}{P}_{\mathsf{\text{LMA}}}\hfill \\ ={\mathsf{\text{S}}}_{\mathsf{\text{Data}}}\left(k{C}_{\mathsf{\text{MN}}-\mathsf{\text{MAG}}}+\mathsf{\text{2}}t{C}_{\mathsf{\text{MAG}}-\mathsf{\text{LMA}}}\mathsf{\text{ + }}k{C}_{\mathsf{\text{MAG}}-\mathsf{\text{CN}}}\right)\mathsf{\text{ + }}blog\left(N_{\mathsf{\text{G}}}\times N_{\mathsf{\text{HM}}}\right)\hfill \end{array}$$

(2)

Accordingly, the TC of PMIPv6 can be calculated as follows:

$$\mathsf{\text{T}}{\mathsf{\text{C}}}_{\mathsf{\text{PMIP}}}\mathsf{\text{ = BU}}{\mathsf{\text{C}}}_{\mathsf{\text{PMIP}}}+\mathsf{\text{PD}}{\mathsf{\text{C}}}_{\mathsf{\text{PMIP}}}$$

(3)

4.2.2. SPMIPv6 cost analysis

In SPMIPv6, authentication functions have been integrated within the LMA to reduce the number of communications by combining the PBU and AAA query, as well as the PBA and AAA reply messages [6]. However, this integration doubles the LMA processing cost to perform both authentications and processing operations (2P_LMA). The binding update process includes setting up the connection between the MN and the MAG, which requires T_Setup, and exchanging the combined authentication and binding message, which takes S_Ctrl × 2T_MAG-LMA.

$$\begin{array}{cc}\hfill \mathsf{\text{BU}}{\mathsf{\text{C}}}_{\mathsf{\text{SPMIP}}}& =T_{\mathsf{\text{Setup}}}+S_{\mathsf{\text{Ctrl}}}\times \mathsf{\text{2}}{T}_{\mathsf{\text{MAG}}-\mathsf{\text{LMA}}}+\mathsf{\text{2}}{P}_{\mathsf{\text{LMA}}}\hfill \\ =T_{\mathsf{\text{Setup}}}+S_{\mathsf{\text{Ctrl}}}\times \mathsf{\text{2}}{T}_{\mathsf{\text{MAG}}-\mathsf{\text{LMA}}}+\mathsf{\text{2}}alog\left(N_{\mathsf{\text{G}}}\times N_{\mathsf{\text{HM}}}\right)\hfill \end{array}$$

(4)

The packet delivery process in SPMIPv6 is the same as that of PMIPv6, and thus

$$\mathsf{\text{PD}}{\mathsf{\text{C}}}_{\mathsf{\text{SPMIP}}}\mathsf{\text{ = PD}}{\mathsf{\text{C}}}_{\mathsf{\text{PMIP}}}$$

(5)

Accordingly, the TC of SPMIPv6 can be calculated as follows:

$$\mathsf{\text{T}}{\mathsf{\text{C}}}_{\mathsf{\text{SPMIP}}}\mathsf{\text{ = BU}}{\mathsf{\text{C}}}_{\mathsf{\text{SPMIP}}}+\mathsf{\text{PD}}{\mathsf{\text{C}}}_{\mathsf{\text{SPMIP}}}$$

(6)

4.2.3. CSPMIPv6 cost analysis

In the proposed CSPMIPv6, two scenarios are used for communications and movements, namely, the intra/inter-cluster handoffs and communications, respectively. In the calculations, both cases are analyzed separately and then the TC is computed by setting the probability parameter (p = 0.5). In addition, the BUC is reduced by integrating the AAA services within the HMAG.

a. Intra-cluster handoff: In this case, the MN moves from one MAG to another in the same HMAG. Similar to the case in SPMIPv6, the HMAG processing cost is also doubled because HMAG performs both the authentication and registration functions (2P_HMAG). The mobility-related signaling messages are exchanged between MAGs and HMAGs to performs MN location update operation (2T_MAG-HMAG), and accessing the LMA is unnecessary, and thus

$$\begin{array}{cc}\hfill {\mathsf{\text{BUC}}}_{\mathsf{\text{CSPMIP}}}^{\mathsf{\text{Intra}}}& =T_{\mathsf{\text{Setup}}}+S_{\mathsf{\text{Ctrl}}}\times \mathsf{\text{2}}{T}_{\mathsf{\text{MAG}}-\mathsf{\text{HMAG}}}+\mathsf{\text{2}}{P}_{\mathsf{\text{HMAG}}}\hfill \\ =T_{\mathsf{\text{Setup}}}+S_{\mathsf{\text{Ctrl}}}\times \mathsf{\text{2}}t{C}_{\mathsf{\text{MAG}}-\mathsf{\text{HMAG}}}+\mathsf{\text{2}}alog\left(N_{\mathsf{\text{MH}}}\times N_{\mathsf{\text{HM}}}\right)\hfill \end{array}$$

(7)

b. Inter-cluster handoff: In this case, the MN moves from one MAG to another that resides in a different cluster, and thus, requiring the involvement of the LMA in the handoff operation because it needs to update its binding cache table. The MAG sends a binding update to its HMAG, and then the HMAG sends the binding update to the LMA (2T_MAG-HMAG + 2T_HMAG-LMA). The BUC for the inter-cluster handoff can be expressed as follows:

$$\begin{array}{cc}\hfill {\mathsf{\text{BUC}}}_{\mathsf{\text{CSPMIP}}}^{\mathsf{\text{Intra}}}& =T_{\mathsf{\text{Setup}}}\mathsf{\text{ + }}{S}_{\mathsf{\text{Ctrl}}}\times \left(\mathsf{\text{2}}{T}_{\mathsf{\text{MAG}}-\mathsf{\text{HMAG}}}+\mathsf{\text{2}}{T}_{\mathsf{\text{HMAG}}-\mathsf{\text{LMA}}}\right)+\mathsf{\text{2}}{P}_{\mathsf{\text{HMAG}}}+P_{\mathsf{\text{LMA}}}\hfill \\ =T_{\mathsf{\text{Setup}}}\mathsf{\text{ + }}{S}_{\mathsf{\text{Ctrl}}}\times \left(\mathsf{\text{2}}t{C}_{\mathsf{\text{MAG}}-\mathsf{\text{HMAG}}}+\mathsf{\text{2}}t{C}_{\mathsf{\text{HMAG}}-\mathsf{\text{LMA}}}\right)\hfill \\ +\mathsf{\text{2}}alog\left(N_{\mathsf{\text{MH}}}\times N_{\mathsf{\text{HM}}}\right)+alog\left(N_{\mathsf{\text{G}}}\times N_{\mathsf{\text{HM}}}\right)\hfill \end{array}$$

(8)

c. Intra-cluster communications: In this case, both the communicating MNs reside in the same cluster. The PDC is performed as follows: first, a packet is sent from the MN to its MAG (T_MN-MAG), which in turn sends the packet to the HMAG (T_MAG-HMAG). The HMAG checks the CN address in its BUL (P_HMAG). If a matched entry is found, HMAG sends the packet to the corresponding MAG (T_HMAG-MAG) to be forwarded to the CN (T_MAG-CN). Therefore, the intra-cluster PDC can be expressed as follows:

$$\begin{array}{cc}\hfill {\mathsf{\text{PDC}}}_{\mathsf{\text{CSPMIP}}}^{\mathsf{\text{Intra}}}& =S_{\mathsf{\text{Data}}}\left(T_{\mathsf{\text{MN}}-\mathsf{\text{MAG}}}+\mathsf{\text{2}}{T}_{\mathsf{\text{MAG}}-\mathsf{\text{HMAG}}}+T_{\mathsf{\text{MAG}}-\mathsf{\text{CN}}}\right)\mathsf{\text{ + }}{P}_{\mathsf{\text{HMAG}}}\hfill \\ =S_{\mathsf{\text{Data}}}\left(k{C}_{\mathsf{\text{MN}}-\mathsf{\text{MAG}}}+\mathsf{\text{2}}t{C}_{\mathsf{\text{MAG}}-\mathsf{\text{HMAG}}}+k{C}_{\mathsf{\text{MAG}}-\mathsf{\text{CN}}}\right)\mathsf{\text{ + }}blog\left(N_{\mathsf{\text{MH}}}\times N_{\mathsf{\text{HM}}}\right)\hfill \end{array}$$

(9)

d. Inter-cluster communication: This scenario deals with the communication between two MNs that belong to different clusters. For example, the communication between MN and CN is performed as follows: once MAG receives a packet from the MN, it forwards the packet to the HMAG, which requires T_MN-MAG + T_MAG-HMAG. Once HMAG receives the packet, it searches its BUL for a CN entry. Since the CN belongs to another HMAG, the HMAG sends a PBQ message to the entire HMAGs multicast group, which requires S_Ctrl × T_HMAG-HMAG × N_HG. Then, only one HMAG replies via a cost given by P_HMAG + S_Ctrl × T_HMAG-HMAG. Finally, the data can be sent to the corresponding HMAG to be forwarded to the MAG of the CN given by S_Data (T_HMAG-HMAG + T_HMAG-MAG + T_MAG-CN) . Accordingly, the PDC for the CSPMIPv6 can be expressed as follows:

$$\begin{array}{cc}{\mathsf{\text{PDC}}}_{\mathsf{\text{CSPMIP}}}^{\mathsf{\text{Intra}}}\hfill & \mathsf{\text{ = }}{S}_{\mathsf{\text{Data}}}\left(T_{\mathsf{\text{MN}}-\mathsf{\text{MAG}}}+\mathsf{\text{2}}{T}_{\mathsf{\text{MAG}}-\mathsf{\text{HMAG}}}+T_{\mathsf{\text{HMAG}}-\mathsf{\text{HMAG}}}+T_{\mathsf{\text{MAG}}-\mathsf{\text{CN}}}\right)\mathsf{\text{ + }}{S}_{\mathsf{\text{Ctrl}}}\times T_{\mathsf{\text{HMAG}}-\mathsf{\text{HMAG}}}\hfill \\ \times \left(N_{\mathsf{\text{HG}}}+1\right)+P_{\mathsf{\text{HMAG}}}\times N_{\mathsf{\text{HG}}}\hfill \\ =S_{\mathsf{\text{Data}}}\left(k{C}_{\mathsf{\text{MN}}-\mathsf{\text{MAG}}}+\mathsf{\text{2}}t{C}_{\mathsf{\text{MAG}}-\mathsf{\text{HMAG}}}+t{C}_{\mathsf{\text{HMAG}}-\mathsf{\text{HMAG}}}+k{C}_{\mathsf{\text{MAG}}-\mathsf{\text{CN}}}\right)\mathsf{\text{ + }}{S}_{\mathsf{\text{Ctrl}}}\times t{C}_{\mathsf{\text{HMAG}}-\mathsf{\text{HMAG}}}\hfill \\ \times \left(N_{\mathsf{\text{HG}}}+1\right)+blog\left(N_{\mathsf{\text{MH}}}\times N_{\mathsf{\text{HM}}}\right)\times N_{\mathsf{\text{HG}}}\hfill \end{array}$$

(10)

The TC for the CPMIPv6 in both intra- and inter-scenarios can be calculated with the help of the inter-cluster probability parameter p as follows:

$$\mathsf{\text{T}}{\mathsf{\text{C}}}_{\mathsf{\text{CSPMIP}}}=\left(1-p\right){\mathsf{\text{TC}}}_{\mathsf{\text{CSPMIP}}}^{\mathsf{\text{Intra}}}+p{\mathsf{\text{TC}}}_{\mathsf{\text{CSPMIP}}}^{\mathsf{\text{Intra}}}$$

(11)

4.2.4. LMA load

In PMIPv6, the involvement of LMA in all handoff and communication processes may lead to significantly increase the load on LMA. Consequently, the high load of LMA results in longer queuing delays and increases the packet loss ratio.

Basically, the LMA load p can be expressed as p = λ/μ, where λ is the average packet arrival rate and μ is the average service time. Taking the processing capacity of LMA into consideration, the threshold θ is the maximum acceptable load on LMA. If p > θ, LMA gets overloaded, and hence, the packets will experience a long queuing delay which results in increasing both the end-to-end delay and the packet loss ratio [28].

In our proposed scheme, the LMA load is alleviated by reducing both the average packet arrival rate and the LMA processing cost. The LMA load can be expressed in terms of the number of accesses and the processing cost. Equation (1) indicates that the LMA is accessed four times and takes P_LMA to process the binding update request. Equation (2) indicates that the LMA is accessed twice and takes P_LMA to perform the communication operation. Accordingly, the LMA load in the PMIPv6 domain can be expressed as follows:

$${\mathsf{\text{LMA}}}_{\mathsf{\text{Load}}}^{\mathsf{\text{PMIP}}}\mathsf{\text{ = }}N\left(6+2P_{\mathsf{\text{LMA}}}\right)$$

(12)

where N is the number of MNs that are either communicating or moving in the PMIPv6 domain. Following the same idea, LMA load for the SPMIPv6 and CSPMIPv6 domains can be expressed using Equations (4)-(5) and (7)-(10), respectively, i.e.,

$${\mathsf{\text{LMA}}}_{\mathsf{\text{Load}}}^{\mathsf{\text{SPMIP}}}\mathsf{\text{ = }}N\left(4+3P_{\mathsf{\text{LMA}}}\right)$$

(13)

$${\mathsf{\text{LMA}}}_{\mathsf{\text{Load}}}^{\mathsf{\text{CSPMIP}}}\mathsf{\text{ = }}N\left(2+P_{\mathsf{\text{LMA}}}\right)$$

(14)

5. Numerical results

This section presents the numerical results based on the derivations in the previous section. The assumptions and the parameter values in [30] have been used in this study to ensure a level comparative platform, as shown in Table 3. Notably, the HMAG is one of the PMIPv6 MAGs, and thus, the distance between the HMAG and MAG is equal to the distance between any two MAGs in any cluster.

Table 3 Parameter values

Figure 8 shows the effect of inter-cluster operations on the TC by changing the parameter (p) and setting all other parameters to their default values. The TC is fixed in the cases of PMIPv6 and SPMIPv6 because the same operations and signals are performed for both inter- and intra-operations, which involve accessing the LMA. However, the SPMIPv6 cost is less than the PMIPv6 cost because of the integration of authentication functions in the LMA.

Figure 8

Effect of the inter-cluster operation on the TC.

In CSPMIPv6, the TC is less than that of other protocols and varied with the number of inter-cluster operations. The cost increased with the increase in the probability of the inter-cluster mobility. However, the TC of the CSPIMPv6 is still less than that of PMIPv6 and SPMIPv6 even when the probability (p) is 1 (i.e., all the nodes perform inter-cluster operations). The low CSPMIPv6 cost can be attributed to the optimal communication path and the low handoff latency.

Figure 9 shows the LMA load by changing the number of MNs. The number of MNs is divided into two equal groups, these groups are supposed to perform communications and handoff, respectively. Both the PMIPv6 and SPMIPv6 generated higher LMA load than the proposed CSPMIPv6. The high LMA load can be attributed to the involvement of LMA in performing the registration and data communication processes. However, the SPMIPv6 generated the highest load because its LMA performed authentication functions that added an extra load. The low LMA load in CSPMIPv6 can be attributed to the use of LMA for inter-cluster handoff operations only.

Figure 9

Effect of the number of nodes on the LMA load.

Figure 10 shows the effect of the wired link delay on the TC. The TC is calculated by changing the wired link delay between the communicating entities. The TC for all protocols increase with increasing wired link delay. However, CSPMIPv6 performs better than PMIPv6 and SPMIPv6 because its communication path is shorter and its LMA is relieved from participating in the intra-cluster handoff. The TC of the SPMIPv6 is less than that of the PMIPv6 because of the signaling reduction scheme, in which the authentication functions are performed within the LMA.

Figure 10

Effect of wired link unit transmission cost on the TC.

Figure 11 shows the effect of the wireless link delay on the TC. The TC for all protocols increases linearly with the increment in the wireless link. The CSPMIPv6 provides the best performance among all the schemes. Notably, all protocols maintain fixed performance differences with one another because the majority of the network-based protocol signals are performed on the wired links.

Figure 11

Effect of wireless link unit transmission cost on the TC.

Figure 12 shows the impact of the distance between the MAGs and LMA on the TC. As can be seen in Figure 12, the C_LMA-MAG significantly affects both the PMIPv6 and SPMIPv6because the LMA is involved in all binding updates and data delivery operations. In addition, the C_LMA-MAG slightly affects CSPMIPv6 because the LMA is involved during the inter-cluster handoff only.

Figure 12

Effect of the MAG-LMA hops on the TC.

6. Conclusions

The SPMIPv6 meets the demands of energy efficiency in terms of reducing signaling and mobility costs because it avoids the involvement of MN in mobility signaling. However, the SPMIPv6 inherits most of the PMIPv6 problems because of its dependence on a single and central LMA. Therefore, this study proposes the CSPMIPv6 to enhance the SPMIPv6 architecture, where the proxy domain is divided into sub-domains that form as clusters. Each cluster comprises a number of MAGs, with one HMAG as a cluster head. Dividing the proxy domain into clusters reduces the load on the LMA, allows the HMAG to perform the intra-cluster handoff locally, and optimizes the communication path, eventually reducing the packet loss ratio. In addition, the use of HMAG provides sufficient buffers for storing the data packets during the handoff and an efficient place for deploying the load balancing and the binding request scheduling algorithms. The HMAG is one of the PMIPv6 MAGs elected to play the role of a cluster head. Thus, introducing the HMAG does not violate the PMIPv6 principles of localized mobility management and exhibits significant impact on total performance. The analysis and numerical results prove that the proposed CSPMIPv6 outperforms both PMIPv6 and SPMIPv6 in terms of the LMA load, local handoff latency, and transmission cost. Future investigations could focus on the implementation of the CSPMIPv6 protocol to validate its scalability using a high and random mobility environment. The next step is to deploy efficient algorithms for both MAG load balancing and binding scheduling. Also, the performance of the CPSMIPv6 needs to be compared with other schemes which have been designed to reduce the handoff latency and to optimize the communication path, such as Fast PMIPv6 and the route optimized PMIPv6. In addition, calculating the packet loss ratio needs further investigations. However, the packet loss ratio is expected to be reduced because the handoff latency time becomes shorter, the path is optimized for the intra-domain communications, and the HMAGs may provide sufficient buffers to store the packets destined to the moving nodes. Moreover, the HMAGs load under random movements and random number of MNs also needs much research to evaluate the benefits from introducing the HMAG.

7. Methods

In this article, the analytical model which has been used by Jung et al. [30], is adopted with the respected extensions to compare the performance of the proposed CSPMIPv6 protocol with the basic PMIPv6 and the SPMIPv6 protocols. The TC, which is expressed as the sum of PDC and BUC, is derived using Equations (1-9) and is used for the performance comparisons. We have studied the impact of the wireless link delay, wired link delay, and the distance between MAG and LMA on the TC. In addition, we have deliberated on how the TC is affected by the intra- and inter-cluster mobility. The LMA load is also estimated using Equations (12-14) and used to compare the performance of the protocols in solving the LMA bottleneck problem. According to the numerical results, the proposed CSPMIPv6 performs better than the basic PMIPv6 and the SPMIPv6 in terms of LMA load, handoff latency, and the transmission cost.