Network Setting: Mobile access gateway (MAG), Local mobility Anchor (LMA), Multicast Router (MR).

PMIPv6 is network based mobility management. MAG, instead of an MN, performs movement detection and binding updates; therefore, unlike Mobile IP, MNs do not need to install any mobility-related protocol. Moreover, the PMIPv6 does not require IP reconfiguration procedures in the same PMIPv6 domain.

Problems with mobile multicasting:

• Tunnel convergence problem: with mobile IP solutions, tunnels are built for forwarding package from home / previous Anchors to new anchors. If multiple nodes move to the same foreign network, multiple multicast tunnel are built.
• The second problem is the great delay experienced by

executing handover, membership management, and multicast tree update for seamless communication whenever MN moves to a foreign network. If an HA does not support multicast router functionalities, an MN should discover a multicast router (MR) and send notification by multicast listener discovery (MLD) query/report messages, including requests to join a group communication. However, the maximum query period for MLD is 125 seconds,

Apporach: To design a PMIPv6-based multicasting service, we consider the position of MR. Fig. 3(a) shows a simple solution, where both the MAG and the LMA contain the MR function; however, this strategy introduces a tunnel convergence problem similar to Mobile IP-based bi- directional tunneling schemes. Therefore, we separate the MR function from the LMA, as shown in Fig. 3(b), so the MAG can connect to both the LMA and the MR. Thus, multicast packets are delivered from the MR while unicast packets are delivered from the LMA via tunnels. However, the overhead for the routing update from both network models (see Fig. 3(a) and (b)) degrades the performance of PMIPv6 components. Consequently, we propose the network model depicted in Fig. 3©, where the MAG contains only an Multicast Listener Discovery (MLD) forwarding proxy (MLD-FP) function that has been proposed by the IETF [8]. Multicast packets without tunnel header are delivered from a local MR, while unicast packets with PMIPv6 tunnel header are delivered from LMA. An MLD-FP and separated data path of unicast and multicast lift the burden from MAG and LMA. As a result, the tunnel convergence problem is solved and routing processing overhead is reduced.

PMIPv6: Proxy Mobile IPv6 [3] provides mobility support to moving hosts without their involvement. This is achieved by relocating relevant functionality for mobility management from the MN to a network node called the Mobile Access Gateway (MAG), that is responsible of the mobility signaling to the Home Agent on the MN’s behalf. MN’s traffic is encapsulated and tunneled between MAGs and the MN’s Home Agent, that in PMIPv6 is renamed as Local Mobil- ity Anchor (LMA). In PMIPv6, the network learns through standard terminal operation, such as Router and Neighbor Discovery [5], or by means of link-layer support, about an MN’s movement and coordinates routing state updates without any mobility specific support from the terminal. While moving inside the PMIPv6 domain, the MN keeps its IP address, and the network is in charge of updating its location in an efficient manner.

Approach: The MEDIEVAL mobility architecture leverages on the concept of Distributed Mobility Management [4], for the development of both network-based and host-based mobility management.

The access network is organized in Local- ized Mobility Domains (LMDs) in which the network-based scheme inspired by [6] is applied. Users are expected to be most of the time roaming within a single LMD, but, for those cases where this is not possible (e.g., roaming to a network owned by a different operator or running a different mobility support scheme), a host-based DMM approach is followed (e.g., based on [7]). In order to integrate both approaches, so that a mobile node can simultaneously have sessions managed by a network-based (“PMIPv6 alike”) approach and a host- based (“DSMIPv6 alike”) approach, we introduce a novel architectural element called Mobile Access Router (MAR). An MAR is a network entity implementing all the functionalities of its counterparts in the standard mobility protocols (MIPv6 and PMIPv6), so it is able to play the role of plain access router, home agent, local mobility anchor and mobile access gateway on a per address basis.

MAR can be placed at many places of the network. Flow Manager (FM) runs on MAR and handle flow-level control.

Intra Local Mobility Domain: When MN move to new MAR, a tunnel from old MAR to new MAR is built for on-going flow (similar to PIPv6 LMA). When another handover occurs, previous MARs establish a tunnel with the serving MAR if the ongoing flows must be maintained, while new communications are started with the prefix advertised by the current MAR (Figure 2-d). This mechanism allows maintaining mobility sessions on a per flow basis, that is, only for those IP flows that really require mobility support, and can be extended to allow flow mobility for load balancing or traffic offloading.

Inter domain mobility: MAR acts as Home Agent and tunnel to MN is built.

Multicast support:

Multicast Mobility Engine (MME). The approach only considers LMD (Network based mobility scenarios, PMIPv6). the Flow Manager triggers MME for multicast flow mobility, which should result in different operations for multicast sources and listeners: for instance, the mobility of a listener may trigger a Context Transfer by the MME, while the mobility of a source could lead to a (source- aware) modified PBU being sent to a MAR. Thus, the MME acts on behalf of the Flow manager, which is responsible for storing information about multicast flows properties, such as IP multicast group addresses, corresponding sources (in PIM- SSM) and multicast trees Rendezvous Points (RPs).

