Global Mobility Management Scheme for Seamless Mobile Multicasting Service Support in PMIPv6 Networks

Abstract

The development of multimedia applications has followed the development of high-speed networks. By improving the performance of mobile devices, it is possible to provide high-transfer-speed broadband and seamless mobile multicasting services between indoor and outdoor environments. Multicasting services support efficient group communications. However, mobile multicasting services have two constraints: tunnel convergence and handoff latency. In order to solve these problems, many protocols and handoff methods have been studied. In this paper, we propose inter local mobility anchor (inter-LMA) optimized handoff model for mobile multicasting services in proxy mobility IPv6 based (PMIPv6-based) networks. The proposed model removes the tunnel convergence issue and reduces the router processing costs. Further, it the proposed model allows for the execution of fast handoff operations with adaptive transmission mechanisms. In addition, the proposed scheme exhibits low packet delivery costs and handoff latency in comparison with existing schemes and ensures fast handoff when moving the inter-LMA domain.

1. Introduction

Unlike the existing 1:1 communication service (unicasting), multicasting is a service that delivers data to multiple users. A representative example is IPTV [1], which specifies its data receivers in a group and sends the sources to the corresponding group via a single transmission. Multicasting services reduce the network load and cost. In addition, mobile nodes (MNs) that receive services can provide mass storage multicasting services owing to improvements in performance.

Because existing multicasting services are applicable to fixed static networks, they are not suitable for use in wireless environments. These services can communicate with other MNs when they have a unique IP address that provides IP-based Internet service. However, because the MN can move to another network in a wireless environment, it cannot ensure consecutive connections with networks to MNs transferred by exploiting the existing IP protocol [2]. To solve this problem, the Internet Engineering Task Force (IETF) Mobile IP working group proposed the Mobile IPv6 (MIPv6) protocol to provide mobility in IP networks [3]. Even though MIPv6 has been studied to provide mobility to the MNs, there are many disadvantages to the scheme that includes the creation of a large load to limited link sources because a large amount of signaling is needed when MIPv6 provides mobility, and the presence of battery problems due to the large amount of signaling and the cost that is incurred when inserting the function performing the MIPv6 operation into the MN. In addition, the TCP performance in Proxy Mobile IPv6 (PMIPv6) can create overhead from each router with the routing method using the existing tunneling owing to the unnecessary routing caused by the packet sequencing dislocation phenomenon and continuous tunnel expansion [4]. To supplement the weakness of MIPv6, PMIPv6 has received attention for its ability to support mobility on the network [5]. Moreover, mobile multicast (MoM) schemes such as the mobile multicast protocol and mobile multicast gateway (MMG), which support multicasting in the mobile environment [6][7][8], have been proposed to solve the tunnel convergence problems. In studies on PMIPv6, multicast support in networks has the problems of binding procedures, which the mobility management protocol fundamentally has, and the transmission delay caused by joining a group. The reception delay could lead to the disconnection phenomenon and the degradation of service performance [9]. Therefore, studies about multicast handoff not only solve these problems but lend support to seamless service. In this paper, research has been carried out regarding this topic.

We propose a PMIPv6-based mobile multicasting support network model to provide effective mobile multicasting service to solve the two problems mentioned above. The proposed scheme is a method for preventing the loss of multicasting service packets, and for reducing the delay time via buffering by building the tunneling of a mobile access gateway (MAG) of a local mobility anchor (LMA), which owns the MAG and newly attached MAG (nMAG) in a move to support seamless multicasting services. The proposed scheme involves binding procedures and the procedures of joining in groups in advance when the MN detects movement. The scheme prevents data loss of the MN from the multicasting service by performing buffering in the nMAG during the time that the MN is detached from the link. The MN reconnects the L2 link in case it moves between the LMAs. It also does not send any signals except for the L2 Report signal, and is not involved in the handoff at all.

We completed a performance evaluation of the proposed handoff method in terms of the delay time and the entire overhead after mathematically modeling the PMIPv6 multicast network method [10] and the fast PMIPv6 multicast handoff method proposed by the IETF. As seen in Fig. 8, a reduction in the delay time and the entire overhead is achieved as a result of confirming the delay time.

