1 Introduction

Recently, IETF proposed a mobility management technique based on the standardized network through PMIPv6 protocol. PMIPv6 is similar to host-centric mobility management protocol [1, 2]. However, it also has the important difference that it does not require MN for any processing as to mobility. It provides MN IP mobility by introducing new mobile agents such as MAG and LMA. MAG within the domain in PMIPv6 recognizes the motion of MN and recognizes L2 connection notification. Moreover, it also performs the role of sending and registering PBU at LMA. LMA performs the role of HA to manage all MNs registered in PMIPv6 domain that was given by the receiving PBU message. LMA resends PBA including HNP for MN to MAG. MN that accessed MAG forms its own address and pHoA (Proxy Home Address) based on HNP received from MAG. When MN runs handover through new network, MN reacquires HNP and HNP acquired from the previously accessed network will be acquired from MAG of newly accessed network. PMIPv6 shows better performance than the conventional host-centric mobility management protocol [3].

However, the previously developed multicast technique cannot be applied to PMIPv6. Furthermore, it is even more difficult to apply the multicast technique between domains. On this account, this paper proposes two PMIPv6 multicast handover techniques for an MN that moves in high speed between LMA domains when multicast service is running. The first proposed PMIPv6 multicast handover technique is to reduce latency through buffering by forming a tunneling between MAGs of LMA through which MAG of LMA has MN and MN’s attempt to move. The second proposed PMIPv6 multicast handover technique is to reduce latency through buffering by forming a tunneling between LMA having MN and LMA that is willing to move.

This paper implemented mathematical modeling of the PMIPv6 multicast network proposed by IETF [4, 9, 10], the latency of multicast handover procedure of the proposed two techniques and the entire network overhead and performed a performance evaluation of these. In the case of latency, IETF’s proposed PMIPv6 multicast network increases latency in the linear form due to an increase in the number of hops. However, the proposed two multicast networks maintain fixed value of 85.6(ms) based on the analysis of results. That is, it shows that the number of hops does not affect them at all. Moreover, IETF’s proposed PMIPv6 multicast network was found to have a difference of at least two times in the case of the entire network overhead.

This paper is organized as follows. In Sect. 2, we will explore related researches. Section 3 will describe a proposed hierarchical modeling system. Section 4 presents performance evaluation of the proposed system modeling. Finally, we will describe the conclusions in Sect. 5.

2 Related Work

With the expansion of PMIPv6, FPMIPv6(Fast PMIPv6) [5] was recently announced as an enhancement of the handover performance of PMIPv6. However, this is designed to optimize unicast communication, and not multicast communication. In other words, because the lack of contribution to the multicast group management, benefits of FPMIPv6 cannot affect to the multicast communication.

FPMIPv6 multicast handover procedure optimizes the multicast group management by using MN roaming context. Context passed from pMAG to nMAG before MN is connected with nMAG contains identification of MN, LMA address of MN, multicast driving information of MN and so on. After nMAG obtains the context of MN, and if it is necessary, it updates multicast forwarding state as well as MLD Proxy Membership Database in advance. Multicast communication is delivered to nMAG in pMAG in the same way as FPMIPv6. By doing so, as soon as MN is connected to the new network, MN is able to receive the multicast communication directly from nMAG.

FPMIPv6 multicast handover procedure does not require a new or added presence in the given PMIPv6 domain. Basic multicast handover procedure requires no changes to MN. However, the function of MAG and LMA needs to be improved [6]. In FPMIPv6 multicast handover procedure, MAG is required the following improvements. Context transfer function is necessary to send and receive the context of MN from nMAG. Context transfer is executed by L2 trigger. Therefore, it is reasonable to assume that the transmission of context to nMAG in pMAG is done before MN is actually connected to nMAG. The multicast subscription information of MN to be transmitted as part of the context updates the multicast forwarding state by nMAG and if it is necessary, it is used to perform the initial MLD Member Report. The function of multicast communication transmission and buffering is required to prevent multicast communication loss during the handover of MN. Information of nMAG such as network identification information or address is held. In order to improve LMA, the following is required. Multicast subscription information of MN transmitted from MAG is used to update the multicast forwarding state. In this case, LMA also requires multicast communication buffering for MN.

As shown in Fig. 1, in FPMIPv6 multicast handover procedure, when L2 trigger is transferred to pMAG, MN prepares the handover to nMAG in pMAG. Using L2 trigger, MN gets network connection information of nMAG such as network identification information. Then, MN provides the network identification information with the identification information of its own to pMAG. pMAG provides service to the current MN by sending a L2 report message.

