1 Introduction

Inter-domain IP mobility research has regained prominence due to recent interest in softwarized 5G mobile networks. It is a general consensus that 5G mobile networks will be composed of multi-domains with heterogeneous wireless accesses [1,2,3]. One of the important design goals for the mobile networks is to achieve resource efficiency while providing improved mobility. Enabling OnDemand mobility management is critical to accomplish this goal in inter-domain use case. OnDemand mobility is achieved by supporting mobility related operations per service flow requirements and releasing the resources when they are no longer needed.

Proxy Mobile IPv6 (PMIPv6) is a network-based IP mobility solution which does not involve Mobile Node (MN) in control operations [4]. It is a renowned mobility solution in enterprise networks as well as in 4G mobile networks. Based on its successful deployment of intra-domain mobility operations, PMIPv6 is expected to be evolved for extended IP mobility use cases in future 4G and early stage multi-domain 5G networks. But current PMIPv6 architecture limits its extension as per future mobile networks requirements such as scalability and minimal end-to-end latency [5]. The following descriptions highlight main challenges in inter-domain PMIPv6 extension.

Facilitating efficient discovery and management of domain(s): Inter-domain mobility management requires the binding information exchange between current and previous PMIPv6 domains of MN. This includes domain discovery for every MN in a scalable manner. Current solutions mostly use centralized and unscalable database to keep track of MN movement between the domains and help them communicate [6,7,8,9]. Software Defined Networking (SDN) can provide the distributive communication between PMIPv6 domains. SDN separates the control and data plane in a network component, and the controller governs the forwarding rule/action. Development of inter-domain controller can effectively facilitate PMIPv6-based inter-domain mobility in a scalable manner.

Enabling OnDemand mobility management support with specification OnDemand mobility provides mobility support to a service flow as per its properties, by assigning an appropriate type of IP address [10]. OnDemand mobility management in inter-domain PMIPv6 can reduce the control signaling overhead as the communication between domains is only in case of service flow continuity. In addition, it improves the average end-to-end latency since not all the traffic need to be steered to its home network domain. The efficient assignment and release of mobility resources is key to OnDemand inter-domain mobility. Once the session(s) using an IP address from some previous domain terminates, the IP should be released from the MN and returned to the home domain that assigned it. To the best of our knowledge, no mechanism for IP retrieval has been specified so far.

Avoiding suboptimal routing of inter-domain traffic Many inter-domain PMIPv6 solutions suffer from intolerable transmission delay caused by suboptimal routing. It happens mainly due to traffic steering through anchor nodes (i.e., LMAs) in current and home domains. Enabling OnDemand mobility can partially address this problem, as traffic from the flows initiated in the current domain is routed directly towards its Corresponding Node (CN). Whereas, the remaining traffic from the flows initiated in the preceding domain(s) still need to route to their respective home domain(s) first. The route convergence related research and practices can be used to directly route this remaining IPv6 traffic towards their respective CNs as well.

This paper proposes an inter-domain mobility solution for PMIPv6 with service level granularity by exploiting SDN and OnDemand mobility management. The proposed solution reduces handover and end-to-end latency; improves resource utilization; and achieves scalable and backward compatible architecture. This paper improves the previous publications [11, 12] by reducing packet loss, providing details for various functions, and thorough analysis. In particular, our key contributions in this extended paper are as follows:

  • An architecture for inter-domain mobility management with necessary network components and their role assignment

  • Specification of a novel distributed controller-to-controller communication (C3) protocol for the east–west communication between different controllers

  • A prefix retrieval mechanism for IP address release and return in OnDemand mobility

  • A new route convergence mechanism to handle the suboptimal data path

We implement the proposed solution to validate and evaluate the performance. Moreover, the analytical analysis against other solutions demonstrates the proposed solution to have a better performance in terms of handover delay, transmission delay and control signaling overhead.

The rest of this paper is organized as follows. Section 2 provides background discussion on PMIPv6 and software defined PMIPv6, with a summary of related work on inter-domain mobility. The proposed OnDemand inter-domain mobility solution is described in Sect. 3 and an analytical model is presented in Sect. 4. Experimental evaluation and numerical results are given in Sect. 5. Finally, this paper is concluded with future work in Sect. 6.

2 Background and related work

2.1 Preliminary: PMIPv6 versus SDN-PMIPv6

PMIPv6Footnote 1 provides localized IP mobility through Mobile Access Gateway (MAG) and Local Mobility Anchor (LMA). MAG performs movement detection and initiates binding update on behalf of MNs, while LMA acts as the topological anchor point and manages Home Network Prefix (HNP) pool for MNs. The control planes of MAGs and LMA exchange Proxy Binding Update (PBU) and Proxy Binding Acknowledgment (PBA) signaling messages for registration, update, and de-registration of MNs. The data plane handles IP traffic of MNs between MAG and LMA over the established IP tunnel. Control and data planes in MAG are bundled in the same physical device as shown in Fig. 1(a), and it is same for LMA. This limits and complicates the evolution of PMIPv6 towards scalable inter-domain mobility. SDN in PMIPv6 is expected to address such limitations through control and data plane separation.

Fig. 1
figure 1

Traditional PMIPv6 versus OF-PMIPv6 architecture in terms of control and data plane

Full size image

One way to incorporate SDN in PMIPv6 is by placing the control plane functions of MAG and LMA as mobility applications over the controller, while the data plane functions are implemented into OpenFlow-enabled switches [13]. This approach provides flexibility to dynamically select one of the switches as an anchor through controller application [14, 15]. However, these solutions assumes a completely SDN enabled localized mobility domain and requires an anchor to be in the same domain. This limits the mobility management to a single SDN domain and makes its integration with legacy networks difficult. In real networks, anchor may resides outside the SDN domain and requires data plane operations to be performed with legacy mobility protocols (e.g., PBU/PBA). The proposed OpenFlow-enabled PMIPv6 (OF-PMIPv6) follows such architecture model [16].