The organization of this paper is as follows. In section 2, we discuss related works. In section 3, we describe the global mobility management scheme for supporting the multicasting service in the proposed PMIPv6 networks. In section 4, we discuss the modeling of the proposed system and its performance evaluation. Finally, the conclusions are summarized in section 5.

 

2. Related Work

2.1 Overview of PMIPv6

PMIPv6 is a network-based mobility management protocol [4][11][12][13][14]. PMIPv6 provides mobility to MNs as in MIPv6, but unlike MIPv6, which is a host-based mobility protocol, it handles signaling, which MN executes, in networks in cases of handoff. The MN is identified as an MN-identifier (MN-ID), similar to the network access identifier (NAI) within the PMIPv6 domain. When the MN successfully completes access authentication [15], the network ensures that the MN remains in the home network. Wherever the MN moves within the same domain, it is regarded as one link because it is allocated an identical home network prefix (HNP) value. Network entities such as the LMA and MAG are newly defined in PMIPv6. When the MN moves in the PMIPv6 network, MAG, which detects the movement, obtains the MN_ID and profile information via MN_Attach.

The MN transmits a router solicitation (RS) message to the MAG to request HNP, or the MAG transmits a proxy binding update (PBU) message to register the current location of the MN into the LMA by recognizing the access of the MN. The LMA transmits a proxy binding acknowledgement (PBA) message which includes the HNP information of the MN to the MAG, and both the MAG and LMA set up a bidirectional IP tunnel. The MN receives the router advertisement (RA) message with the HNP information from MAG and completes the setting of the IP address. Once the setup is completed, the LMA receives the packets transmitted from outside of the PMIPv6 domain to MN within the domain. The packets are then transmitted to the MAG via the bidirectional IP tunnel located between the MAG and LMA, and are forwarded to the MN. Afterwards, the same process mentioned above is performed again if handoff occurs in the same domain. However, the MN is considered to remain on the same link, and any additional operation is not necessary because the LMA does not allocate a new MN-HNP but re-sends the HNP that the existing NM used. The PMIPv6 domain is illustrated in Fig. 1.

Fig. 1.PMIPv6 domain structure.

2.2 Handoff Applying Multicasting

2.2.1 Multicasting in FPMIPv6

Fast handoff for mobile IPv6 (FMIPv6) is a protocol that minimizes the delay time to improve the handoff performance of MIPv6 and reduce the packet loss [10]. Methods that apply fast handoff to PMIPv6 have been proposed by the IETF [16][17]. The only handoffs within the same domain were defined in FPMIPv6 [18]. FPMIPv6 is a way of performing an L3 handoff before an L2 handoff occurs. FPMIPv6 was designed by focusing on two issues; one is for sending packets as soon as MN detects a new node, the other issue is for receiving packets as soon as the L2 handoff of the MN is completed.

If the MN detects a new node, it recognizes the information of the nMAG, which the node of the new nMAG belongs to. If the MAG of the node is different from the information of the previous MAG (pMAG) that currently provides service to the MAG, the MN predicts that handoff can occur. When detecting a handoff, the MN informs the pMAG of the MN-ID and a new access point identifier (AP-ID). Via these processes, the pMAG sends a handoff initiation (HI) message that includes the address of the LMA that the MN-ID, HNP, and MN are currently receiving services from the nMAG. The nMAG responds to the pMAG with a handoff acknowledgement (HoAck) message, and sets up two-way tunneling between the nMAG and the pMAG, and all packets that are delivered between the MN and the pMAG become buffered to the nMAG through the tunnel. In addition, the pMAG sends a DeReg PBU+MSO message to the LMA and receives a DeReg PBA message. After finishing the movement of the MN, the nMAG transmits a PBU to the LMA, and the LMA responds with a PBA. Afterwards, two-way tunneling between the LMA and the nMAG is set up, and packet exchange occurs through the tunnel. Fig. 2 shows the handoff procedures within FPMIPv6. The handoff flow in Fig. 2 is a procedure that is completed when movement occurs within the LMA. In other words, Fig. 2 shows the case of MAG movement within the same domain.