Fig. 1.
figure 1

FPMIPv6 multicasting handover procedures.

Full size image

MLS of FPMIPv6 multicast handover procedure begins with Handover Initiate(HI) message including identification information of MN, HNP of MN, LMA address of MN, Multicast Support Option(MSO). Multicast subscription information of MN included in MSO is transmitted from pMAG to nMAG, and it is used as a parameter for MLS. If nMAG acquires HI message and the state of nMAG can provide service to MLS for MN, it will check the message. nMAG sends back to pMAG Hack(Handover Acknowledge) message containing the value to accept or reject. If it is accepted, nMAG updates the multicast forwarding state for MN roaming. You should note that nMAG’s MLS decision is determined based on the required multicast service, available buffer size, capacity of MN’s number and so on. When receiving HAck message with the accepted values, pMAG delivers the multicast communication for MN to nMAG. Multicast communication transmission is performed until pMAG receives multicast communication for MN from LMA.

3 Proposed Scheme

In the case of PMIPv6 multicast and FPMIPv6 multicast handover, the mobile multicast approach is only for the case in which MN in LMA moves to nMAG in pMAG. However, network size is becoming larger and usage scope of network is expanding. Thus, this paper proposes a better technique through the performance analysis of the aforementioned two techniques by proposing the two handover techniques for the case in which MN between LMAs moves by expanding it.

Procedure between LMA domains optimizes multicast group management by utilizing MN roaming context such as FPMIPv6 multicast handover. The context to be sent from pMAG to nMAG before connecting MN to nMAG includes MN identification, LMA address of MN and multicast operation information of MN. nMAG acquires MN context. If necessary, it renews multicast transmission status in advance as well as MLD proxy membership database. Similar to FPMIPv6, multicast communication transmits pMAG in nMAG. In this way, MN becomes able to receive multicast communication directly from nMAG as soon as MN accesses new network.

As for FPMIPv6 multicast handover procedure between LMA domains (Fig. 2), MAG needs the following outline just like FPMIPv6 multicast handover procedure. Context transmission function needs to send and receive MN context from/to nMAG. Context transmission is to be conducted by L2 trigger. As for the proposed multicast handover, it requires outline of nMAG unlike FPMIPv6 multicast handover procedure within domain. nMAG conducts proxy binding procedure in advance before sending HAck message to pMAG while pMAG and LMA2 exchange MSO message with pre-PBU (previously-PBU) and MSO message with pre-PBA (previously-PBA). Hereupon, multicast communication loss will be reduced substantially during MN handover.

Fig. 2.
figure 2

FPMIPv6 multicasting communication between pMAG and nMAG.

Full size image

PMIPv6 multicast handover procedure between LMA domains based on MAG transmits multicast subscription information of MN included in MSO from pMAG to nMAG by utilizing communication between pMAG and nMAG in order to conduct FPMIPv6 multicast handover procedure between LMA domains (Fig. 3). The proposed handover procedure communicates with LMA2 by sending multicast subscription information of MN included in MSO when sending DeReg.PBU message from pMAG to LMA1. Thus, it reduces multicast handover procedure. Thereupon, the loss associated with multicast communication during MN handover is reduced substantially.

Fig. 3.
figure 3

Multicasting communication between LMA1 and LMA2.

Full size image

4 Performance Evaluation

In this section, by mathematical modeling of the proposed multicast handover procedure’s delay time and overall network overhead, we will perform a performance evaluation.

In the mathematical modeling of the handover delay time, MN performs a handover procedure between LMA domains. The communication path between LMA and LMA, LMA and MAG is a wired connection, the communication path between MAG and MN is a wireless connection. Also, we assumed that the processing time of each component can be ignored, and a message is transmitted through wired / wireless link without the error.

In the mathematical modeling of the entire network overhead, we assumed that Session Arrival Rate is same in each MN and average file size in Session is also same. In addition, all average numbers of LMA (in case of PMIPv6 network) or HA (in case of HMIPv6 network) are equal, and the standard IP switching cost is ignored. MN in the network is distributed uniformly, and finally, the location DB is searched by the binary search (Table 1).

Table 1. Parameter for defining the network overhead costs [6, 7]
Full size table

4.1 Handover Delay Time Modeling