The OF-PMIPv6 architecture virtualizes the control plane of all MAGs as a single control plane gateway (CP-G) application over the controller as shown in Fig. 1(b). Therefore, MAGs are reduced to only data plane gateway (DP-G) which mainly performs data forwarding and tunnel management, and uses OpenFlow protocol [17, 18] to communicate with CP-G. OF-PMIPv6 uses legacy PMIPv6 LMA as anchor and CP-G exchanges PBU and PBA messages with it on behalf of DP-Gs. The controller assigns a prefix to MN and maintains it in Controller Binding Cache (CBC) for MN sojourn in the domain. Data communication happens directly between DP-Gs and controller through IP tunnel. A domain in OF-PMIPv6 is defined by the controller and DP-Gs connected to it. By keeping the legacy anchor, OF-PMIPv6 offers more realistic and scalable solution with PMIPv6 backward compatibility in terms of mobility operations, and can be easily extended for inter-domain mobility solution. Hence, we use OF-PMIPv6 architecture for individual domains and extend it to enable the proposed OnDemand inter-domain mobility solution.

2.2 Related work

One of the main challenges in providing the inter-domain mobility support in PMIPv6 is to recognize the previous domain of MN. Recently, inter-domain PMIPv6 solution with OnDemand mobility (D-PMIP) has been presented [9]. D-PMIP has two modes of operation, one partially distributed (DP-PMIP) and other fully distributed (DF-PMIP). DP-PMIP recognizes the previous domain of MN through Inter-domain Central Mobility Database (ICMD). DP-PMIP discusses three signaling procedures (locator, relay and proxy) to discover and communicate with previous domain LMA. This paper only consideres proxy DP-PMIP from here onwards, as it outperforms others. Figure 2(a) shows the architecture and handover signalling for proxy DP-PMIP. The new LMA in proxy DP-PMIP sends a PBU to ICMD upon handover. After locating MN binding entry, ICMD forwards the received PBU to previous LMA and as a proxy sends PBA to new LMA. DP-PMIP faces the same impracticalities of any other centralized database based solution, which increase the delay due to newly added control signaling with ICMD.

Fig. 2
figure 2

Architecture and handover signaling of two operational modes of D-PMIP

Full size image

DF-PMIP takes a different approach where it uses MN prefix in the previous domain to determine the identity of the previous domain. DF-PMIP then utilizes a distributed AAA server to communicte with the previous MN domain and gets the LMA information, as shown in Fig. 2(b). A tunnel between current and previous LMAs is established through separate exchange of PBU/PBA messages. In order to get MN prefix in previous domain, DF-PMIP excahgnes Node Information (NI) query/response messages with MN [19]. NI is a part of an experimental RFC and might not be supported by all MNs, in which case mobility support will fail. Suboptimal routing occures in both DP-PMIP and DF-PMIP due to data traversal through anchors in current and previous domains via tunnel. Also, both solutions do not handle the prefix release and retrieval once it is no longer in use.

I-PMIPv6 is regarded as pioneering solution for inter-domain mobility in PMIPv6, and proposes centralized as well as distributed mechanisms to locate LMA in previous domain of MN [6]. Similar to DP-PMIP, the centralized approach uses a central database called Virtual Mobility Anchor (VMA) to store MN binding information. Unlink proxy DP-PMIP, VMA waits for PBA from previous LMA after forwarding it the PBU from new LMA (i.e., messages 7 and 8 in Fig. 2a). VMA forwards the PBA to new LMA after receiving it from previous LMA. Distributed approach in I-PMIP requires new LMA to inspect MN traffic to infer MN prefix in previous domain. Using inferred MN prefix, new LMA tries to contact previous LMA and exchange binding update messages. In this article we only focus on centralized I-PMIP as distributed approach might not always work.

A new network entity known as Traffic Distributor (TD) is proposed by another centralized inter-domain mobility solution to solve the suboptimal routing problem [7]. TDs are placed in the aggregate network between LMAs and the Internet. A tunnel is created between TD and LMA to forward data traffic of MN to the new domain. Yet another centralized approach proposes a new network entity called Global LMA (GLMA). GLMA provides seamless inter-domain handover through a connection with the LMAs in different PMIPv6 domains [8]. GLMA differs from I-PMIP in terms of its proactive inter-domain registration and authentication procedures. Few other solutions propose the use of IEEE 802.21 Media Independent Handover (MIH) to facilitate the inter-domain PMIPv6 mobility [20, 21]. These solutions use MIH control messages to inform the new domain about MN previous domain prefix and anchor address. Dependence on MIH availability on every component reduces the feasibility of these solutions.

Inter-domain mobility in cellular networks is relatively new. The recent data traffic surge has shifted the trend towards softwarization [22,23,24] and distributed cores for better manageability, scalability, and service. Double NAT and forwarding table modifications are discussed for inter-domain mobility in the future 4G networks [25, 26]. These SDN based solutions tackle the IP mobility in the transport network between EPC and data network, and require the operator to deploy OpenFlow enabled switches in the transport network which needs significant investment. Our proposed solution fits within and between the distributed EPCs and only requires DP-Gs to be OpenFlow enabled.

3 OnDemand inter-domain SDN-PMIPv6

3.1 System architecture

The system architecture of the proposed OnDemand Inter-domain SDN-PMIPv6 (OIS-PMIP) is shown in Fig. 3. MN registration in OIS-PMIP is highlighted in Fig. 3(a), and inter-omain handover is covered in Fig. 3(b). OIS-PMIP architecture consists of multiple independent OF-PMIPv6 domains. Here, each domain consists of an anchor and multiple DP-Gs controlled by a single domain controller. Controllers in these domains communicate with each other using the proposed Controller to Controller Communication (C3) protocol. New fields are added in CBC to manage MN mobility in multiple domains. The domain controller inherited from OF-PMIPv6 manages the intra-domain mobility [16].

