Abstract
Proxy Mobile IPv6 (PMIPv6) is proposed as a promising network-based mobility management protocol, which does not need any participation of mobile nodes. PMIPv6 does not support the multicast well and most of the current research concentrates on the mobile multicast receiver. However, the mobile multicast sender is also very important and challenging, which has not been addressed well. Therefore, in this paper we propose two efficient PMIPv6 based mobile multicast sender support schemes which are PMIP bidirectional tunneling (PMIP-BT) and PMIP direct routing (PMIP-DR). In the PMIP-BT, the multicast traffic can be delivered through the PMIPv6 bidirectional tunnel, while, in the PMIP-DR, the multicast data can be transmitted via an optimized direct multicast routing. Both of them can support the multicast sender mobility transparently enabled in the PMIPv6 networks. We evaluate the performance of the proposed schemes by theoretical analysis, and the numerical results show that the proposed schemes have a better performance in terms of the signaling cost than the current schemes. Meanwhile, the proposed schemes are also implemented on the test bed, and the experimental results not only verify the validity and feasibility of our proposed schemes, but also conclude the different scenarios to which they are applicable.
1. Introduction
With the development of the wireless and mobile communication technology, the mobile Internet has been popular and become the focus of the development of information and communication industry [1–3]. As an extension of mobile Internet, mobile multicast has become a research hotspot, such as [4, 5], and has drawn significant attention over a decade [6]. Until now, a variety of solutions have been proposed, but most of them are based on the host-based mobility approach [6, 7], such as Mobile IPv6 (MIPv6) [8]. Besides, it is pointed out that the performance of mobile multicast depends upon that of mobility management protocols [6]. As a network-based mobility support protocol, Proxy Mobile IPv6 (PMIPv6) [9] has a smaller handover delay and higher quality of service (QoS) than the host-based mobility solutions and does not require any participation of mobile nodes (MNs) in mobility-related signaling. Therefore, PMIPv6 is believed to be one of the promising solutions for the future all-IP wireless network [10] and is adopted in the 3GPP (3rd Generation Partnership Project) LTE (Long Term Evolution) and SAE (System Architecture Evolution) architecture [11]. However, the basic PMIPv6 does not provide the multicast communication schemes. As a result, a new development boom for IP mobile multicast based on PMIPv6 has been launched.
At the same time, the mobile multicast technology generally focuses on the multicast receiver mobility [12] and the Internet community has made great efforts to support mobile receivers in multicast sessions [7]. Comparing with the multicast receiver mobility, there is less interest in mobile multicast senders. However, the area of the multicast sender mobility has been accompanied by the development of mobile multicast [7], and this issue is highly critical for the deployment of the multicast service. For example, there is an advanced concept based on the Intelligent Transport Systems (ITS) service. In this concept, all the vehicles on the same route are identified by using a GPS or a car-navigation system. The vehicles multicast real-time video information about the transportation through the communication infrastructure like 3G, WiFi to the other vehicles interested in it [13]. Besides, in the mobile social network services especially the user generated content (UGC) services [14], most users want to publish their contents at anytime and anywhere and many users want to acquire these contents, so it is important to provide the mobility support to meet the requirements for large number of users. The multicast sender mobility is one of the core supporting schemes to realize the above functions.
In addition, due to the fact that the mobility of the multicast receivers only affects the reception of data for the node itself and the multicast sender mobility directly results in the failure of the entire multicast tree, the processing of the sender mobility will be more complex than the receiver mobility [6]. Until now, the mobile multicast for mobile receiver based on PMIPv6 has been published as RFC6224 in IETF [4]; however, the multicast sender mobility is still in the early stage [5]. Even though the IETF MULTIMOB working group [5] and Wang et al. [15] have proposed methods for multicast sender mobility in PMIPv6 networks, they all need the additional multicast listener discovery (MLD) proxy functions [16] and have the inefficient routing issue. Therefore, efficient multicast sender mobility schemes for PMIPv6 are needed urgently.
In this paper, we make some extensions of the PMIPv6 protocol to support the multicast communication in PMIPv6 networks and propose PMIP bidirectional tunneling (PMIP-BT) and PMIP direct routing (PMIP-DR) as two efficient PMIPv6 based mobile multicast sender support schemes. The PMIP-BT scheme supports the multicast data transmitted through the PMIPv6 bidirectional tunnel, while the PMIP-DR mechanism delivers the multicast packets through a direct multicast routing. Both of them can enable the multicast sender mobility transparently in the PMIPv6 networks and can solve the inefficient routing issue existing in [5, 15]. The performance evaluation is performed by the theoretical analysis, and the numerical results show that our proposed schemes significantly decrease the signaling cost. In addition, we implement the proposed schemes in the test-bed, which verifies their validity and feasibility. Furthermore, from the experimental results, we can obtain that the proposed two schemes are suited for distinct scenarios.
The remainder of this paper is organized as follows: Section 2 briefly reviews the related work. Section 3 describes the proposed PMIP-BT and PMIP-DR schemes in detail. Section 4 presents the performance evaluation and the numerical results in terms of signaling costs. Section 5 presents the implementation overview and the experimental results on the performance of multicast handover latency. Section 6 concludes the paper.
2. Related Work
Till now, a variety of mobile multicast mechanisms have been raised, in which most schemes commit to solve the multicast receiver mobility problem. Therefore, we mainly focus on the schemes for the multicast sender mobility support. There are two types of mobility support protocols proposed by the IETF, which are host-based and network-based mobility management architectures. Thus, current mobile multicast sender technologies are divided into the host-based and network-based categories in analogy, which is shown in Table 1. From Table 1, we can conclude that current mobile multicast sender supporting schemes mostly are based on MIPv6 and there are few technologies based on PMIPv6.
In the host-based mobility management architecture, the issue of multicast sender mobility has been widely recognized and studied. A variety of solutions have been proposed for mobile multicast sender support, which mainly followed the basic method for mobile multicast receivers, that is, mobile IP bidirectional tunneling approach (MIP-BT) and mobile IP remote subscription approach (MIP-RS) [8, 17]. In addition, there are also some extension methods, such as MRP [18] and MSSMS [19].
In [8, 17], two essential host-based multicast mobility approaches, which are MIP-BT and MIP-RS, are proposed. However, lots of disadvantages still exist in both of the schemes, such as the triangle routing issue [24] in the MIP-BT mechanism and higher handover delay and “out-of-synch” problem [25] in the MIP-RS scheme. Therefore, many researches such as MoM [26] and RBMoM [27] focused on solving the problem existing in the two basic approaches to improve the overall performance. Besides, there are also some extension methods proposed for the mobile multicast sender support, including tree morphing approach [20] and state update mechanism [21].
In [20], a tree morphing protocol for multicast sender mobility is proposed, in which the existing source-based distribution trees are reused and modified to continuously serve for the multicast data delivery of mobile senders. In this scheme, all nodes can identify (CoA,G) based tree topology and (HoA,G) based group membership by maintaining (CoA,G,HoA) address-triples in router states. Therefore, it is required that all the routers need to be extended, which not only increases the complexity but also introduces an expensive signaling overheads and state refresh costs. In addition, it is a host-based scheme and then will inherit all the disadvantages of MIPv6.
In [21], the authors introduced a state update mechanism which reuses the major parts of prior established multicast trees. However, the reconstruction of the multicast tree in this scheme is initiated by the multicast sender instead of the multicast receiver, which needs lots of changes for multicast.
In [18], the case that an MN is working as a sender and simultaneously a receiver for the multicast group is considered. In this mechanism, a combination of the MIP-BT and MIP-RS scheme is adopted. For the sender, to forward the multicast traffic, a reverse tunnel from the MN’s current point of attachment to its home agent (HA) is utilized. For the receiver, to receive the multicast data, the MIP-RS scheme is used. A multicast join message as well as a notification message from the sender to its HA or foreign agent (FA) is needed, which indicates that higher requirements will be needed for the hosts and the bandwidth resources as well as signaling costs will increase.
In [22], the authors introduced a scheme that is an extension to the MLD multicast protocol, in which a new entity called MDA (multicast delivery agent) is added. In this scheme, the tunnel is established between the MDA and the HA. Thus, the multicast traffic originated from the sender is transmitted to the HA through the MDA. Due to the fact that the route of this scheme is more optimized than that of the MIP-BT scheme and the delay of the tree reestablishment is lower than that of the MIP-RS scheme, it is a compromise of the MIP-BT scheme and the MIP-RS scheme. However, the signaling interaction between the multicast sender and the MDA will bring extra network traffic loads. Besides, the check of the direct connection between the multicast sender and the MDA is still up in the air.
All the above schemes are host-based, which will have the deployment limitation issue. In recent years, with the release of the network-based mobility protocol in the IETF, a new development boom of IP mobile multicast has been launched [15]. The MULTIMOB working group was established by the IETF in 2009 to provide guidance of multicast support in PMIPv6 networks and the base deployment for multicast receiver mobility in PMIPv6 domains has been released as RFC6224 [4]. However, there are only a few mobile multicast sender support schemes which are based on PMIPv6 and Von Hugo et al. propose that the mobile multicast sender support in PMIPv6 networks is needed to solve in the future [28].
In [23], two PMIPv6 multicast methods, called the LMA-based (local mobility anchor-based) method and MAG-based (mobile access gateway-based) method, are proposed. However, our experiments verify the infeasibility of the two methods. For the LMA-based method, it is infeasible that the source address of the report message sent by the multicast receiver is a globally routable address, because it is specified in RFC3810 [29] that the source address of the report message should be link address. Besides, the multicast packets sent by the multicast sender can not be transmitted to the PMIPv6 bidirectional tunnel; that is due to the fact that PMIPv6 specification does not provide the multicast communication scheme. For the MAG-based approach, the join message from the multicast receivers can not be directly delivered to the MAG, since the topological anchor of the MN in PMIPv6 networks is the LMA and thereby the join message will not be sent to the MAG but the LMA.
In [5, 15], two multicast sender mobility schemes for PMIPv6 are proposed, which are the BS (base solution) and the DMRS (direct multicast routing scheme). The BS can support the multicast data delivered to the receivers through the PMIPv6 tunnel firstly, while the DMRS can provide a direct optimized routing for the multicast traffic. The two proposed schemes can not only provide multicast communications but also support the multicast sender mobility in PMIPv6 networks. However, the additional MLD Proxy functions [16] are needed for these schemes, which increases the complexity. Meanwhile, there is inefficient routing issue in the BS.
3. Efficient PMIPv6 Based Mobile Multicast Sender Support Schemes Design
3.1. Design Goals
According to the goals for PMIPv6 described in [30] and the various problems existing in the host-based multicast sender mobility schemes, we firstly overview the design goals for PMIPv6 based multicast sender mobility schemes.
First of all, we must follow the principle of PMIPv6 that is supporting unmodified MN, which makes PMIPv6 avoid the deployment issue in MIPv6. In this way, when MN moves from one MAG to another MAG, the MN does not need any modification, which indicates that the MN always remains agnostic of multicast mobility operations and the handover is transparency to the mobile sender MN.
Secondly, the handover performance must be improved, such as multicast handover delay and packet loss. The reason is that the mobility of a multicast sender will result in the failure of the entire multicast tree [6]. Therefore, the multicast handover delay should be minimized under the movement of a multicast sender.
Last but not least, the routing inefficiency problem illustrated in [5] must be solved to enhance the multicast routing performance. We must achieve the multicast services at the least cost of the network resources, which can meet the requirements of low power for smart city in the future.
3.2. Design and Function Implementation
According to the forwarding rules described in RFC5213, when an MAG receives packets from an MN connected to its access link, to a destination that is not directly connected, the packets must be forwarded to the LMA through the bidirectional tunnel established between the MAG and the LMA (MAG-LMA). Besides, it is assumed that the link between the MN and the MAG has multicast capability. However, there is no scheme for the multicast data forwarding. Thus, when the multicast traffic flows sent by the mobile sender arrive at the MAG, these packets will be simply discarded by the MAG, which has been verified by our experiments in the test-bed. The reason is that there is no multicast forwarding information base (MFIB) on the MAG.
Therefore, in order to make the multicast data be forwarded or transmitted through the MAG-LMA bidirectional tunnel in PMIPv6 network, some extensions on the PMIPv6 protocol are required. The MAG should make some extensions to establish the corresponding multicast forwarding states for the multicast data transmission through the MAG-LMA tunnel. Then, when a mobile sender MN accesses to an MAG, this MAG should not only build the PMIPv6 bidirectional tunnel and add route for the unicast data destined to or originated from the MN, but also update the multicast forwarding cache (MFC) for the multicast traffic. In this way, the PMIPv6 protocol could support the delivery of the multicast packets.
In order to support the multicast communication in PMIPv6 networks, the proxy binding update (PBU) message and proxy binding acknowledgement (PBA) message are extended, which are shown in Figures 1 and 2. From Figures 1 and 2, we can see that a one-bit “S” flag and “D” flag as well as two new mobility options are added, in which the “S” flag is a multicast sender identification flag and is used to identify whether this MN is a mobile multicast sender. When the “S” flag in the PBU and PBA message is set to “1,” the multicast group address related to the multicast session provided by the mobile multicast sender should be attached in the multicast group address option. Besides, the “S” flag in the PBA message is set to “1” only if the corresponding PBU message has the “S” flag set to “1.” A one-bit “D” flag is used to identify whether the MAG has the ability to support the direct routing for multicast data. When the “D” flag in the PBA message is set to “1” as the same value in the PBU message, the MAG will not deliver the multicast packets to the PMIPv6 tunnel but directly send them to the multicast domain. However, when the “D” flag in the PBA message is set to “0” but its value in the PBU message is “1,” the direct routing for multicast data is not allowed by the LMA. Since one multicast packet transmission path is through the PMIPv6 bidirectional tunnel, we call the scheme PMIP-BT, while since the other path for the multicast data is direct routing, this mechanism is denoted as PMIP-DR for simplicity, which will be described in detail in the following sections.
3.2.1. PMIP-BT Scheme
Figure 3 shows the detailed procedure of the mobile multicast sender’s attachment and multicast communication in PMIP-BT scheme. As illustrated in Figure 3, when a mobile sender MN connects to an MAG, the MAG detects the attachment of the MN firstly and then obtains some information from the policy profile, including the MN-identifier (MN_ID), multicast group address, and the LMA address. Then an extended proxy binding update (PBU) message with both the “S” flag and the “D” flag set to value of 1 is sent to the LMA. Receiving this extended PBU message, the LMA decides whether this MN is authorized to send multicast data for the group address in the multicast group address option. If the MN is certified, the LMA sends back an extended proxy binding acknowledgement (PBA) message with the “S” flag set to “1,” “D” flag set to “0,” and the home network prefix (HNP) assigning for the MN to the MAG. Afterwards, the tunnel is established in the LMA. On receiving the PBA message, the MAG establishes its endpoint of the bidirectional tunnel to the LMA and also sets up the forwarding routes for the MN’s unicast traffic. At the same time, the MAG also updates the MFC in the kernel for supporting the multicast communication. After that, the MAG sends router advertisement (RA) message to the MN on the access link for advertising the MN’s HNP as the hosted on-link prefix. In this way, when the MAG receives a multicast packet from a mobile sender MN connected to its access link, to a multicast destination that has been authorized by the LMA, the MAG will forward this packet to the LMA through the bidirectional tunnel established between itself and the LMA, which is just the same as the unicast data transmission specified in RFC5213.
When the mobile multicast sender hands over from one MAG to another, it can continue to send multicast data as soon as the network connectivity is reconfigured. At this time, the new MAG performs the binding registration to the LMA and updates the corresponding unicast routes and MFCs for the mobile multicast sender. In this way, the multicast packets arriving at this new MAG will be forwarded again to the LMA according to the MFC and eventually to the receivers.
The detailed handover process is illustrated in Figure 4, in which MN1 is the mobile multicast sender and the MN2 and correspondent nodes (CNs) are both the multicast receivers. Besides, the MN2 attaches to the same MAG (MAG1) with the mobile sender MN1 but associates with a different LMA (LMA2). For simplicity, we abbreviate the “MLD Membership Report” as “Join” in Figure 4. As shown in Figure 4, when the MN1 accesses to the MAG1, the multicast packets could be transmitted to the CN through the PMIPv6 tunnel and directly sent to the MN2 via the MFC at the MAG1. When the MN1 moves to the MAG2, as soon as the binding registration to the LMA1 and the establishment of multicast forwarding states for the MN1 at the MAG2 has been completed and also the IP address of the MN1 has been configured, the multicast data could be successfully delivered by the MAG2 to the LMA1 and eventually to the receivers CN and MN2. Therefore, the multicast sender mobility is transparently enabled in the PMIPv6 networks.
3.2.2. PMIP-DR Scheme
Figure 5 illustrates the detailed procedure of the mobile multicast sender’s attachment and multicast communication in PMIP-DR scheme. Compared with Figure 3, the difference of the attachment for the mobile sender is the “D” flag in PBA message. As shown in Figure 5, the value of the “D” flag in the extended PBA message is “1” in this scheme, while the value is set to “0” in PMIP-BT scheme. That means the direct routing for the multicast data transmission will be adopted. After the PMIPv6 registration of the mobile sender, the sender begins to send multicast data to the MAG. The receiver CN sends join message to the sender and finally arrives at the MAG which is the designated router (DR) of the multicast sender. At this time, the MAG establishes the multicast forwarding states for the CN. Then, the multicast data is delivered to the CN through a direct routing from the MAG.
When the mobile multicast sender moves from one MAG to another, it can continue to send multicast traffic once the PMIPv6 registrations have been successfully completed. At this time, the new MAG will act as the new DR for the mobile multicast sender and establish the multicast forwarding states for all the receivers who subscribe to the multicast service provided by the mobile sender. In this way, according to the MFC of the new MAG, the multicast packets arriving at this new MAG will be transmitted again to the multicast domain via a direct routing and eventually to the receivers.
The detailed handover process is shown in Figure 6. Similar to Figure 4, the MN1 is the mobile multicast sender, while both MN2 and CN are the multicast receivers. Additionally, the MN2 attaches to the same MAG (MAG1) with the MN1 but associates with a different LMA (LMA2). Also, “MLD Membership Report” is abbreviated as “Join” for simplicity in Figure 6. As shown in Figure 6, when the MN1 accesses to the MAG1, the multicast data could be directly delivered to the CN and the MN2 by the MAG1 via the MFC. When the MN1 hands over to the MAG2, after the completion of the binding registration for the MN1 and the establishment of multicast forwarding states at the MAG2 for the receivers, the multicast data could be successfully transmitted by the MAG2 to the receivers CN and MN2 through a direct routing. Thus, the multicast sender mobility is also transparently enabled in the PMIPv6 networks by this scheme.
3.2.3. Operations of the MN
There are not any additional functionalities or modifications required for the MN, which meets one of the design goals for this scheme. Therefore, an MN serving as a mobile multicast source will send multicast data as if attached to the fixed Internet.
3.2.4. Operations of the MAG
In order to provide the multicast service in PMIPv6 networks, the MAG must recognize the MN attached to it is a multicast sender firstly. Then, the corresponding multicast group address of which the multicast sender MN provides multicast service must also be learned. The MAG can learn these pieces of information during the authentication phase for example. Therefore, the PBU message should be extended, including the multicast sender identification flag “S”, direct routing identification flag “D”, multicast group address option, and multicast sender address option. Figures 7 and 8 show the format of these two mobility options. When the MAG finds that the attached MN is a multicast sender, it should send the extended PBU message to the LMA. In the extended PBU message, a one-bit “S” flag is set to “1” and the multicast group address is contained in the multicast group address option. Besides, a one-bit “D” flag indicates whether the MAG supports the direct routing scheme. When the MAG receives the extended PBA message with the “D” flag set to “1,” it will forward the multicast data through a direct multicast routing. Otherwise, the multicast service must be provided via the PMIPv6 bidirectional tunnel.
In PMIP-BT scheme, on the arrival of a mobile multicast sender MN, the MAG should not only set up the unicast route for the MN, but also establish the multicast forwarding state and update the MFC for the MN. Besides, the establishment of the multicast forwarding states for the receivers is required for a MAG in PMIP-DR scheme. Thus, the MAG should participate in multicast routing functions, such as Protocol Independent Multicast-Sparse Mode (PIM-SM). Besides, the MAG serves as the DR of the multicast sender MN. According to RFC4601 [31], it is required that the DRs should directly connect with the senders. However, the LMA, not the MAG, advertises the HNP of the mobile sender to the network in PMIPv6 networks. Therefore, to address this issue, the MAGs should be set as PIM border routers and the border-bit should be activated, or the MAGs run the Bidirectional Protocol Independent Multicast (BIDIR-PIM) [15, 32].
3.2.5. Operations of the LMA
Similar to the extensions of the PBU message, the PBA message should also add the “S” flag, “D” flag, multicast group address option, and multicast sender address option. If the LMA receives the extended PBU message with “S” flag and “D” flag set to value of “1,” it should judge whether the MAG could adopt the direct multicast routing scheme and indicate this to the MAG by the extended PBA message with the “D” flag. However, if the “D” flag is set to “0” in the extended PBU message, the LMA will set the “D” flag to value “0” in the extended PBA message.
In PMIP-BT scheme, as the persistent HA and the DR of the multicast sender MN, the LMA should not only establish a tunnel to the MAG and update the unicast route table for the MN, but also manage and maintain a MFIB for all group traffic arriving from its mobile senders. At the same time, the LMA should participate in multicast routing functions, such as PIM-SM, that enable traffic redistribution to all adjacent routers and thereby ensure a continuous session when the multicast sender is in motion. As described above, the DRs require the senders to be directly connected with itself based on RFC4601 [31]. However, since the MAGs are routers intermediate to the multicast senders (MNs) and the LMAs who are serving as DRs of the MNs in PMIPv6 domain, there exists the check of direct connection issue specified in [15]. Therefore, to address this issue, the LMAs should be set as PIM border routers and the border-bit should be activated, or the LMAs run the BIDIR-PIM [15, 32].
4. Performance Evaluation
This section evaluates the performance of the two proposed multicast sender mobility schemes which are PMIP-BT and PMIP-DR. In the analysis, we compare our schemes with HMIP bidirectional tunneling (HMIP-BT) and HMIP remote subscription (HMIP-RS) [8] and mainly concern on the signaling cost. In this paper, we define the signaling cost as hops × signaling message size [33].
4.1. Analytical Mobility Model
In [34], a new two-dimensional hexagonal random walk model in personal communication services (PCS) system had been presented. Due to the large number of states, an improved random walk model was proposed in [35]. Given the fact that one MAP or PMIPv6 domain is usually composed of several subnets, we present a modified two-dimensional hexagonal random walk model to analyze the signaling cost.
Figure 9 shows the six-layer hexagonal analytical mobility model. In this model, each ring is labeled according to its distance from the center. The innermost cell “0” is called the center cell; the cells labeled “1” form the first ring around the center cell; the cells labeled “2” form the second ring around the center cell and so on. Each ring consists of cells. Based on this model, each cell represents an MAG or AR subnet, and a PMIPv6 domain or MAP domain includes six layers.
Figure 10 illustrates the type classification for the six-layer analytical mobility model. The subnets in a domain are classified into different types. The form is used to distinguish the different subnets, where indicates that this subnet is in ring , and indicates the st type in ring . The subnets which are at the symmetrical positions on the hexagonal domain will have same type and same traffic flow pattern.
Suppose that an MN resides in a MAG/AR subnet for a period and moves to one of its six neighbors with equal probability (1/6). Figure 11 presents the state transition diagram for the six-layer random walk model, in which state represents the MN is in one of the subnets of type and state is absorbing state, where , , and is the layers of a domain. In our presented random walk model, the numbers of states are when is odd and when is even, which significantly reduces the number of states when compared with that in [34] (). The corresponding one step state transition matrix is as follows, in which the elements are in the following order: , , , , , , , , , , , , :
In order to compute the steps state transition matrix, the Chapman-Kolmogorov equation [36] can be used. The steps state transition matrix can be derived as follows [34]:
Let represent the subnet residence time of an MN and denote the domain residence time of an MN, which are both independently and identically distributed random variables. Suppose that the density functions of and are and , respectively. In this paper, we choose Gamma distribution for the subnet residence time and the domain residence time of the MN to analyze the total number of subnet handover and domain handover and also compute the total signaling cost. The reason of the Gamma distribution is specified in [37]. The subnet residence time of the MN has Gamma distribution with mean and variance , whose Laplace-Stieltjes transform is expressed as follows:
Besides, suppose that the expected value of a call hold time is . Therefore, the probability that an MN moves across subnets in a call hold time can be calculated as follows [34]:where is the call-to-mobility ratio (CMR).
Then, the average number of subnets that the MN traverses in a call hold time can be derived as
Similarly, the probability that an MN moves across domains in a call hold time iswhere , in which can be obtained from the following equation [38]:where , is the Laplace transform of , denotes the probability that an MN moves into the domain through the type subnet at the first step, and represents the probability that an MN resides at type subnet initially, then moves to type subnet through steps, and finally moves out of the domain at the st step.
Thus, the average number of domains that an MN moves across in a call hold time can be derived as
4.2. Signaling Cost Analysis
Signaling cost contains two major components which are the signaling cost related to the mobility management and the packet transmission [39]. In our analysis, we omit the signaling cost required for authentication and for L2 handoff, because they are the same for all protocols. Therefore, the total signaling cost consists of location update signaling cost and packet delivery cost. and represent the location update cost and the packet delivery cost, respectively. Then, the total signaling cost can be expressed as follows:
4.2.1. Location Update Cost
Because an MN moves between different subnets either within a domain or out of a domain, two types of binding update will be performed, which are the intersubnet binding update and the interdomain binding update. We denote and as the signaling cost for the intersubnet binding update and the interdomain binding update, respectively. Based on the analytical mobility model specified above, the location update cost per unit time can be derived as follows:
The packet transmission cost in IP networks is proportional to the distance in hops between source and destination nodes [40]. Besides, the transmission cost in a wired link is generally lower than the transmission cost in a wireless link [41]. Let be the unit transmission cost over wired link and the weighting factor for the wireless link unit transmission cost. The signaling cost for the binding update includes the signaling transmission cost and the signaling processing cost at different entities. Besides, we also consider the route optimization (RO) case in the interdomain handover and suppose be the probability that an MN executes the RO process. Therefore, and can be derived from the following equations [15, 42]:where , , , , , and are the size of the signaling messages for the location update in PMIPv6 and MIPv6, respectively. is the hop distance between the MAG and the LMA, is the hop distance between the AR and the MAP, is the distance between the LMA and the home agent (HA), is the distance between the MAP and the HA, is the distance between the LMA and the receiver, and is the distance between the MAP and the receiver. is the number of the receivers communicating with the MN. , , , , and are the processing costs for binding update procedure at the MAG, the LMA, the HA, the MN, and the receiver, respectively.
Since the PMIP-BT and the PMIP-DR are all based on the PMIPv6 mobility protocol, the location update cost for the PMIP-BT is equal to that for the PMIP-DR; that is,
Similarly, the HMIP-BT and the HMIP-RS have an equal location update cost, which is as follows:
4.2.2. Packet Delivery Cost
The cost for packet delivery procedure can be derived as follows [41, 42]:where denotes the transmission cost of packet delivery from the mobile multicast sender to the receiver and and represent the processing cost of packet delivery at the MAG and the LMA, respectively.
The multicast packets are transmitted through the bidirectional tunnel firstly and then to the receiver based on the multicast tree in the PMIP-BT and HMIP-BT schemes, while they are delivered from the MAG/AR directly to the receiver according to the corresponding multicast states in the PMIP-DR and HMIP-RS schemes. Besides, in the PMIP-BT and HMIP-BT schemes, suppose that only the first packet of a session transits to the HA in order to detect whether or not an MN moves into foreign networks as assumed in [42], and all the successive packets are directly routed to the receiver through the MAP/LMA. Thus, the transmission cost of packet delivery from the mobile multicast sender to the receiver can be calculated as follows:where denotes the multicast session arrival rate, is the average session size in the unit of packet, is the multicast packet size, denotes the size of the extra header for the packet encapsulation, and , represent the distance of the shortest path from the AR, the HA to the receiver, respectively.
The processing cost of packet delivery includes the mapping table lookup cost () and the routing cost () [41, 42]. Therefore, the processing cost for the PMIP-BT scheme can be calculated as follows [15, 41, 42]:where is the average number of MNs located in the coverage of an MAG subnet, and are the weighting factors of the mapping table lookup and the routing table lookup, respectively. and are the length of the routing table at the MAG and the LMA, respectively.
In the PMIP-DR scheme, the MAG directly forwards the multicast packets to the multicast domain. Therefore, there is processing cost only at the MAG and the MAG has no mapping table lookup cost. Thus, the processing cost at the MAG in the PMIP-DR scheme can be derived as follows:
Similarly, we can get the the processing cost for the HMIP-BT and HMIP-RS scheme, which will not be described here.
4.3. Numerical Results
This subsection presents various analysis results based on the above analytical mobility model. Table 2 shows the parameter values for the analysis, which are referenced from [15, 41, 42].
4.3.1. Location Update Cost versus Average Cell Residence Time
Figure 12 illustrates the impact of average cell residence time on location update cost. As shown in Figure 12, all the location update costs decline with the increased average cell residence time and the costs of PMIP-BT/PMIP-DR are lower than HMIP-BT/HMIP-RS. As the longer time an MN resides in a subnet, the lower frequencies the MN hands over. Besides, HMIPv6 is a host-based mobility management protocol, while PMIPv6 is a network-based mobility scheme and thereby when the MN performs handover, the MN does not need to participate in the location update procedures in PMIPv6 networks. In addition, from Figure 12, we can see that the location update cost with a higher probability of RO is higher. The reason is that the increased signaling cost is induced due to the increased binding update process between the MN and the receiver.
4.3.2. Location Update Cost versus Call-to-Mobility Ratio (CMR)
Figure 13 presents the location update cost with the impact of call-to-mobility ratio (CMR) for intra-PMIPv6/MAP domain roaming. From Figure 13, we can get that with the increase of the CMR, all the location update costs are decreased and the PMIP-BT/PMIP-DR has a lower location update cost than HMIP-BT/HMIP-RS. Since when CMR is small, the session arrival rate is smaller than mobility rate and then an MN will perform handoffs between different subnets frequently due to its mobility, which indicates that the location update cost increases. However, when the mobility rate is lower than the session arrival rate (i.e., CMR is greater than 1), the binding update will be less often performed and the location update cost will decline due to the fact that the frequency of subnet changes decreases. Besides, Figure 13 indicates that when the probability of RO is smaller, the location update cost is lower.
4.3.3. Packet Delivery Cost versus Multicast Session Arrival Rate
Figure 14 shows the packet delivery cost as a function of the multicast session arrival rate. In Figure 14, with the increased multicast session arrival rate, all the packet delivery costs increase; that is because in this case more packets should be transmitted. Meanwhile, the packet delivery cost of PMIP-BT/PMIP-DR is lower than that of HMIP-BT/HMIP-RS, and HMIP-RS/PMIP-DR has the lowest packet delivery cost for its more optimized routing than HMIP-BT and PMIP-BT. In addition, the packet delivery cost with a higher probability of RO is lower. The reason is that a higher probability of RO indicates that more optimized path routes will be provided for these schemes.
4.3.4. Packet Delivery Cost versus Hop Distance between the AR/MAG and Receiver
Figure 15 compares the results of packet delivery cost under the hop distance between the AR/MAG and receiver. From Figure 15, we observe that all the results for the HMIP-BT and PMIP-BT keep unchanged and the packet delivery cost of the HMIP-RS/PMIP-DR increases with the increased hop distance between the AR/MAG and receiver. That is due to the fact that more optimized routing for the HMIP-RS and PMIP-DR will be brought by the shorter hop distance between the AR/MAG and receiver, and thereby less signaling cost will be required. Besides, HMIP-BT and PMIP-BT transmit multicast data via bidirectional tunnel, while HMIP-RS and PMIP-DR do not need the encapsulation overhead.
5. Experimental System Development
In this section, we implement the proposed schemes and analyze the experimental evaluation results which mainly focus on the multicast handover latency.
5.1. Implementation Overview
Figure 16 illustrates the whole implementation framework for the proposed schemes, which mainly contains two parts: PMIPv6 and PIM-SM. In our implementation, PMIPv6 is based on the MIPL2.0 (MIPv6 for Linux) [43] and the detailed PMIPv6 module is shown in Figure 16.
The PMIPv6 implementation includes the LMA, the MAG, and the AAA. The modules in the MAG consist of modules MN detection, PBU/PBA process, routing state update, BULE maintenance and establish multicast forwarding state and router advertisement. The MN detection module monitors the MN attachment and detachment events through the link layer technologies (the syslog function is used in our implementation). The PBU/PBA process module generates and processes the mobility signaling messages including the (extended) PBU and PBA. The routing state update module sets up the tunneling routing between the LMA and the MAG. BULE maintenance module sets up and maintains the BU list in the MAG. Establishing multicast forwarding state module is extended to establish the multicast forwarding state for the multicast data originated from the MN. Router advertisement module emulates the home link by sending the home network prefix from the LMA. The modules in the LMA consist of the PBU/PBA process module similar to that of MAG, the routing state update module similar to that of MAG, BCE maintenance module, home network prefix management module, and PIM-SM module for PMIP-BT scheme. The BCE maintenance module records the BU in the LMA. The home network prefix management module allocates the IPv6 prefixes for the MNs belonging to the PMIPv6 domain. The PIM-SM module is used to update the MFC and this module is only needed in the PMIP-BT scheme. Besides, the AAA module is used to authenticate the MN, which is implemented in the MAG in our implementation.
PIM-SM routing protocol design is divided into two parts, which are kernel space and user space. The kernel space is responsible for the multicast packets forwarding. When the multicast router receives the multicast packets, it can forward those data according to the multicast routing information stored in the MFC. And the user space is in charge of establishing multicast route table (MRT) and updating the MFC in kernel. The PIM-SM system model is shown in Figure 17, where the functional modules of the user space include modules MRT, inner control message process, PIM and MLD protocol message process, timer, virtual interface, and kernel interface, while the kernel space includes PIM message process module, multicast packets process module, and support user space set socket option module. The user space modifies and updates the MRT based on the process results and also reflects the relevant changes to the kernel space via the system call.
Figure 16 also shows the detailed operation flow of PMIPv6 based mobile multicast sender support scheme, which will be described as follows. When a multicast sender MN attaches to the layer 2 equipment (Cisco 1200 AP) (1), the attachment event is firstly detected and then notified to the MAG by the equipment (2). Thus, the layer 2 address of the MN is derived by the MAG from the notified message. Meanwhile, the MAG acquires the MN-identifier and policy profile from the policy server, in which the profile is stored in the local store for simplicity in our implementation (3). After the MAG gets the MN-identifier and AAA information, it sends the extended PBU message with both the “S” flag and the “D” flag set to value of 1 to the LMA (4). After receiving this extended PBU message from the MAG, the LMA not only updates the unicast routing states and the multicast forwarding states, but also maintains the binding caches (5). Then, the LMA judges whether the MAG could adopt the direct multicast routing scheme and indicate this to the MAG by the extended PBA message with the “D” flag (6). Just like the LMA, the MAG receiving the extended PBA message not only performs the PBU/PBA module to maintain the binding update lists and update the unicast routing states, but also establishes the multicast forwarding states for the MN (7). After that, the MAG advertises the HNP to the MN by sending the router advertisement (RA) message (8), and then the MN configures its address (9). Acting as a multicast sender, the MN begins to send multicast data to the MAG (10). Then the MAG forwards the multicast packets either to the LMA through the PMIPv6 bidirectional tunnel or directly to the multicast domain (11).
5.2. Experimental Setup
In order to analyze the two proposed schemes in detail, we set up two experimental test-bed topologies which are illustrated in Figure 18. The main difference between Figures 18(a) and 18(b) is the distance between the MAG/LMA and the multicast domain. In Figure 18, there are one multicast sender MN, two access points (AP), two MAGs, one LMA, one RP, one DR, two Routers, and three multicast receivers. The multicast sender MN provides multicast video services by running VLC (VideoLAN Client) media player. The MAG and the LMA run extended PMIPv6 protocol and PIM-SM protocol. Routing Information Protocol (RIP), RIP next generation (RIPng), and PIM-SM routing protocols are performed on all the other routers in the test-bed. Table 3 presents the experimental configuration parameters.
(a)
(b)
In order to evaluate the performance in different environments, we set up different test scenarios and perform three kinds of experiments. The first and the second experimental scenarios are both based on the topology in Figure 18(a), while the first scenario does not introduce any additional delay and the second scenario uses the WANem to introduce transmission delay and packet loss among the LMA and the RP in order to emulate the wide area networks. The third scenario uses the WANem to set up one case that the MAG is near to the multicast domain and the LMA is far away from the multicast domain, which is based on the topology in Figure 18(b) and is different from the former scenarios.
5.3. Experimental Results
We use the VLC media player to provide multicast data for a certain group and test the intra-PMIPv6 domain handover performance for both the PMIP-BT and the PMIP-DR schemes. Figure 19 presents the experimental results in terms of the multicast handover latency of the PMIP-BT and the PMIP-DR schemes for 20 times handovers.
(a) Scenario 1
(b) Scenario 2
(c) Scenario 3
Figures 19(a) and 19(b) display the multicast handover latency in Scenarios 1 and 2, respectively. In Figures 19(a) and 19(b), we can see that PMIP-BT has a lower latency than PMIP-DR. The reason is that the path route from the multicast sender to the receiver is the same for these two proposed schemes; that is, the data transmission of the PMIP-DR scheme must also pass through the LMA. In this case, the advantage of the optimized multicast routing for the PMIP-DR scheme is not represented and that of the unchanged DR for the PMIP-BT scheme is good at the improvement of the handover performance. Since the DR in the PMIP-DR scheme changes from the previous MAG to the new MAG whenever the multicast sender handovers, whereas the LMA acting as the DR keeps unchanged in the PMIP-BT scheme, thereby the multicast tree from the DR to the RP needs to be reconstructed for the PMIP-DR scheme but need not for the PMIP-BT scheme. Therefore, we can conclude that the PMIP-DR scheme is suitable for the lower multicast sender handover frequency scenarios, while the PMIP-BT scheme is suitable for the higher multicast sender handover frequency scenarios. Besides, we can see that the average multicast handover latency for both the PMIP-BT and PMIP-DR scheme in Scenario 1 is larger than that in Scenario 2, because Scenario 2 has more transmission delay than Scenario 1.
However, it can be seen from Figure 19(c) that PMIP-DR has a lower latency than PMIP-BT. That is due to the fact that the LMA is far away from the multicast domain and the MAG is near to the multicast domain in this scenario. Thus, the PMIP-DR scheme can transmit the multicast data through a direct multicast routing, which is a much more optimized path route than the PMIP-BT scheme. Based on the experimental results, we can get that the PMIP-DR scheme is suitable for the more optimized routing from the MAG/AR to the multicast domain scenarios, whereas the PMIPv6-BT scheme is suitable for the less optimized routing scenarios.
6. Conclusion
In this paper, PMIP-BT and PMIP-DR are proposed to support the multicast sender mobility in PMIPv6 networks efficiently. The PMIP-BT scheme inherits the transmission path of the unicast data in PMIPv6 domain, in which the multicast data must be transmitted through the PMIPv6 tunnel. However, the PMIP-DR scheme can provide a local optimized multicast routing, but the multicast tree needs to be reestablished whenever the multicast sender moves. Therefore, they are suited for the different application scenarios. We not only evaluate the proposed schemes’ performance in terms of signaling cost by numerical analysis, but also analyze their performance of multicast handover latency via implementation and practical tests. The theoretical results and experimental results show that our proposed schemes are feasible and outperform the current schemes. Meanwhile, the evaluation experiments also indicate that the PMIP-BT scheme is suitable for the higher multicast sender handover frequency and less optimized routing from the MAG/AR to the multicast domain circumstances, while the PMIP-DR scheme is suitable for the lower multicast sender handover frequency and more optimized routing scenarios.
As part of future work, we plan to expand our current simple test-bed to a complex experimental scenario to further verify the feasibility and validity of our proposed schemes. Besides, we will set up the simulations to get a more comprehensive performance evaluation for the schemes proposed in this paper. Moreover, we will also study the combination of PMIP-BT and PMIP-DR under practical circumstances and continue to deeply study on this PMIPv6 based mobile multicast sender support issue to obtain a much more better handover performance.
Conflict of Interests
The authors declare that there is no conflict of interests regarding the publication of this paper.
Acknowledgment
This work is supported by the National Basic Research Program of China (973 program) under Grant no. 2013CB329101, the National Key Technology R&D Program under Grant no. 2012BAH06B01, the National Natural Science Foundation of China (NSFC) under Grant no. 61271201, 61271202, 61003283, and Beijing Natural Science Foundation under Grant No. 4122060.