Fig. 2.FPMIPv6 handoff procedures.

2.2.2 Multicasting handoff Scheme between LMAs

The multicasting handoff scheme between the other domains proceeds from the moment when the nMAG detects the L2 trigger of the MN [19]. The overall flow of the handoff between the LMA is shown Fig. 3.

Fig. 3.Handoff between LMA s .

The nMAG detects the movement of the MN at the start of handoff by sending handoff request (HOREQ) messages to the nLMA. The nLMA delivers the HOREQ to the pLMA, and the pLMA responds to the nLMA with a HOACK message. During this time, the pLMA transmits the multicasting information of MN with the response. In the messages, the MN-ID and multicast group addresses are included. The nLMA forms PIMJOIN with the information, and the nMAG receives a HOACK message from the pLMA. The pLMA creates a tunnel with the nLMA and forwards all of the multicast data that are delivered to the MN and nLMA, while nLMA transmits the multicast data to the nMAG. The nMAG buffers the multicast data until the link connection of the MN is completed. The MN receives the multicast data upon completion of the link connection setup. The nLMA and nMAG form a tunnel, and multicast data are delivered to the MN by exploiting the tunnel. The nMAG renews the binding by transmitting the multicast addresses and PBU to the nLMA and receives the response value (=PBA). Through these methods, handoff between the LMA domains is completed. Fig. 4 shows the flow of the handoff procedures between LMA domains. As this method is executed from the moment the nMAG detects the handoff, the MN goes through the suspension of multicast service. Therefore, it is necessary for this method to minimize the delay time of the handoff and more quickly respond to handoff detection.

Fig. 4.Handoff procedures between LMA domains.

 

3. Global Mobility Management Scheme for Supporting Multicasting Service

In this section, we propose a PMIPv6-based network model to reduce the cost of packet transmission for multicasting [20][21]. PMIPv6 supports mobility only in the network within the PMIPv6 domain with the MAG and LMA configuration. The MAG detects movement and updates the binding on behalf of the MN. Unlike mobile IP, the MNs do not have to perform any actions related to mobility. In addition, PMIPv6 does not request IP reconfiguration in the identical PMIPv6 domain. The proposed scheme begins by recognizing the possibility of occurrence of cases where the MN detects the nMAG, delivering a report message to the pMAG, and transmitting the multicast support option (MSO) that includes a Pre-PBU message and the HI from the pMAG to the nLMA and nMAG. The pMAG transmits the MSO to the nLMA for binding updates and for joining the multicast service in advance. At the same time, the pMAG requests handoff to the nMAG. The nLMA requests PIMJOIN with the corresponding node (CN) and sends Pre-PBAck to the nMAG but not to the pMAG. The nMAG redirects to the HI message response that originates from Pre-PBAck signals and the pMAG that is transmitted from the nLMA to the pMAG. The pMAG and nMAG form a tunnel, while the pMAG forwards all packets to the nMAG, including the multicast data that are transmitted to the MN. The nMAG checks if the MN enters into its domain, and buffers the packets until the MN completes the link connection setup. The nLMA joins the nMAG in multicast groups in advance by referring to the MSO that was received from the pMAG. In addition, the nLMA completes the binding update between the nLMA and the nMAG by exchanging Pre-PBU and Pre-PBAck messages beforehand. The MN then moves to the nMAG. After completing the link connection, the MN can receive multicast data. This method satisfies the request of the MN, which requires seamless multicasting service. Moreover, this scheme remarkably reduces the signaling messages of the network, the packet delivery cost, and the delay time. The overall network flow of the method is shown in Fig. 5.

Fig. 5.Fast handoff applying to multicasting between LMA domains.