Fig. 3
figure 3

Registration and Inter-domain handover in OIS-PMIP with the OnDemand concept

Full size image

The proposed OIS-PMIP exploits the OnDemand mobility at the domain level. The domain controller assigns a prefix to MN and maintains it for the sojourn of MN in the domain. Newly initiated IP sessions use the IPv6 address generated from the prefix assigned by the current domain. As shown in Fig. 3(a), controller A assigns Prefix A to MN and then maintains it as long as MN stays in domain A. Sessions initiated at MN during its stay in domain A use the IPv6 address with Prefix A. Upon inter-domain handover, the new serving domain assigns a new prefix to MN but also maintains and manages the prefix from previous domain. In Fig. 3(b), controller B assigns new Prefix B to MN and also manages Prefix A which is handed over from domain A, since session(s) continuing over from domain A still uses Prefix A. A newly initiated session in domain B uses an IPv6 address with Prefix B. IPv6 address with Prefix A remains active in domain B until the session(s) using that IPv6 address stays active.

A domain needs to distinguish between the prefix it assigns to MN and the prefix that is handed over from its previous domain, as they require different operations. For this purpose, we propose the terms home prefix and proxy prefix. Home prefix is defined as the prefix which is assigned and maintained by the current domain of MN (e.g., Prefix B in Fig. 3b). Whereas, proxy prefix is defined as the prefix which is only managed by the current domain, but was assigned by some previous domain of MN (e.g., Prefix A in Fig. 3b). For brevity, this paper calls a domain, its controller, and its anchor as home domain, home controller and home anchor, respectively, when they are handling the home prefix. Similarly they are called as proxy domain, proxy controller, and proxy anchor when they are handling the proxy prefix. Domain B, controller B, and anchor B in Fig. 3(b) are called as home domain, home controller and home anchor for Prefix B, while simultaneously they are called proxy domain, proxy controller and proxy anchor for Prefix A.

To implement simultaneous roles of home and proxy domains, we extend CBC by adding a new field ‘Proxy.’ This field stores a list of proxy tuples where a tuple is defined as: (prefix, home controller of the prefix). At the time of MN registration the Proxy field in Fig. 3(a) is empty as there is no proxy prefix. After the inter-domain handover in Fig. 3(b), CBC in controller B stores Prefix B in the home prefix field and tuple of Prefix A and controller A in Proxy field. In case Prefix A is still active when MN moves from domain B to another domain, the proxy tuples of Prefix A and Prefix B will be stored in the Proxy field of new domain’s CBC.

3.2 OIS-PMIP operation

Registration of MN initiates when it attaches to a domain in OIS-PMIP for the first time. The control signaling flow for MN registration is illustrated in Fig. 4 and comprises the following steps.

Fig. 4
figure 4

Control signaling flow for MN registration in OIS-PMIP

Full size image

  • Step 1 MN initiates the registration in OF-PMIPv6 domain A by sending a Router Solicitation (RS) message to DP-G after performing the layer-2 attachment.

  • Step 2 DP-G forwards RS message encapsulated in the OpenFlow Packet_In (O-RS) to controller A.

  • Step 3 Controller A extracts MN ID from O-RS message and after successful authentication of MN it performs a prefix discovery procedure to determine if MN is registering or is executing an inter-domain handover. To do this, controller A sends a Discovery Request (Disc-Req) with MN ID and anchor A address to all the controllers in other domains (peers) with whom session is already established.

  • Step 4 All the peers check their CBC for received MN ID and send a Discovery Response (Disc-Res) with home prefix and anchor address if they find a matching entry. Else, they send an empty Disc-Res. In registration all the received Disc-Res are empty, and controller A concludes that MN is registering.

  • Steps 5–7 Controller A proceeds by exchanging PBU and PBA messages with anchor A. Also, it sends a Tunnel Create (TC) message to the serving DP-G to establish a bidirectional IP tunnel between anchor A and DP-G. Experimenter message type in OpenFlow protocol is used to define the TC message.

  • Steps 8–10 Controller A provides a prefix (Prefix A) and makes a new entry in CBC for MN ID. It sends the Prefix A to DP-G in Router Advertisment (RA) message encapsulated in the OpenFlow Packet_Out message (O-RA). DP-G decapsulates O-RA message and forwards RA message to MN. Any session initiated at MN now uses Prefix A based address for communication.

Inter-domain handover occurs when MN moves from domain A to B. The control signaling flow for inter-domain handover is detailed in Fig. 5, where initial three steps are similar to MN registration. Starting from message four, inter-domain handover comprises of following steps.

  • Steps 4–6 Controller A sends a Disc-Res message containing information of Prefix A and anchor A to controller B. Also, controller A performs a binding update with anchor-A to establish a transitory tunnel from anchor A to anchor B.

  • Steps 7–9 Controller B exchanges binding update messages with anchor B after receiving all Disc-Res messages. This updates the routing table entries in anchor B for both Prefix A and newly assigned Prefix B, along with the creation of IP tunnel to the DP-G and transitory IP tunnel to anchor A. Later, controller-B sends a TC message to the serving DP-G with both Prefix A and B to create IP tunnel with anchor B.

  • Steps 10–11 Controller B updates its CBC for MN ID by adding Prefix B and A in home prefix and Proxy fields, respectively. It sends the Prefix A and B to DP-G in RA message encapsulated in OpenFlow Packet_Out (O-RA). DP-G forwards RA message to MN after decapsulation. Sessions continuing over from domain A keep using Prefix A, and newly initiated sessions at MN now use Prefix B.

  • Steps 12–14 OIS-PMIP differentiates between uplink and downlink traffic of proxy prefixes in order to reduce the transmission delay. The uplink traffic of proxy prefix (Prefix A) does not need to be routed to the home anchor (anchor A) and can be forwarded to the Internet by proxy anchor (anchor B). This is because the routing path in the traditional networks is determined based on the destination IP address (i.e., CN 1 IP address). Therefore, Prefix A uplink traffic routes to CN 1 from anchor B without any problem. The downlink traffic with Prefix A based destination address still routes to anchor A, because Prefix A is hosted and advertised by anchor A. Downlink traffic routes from anchor A to anchor B via transitory tunnel and then to MN through IP tunnel between DP-G and anchor B (Fig. 3b).

  • Step 15 All Prefix B traffic routes to and from the Internet through anchor B, and after route convergence (Sect. 3.4), all Prefix A traffic also routes to and from the Internet through anchor B.