We define the handover delay time \( TDT_{(HO)}^{{\text{(} \cdot \text{)}}} \) as the time that MN does not receive a multicast packet during the handover execution. That is, the handover delay time means that MN receives the first multicast packet since MN has moved to LMA2 in LMA1 and pMAG located in LMA1 has received DeReg.PBA from LMA1. \( TDT_{(HO)}^{(BASE)} \) is defined as a handover delay time of a basic handover procedure between LMA domains.

$$ TDT_{(HO)}^{(BASE)} = (DT_{L2} + DT_{RS} + DT_{LU} + DT_{MLD} + DT_{FWD} + DT_{LMA} ) $$

In here, \( DT_{L2} \) is a link switching time, \( DT_{RS} \) is a delay time of RS message sent to nMAG of LMA2 from MN, that is \( DT_{MAG - MN} . \) \( DT_{LU} \) is PBU and PBA procedure that is location update delay, \( 2DT_{LMA - MAG} . \) \( DT_{MLD} \) is the procedure which register the multicast service of MN to Proxy Membership Database, \( 2DT_{MAG - MN} + DT_{LMA - MAG} . \) \( DT_{FWD} \) is the arrival delay time of the first multicast packet of the multicast communication from LMA2 to MN, \( DT_{LMA - MAG} + DT_{MAG - MN} . \) \( DT_{LMA} \) is the arrival delay time between LMA domains, \( nDT_{LMA - LMA} \).

We will call the handover delay time of first proposed multicast handover procedure as \( TDT_{(HO)}^{{(PRO_{1} )}} \).

$$ TDT_{(HO)}^{{(PRO_{1} )}} = DT_{L2} + DT_{RS} + \overline{{DT_{FWD} }} $$

In here, \( \overline{{DT_{FWD} }} \) is the delay time of multicast communication’s first packet buffered from nMAG to MN. It is \( DT_{MAG - MN} \).

We will call the handover delay time of second proposed multicast handover procedure as \( TDT_{(HO)}^{{(PRO_{2} )}} \).

$$ TDT_{(HO)}^{{(PRO_{2} )}} = DT_{L2} + DT_{RS} + \overline{{DT_{FWD} }} $$

The handover delay time of the second proposed multicast handover procedure is equal to the handover delay time of the first proposed multicast handover procedure.

4.2 The Entre Overhead Modeling in the Network

The entire overhead in the network can be defined as the sum of the query message, registration message and packet tunneling costs [7].

  1. (1)

    Query Message. The costs of query message in proposed FMIPv6(MAG) multicast network are similar to the costs of query message in PMIPv6 network. The costs of query message from the entire CN in the network are as follows:

    $$ \varLambda_{{^{{}} }}^{{^{Query} }} = N_{m} N_{c} \lambda_{s} (2\beta_{c} \varPhi_{LMA - CN} + \eta N_{LMA} (\log N_{m} - \log N_{LMA} )) $$
  2. (2)

    Registration Message. The registration message of proposed FPMIPv6(MAG) network does not need the performing procedure for MLD Membership Report of PMIPv6 multicast. Therefore, the costs of the registration message are as follows:

    $$ \varLambda_{{^{{}} }}^{{^{{\text{Re} gistration}} }} = N_{m} \frac{{2\beta_{pc} (\varPhi_{MAG - LMA} - 1 + \sigma ) + \delta_{pc - mso} }}{{MT_{r} }} $$
  3. (3)

    The Costs of Packet Tunneling. The costs of multicast network tunneling of proposed FPMIPv6(MAG) are simpler than the costs of the multicast network of PMIPv6. Packet can be transmitted between MN and cnMAG, and that cost is \( (\beta_{dp} + \beta_{da} )\sigma \). Packet is transmitted between cnMAG and nmMAG through the encapsulation. That costs is \( (\beta_{dp} + \beta_{da} )(\sigma + \varPhi_{cnMAG - mnMA} ) + 2\xi \). Finally, the sum of the costs of packet transmission between mnMAG and mnLMA and the costs of packet transmission between MN and mnMAG are \( (\beta_{dp} + \beta_{da} )(\varPhi_{mnMAG - mnLMA} + \sigma ) + 2\xi \), which are the costs of the entire packet tunneling. Therefore, the costs of packet tunneling are as follows:

    $$ \varLambda_{{^{{}} }}^{{^{Packet\_T} }} = N_{m} N_{c} \lambda_{s} \left[ {\frac{\alpha }{k}} \right]\left[ \begin{subarray}{l} (x + 1)(\beta_{dp} + \beta_{da} )(\sigma + \varPhi_{cnMAG - mnMA} ) + 2\xi \\ + (\beta_{dp} + \beta_{da} )(\varPhi_{mnMAG - mnLMA} + \sigma ) + 2\xi \end{subarray} \right] $$
  4. (4)

    The Entire Overhead in the Network. The entire overhead in the network is defined as the sum of the costs of query message, registration message and packet tunneling, then it is as follows:

    $$ \varLambda_{{^{Network} }}^{{^{{}} }} = \varLambda_{{^{{}} }}^{{^{Query} }} + \varLambda_{{^{LC} }}^{{^{{\text{Re} gistration}} }} + \varLambda_{{^{{}} }}^{{^{Packet\_T} }} $$