The DeReg PBU and DeReg PBA messages between the pMAG and the pLMA can be ignored because they receive multicast data after building PIMJOIN in the nLMA, and do not affect the proposed scheme. Essentially, the FPMIPv6 multicast handoff procedures between the pMAG and the LMA are identical with the procedures that send the L2 Report in which the MN provides the nLMA network information to the pMAG via the L2 Report of the FPMIPv6 multicast handoff procedures. At this time, the nLMA information is also included in the L2 Report messages. The pMAG, which receives the report messages from the MN, begins with Pre-PBU messages including the MN-ID, HNP, and MSO, which is the address of the LMA in the proposed fast pre-inter-LMA handoff for multicast (FPILH-M) procedures. The Pre-PBU messages help the nLMA and nMAG to perform the binding update. As a result, the MN can use seamless multicast service. The MN does not experience any delay except for the delay time of the L2 link connection between the pMAG and the nMAG. The procedure seems complicated; however the MN can receive continuous multicast service after movement because it sends report messages in advance, overlaps during the handoff time in which the MN moves to the nMAG, and delivers multicast data to the nMAG in advance in cases where the MN is transferred from the pMAG and if MN stores multicast data through buffering. The handoff operating procedures of the proposed scheme are shown in Fig. 6.

Fig. 6.Fast handoff procedures applying multicasting between LMA domains.

Consequently, the reception delay time of the multicast data can be significantly reduced by approving the joint multicasting of buffering, the nLMA, and the nMAG of the MN first, while simultaneously completing the binding update, even though a delay time occurs in the existing schemes from the point at which the L2 trigger of the MN occurs to the point at which the link connection is initiated.

Additionally, the waiting time incurred by multicast listener discovery (MLD) query/report causes service errors when applying the existing PMIPv6 handoff network model [22]. To solve this problem, we propose high-speed handoff by using a transmission mechanism that is suitable for our situation. As Fig. 2 shows, when the MN completes handoff, it predicts the directions of movement and sends context messages that include the MN-ID of the MLD-FP, the HNP, the MN, a current MAG address, and a multicast group address. The MAG then checks if it could receive multicast data, substituting the previous MAG that the group requests. If there is no host available to use the pMAG that the group requests, the nMAG begins the timer and transmits the MLD report to join the group with the MN. If the MN does not arrive at the nMAG within the designated time, it sends an MLD stop message to the nMAG to secure the wireless network bandwidth.

 

4. Performance Analysis

4.1 Network Modeling

Fig. 7 shows that the waiting time handoff analysis uses a hierarchical cell structure that consists of k layers, as in [23]. Fig. 7 (a) shows the mobility of the MN from di to di+4 when the k layer is 2. Fig. 7 (b) shows the minimum and maximum mobility distance ranges within a cell. Before calculating the handoff delay time, the MN should check whether a handoff occurs whenever the MN crosses the border between MAGs, and how often it occurs. Therefore, we have to calculate the number of cells that belong to the MAG.

Fig. 7.Mobility pattern for performance analysis.

Handoff occurs at the three sides that are located near another cell among the six sides of the cell between MAGs.

Therefore, the value of the probability Pb is half of the probability that handoff occurs between MAGs. The handoff to obtain the probability of 1/2 must be multiplied. Therefore, PMAG-HO is as follows:

Moreover, the probability of a handoff occurring between LMA becomes 1 – PMAG-HO.

4.2 Multicasting Handoff Delay Time

We conducted a performance evaluation by mathematically modeling the delay time of the proposed multicast handoff procedures. The total handoff delay time of PMIPv6 can be divided into the L2 link connection time and the PBU/PBA time, as shown in (5). Equation (6) shows the MLD waiting time for the multicast group update.

Table 1.Parameters defining the network delay time.

Therefore, the total handoff delay time can be calculated by multiplying the probability of a handoff between the LMA domains by the individual handoff delay. The handoff delay time between the existing LMA domains is defined as (7).

FPMIPv6 does not experience a delay caused by MLD operation. Therefore, the formula is as follows:

As in FPMIPv6, the proposed FPILH-M scheme is not affected by the MLD delay. To apply the handoff delay time, PBU/PBA messages are included in the Pre-PBU signal (see Fig. 5). Therefore, the MN does not experience any delay time except for the L2 connection by exploiting the multicasting service. By applying this formula, the time limit of handoff-applied multicasting is defined as (9).