Fig. 5
figure 5

Control signaling flow for MN inter-domain handover in OIS-PMIP

Full size image

Once the sessions using proxy prefix are completed, that prefix must be released and returned to its home domain. OIS-PMIP uses the flow table operations of OpenFlow protocol to detect the completion of IP sessions associated with the proxy prefix. OpenFlow protocol defines an idle timeout parameter for a flow entry which causes the flow entry to be removed if no packet is matched against it for a specified period. Once the idle timeout expires for the flow entry of proxy prefix, DP-G removes that flow entry. The control signaling after the removal of the flow entry is shown in Fig. 6 and has following steps.

  • Step 1 DP-G notifies proxy controller (controller B) about removal of the proxy prefix (Prefix A) flow entry by sending the flow removal message. OIS-PMIP uses OpenFlow Send-Flow-Remove flag for this purpose. When set, this flag forces the switch to notify the controller about removal of the flow entry.

  • Steps 2–3 Controller B exchanges the binding update messages with anchor B to deregister Prefix A.

  • Step 4–5 Controller B finds Prefix A in CBC and sends a Prefix Retrieval message to controller A. Later, controller B removes that prefix A from Proxy field in CBC. Now MN traffic only consists of IPv6 address with Prefix B.

Fig. 6
figure 6

Control signaling flow for prefix retrieval in OIS-PMIP

Full size image

3.3 Controller to controller communication (C3) protocol

OIS-PMIP requires the serving OF-PMIPv6 domain of MN to discover and communicate with the neighboring domains to determine the proxy prefix. This subsection discusses the proposed Controller to Controller Communication (C3) protocol which establishes session between peers to facilitate prefix discovery. Similar to BGP [27], we assume that public IP address of the peers is configured in every controller statically. At the initiation of OF-PMIPv6 domain, the controller uses preconfigured addresses of peers to establish a session. Figure 7 shows the finite state machine (FSM) for the session establishment with a peer, and controller needs to maintain it for every peer. At peers, same FSM is maintained for incoming session requests.

Fig. 7
figure 7

Controller to controller communication (C3) protocol session establishment FSM

Full size image

At initialization of domain, session with the peer is in disconnect state and it remains in this state if the peer is unavailable. It moves to connect when the peer becomes available or a connection request is received from the peer. Disconnect is the only state in which controller entertains the connection request from the peer. Controller tries to establish TCP connection with the peer in connect state and moves to dormant if connection attempt fails. After a predetermined backoff time, the session moves from dormant to connect and retries the connection. Successful connection triggers the success event and session moves to validate. Session reverts back to disconnect if peer closes the connection or any other event occur.

Validate state determines and approves the identity of the peer, and decide security parameters in order to keep the communication secure. For this purpose, a validate message is sent to the peer to which it responds either with a validate message of its own in case of successful agreement, or with a notification message if security parameters need to be updated. Notification message is also used by the peer to notify if validation has failed, which causes the connection to be closed and session shifts to disconnect. Session moves to confirm after receiving the validate message from the peer.

Session attributes like keep alive timer, duration, and mobility parameters are decided in confirm. Similar to validate state, negotiations on session parameters take place through confirmation and notification messages. Failure in negotiations force the session to disconnect, whereas, success leads it to established state. In established, exchange of discovery request and discovery response messages becomes possible. Properties of the session can be changed by the peer through notification message. The session reverts to disconnect if the controller terminates the session with the peer via notification message or vice versa.

Control signaling for session establishment does not cause major overhead, as neighboring domains are usually handful. C3 protocol does not affect the handover delay because IP sessions with the peers are established only once at the initiation of the domain. In case of different domains managed by a single operator, the number of peer domains can be restricted depending on their geographical locations.

3.4 Leveraging route convergence

The Internet uses BGP to route the data traffic across different autonomous systems (ASes). BGP speaker at the edge of an AS (i.e., gateway router) makes route advertisement or withdrawal announcement through BGP update message upon availability or unavailability of a route, respectively. Peer BGP speakers take significant time to reach a consistent view of routes after receiving the update message. This delayed convergence of routes is due to transient routing table fluctuations caused by BGP path selection process. To optimize the route convergence delay, comprehensive research has been conducted [28,29,30]. The theoretical upper and lower bounds for convergence delay in a complete graph topology are O(n!) and Ω(1), respectively, where n is the number of ASes [1].