Multicast Listener mobility: To avoid tunnel convergence problem:

• Multicast router (MR) is implemented on MAR.
• A message exchange between MARs must occur in order to allow multicast context transfer

MAR handles multicast sessions on behalf of MN.

Multicast Source Mobility: Source needs to signal mobility, which is not supported in PMIPv6. two schemes for source mobility support are proposed: LMA-based and MAG- based. The former is the easiest to deploy and brings more advantages in mobile scenarios, but when to use Rendezvous Point Tree (RPT) or Shortest Path Tree (SPT) needs to be evaluated; the latter for example, allows for setting the LMA as the RP, preventing the tree reconstruction in case of mobility.

Forwarding within multicast group.

All nodes in the multicast group form a virtual network graph, in which 2 nodes are connected by a number of hops in the underlying network. Form a tree from source node to all destination nodes.

Similar to previous paper. With different approach

Multicast flows are sent to all APs in a multi/broadcast Service (MBS) zone. This results in waiste of bandwidth in large MBS zone in order to keep low handover. The author propose “network planning” to devide MBS-zone to Local Multicast Area (LMA) containing adjacent APs. Only APs in LMA receive Multicast when MN is present.

Overview:

• Discussion of multicast-based mobility support based on architectural, performance-related, and functional requirements.
• Case studies for multicast-based mobility in IP-based cellular networks.
• Experiment and comparison with basic Mobile IP and hierarchical Mobile IP

Multicast-based Mobility Support:

• Separation of host's location (IP) and identity (ID of Mcast group)
• Location: IP-addresses at which Host is reachable
• Mcast group: Mapping fixed mcast ID to changing IP-addresses.
• Mobility support: deliver packets to multiple locations (APs). Figure

Note: The branches of the multicast tree can grow and shrink to follow the mobile host’s trajectory. Hence, in a wireless network with multiple access points arranged as ce ll clusters of neighboring cells, data can be efficiently forwa rded to multiple access points simultaneously. When a mobile hos t moves to a new wireless cell within the cell cluster, the data destined for the mobile host are already available in the acc ess point. The new access point can immediately start forwardin g data over the wireless link to the mobile host. Consequently , the service interruption is shortened. For support of host mobility predictive handoff is an obvious benefit of utilizing multicast.

Handoff:

• Soft and predictive HO:
• Simultaneous distribution of data to multiple locations: mcast vs replicated unicast

Multicast Protocol Selection:

• Mcast type (sender / receiver oriented)
• Multicast Endpoint: Host / AP
• Micro-/Macro Mobility: migration b/w access networks
• Multicast tree directionality:
• X + Multicast: Mobility is handled separately
• Dynamic Tree: Leaves are APs or MHs

Candidates protocol: Any Source Mcast (ASM), broadcast-and-prune  mechanisms  (DVMRP), source-specific  multicast (SSM), MCall

Note:

• The ASM service model is defined as the “transmission of an IP datagram to a host group, a set of zero or more hosts identified by a single IP destination address” [15] where any host can send to a group and the sender does not need to be a member of the group
• broadcast-and-prune mechanisms (DVMRP). This routing protocol is optimized to support large groups with sparsely distribute d members, an assumption that does not match mobility support . A modification of this proposal is to use explicit join/leave protocols. We follow this latter approach in its basic protocol option choices (e.g., placing the multicast endpoint in the access point, dynamic tree, no adaptivity) and extend it by some additional mobility functions (esp. support for inactive h osts, paging).
• SSM: simple model, tree-like topologies of access networks with a gateway as th e root.
• MCall a multicast group in this model is represented by a multi-point, multi-connection communication channel termed call , where only end points being member of the call are allowed to send and receive to/from the call (closed group). End points (i.e. hosts) can be dynamically added and dropped to/from the call, as well as connections between the members of the call. The multicast group is non-anonymous and op-erations can be executed by the host itself or by a surrogate host. Particularly important for mobility support is the fa ct that the MCall service model facilitates, unlike the ASM and SSM service models, a much better management of the members of the multicast group, including the senders, and the communication between them. The addition and dropping of end points to/from the call allows precise control of rerouting operations for mobility, such as break-make and make-break rerouting. Additional protocol mechanisms suc h as third-party registration, resource reservation in adva nce, sub-casting and others are useful and may potentially impro ve the handoff performance. Such mechanisms provide a larger design space and increased possibilities for the design of multicast-based mobility concepts, but are not available i n cur-rent IP-based multicast protocols.

Future work:

• Problem
  • Scalability: limited number multicast groups containing 1 MH
  • Mcast overhead: Increased signalling
  • Complex operation: Links / Group management, address translation, registration, paging inactive host
  • Network based?
• Potential Improvement:
  • SDN based improvement to complexity of IP multicast: group management, limited number of mcast group