The MLD query time takes 0-1 s depending on the mobile environment. If the MN receives an MLD query, it sends an MLD report. The MLD query transmission has periodicity and an equal distribution as follows. The MLD query delay is calculated as an equal arbitrary variable depending on each handoff. Fig. 8 shows the accumulated delay time versus the number of handoffs. We see a significant reduction in the delay time in comparison to the existing methods, even with repetitive overhead.

Fig. 8.Accumulated delay time versus the number of handoffs.

Fig. 9 shows the handoff delay time according to the number of layers, k. An increase in the number of layers causes a decrease in the frequency of the number of handoffs when increasing the number of cells that is involved in a group. Therefore, the proposed handoff method, which is a transmission mechanism suitable for PMIPv6, is more effective than the existing PMIPv6 multicast and FPMIPv6 multicast methods in terms of the delay time of handoff.

Fig. 9.Delay handoff depending on the number of layers, k.

4.3 Cost Analysis for Multicasting Service

We conducted performance evaluations by mathematically modeling the entire network overhead of the proposed multicast handoff procedures. The entire network overhead is defined as the sum of the costs, which are the query message, registration message, and packet tunneling. In the performance analysis environment, it is assumed that the frame size of several signals necessary for handoff is the same. Further, it is assumed that IEEE 802.20 is observed in the case of an MN shift and that the information of the nLMA can be acquired. As expressed in (10). We refer to Table 2. to express the parameters used [24].

Table 2.Parameters to define the network overhead cost [24].

4.3.1 PMIPv6

The methods of determining the entire overhead of PMIPv6 are as follows.

1) Query message: The query message costs of the PMIPv6 network of all the MNs and CNs are Nm and Nc. The cost of all queries and response messages is NcNm(2ՓhcBq)λs. The query message cost from the entire CN in the network is as follows:

2) Registration message: For PMIPv6, the registration message is created only through the PBU and PBA messages between the MAG and the LMA. Therefore, the registration message cost is expressed as

3) Packet tunneling cost: The packet tunneling cost is (13) in PMIPv6 networks.

4.3.2 PMIPv6 Multicast

The methods for determining the entire overhead in a PMIPv6 multicast network are as follows.

1) Query message: The query message cost of the PMIPv6 multicast network does not differ greatly from the query message cost of PMIPv6 networks. The query message cost for the entire CN in the network expressed as

2) Registration message: The registration message produces the parameters βm-query and βm-report. These are the parameters for handling the MLD membership report when performing the PBU and PBA message procedures. Therefore, the registration message cost is as follows:

3) Packet tunneling cost: The packet tunneling cost of the PMIPv6 multicast network does not differ greatly from the packet tunneling cost of PMIPv6 networks. The packet tunneling cost is expressed as

4.3.3 FPMIPv6 Multicast

The methods for determining the entire overhead of FPMIPv6 multicast networks are as follows.

1) Query Message: The query message cost of the FPMIPv6 multicast network does not differ greatly from the query message cost of the PMIPv6 network. The query message cost for the CN in the network is expressed as

2) Registration message: The registration message of the FPMIPv6 network does not require the procedures for handling the MLD membership report, as in a PMIPv6 multicast network. Therefore, the registration message cost is as follows:

3) Packet tunneling cost: The packet tunneling cost in the FPMIPv6 multicast network does not differ greatly from the packet tunneling cost of PMIPv6 networks. The packet tunneling cost is expressed as

4.3.4 Proposed Scheme

The methods for determining the entire overhead of the proposed FPILH multicast network are as follows.

1) Query message: The query message cost of the proposed FPLIH multicast network does not differ greatly from the query message of the PMIPv6 network. The query message cost for the entire CN in the network is as follows:

2) Registration message: The registration message of the FPLIH multicast network does not require the procedures for handling the MLD membership report of the PMIPv6 multicast network. Therefore, the registration message cost is