An anchor is generally implemented in a gateway router to increase the domain footprint. This paper exploits the general location of an anchor and route convergence to reduce the transmission delay of Prefix A downlink traffic. OIS-PMIP designs anchor A to send the route withdrawal update message and anchor B to send the route advertisement update message for Prefix A, after establishing transitory tunnel. These update messages trigger recalculation of Prefix A routes in other ASes, and converge them to a new downlink path towards anchor B. Anchor A forwards Prefix A traffic to anchor B via transitory tunnel during the convergence period. Once convergence completes, all traffic of Prefix A route to the Internet through anchor B directly and transitory tunnel is removed or vacated. The suboptimal routing of downlink traffic through anchor A occurs only once during convergence period after every inter-domain handover. Provision to trigger the transmission of BGP update message from anchor can be implemented in PMIPv6 by new mobility option type for PBU message.

The proposed route convergence mechanism requires assignment of unique prefix for every MN, as specified in RFC 5213 [2]. When a single prefix is shared among multiple MNs, the proposed mechanism can work only if anchor B advertises complete Prefix A IPv6 address of MN. This ensures no routing anomalies occur, as anchor A cannot send a withdrawal message due to prefix sharing. We acknowledge that in a network, anchor and BGP can be on separate routers. In such cases, a controller application (e.g., SDN-IP [31]) can send update messages to peers in neighboring ASes on behalf of the anchor.

4 Analytical modelling

This section models handover delay, transmission delay, and control signaling cost for the proposed OIS-PMIP. It also provides detailed accounts for other solutions like DP-PMIP, DF-PMIP, and I-PMIP for comparative analysis. Table 1 provides the description and values of the used parameters [32,33,34]. The delay of a message from source to destination is the sum of link propagation delay, and service delay at intermediate/destination network elements. The service delay of a network element is modeled using the M/M/1 queue with the assumption of no packet drop during the processing. The arrival rate (\(\lambda_{i}\)) is defined at every network element \(\left( i \right)\), whereas the service rate (\(\mu\)) remains same. Service delay \(X_{i}\) is calculated using the mean wait time of the M/M/1 queue:

$$X_{i} = \frac{{{\raise0.7ex\hbox{$1$} \!\mathord{\left/ {\vphantom {1 \mu }}\right.\kern-0pt} \!\lower0.7ex\hbox{$\mu $}}}}{{1 - \rho_{i} }} ,$$
(1)

where \(\rho_{i}\) is \({\raise0.7ex\hbox{${\lambda_{i} }$} \!\mathord{\left/ {\vphantom {{\lambda_{i} } \mu }}\right.\kern-0pt} \!\lower0.7ex\hbox{$\mu $}}.\)

Table 1 Notations
Full size table

4.1 Handover delay

Handover delay is defined as the period starting from L2 connection establishment till the arrival of RA message. In OIS-PMIP and other schemes, MN performs both inter-domain and intra-domain handovers, and we model them individually to get the average handover delay. Intra-domain and inter-domain handover in OIS-PMIP are given by:

$$D_{intra}^{OIS - PMIP} = T_{WRS} + T_{R} + T_{OR} + T_{BU} + T_{TC} .$$
(2)
$$D_{inter}^{OIS - PMIP} = D_{intra}^{OIS - PMIP} + T_{DR} .$$
(3)

Inter-domain handover in (2) is independent of binding updated messages between controller A and anchor A in the step 5 and 6 of Fig. 5. Intra-domain handover delay for DP-PMIP, DF-PMIP, and I-PMIP is same as PMIPv6 intra-domain handover delay, which is given by:

$$D_{intra}^{PMIP} = T_{WRS} + T_{R} + T_{AAA} + T_{BU} .$$
(4)

Inter-domain handover delay for DP-PMIP, DF-PMIP, and I-PMIP is expressed by:

$$D_{inter}^{DP - PMIP} = D_{intra}^{PMIP} + T_{DR} .$$
(5)
$$D_{inter}^{DF - PMIP} = D_{intra}^{PMIP} + T_{AAA} + 2T_{DR} .$$
(6)
$$D_{inter}^{I - PMIP} = D_{intra}^{PMIP} + 2T_{DR} .$$
(7)

If \(P_{f} /\left( {1 - P_{f} } \right)\) gives the odds of transmission failure over wireless link, then delay for RS and RA messages is given by:

$$T_{RS} = \frac{{P_{f} \left( {X_{GW} + H_{W} L_{\beta } } \right)}}{{1 - P_{f} }} .$$
(8)
$$T_{RA} = \frac{{P_{f} \left( {H_{W} L_{\beta } } \right)}}{{1 - P_{f} }} ,$$
(9)

where \(T_{RA}\) only depends on wireless propagation delay, and does not count the service delay on MN. From (8) and (9):

$$T_{R} = \frac{{P_{f} \left( {X_{GW} + 2H_{W} L_{\beta } } \right)}}{{1 - P_{f} }} .$$
(10)

Based on service delays and routing distances, the delay for O-RS and O-RA messages is given by:

$$T_{O - RS} = H_{C} K + X_{PC} .$$
(11)
$$T_{O - RA} = H_{C} K + X_{GW} .$$
(12)

From (11) and (12):

$$T_{OR} = 2H_{C} K + X_{GW} + X_{PC} .$$
(13)

Using the derivation of \(T_{OR}\) in (11)–(13), \(T_{BU}\),\(T_{DR} ,\) and \(T_{AAA} ,\) are given by:

$$T_{BU} = 2H_{S} K + X_{P - LMA} + X_{PC} .$$
(14)
$$T_{DR} = 2H_{B} K + X_{HC} + X_{PC} .$$
(15)
$$T_{AAA} = 2H_{S} K + X_{GW} + X_{P - AAA} .$$
(16)

Binding update messages in DP-PMIP, DF-PMIP, and I-PMIP are exchanged between gateway and anchor. Therefore, \(X_{PC}\) in (14) will be replaced by \(X_{GW}\) while calculating \(T_{BU}\) in (4). \(T_{DR}\) in (5) is the delay between anchor and ICMD in DP-PMIP, and for DF-PMIP in (6), \(T_{DR}\) is the delay between distributed AAA servers. Authentication in PMIPv6 is mandatory during handovers, as there is no mechanism at gateways to determine any prior attachments of MN in the domain. Therefore, authentication is an important delay factor in all PMIPv6 based mobility schemes.