4.3 Numerical Results

We analyzed the multicast handover delay time and the entire overhead by a mathematical model, and tried to evaluate the performance in two different ways. The handover delay time is by reference to the parameter values of [6], the entire overhead is by reference to the parameter values of [7], it is the same as in Table 2.

Table 2. Parameter vales used performance evaluation [7].
Full size table
  1. (1)

    Analysis of Delay Time. This section provides performance evaluation results according to the delay time. Numerical analysis has been used with the following parameters. In wired connection, transmission delay for one Hop count is \( T_{tr} \) = 20 ms and \( T_{tr} \) = \( DT_{MAG - MN} \), \( nT_{tr} = DT_{MAG - MN} \) [1]. Figure 4 showed a change in the delay time according to n Hop count between LMA domains, and the comparison of Fig. 4 presented by changing Hop count which MN reached between LMA and MAG to 3 and 7. As shown in Fig. 4 in basic multicast procedure, when MN moves between LMA domains the handover delay time is influenced by Hop count between LMA domains. Also, if we compare Fig. 4, the basic multicast procedure is the value of Hop count’s comparison between LMA and MAG in LMA domain which MN reached. That is, the delay time is influenced by two ways; one is Hop count between LMA domains, and the other is Hop count between LMA and MAG in LMA domain. However, FPMIPv6 multicast handover procedure between LMA domains by using proposed MAG and FPMIPv6 multicast handover procedure between LMA domains by using LMA are not influenced by Hop count between LMA domains and Hop count between LMA and MAG in LMA domain which MN reached.

    Fig. 4.
    figure 4

    n Hop Count delaytime between LMA domains.

    Full size image
  2. (2)

    The Entire Overhead Analysis. This section provides performance evaluation results according to the entire overhead costs. As explained in Sect. 4.2, the costs of the entire overhead is the sum of query message, registration costs, and costs of packet tunneling. The explanation and the value of the parameter which has been applied are by reference to [2]. A formula for calculating the network overhead costs of HMIPv6 and PMIPv6 is a data for a mathematical modeling of each multicast network costs, and it is excluded from the performance evaluation.

    Figure 5 is the overhead of entire network in accordance with an increase in MN per MAG. With the increase of the number of MN, both PMIPv6 multicast handover procedure and two proposed multicast handover procedure linearly increased. Although multicast network between LMA by second proposed LMA tunneling is lower than PMIPv6 multicast network proposed from IETF, we can find that the entire overhead of multicast network between LMA through first proposed MAG tunneling is lowest.

    Fig. 5.
    figure 5

    The overhead of entire network in accordance with an increase in MN per MAG.

    Full size image

    Figure 6 is the overhead of entire network in accordance with an increase in SMR. SMR is defined as \( T \times_{r} \lambda_{s} \), and we fix \( \lambda_{s} \) as 0.01 and increase \( T_{r} \) to calculate SMR in Fig. 6. We can find that the overhead of entire network decreases according to increasing of SMR. Although multicast network between LMA by second proposed LMA tunneling is lower than PMIPv6 multicast network proposed from IETF, we can find that the entire overhead of multicast network between LMA through first proposed MAG tunneling is lowest.

    Fig. 6.
    figure 6

    The overhead of entire network in accordance with an increase in SMR (Session to Mobility Ratio). (\( \lambda_{s} \) = 0.01).

    Full size image

5 Conclusion

This paper conducted mathematical modeling of latency and entire network overhead in accordance with multicast network handover procedure. Also, it performed performance evaluation based thereon. As shown in the graph of performance evaluation, the two proposed multicast networks were found to have substantially lower latency and overhead than PMIPv6 multicast network proposed by IETF. This paper also confirmed that multicast network between LMAs through MAG tunneling among the two proposed multicast networks was more efficient. Moreover, this paper showed more reliable information because it analyzed performance evaluation through the changes of several parameters.