3) Packet tunneling cost: The proposed FPMIPv6 multicast network tunneling cost is simpler than the PMIPv6 multicast network cost. Packets are transferred between the MN and the pMAG, and this cost is (βdp + βda)σ. Further packets are transferred between the pMAG and the nMAG through encapsulation. The cost becomes (βdp + βda)ՓpMAG-nMAG + 2ξ. Therefore, the packet tunneling cost is expressed as

4.4 Numerical Results

In this section, we provide the performance evaluation results that depend on the entire overhead cost. The entire overhead cost consists of the sum of the query message, registration cost, and packet tunneling cost, which was already mentioned in section 4.2. Table 3. (refer to [24]) summarizes the descriptions and values of the parameters. The formula for calculating the network overhead cost of PMIPv6 is the source for mathematically modeling each multicast network overhead cost and is excluded from the performance evaluation.

Table 3.Parameter values used for the performance evaluation [24].

Fig. 10 shows the overhead of the entire network depending on the increase in the number of MNs per MAG. As the number of MNs increases, the entire network overhead linearly increases not only for the PMIPv6 and FMIPv6 multicast handoff procedures, but also for the proposed FPILH multicast handoff procedure. The proposed method exhibits a lower overhead than the FPMIPv6 multicast network, including the proposed PMIPv6 multicast network from the IETF.

Fig. 10.Overhead of the entire network depending on the increase in the number of MNs per MAG.

Although Figs. 11 and 12 show the overhead according to the increase in the SMR, they show the entire network overhead for a fixed value of Tr and increasing λs, which allows the increase in the overhead of the entire network to be observed. We see that the overhead of the entire network increases much more when Tr increases . Even though there are no significant differences in the figures for the PMIPv6 multicast network, the overhead of the entire network has a slight difference for FPMIPv6 in the graph that is not indicated as a graph redundancy.

Fig. 11.Overhead of the entire network depending on the increase in the SMR (Tr = 100).

Fig. 12.Overhead of the entire network depending on the increase in the SMR (Tr = 500).

Fig. 13 shows the overhead depending on the increase in the number of the CNs. As the number of the CNs increases, the overhead of the entire network increases linearly. We see that the entire overhead of the multicast network between the LMAs through the proposed pMAG and nMAG tunneling is the lowest.

Fig. 13.Overhead of the entire network depending on the increase in the number of CNs.

 

5. Conclusion

In order to effectively support an MN joining and leaving a multicast group, a group management protocol is necessary; thus, group management protocols such as the MLD protocol, Internet group management protocol (IGMP), and others should be expanded for conformance to wireless and mobile environments. In order to enable multicast communication in PMIPv6, multicast packets should be forwarded to the MN that belongs to the multicast group through the LMA and MAG; therefore, the LMA shall support the multicast routing protocol. Further, the MAG should manage the multicast group membership status of the MN that accesses itself; thus, the MAG should support group management protocols such as the MLD or IGMP. As the MN shifts from an MAG to another MAG, it should support seamless and fast handoff and a technique to support multicast session continuity, and the prevention of multicast packet loss should be provided. Therefore, this study proposed a technique that commands an nMAG to perform buffering after the binding and group joining procedures when it senses the detachment of an MN. Further, the proposed technique notifies the network in advance and prevents data loss in the multicast service while the MN is detached from the link. Moreover, a performance evaluation that compares the proposed technique and PMIPv6 multicast network method proposed by the IETF was conducted.

We proposed a mathematical model that includes the delay time and the overhead of the entire network in each scheme according to the multicast network handoff procedures. We also performed evaluations on the basis of the mathematical modeling. Although the methods of transferring multicast data via tunneling between the LMAs and between MAGs in the existing handoff method between LMA domains have been studied, the proposed method reduces the signaling cost of the network and can use seamless multicast service by performing proxy binding updates in advance with a Pre-PBU signaling message, even for the tunneling method between MAGs before the MN is transferred to the nLMA. The analytical results demonstrate that the proposed multicast network exhibits a lower delay time and overhead than the proposed PMIPv6 multicast network from the IETF. We also find that the multicast network is more effective, via the proposed MAG-MAG tunneling. Moreover, this paper provides more reliable information because of the performance analysis that changes various parameters.