4.2 Packet transmission delay

Transmission delay is defined as the time taken by a data packet to reach from home anchor to MN. In case of OIS-PMIP and D-PMIP (DP-PMIP + DF-PMIP), the traffic using home prefix (Prefix B in Fig. 3b) is routed to and from the Internet at Prefix B home anchor (anchor B). D-PMIP routes proxy prefix (Prefix A) traffic via its home anchor (anchor A). The proposed OIS-PMIP routes proxy prefix uplink traffic to the Internet at proxy anchor (anchor B) and downlink traffic through home anchor (anchor A) until the route convergence is completed. After completion, OIS-PMIP routes both uplink and downlink traffic of proxy prefix through proxy anchor. Following expressions define the transmission delay in OIS-PMIP and D-PMIP.

$$R_{OIS - PMIP} = R_{H - prefix} + \left( {R_{P - prefix}^{UL} + R_{P - prefix}^{DL} } \right) .$$
(17)
$$R_{D - PMIP} = R_{H - prefix} + R_{P - prefix} ,$$
(18)

where each internal notation can be extended as:

$$R_{P - prefix}^{UL} = H_{S} K + X_{P - LMA} + \frac{{P_{f} \left( {X_{GW} + H_{W} L_{\beta } } \right)}}{{1 - P_{f} }} .$$
(19)
$$R_{H - prefix} = R_{P - prefix}^{UL} + H_{S} K + X_{GW} + \frac{{P_{f} \left( {H_{W} L_{\beta } } \right)}}{{1 - P_{f} }}.$$
(20)
$$R_{P - prefix} = R_{H - prefix} + H_{B} K + X_{P - LMA} + X_{H - LMA} .$$
(21)
$$R_{P - prefix}^{DL} = \left\{ {\begin{array}{*{20}l} {R_{H - prefix} - R_{P - prefix}^{UL} ,} \hfill & { if\;route\;covergence\;rightly\;completes,} \hfill \\ {\left( {R_{H - prefix} - R_{P - prefix}^{UL} } \right) + H_{B} K + X_{P - LMA} ,} \hfill & {otherwise.} \hfill \\ \end{array} } \right.$$
(22)

The route convergence delay \(T_{RC}\) is modeled using ideal convergence scenario, where OF-PMIPv6 domain A and B are attached with a same AS [35]. Also, it is assumed that number of hops between AS and domain A (\(H_{A}\)) are same as the number of hops between AS and domain B. AS takes time \(T_{down}\) to re-calculate the best path and update its forwarding table after receiving withdrawal update message from domain A, similarly it takes time \(T_{up}\) after receiving advertisement message from domain B. Hence, convergence delay is: \(T_{RC} = T_{down} + T_{up}\), where \(T_{down} = T_{up} = H_{A} K + \left( {L_{\alpha } + T_{RR} } \right)\).

We acknowledge the simplistic nature of route convergence scenario, but the focus here is to establish that OIS-PMIP considerably reduces transmission delay after certain \(T_{RC}\). Also, the transitory tunnel ensures there is no packet loss during route convergence, and this makes the actual value of \(T_{RC}\) less significant. After convergence, the transmission delay remains constant for MN sojourn in the domain. I-PMIP assigns only single prefix to MN and maintains it across multiple domains. I-PMIP also establishs an IP tunnel between anchors in home domain and currently serving domain, as MN prefix stays anchored at home anchor. Therefore, transmission delay in I-PMIP (\(R_{I - PMIP}\)) is same as \(R_{P - prefix}\) in (21).

4.3 Control signalling cost

The control signaling cost for inter-domain and intra-domain handover is defined as the transmission cost of control messages from source to destination and service delay at the destination entity. The transmission cost is proportional to the number of hops and their service delays. It is assumed that during MN sojourn in OIS-PMIP, some proxy prefixes are released and some new join but value of M at the time of handover remains same. The control signaling cost of intra-domain and inter-domain handover for OIS-PMIP is given by:

$$C_{intra}^{OIS - PMIP} = \frac{{P_{f} \left( {X_{GW} + 2H_{W} L_{\beta } } \right)}}{{1 - P_{f} }} + \left( {3H_{C} + 2H_{S} } \right)K + 2X_{PC} + 2X_{GW} + X_{P - LMA} .$$
(23)
$$C_{inter}^{OIS - PMIP} = C_{intra}^{OIS - PMIP} + M\left( {2H_{S} K + X_{H - LMA} + X_{HC} } \right) + N\left( {2H_{B} K + X_{PC} + X_{HC} } \right).$$
(24)

Inter-domain control signaling cost in OIS-PMIP increases due to communication with peer controllers, and is directly proportional to N. Signaling cost is also impacted by M, as binding updates are exchanged between home controller and anchor of each proxy prefix to establish the transitory tunnel.

Intra-domain control signaling cost for DP-PMIP, DF-PMIP and I-PMIP is akin to PMIPv6:

$$C_{intra}^{PMIP} = \frac{{P_{f} \left( {X_{GW} + 2H_{W} L_{\beta } } \right)}}{{1 - P_{f} }} + 4H_{S} K + 2X_{GW} + X_{P - LMA} + X_{P - AAA} .$$
(25)

DP-PMIP and DF-PMIP inter-domain model is extended to include multiple active proxy prefixes:

$$C_{inter}^{DP - PMIP} = C_{intra}^{PMIP} + M\left( {4H_{B} K + X_{P - LMA} + X_{H - LMA} + 2X_{ICMD} } \right).$$
(26)
$$C_{inter}^{DF - PMIP} = C_{intra}^{PMIP} + \left( {1 + M} \right)\left( {X_{P - LMA} + X_{P - AAA} } \right) + M\left( {4H_{B} K + X_{H - AAA} + X_{H - LMA} } \right) + 2H_{S} K.$$
(27)

I-PMIP assigns a single prefix to MN and maintain it across multiple domains. This limits the control signaling only with the previous domain. Its control signaling overhead is given as:

$$C_{inter}^{I - PMIP} = C_{intra}^{PMIP} + 4H_{B} K + 2X_{ICMD} + X_{P - LMA} + X_{H - LMA} .$$
(28)

5 Performance evaluation

5.1 Analytical results

Handover frequency is an important factor in evaluation of inter-domain mobility, and it is incorporated using renowned Session-to-Mobility Ratio (SMR) [36]. SMR (\(\sigma\)) is defined as a ratio of session arrival rate (\(\gamma\)) to the MN attachment period with a DP-G (\(\eta\)), (i.e., \(\sigma = \frac{\gamma }{\eta }\)). If the coverage area of DP-G/MAG is circular with the domain size Y, then as per [9, 37] intra-domain and inter-domain handover probabilities and expected values are:

$$\begin{aligned} p_{intra} (x) & = \frac{1}{1 + \sigma \left( x \right)}\quad and\quad p_{inter} (x) = \frac{1}{1 + \sigma \left( x \right)\sqrt Y } \\ E_{intra} (x) & = \frac{1}{\sigma \left( x \right)}\quad and\quad E_{inter} (x) = \frac{1}{\sigma \left( x \right)\sqrt Y } , \\ \end{aligned}$$
(29)

where x is a random variable denoting MN.

5.1.1 Handover delay

Average handover delay for MN moving across multiple domains can be calculated as [9]: \(D_{avg}^{\left( . \right)} = \left( {\delta_{intra} - \delta_{inter} } \right)D_{intra}^{\left( . \right)} + \delta_{inter} D_{inter}^{\left( . \right)}\), where (.) denotes any aforementioned mobility scheme. Figure 8 shows handover delay performance of different schemes as a function of SMR, where Y is 32. OIS-PMIP outperforms other solutions under high mobility scenario \(\left( {SMR \ll 1} \right)\) with approx. 4% gain over closest solution (DP-PMIP). All solutions tend to show dip in handover delay when SMR moves above 1, and converge as SMR moves towards higher values. Based on the results in Fig. 8, it can be stated that OIS-PMIP is suitable for high as well as low mobility scenarios.

Fig. 8
figure 8

Average handover delay as a function of SMR

Full size image

Domain size is another contributing factor in average handover delay. Smaller domain size causes more frequent inter-domain handovers and vice versa. Figure 9 presents handover delay of different schemes as a function of domain size. OIS-PMIP shows better performance compared to the other solutions with approx. 4% gain over DP-PMIP. Lower and consistent handover delay values under high inter-domain mobility, makes OIS-PMIP more acceptable for small/femtocell deployments.

Fig. 9
figure 9

Impact of domain size on the average handover delay

Full size image

The global mobile traffic is likely to increase seven-fold in next 5 years [38]. Therefore, it is important to evaluate different solutions under high traffic conditions. Figure 10 shows the performance of different solutions against increasing network utilization at every component (i.e., DP-G, controller, anchor and intermediate switches). DF-PMIP performs worst due to extensive signaling between various components. OIS-PMIP shows the lowest handover delay with approx. 9% gain over DP-PMIP under maximum network utilization. This confirms the robustness of OIS-PMIP under intense network traffic conditions that are expected in 5G mobile networks.

Fig. 10
figure 10

Impact of network utilization on average handover delay

Full size image

5.1.2 Transmission delay analysis

Packet transmission delay is important for future ultra-reliable low latency communication use cases [2]. Figure 11(a) presents the cumulative uplink and downlink transmission delay for home prefix traffic, and Fig. 11(b) presents the same for proxy prefix. OIS-PMIP shows improved performance over I-PMIP but is same as D-PMIP for home prefix in Fig. 11(a). This performance gain highlights the impact of OnDemand mobility with differentiation between home and proxy prefix. OIS-PMIP directly routes the uplink traffic of proxy prefix to the Internet from proxy anchor, and this enables it to achieve 30% performance gain over D-PMIP and I-PMIP in Fig. 11b.

Fig. 11
figure 11

a Home prefix uplink and downlink traffic transmission delay. b Proxy prefix uplink and downlink traffic transmission delay

Full size image

Figure 12 presents transmission delay for proxy prefix downlink traffic from the instance route convergence initiates after the inter-domain handover. Initially, OIS-PMIP has similar transmission delay for proxy prefix downlink traffic as I-PMIP and D-PMIP. However, the transmission delay is reduced by 45% comparing to I-PMIP and D-PMIP after the convergence delay \(T_{RC}\) (i.e., 0.8 s in Fig. 12). This improvement is because downlink traffic is directly routed to the proxy anchor after convergence.

Fig. 12
figure 12

Impact of route convergence on proxy prefix downlink traffic

Full size image

5.1.3 Control signaling overhead analysis

The average control signaling overhead of MN in OIS-PMIP is calculated as [9]: \(C_{avg}^{\left( . \right)} = \left( {E_{intra} - E_{inter} } \right)C_{intra}^{\left( . \right)} + E_{inter} C_{inter}^{\left( . \right)}\). Figure. 13 shows the control signaling overhead of different solutions as a function of SMR, where neighboring domains (N) are 3 and proxy prefixes (M) are 1. The control signaling overhead for OIS-PMIP is same as DP-PMIP and I-PMIP, even when OIS-PMIP communicates with three neighboring domains in comparison to a single neighboring domain in case of DP-PMIP and I-PMIP. This result highlights the contribution of OIS-PMIP distributed architecture, which unlike other distributed solutions, impose much less control signaling overhead.

Fig. 13
figure 13

Average control signaling cost as a function of SMR

Full size image

Next we analyze the impact of maintaining multiple proxy prefixes in a domain. Figure 14 presents the control overhead as a function of M and N with SMR equal to 1. The results show that OIS-PMIP has the lowest overhead when the value for both M and N is 1. With increase in M, the control signaling cost for DP-PMIP and DF-PMIP increases linearly, and although, OIS-PMIP is a function of both M and N but it manages to outperform DP-PMIP and DF-PMIP due to distributed C3 protocol. Control signaling cost for I-PMIP remains constant as it only maintain one prefix per MN and is independent of M and N.

Fig. 14
figure 14

Impact of M and N on average control signaling cost

Full size image

The control signaling overhead also varies with the domain size, and it is presented in Fig. 15, where SMR, M, and N are 1, 3 and 3, respectively. In comparison to DP-PMIP and DF-PMP, OIS-PMIP imposes lower control overhead and converges towards I-PMIP as the domain size increases. It can be stated that for a reasonable domain size (60-80 DP-Gs) OIS-PMIP control overhead is same as I-PMIP.

Fig. 15
figure 15

Impact of domain size on average control signaling cost

Full size image

5.2 Experimental analysis

5.2.1 Testbed setup and experimentation

We have developed an initial testbed for evaluation and operational assessment of OIS-PMIP, with focus on handover delay results for inter-domain mobility. Currently, our testbed consists of two OF-PMIPv6 domains and each domain consists of OpenFlow-enabled access points (DP-Gs), a controller, and an anchor (LMA). The layout of the testbed with physical connections between different entities is shown in Fig. 16. In order to imitate real network between domain controllers, we have used Mininet [39] to emulate network topologies with varying background traffic generated through IPerf. Domain controllers are interfaced with Mininet through bridging technique.

Fig. 16
figure 16

OIS-PMIP testbed layout

Full size image

Open source router implementation for embedded devices (OpenWRT) [40] is deployed over Alix 2D2 development kit to implement DP-G. We have used an open source switch implementation of the OpenFlow protocol v1.3 [41] on DP-G for OpenFlow control signaling. OpenFlow implementation in DP-G is extended to establish IP tunnel with the anchor and adds corresponding routing table entries. OIS-PMIP uses NOX implementation as the controller [41]. Each domain controller is deployed on a dedicated Linux server with 32 GB memory and Intel Xeon CPU (3.10 GHz quad-core).

A windows 7 laptop is used as MN, and DP-Gs are placed in separate rooms to ensure minimal footprint overlap. To perform the inter-domain handover experiments, we walked at a normal pace from one room to another. The handover is triggered by Windows 7 network manager based on low Received Signal Strength (RSS). 60 handover trials are conducted to get the experimental results.

6 Results

The first experiment evaluates the impact of peer domains on handover delay. We deploy multiple controllers to represent different domains, with whom the serving domain controller communicate during the handover. In this experiment the emulated network topology is one hop with no background traffic. The results in Fig. 17 show that 85% of delay values are smaller or equal to 100 ms. As expected the number of peer domains have minimal effect on handover delay because of negligible processing delay at controllers. Therefore, rest of our experiments are with only one peer domain. Few values above 200 ms are due to numerous RA message re-transmissions caused by dynamic campus environment. Results in Fig. 17 do not include the \(T_{WRS}\) delay, and adding its value (220 ms) aligns these results with the analytical model results and confirms their correctness.

Fig. 17
figure 17

Impact of N on inter-domain handover delay in OIS-PMIP

Full size image

Routing distance between serving and peer domain effects the handover delay. We have evaluated this effect by emulating three, five and seven hop topologies on Mininet with 40 Mbps background traffic, where link capacity in Mininet is 100 Mbps. The results in Fig. 18 show that the handover delay increases as expected with the increasing number of hops between two domains. Nearly 85% of the delay values are less than 150 ms, showing that OIS-PMIP performs well even when domain controllers are far apart.

Fig. 18
figure 18

Impact of HB on inter-domain handover in OIS-PMIP

Full size image

In real system, domains are expected to communicate over the Internet, unless they exist under a same operator. To evaluate the impact of varying network conditions on handover delay, we conducted experiments with 40%, 60%, 80% and 98% link utilization The results in Fig. 19 show that handover delay is minimally effected until 80% link utilization, but massively increases when link is almost chocked with 98% link utilization, which is rarely the case in production networks.

Fig. 19
figure 19

Impact of link utilization on inter-domain handover delay in OIS-PMIP

Full size image

7 Conclusion and future work

This paper proposed OIS-PMIP solution which leverages PMIPv6 with SDN and OnDemand mobility management to provide inter-domain mobility. OIS-PMIP offers detailed accounts for a distributed communication protocol between domain controllers, a prefix retrieval method, and a mechanism to reduce the transmission delay which benefits from the route convergence. The results confirm that handover delay in OIS-PMIP is minimally effected by domain size and achieves better performance in high mobility and network utilization scenarios, which justifies its suitability for 5G use cases. The results also validate that separate treatment of uplink/downlink traffic and route convergence technique improves the overall transmission delay; making it suitable for delay intolerant applications. The control signaling overhead is relatively higher for OIS-PMIP in high mobility scenarios but it rapidly reduces under moderate or low mobility. Our experimental results from the testbed for handover delay further reaffirms the presented analytical analysis. We are continuously extending our testbed for further analysis and in future will work on softwarization and dynamic deployment of anchor through NFV integration.