Multicast Extension to Proxy Mobile IPv6 for Mobile Multicast Services

  • cc icon
  • ABSTRACT

    Recently, Proxy Mobile IPv6 (PMIPv6) has received much attention as a mobility management protocol in next-generation all-IP mobile networks. While the current research related to PMIPv6 mainly focuses on providing efficient handovers for unicast-based applications, there has been relatively little interest in supporting multicast services with PMIPv6. To provide support for multicast services with PMIPv6, there are two alternative approaches called Mobile Access Gateway (MAG)-based subscription and Local Mobility Anchor (LMA)-based subscription. However, MAG-based subscription causes a large overhead for multicast joining and LMA-based subscription provides non-optimal multicast routing paths. The two approaches may also cause a high packet loss rate. In this paper, we propose an efficient PMIPv6-based multicast protocol that aims to provide an optimal delivery path for multicast data and to reduce handover delay and packet loss rate. Through simulation studies, we found that the proposed protocol outperforms existing multicast solutions for PMIPv6 in terms of end-to-end delay, service disruption period, and the number of lost packets during handovers.


  • KEYWORD

    Proxy Mobile IPv6 , Mobile IP Multicast , Fast handover

  • I. INTRODUCTION

    To provide seamless mobility to mobile users, various mobil-ity management schemes have been proposed. Mobile IPv6 (MIPv6) [1] is one of the most widely known IP mobility sup-port protocols, which solves many of the problems encountered in Mobile IPv4 such as triangle routing, security, and limited IP address space. However, MIPv6 and its enhancements such as Fast Handovers for Mobile IPv6 (FMIPv6) and Hierarchical Mobile IPv6 (HMIPv6) basically require protocol stack modifi-cations of mobile nodes, and thus they have not achieved wide market penetration. To bypass the need to modify protocol stacks, Internet Engineering Task Force (IETF) has proposed Proxy Mobile IPv6 (PMIPv6) [2]. In PMIPv6, network entities perform mobility management on behalf of mobile nodes, and thus mobile nodes are not required to participate in any mobil-ity-related signaling.

    With these improvements, which support mobility in the IP layer, the demand for multimedia group communications such as mobile Internet Protocol Television (IPTV) and video confer-encing has also increased. To support efficient multimedia group communications in mobile networking environments, many studies have sought to combine IP multicast with mobility management protocols. In particular, MIPv4 and MIPv6 pro-vide two basic approaches for supporting multicast services to mobile nodes: foreign agent-based multicast (remote-subscrip-tion) and home agent-based multicast (bi-directional tunneling) [3]. Moreover, based on these two approaches, several mobile multicast protocols such as Mobile Multicast (MoM) [4], Multi-cast by Multicast Agent (MMA) [5], Range-based Mobile Mul-ticast (RBMoM) [6], and Timer-based Mobile Multicast (TBMoM) [7] have been proposed. However, since these mobile multicast protocols are designed for MIPv4 or MIPv6, and thus require mobile nodes to participate in message signaling, they cannot be applied directly to PMIPv6.

    Recently, there have been several attempts to support multi-cast services in PMIPv6 [8-10]. These are based on two alterna-tive approaches, referred to as Mobile Access Gateway (MAG)-based subscription and Local Mobility Anchor (LMA)-based subscription. In MAG-based subscription, when a Mobile Node (MN) connects to a new MAG that has not yet joined the multi-cast group, the MAG performs multicast tree joining. MAG-based subscription can provide an optimal multicast routing path to the MN, but it causes a large overhead for multicast join-ing. On the other hand, LMA-based subscription has a smaller joining overhead, since the LMA, which manages multiple MAGs, joins multicast groups instead of MAGs. However, this approach results in non-optimal multicast routing paths, since multicast data is always delivered through the LMA even though there is a shorter path.

    In this paper, we propose an efficient multicast solution for PMIPv6. The proposed protocol aims to provide an optimal routing path for multicast data and to reduce packet loss and the service disruption period during handovers. To this end, in the proposed protocol, a MAG joins a multicast group and initiates a handover in advance. To evaluate the performance of the pro-posed protocol, we performed simulations using the network simulator (NS)-2. According to the performance study results, compared to LMA- and MAG-based subscriptions, the pro-posed protocol provides a shorter service disruption period and lower end-to-end delay by using an optimal routing path and it reduces the number of lost packets during the MN’s handover.

    II. BACKGROUND AND RELATED WORK

    In this section, we briefly describe PMIPv6 and existing mul-ticast protocols for PMIPv6.

      >  A. Proxy Mobile IPv6

    PMIPv6 is designed to provide network-based mobility man-agement support to MNs in a topologically localized domain. In PMIPv6, an MN is not required to participate in any mobility-related signaling, and proxy entities in PMIPv6 (i.e., LMAs and

    MAGs) perform all mobility-related signaling on behalf of MNs. Fig. 1 shows the system architecture of PMIPv6. The role of the LMA is similar to that of the Home Agent (HA) in MIPv6. A MAG detects an MN’s movement and processes mobility-related signaling with the MN’s LMA on behalf of the MN. The MAG establishes a bi-directional tunnel with the LMA for each MN, and emulates the MN’s home network on the access network.

    The basic mechanism of PMIPv6 is as follows. When an MN is connected to a new MAG, access authentication is performed using MN-Identification (MN-ID). After the MAG obtains the MN’s profile, it sends a Proxy Binding Update (PBU) message including the MN-ID to the MN’s LMA on behalf of the MN. When the LMA receives the PBU message, it sends a request to the Authentication, Authorization and Accounting (AAA) server to check whether or not the sender of the PBU message is an authorized host. If the sender is an authorized MAG, the LMA accepts the PBU message and responds to it with a Proxy Binding Acknowledgment (PBAck) message including the MN’s home network prefix option. Finally, the LMA establishes a route for the MN to the MAG over the bi-directional tunnel.

      >  B. Multicast Protocols for PMIPv6

    Several multicast protocols based on PMIPv6 have been pro-posed [8-10]. As mentioned in Section I, they are categorized as LMA- and MAG-based subscription protocols. Figs. 2 and 3 show the respective flows of MAG- and LMA-based subscription.

    In MAG-based subscription, MAGs work as multicast rout-ers and join a multicast tree by using IP multicast routing proto-cols such as DVMRP, MOSPF, and PIM. As shown in Fig. 3, before an MN performs a handover, the previous MAG (pMAG) that joined a multicast group for the MN forwards multicast data packets to it. When new MAG (nMAG) detects that the MN has established a connection with itself, the LMA and nMAG exchange binding update and binding acknowledgement messages, and then the nMAG joins the multicast group for the MN. During the joining and binding update period, the MN can-not receive multicast data packets. After joining, the nMAG for-wards multicast data packets to the MN.

    In LMA-based subscription, the LMA works as a multicast router and joins a multicast tree instead of MAGs. When an MN's handover occurs, it performs the binding update in the same manner as MAG-based subscription. After the binding update, a tunnel between the LMA and nMAG is established and the MN receives multicast data through it. In LMA-based subscription, joining at each MAG is not required and thus the MN’s service disruption period is shorter than MAG-based sub-scription. However, since all multicast packets are forwarded by the LMA, the optimal routing path from a multicast source to an MN may not be provided. Simulation results in [8] show that LMA-based subscription usually provides better performance, since the latency for multicast joining is quite large.

    In [9], the authors introduce a hybrid method that uses both MAG- and LMA-based subscriptions. In this method, both the MAG and LMA always join the multicast group. The MAG selects the first packet to be delivered by using one of the two alterna-tive subscription methods and drops the other one. A severe problem with this method is packet duplication at the MAG.

    III. PROPOSED PROTOCOL

    In this section, we propose an efficient handover protocol for

    multicast subscribers in the PMIPv6 domain. The design goals of the proposed protocol are as follows. First, protocols should show low end-to-end delay, as with MAG-based subscription, which uses the optimal path. To achieve this goal, the MAG joins a multicast group in advance so that multicast packets can be delivered through the MAG. This reduces the end-to-end delay of multicast data and thus the proposed protocol has lower end-to-end delay than LMA-based subscription. Second, with MAG-based subscription, multicast packets are delivered through the optimal path from the source to an MN. However, the MAG needs to join a multicast group whenever a new MN connects to it, which causes a long handover disruption period and high packet loss rate. LMA-based subscription has a shorter service disruption period, but it cannot completely eliminate multicast data losses during handovers. The proposed protocol aims to achieve a shorter service disruption period than LMA-based subscription and to minimize packet losses during handovers.

    Before we describe the operation of the proposed protocol in detail, we first define a new mobility option called the multicast option. The multicast option is included in the mobility option field of Handover Initiation (HI) messages. Fig. 4 illustrates the format of the multicast option. As shown in the figure, the mul-ticast options include an 8-bit type field, an 8-bit length field, a 16-bit reserved field, and a field for multicast group addresses. The type field represents the type of mobility option. The length field contains an 8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields. This field must be set to 16n+2, where n is number of addresses in the multicast addresses field. The multicast addresses field is filled with the multicast group addresses to which an MN cur-rently subscribes.

    The initial attachment of MNs to the PMIPv6 domain is the same as the basic operation of the original PMIPv6. In the pro-posed protocol, after the initial attachment, an MN sends a join message to a MAG if it wants to join a specific multicast group. After receiving the join message, the MAG updates the MN's multicast information in its multicast table and joins the multi-cast group on behalf of the MN. The multicast table consists of tuples. Subsequently, the MAG for-wards multicast packets to the MN by checking the multicast table. Note that multicast packets do not pass through the LMA.

    Fig. 5 shows the flow of messages for an MN's handover in the proposed protocol. When the pMAG detects the Layer-2 (L2) trigger for an MN, the MAG sends a HI message contain-ing the MN's ID and multicast state to the MN’s nMAG. The multicast option includes the group addresses to which the MN currently subscribes, and it is attached to HI as a mobility option. The implementation of the L2 trigger depends on the specific L2 technology (e.g., IEEE 802.11, IEEE 802.16e). We assume that the L2 trigger occurs when a handover is imminent and it contains the information that helps the pMAG to acquire

    the IP address of the nMAG. After receiving the HI message, the nMAG responds to it with a Handover Acknowledge (HAck) message, which includes the MN's ID. After receiving the HAck message, a bi-directional tunnel is established between the two MAGs, and multicast data destined for the MN are tunneled to the new MAG from the previous one and buffered at the new one.

    The nMAG that receives the HI message joins the multicast group described in the HI message. After that and after the MN connects to the nMAG, the MN receives tunneled multicast data and then new multicast data is delivered via the nMAG.

    In contrast to LMA-based subscription, the proposed proto-col does not need to exchange PBU and PBAck messages after L2 handover is completed, since multicast data is directly deliv-ered via a MAG. Therefore, the proposed protocol reduces addi-tional bandwidth usage while achieving seamless multicast service during handover.

    Fig. 5 does not indicate exactly when the L2 trigger occurs or how the pMAG obtains the IP address of the nMAG after receiving the L2 trigger. In order to clarify these points, we apply the proposed protocol to the IEEE 802.16e [11] and IEEE 802.11k [12] networks.

    Fig. 6a shows the operational flow of the proposed protocol applied to IEEE 802.16e networks. In the figure, MOB_NBR-ADV (Neighbor Advertisement), MOB_MSHO-REQ (Mobile Station Handover Request), and MOB_BSHO-RSP (Base Sta-tion Handover Response) are L2 messages defined in the IEEE 802.16e standard. A Base-Station (BS) broadcasts a MOB_NBR-ADV that contains information on the neighbor BS. If the MN discovers a new BS (nBS), it initiates a handover by sending a MOB_MSHO-REQ to the previous BS (pBS) and the BS responds with a MOB_BSHO-RSP. The exchange of MOB_MSHO-REQ and MOB_BSHO-RSP messages performs the role of the L2 trigger in the proposed protocol.

    The pBS notifies the pMAG of the MN’s new base-station ID (BSID) and the pMAG resolves the nMAG’s address using the new BSID. To this end, MAGs should be able to match the BSID of a BS with the IP address of the corresponding MAG. The mapping can be configured manually by the network administrator or by using an access router information resolu-tion protocol such as a Candidate Access Router Discovery (CARD) protocol [13]. After the L2 handover, the initiation

    period is completed, and the nBS triggers the nMAG to make it forward buffered packets to the MN by sending a Fast Neighbor Advertisement (FNA) to the nMAG.

    The legacy IEEE 802.11 standard does not define the L2 trig-ger operation. However, one of the extensions of the IEEE 802.11k standard extends the IEEE 802.11 operation to support the L2 trigger. We apply the proposed protocol over IEEE 802.11k networks, as shown in Fig. 6b. In IEEE 802.11k net-works, the L2 handover consists of the three steps of the L2 trigger as well as an association. Except for the L2 trigger, the remaining operations are similar to those of IEEE 802.16e. The previous AP (pAP) lets a MN prepare to move to another AP(HI). The MN sends a neighbor list request to the pAP, which responds with a site report that contains the list of neighbor APs. The pMAG, which manages the pAP, sends an HI message to the MAGs administrating the APs listed in the site report. Then, the MN chooses a new AP from the list and makes an association with it. After the connection between the MN and

    the new AP (nAP) is established, the nAP lets the new MAG (nMAG) forward buffered packets to the MN by sending a FNA to the nMAG. Subsequently, the MN starts to receive multicast data from nMAG.

    Fig. 7 shows the handover time for MAG- and LMA-based subscription, and the proposed protocol, where the multicast packet disruption period is also included. The dark gray bars in the figure show the service disruption period, which is the sum of delays required to complete the MN’s handover. The consid-ered delays are the L2 handover delay (DL2), the access delay between LMA and MAG (DLMA-MAG), the multicast tree join delay (Djoin), and the access delay between MAGs (DpMAG-nMAG). As shown in the figure, the MAG- and LMA-based subscrip-tions need an additional binding update delay when the MN's handover occurs (2DLMA-MAG). In addition, in the case of MAG-based subscription, if the nMAG has not joined a multicast group to which a MN subscribes, an additional join delay (Djoin) is needed. Since the joining delay depends on the current state of the multicast tree, it can be a crucial factor for the whole han-dover disruption period of the MN.

    The proposed protocol has the shortest disruption period needed for L2 handover. It does not need the binding update delay, in contrast to the MAG- and LMA-based subscriptions. In addition, the proposed protocol reduces the number of lost packets by forwarding and buffering at the new MAG while the MN performs a handover. Although it needs additional signals for HI and HAck messages, it does not increase the service dis-ruption period. We can redefine the service disruption period in each protocol shown in Fig. 7 as follows:

    image

    Table 1 shows the important multicast performance metrics of MAG- and LMA-based subscription, and the proposed proto-cols. Since MAG-based subscription requires both a multicast tree join delay and a binding update delay, it has the longest ser-vice disruption and as a result of this, its packet loss rate is also high. LMA-based subscription achieves both a shorter service disruption period and a lower packet loss rate than MAG-based subscription, since it does not require a multicast tree join delay. However, it still needs a binding update delay. The proposed protocol has the shortest service disruption period, because it does not need both a multicast tree join delay and a binding update delay. Moreover, its packet tunneling mechanism further reduces the packet loss rate. As shown in the table, the proposed protocol provides both a short service disruption period and a low packet loss rate while providing an optimal path length.

    IV. PERFORMANCE EVALUATION

    In this section, we evaluate the performance of the proposed

    protocol. We performed simulations using the ns-2 simulator for three protocols: MAG- and LMA-based subscription, and the proposed protocol. We performed our simulation study for the two topologies shown in Fig. 8, where each wired link has a 10 Mbps bandwidth and a 10 ms link delay. We used IEEE 802.11k as the wireless MAC-layer protocol in our simulation. We modified the IEEE 802.11 model in the ns-2 simulator to support the L2 trigger operation defined in IEEE 802.11k. We set the data rate as 11 Mbps and the multicast source generated CBR packets with a size of 1,000 bytes and a bit-rate of 512 Kbps. The PIM-SM multicast protocol was used to con-struct a multicast tree. The difference between the two topolo-gies was that there were direct paths from the multicast source to MAGs without the intervention of the LMA in topology 1, while every multicast packet was forwarded to MAGs through the LMA in topology 2. The metrics for performance compari-son were the end-to-end delay of multicast data, the service dis-ruption period, and the number of lost packets during handovers. We defined the service disruption period as the difference between the reception time of the last packet from the pMAG and that of the first packet from the nMAG. We ran the simula-

    tions with five different random seeds for each topology and calculated the average end-to-end delays of multicast data, the service disruption periods, and the number of lost packets. The MN’s handover occurred once in each scenario.

    Table 2 shows the average service disruption periods and the average numbers of lost packets during a handover by the three protocols. MAG-based subscription shows the longest service disruption period, while the proposed protocol shows the short-est one, as we noted in Section III. Since a longer disruption period increases the number of lost packets, MAG-based sub-scription shows the largest number of lost packets, while the proposed protocol shows the smallest number of lost packets. An interesting result is that only one packet is lost with the pro-posed protocol in both topologies. This is a result of the tunnel-ing mechanism between the pMAG and nMAG in the proposed protocol, where in-flight packets to the pMAG are forwarded to the nMAG (described as “tunneled packets” in Figs. 9c and 10c).

    Fig. 9 depicts the end-to-end delay of the three protocols in topology 1. The figure shows that MAG-based subscription and the proposed protocol have a much lower end-to-end delay than the LMA-based subscription in topology 1. This is because in topology 1, there is a direct path from the multicast source to MAGs, whereas there is no such path between the source and an LMA. The figure also shows that the proposed protocol outper-forms MAG- and LMA-based subscription in terms of lost pack-ets, because it tunnels packets between MAGs during handover.

    Similarly, Fig. 10 shows the end-to-end delay in the case of topology 2. As shown in the figure, all the protocols have com-parable end-to-end delays, since every multicast packet is for-warded to MAGs through the LMA in topology 2. However, the proposed protocol causes a smaller number of lost packets than

    MAG- and LMA-based subscription during handover, due to its packet tunneling. In both Figs. 9 and 10, we can see that tun-neled packets in the proposed protocol suffer from a long end-to-end delay, since they are buffered at the nMAG until the tar-get MN completes an L2 handover.

    Fig. 11 illustrates the impact of the access delay between the LMA and MAG in the service disruption period measured in topology 1 and 2. We measure the change of the service disrup-tion period with the increase of the link delay between the LMA and MAG. Fig. 11 shows that in each topology, the service dis-ruption periods in both MAG- and LMA-based subscription increase linearly as the access delay between LMA and MAG is increased. In contrast, the proposed approach is not affected by the increase of the access delay.

    V. CONCLUSION

    In this paper, we propose a new multicast protocol for proxy mobile IPv6. In the proposed protocol, MAG joins a multicast group in advance by detecting the L2 trigger and exchanging HI and HAck messages so that multicast packets can be delivered through MAG. The proposed protocol has a shorter service dis-ruption period and a lower packet loss rate than MAG- and LMA-based subscription. It also decreases end-to-end delay, since it provides an optimal delivery path. According to our per-formance study, we found that the proposed protocol shows improved performance in terms of end-to-end delay, service dis-ruption period, and the number of lost packets during a han-dover period.

  • 1. Johnson D, Perkins C, Arkko J 2004 Mobility Support in IPv6. IETF Standard Track RFC 3775 google
  • 2. Gundavelli S, Leung K, Devarapalli V, Chowdhury K, Patil B 2008 Proxy Mobile IPv6. IETF Standard Track RFC 5213 google
  • 3. Romdhani I, Kellil M, Hong-Yon L, Bouabdallah A, Bettahar H 2004 “IP mobile multicast: challenges and solutions” [IEEE Communications Surveys & Tutorials] Vol.6 P.18-41 google
  • 4. Harrison T. G, Williamson C. L, Mackrell W. L, Bunt R. B 1997 “Mobile multicast (MoM) protocol: multicast support for mobile hosts” [Proceedings of the 3rd annual ACM/IEEE inter-national conference on Mobile computing and networking] P.151-160 google
  • 5. Suh Y. J, Shin H. S, Kwon D. H 2001 “An efficient multicast routing protocol in wireless mobile networks” [Wireless Net-works] Vol.7 P.443-453 google doi
  • 6. Lin C. R, Wang K. M 2000 “Mobile multicast support in IP net-works” [Proceedings of IEEE INFOCOM 2000: Nineteenth Annual Joint Conference of the IEEE Computer and Communica-tions Societies] P.1664-1672 google
  • 7. Park J, Suh Y. J 2003 “A timer-based mobile multicast routing protocol in mobile networks” [Computer Communications] Vol.26 P.1965-1974 google doi
  • 8. Li Y, Chen W, Su L, Jin D, Zeng L 2009 “Proxy mobile IPv6 based multicast listener mobility architecture” [Proceedings of the IEEE Wireless Communications and Networking Conference] P.1-6 google
  • 9. Kim Y. T, Han S. J 2009 “Proxy mobile IP extension for mobile multimedia multicast services” [Proceedings of the 6th IEEE Consumer Communications and Networking Conference] P.1-5 google
  • 10. Asaeda H, Seite P, Xia J 2010 PMIPv6 Extensions for Multi-cast Internet-Draft (draft-asaeda-multimob-pmip6-extension-03) google
  • 11. 2006 IEEE Std 802.16e-2005 and IEEE Std 802.16-2004/Cor 1-2005 (Amendment and Corrigendum to IEEE Std 802.16-2004), IEEE Standard for Local and Metropolitan Area Networks Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems Amendment 2: Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands and Corrigendum 1 google
  • 12. 2008 IEEE Std 802.11k-2008 (Amendment to IEEE Std 802.11-2007), IEEE Standard for Information Technology Telecommunications and Information Exchange Between Systems Local and Metropolitan Area Networks Specific Requirements Part 11: Wireless Lan Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 1: Radio Resource Measurement of Wireless Lans google
  • 13. Liebsch M, Singh A, Chaskar H, Funato D, Shim E 2005 Can-didate Access Router Discovery (CARD). RFC 4066 google
  • [Fig. 1.] System architecture of Proxy Mobile IPv6 (PMIPv6). LMA: local mobility anchor pMAG: previous mobile access gateway nMAG: new MAG MN: mobile node AAA: Authentication authorization and accounting.
    System architecture of Proxy Mobile IPv6 (PMIPv6). LMA: local mobility anchor pMAG: previous mobile access gateway nMAG: new MAG MN: mobile node AAA: Authentication authorization and accounting.
  • [Fig. 2.] Handover of MAG-based subscription. MN: mobile node pMAG: previous mobile access gateway nMAG: new MAG LMA: local mobility anchor.
    Handover of MAG-based subscription. MN: mobile node pMAG: previous mobile access gateway nMAG: new MAG LMA: local mobility anchor.
  • [Fig. 3.] Handover of LMA-based subscription. MN: mobile node pMAG: previous mobile access gateway nMAG: new MAG LMA: local mobility anchor.
    Handover of LMA-based subscription. MN: mobile node pMAG: previous mobile access gateway nMAG: new MAG LMA: local mobility anchor.
  • [Fig. 4.] Multicast option format.
    Multicast option format.
  • [Fig. 5.] Handover of the proposed protocol. MN: mobile node pMAG: previous mobile access gateway nMAG: new MAG HI: handover initiation HAck: handover acknowledge.
    Handover of the proposed protocol. MN: mobile node pMAG: previous mobile access gateway nMAG: new MAG HI: handover initiation HAck: handover acknowledge.
  • [Fig. 6.] Proposed protocol over IEEE 802.16e and IEEE 802.11k networks. MN: mobile node pBS: previous base station pMAG: previous mobile access gateway nBS: new BS nMAG: new MAG LMA: local mobility anchor HI: handover initiation HAck: handover acknowledge FNA: fast neighbor advertisement.
    Proposed protocol over IEEE 802.16e and IEEE 802.11k networks. MN: mobile node pBS: previous base station pMAG: previous mobile access gateway nBS: new BS nMAG: new MAG LMA: local mobility anchor HI: handover initiation HAck: handover acknowledge FNA: fast neighbor advertisement.
  • [Fig. 7] Handover timing diagrams of protocols. pMAG: previous mobile access gateway nMAG: new MAG LMA: local mobility anchor MN: mobile node.
    Handover timing diagrams of protocols. pMAG: previous mobile access gateway nMAG: new MAG LMA: local mobility anchor MN: mobile node.
  • [Table 1.] Comparison of MAG- and LMA-based subscription and the proposed protocol
    Comparison of MAG- and LMA-based subscription and the proposed protocol
  • [Fig. 8.] Simulation topology. LMA: local mobility anchor pMAG: previous mobile access gateway nMAG: new MAG MN: mobile node.
    Simulation topology. LMA: local mobility anchor pMAG: previous mobile access gateway nMAG: new MAG MN: mobile node.
  • [Table 2.] Service disruption period and number of lost packets
    Service disruption period and number of lost packets
  • [Fig. 9.] End-to-end delay of each protocol in topology 1. MAG: mobile access gateway LMA: local mobility anchor.
    End-to-end delay of each protocol in topology 1. MAG: mobile access gateway LMA: local mobility anchor.
  • [Fig. 10.] End-to-end delay of each protocol in topology 2. pMAG: previous mobile access gateway nMAG: new MAG LMA: local mobility anchor.
    End-to-end delay of each protocol in topology 2. pMAG: previous mobile access gateway nMAG: new MAG LMA: local mobility anchor.
  • [Fig. 11.] Comparison between service disruption periods in each protocol: impact of link delay between local mobility anchor (LMA) and mobile access gateway (MAG).
    Comparison between service disruption periods in each protocol: impact of link delay between local mobility anchor (LMA) and mobile access gateway (MAG).