Mobility-Sensitive Multicast Protocol in NEMO

Abstract

In view of the past, the mobility of the multicast source in the mobility networks is seldom discussed in the traditional multicast protocols. It is a heavy cost for the traditional multicast protocols to reconstruct the multicast tree in the Network Mobility (NEMO) environment. This article proposes an alternative multicast protocol, referred to as Mobility-Sensitive Multicast protocol (MSM), for the NEMO environment. The MSM can be considered as an alternative version of the Multicast Listener Discovery (MLD) protocol to maintain the multicast tree in the NEMO. There are two obvious contributions for the MSM. Reconstruct mechanism could rebuild the multicast tree for the mobility of the multicast source. Multi-group suppression mechanism reduce the multicast tree maintaining cost for the mobility of the multicast members. Through the performance evaluations and analyses, the MSM has less cost to maintain the multicast tree than the traditional multicast protocols, especially for a large numbers of multicast groups. Moreover, the MSM allows the mobility of the multicast source to reconstruct the multicast tree easily.

1. Introduction

Recently, the evolution of wireless technology leads to Internet roaming as the major activity for the personal mobile device. That is, ubiquitous computing causes people to communicate, watch video, and play online game with the mobile device in the bus, train, and MRT. Numerous mobile devices are needed for the Internet service. The supported communication of the Internet services is based on TCP/IP protocol. Every mobile device needs a IP address to access the Internet resource.

Coincidentally, the growth of the Internet of things (IoT) which converges a colossal field of multiple technologies needs more wireless technology to maintain the link. For mobile and communicating conveniently, the IoT utilizes the wireless technology to control the sensors and collect the data of the sensors. The IoT requires more bandwidth to transmit the media and data.

Additionally, the vehicular ad hoc network (VANET) [1] and the aircraft cabin wireless system for entertainment [2-4] are identical. These also urgently require the greater bandwidth and lower latency quality of the transmission.

In order to meet the requirement of the greater bandwidth, the fifth generation (5G) [5] technology standard for broadband cellular networks is one of the key solutions. The main advantage of the 5G is that the systems provide the greater bandwidth and higher download speeds for mobile devices. The technology creates new applications for IoT and VANET. To provide a large bandwidth for the communication between devices in 5G, the improving multicast routing algorithm and the efficient resource allocation strategy are proposed in [6]. To transmit media and data in the Internet, every mobile device always needs one IP address. Therefore, the traditional mobile IPv4 protocol cannot burden a large number of mobile devices. The Mobile IPv6 (MIPv6) protocol can be the best strategy to solve the Internet access of a vast number of mobile devices. Another issue for the MIPv6 is the heavy loading of the group mobility. Group Mobility, such as the mobile devices in the mobile bus, should lead to a great overhead for the communication bandwidth. The NEMO (NEtwork MObility) Basic Support protocol [7] can be a solution for group mobility. The NEMO enables the Mobile Network to attach to an access point and allows to change the attachment to another access point for the mobility. The protocol can be considered as an extension of Mobile IPv6. It allows session continuity for every node in the Mobile Network as the network changes the location.

In the current network, data packets sent by the source are mainly sent to the client in a unicast manner. Assuming that many clients request the same data from the source at the same time, the source must send it to many clients separately. If many clients receive message packets under the same subnet at the same time, it may cause network bandwidth congestion. For improving this problem, the multicast protocol is designed. Through the multicast protocol, the source node only sends a data packet once to many designated clients. Nowadays, the application of the multicast protocol becomes more and more popular, and apply in all video conferences, communication software, and real-time video transmission.

The principle of the multicast protocol is mainly that the source node sends multicast data packets including the multicast address in the destination address. The multicast data packets are transmitted along the multicast tree constructed by the multicast protocol. When the data packets are sent to the fork of the multicast tree, the Multicast Router (MR) clones them and sends to all the branches of the multicast tree. Finally, the cloned data packets will reach each client through the multicast tree. The advantage of the multicast protocol is that if Unicast is used to send the same data packet to N different clients at the same time, the source must send N data packets; Multicast only needs to send one which can be copied on the MR and sent to the multicast tree branch. In contrast, the burden of Multicast is much less than Unicast.

In the NEMO, the clients move from one MR to another and want to keep the link, they must reconstruct and maintain the multicast tree. At this time, the reconstruction and maintenance of the multicast tree will cost higher. There are two questions at this moment. One question is that if clients send multicast packets to group members in the NEMO by using the source tree, the topology of the multicast tree changes due to movement, and the cost of rebuilding the multicast tree is higher. The other question is that the maintenance of the multicast tree usually exhausts colossal bandwidth.

This paper proposes an improved multicast protocol named Mobility-Sensitive Multicast (MSM) protocols to solve these two problems as mentioned. This protocol aims to reduce the cost of maintaining multicast tree and save the limited bandwidth by expanding the Multicast Table fields. If the cost of maintaining the multicast tree is reduced, it also saves the network bandwidth. Under the limited network bandwidth, the transmission will has relatively the better quality.

The remainder of this paper is organized as follows: Section 2 mainly proposes the introduction and operation process of NEMO and some wireless network multicast protocols. Section 3 describes the proposed Multicast routing protocol in details. Session 4 describes the analysis and evaluation for this multicast routing protocol. The discussion and summary of this article is Section 5.

2. Related Works

The traditional wired multicast protocols, such as DVMRP [8], MOSPF [9], PIM [10], CBT [11], and so on, are not suitable for the mobility computing. The router in the wired network is immobile. The multicast topology of the wired network is fixed and easy to maintain. However, for some wireless network circumstances, such as NEMO or Ad-Hoc network, routers are mobile anytime and anywhere. If the multicast source node is jointed in the NEMO or Ad-Hoc network, the multicast protocol needs to reconfigure the multicast topology to meet the multicast requirement after the source moving. Therefore, the traditional multicast protocols of the wired networks are not suitable.

The traditional multicast protocols always work on IPv4. MLD[12] is a protocol used between IPv6 MR and the Host. The earliest version is defined in RFC₂₇10. The purpose of this protocol is to exchange group member status information for Host and MR. The messages used by MLD are ICMPv6 packets. The system assumes that there are several IPv6 routers in a network segment simultaneously, these routers automatically select a Querier Router responsible for the investigation group. Querier Router periodically sends MLD Query Message to inquire the group the Host under the network segment. When the Host receives the Query Message, it responses a Report Message. Several hosts in the network segment utilize the membership report suppression mechanism to reduce to send Report Messages if they join in the same group. If a host leaves the group, it sends a Done Message to inform the Querier Router. Then the Querier Router sends a Multicast-Address-Specific Query Message to inquire the specific group to know whether other hosts in this network want to continue to receive the Multicast Packet of the group. After a while, when hosts respond nothing, this Multicast Packet means unrequired.

Mobile IP is designed for the mobility computing. The directly design proposal is to select an agent of Mobile Node (MN) with the tunnel technology. The Bi-directional Tunnel (BT) [13-14] method is to establish a two-way tunnel between the Home Agent (HA) of the MN and the mobile network of the MN. When the MN requests multicast data, the MR in the Home network will send a join request message to the nearest MR in the multicast tree to join the multicast tree. After joining multicast tree, the HA forwards the multicast data to the MN through the established BT. The advantage of this scheme is that the multicast tree needn’t be changed after handoff the MN. No matter where the MN moves, the multicast data can be sent the HA and redirect to the MN of the mobile network by the BT. The disadvantage is that a triangle routing problem surfaced. The multicast data can be sent to the HA and then forwarded to the MN. The tunnel establishment should cause a considerable additional burden.

Without the tunnel technology, Remote Subscription [13-14] is an simple architecture to implement the multicast protocol in Mobile IP. In this architecture, MN directly uses Care-of- Address (CoA) to join the multicast tree after handoff. When the MN handoff to a new access point, it will have a new CoA. The MN only uses the new CoA to join the original multicast tree to receive the multicast data. The advantages of this architecture are that it is easy to implement. It does not require additional paths and burdens to transmit data using tunnels like BT Scheme. The disadvantage is that it is easy to cause more packets to be lost when handoff.

The Multi-hoc wireless network is the key topology of the Ad-Hoc network in the wireless networks. The proposal of the multicast protocol should consider the characteristic of the Multi-hoc wireless networks. ODMRP [15] is a protocol proposed by the IETF to support the multicast function for the Ad-Hoc networks. This protocol utilizes the JoinReq Packet to periodically broadcasts to the entire Ad-Hoc network. If the members receive this JoinReq Packet, they send the JoinReply Packets back along the path to construct the multicast tree. The members periodically repeat to send JoinReq and JoinReply This protocol can maintain the multicast tree in the renew topology of the Ad-Hoc network for the new join nodes or the dying nodes. The disadvantage of the protocol is that it will incur relatively high costs because JoinReq needs to be broadcast regularly to the entire Ad-Hoc network.

In the Ad-Hoc network, many multicast protocols have been proposed such as ODMRP [15], NSMP [16], MAODV [17-20] and so on. These multicast protocols are not suitable for the NEMO without IP protocol supporting. There are few related works of multicast protocols proposed in the NEMO. In the NEMO, the MN moves from one MR to another and acquires a new CoA to keep link with the network. Assuming that while an MN which is the source of Multicast is sending multicast packets to group members, it moves and connects to another MR and leads to acquire a new CoA. At this time, the reconstruction and maintenance of the multicast tree will cost higher. One question is that if an MN send multicast packets to group members in the NEMO by using the Source Tree, the topology of the multicast tree will be modified due to MN movement, and the cost of rebuilding the multicast tree is higher. Another question is that the maintenance of the multicast tree usually requires colossal costs. To provide a suitable multicast operation in the NEMO, this article proposed a multicast protocol dedicated for the NEMO to cope with the mobile communication nodes.

NEMO Basic Support Protocol is a protocol to support the technology of the Mobile IPv6 and Ad-Hoc networks [7]. In the NEMO, the implementation of Multicast has considerable problems [21]. Video and audio streams are transmitted from remote servers to each user through the multicast protocol for the conventional network in the past. In the wired network, Multicast has been developed mature protocols such as DVMRP [8], MOSPF [9], PIM [10], and been proposed also in the wireless network. However, due to the characteristics of the NEMO, many protocols used in the NEMO cannot achieve the expected performance. The NeMRI is a multicast route optimization scheme in NEMO environments [22]. It records a multicast tree of the CoAs of all the MRs located below it. The NeMRI has two disadvantages. One is every node must transmit the multicast datagrams to the Top-level Mobile Router(TLMR). The other is every MR stores too many multicast datagrams to reduce performance. The Mobile Router Forwarding Scheme (MRFS) [23] can resolve the two disadvantages of the NeMRI. The MRFS define three tables in ever MR. These three tables describe the parent and child relationship of the MR. The MRFS also modifies the transmit timing of the Router Solicitation (RS) message and the format of the RS message. The MRFS utilizes the resource efficiently when every node transmits to reduce the multicast datagrams to TLMR and MR. MRFS also reduce the multicast datagrams when the node join and leave the Multicast Three.

3. Mobility-Sensitive Multicast Protocol (MSM)

3.1 NEMO Basic Support Protocol

In the Mobile IPv6 protocol [24], the wireless network is a composite of Mobile Nodes (MN), and a Home Agent (HA). The Mobile IPv6 protocol provides an IP address for the MN in the Home Network as the permanent address called Home Address and registers this address to a HA. When the MN attaches a foreign link away from the Home Network, the MN acquires a Care-of-Address (CoA) through conventional IPv6 mechanisms. The CoA is an IPv6 address that has the subnet prefix of a particular foreign link different from the Home address. In the Mobile IPv6 protocol, an MN has several CoAs for the different foreign links. The MN registers its primary CoA on the home link. While the MN leaves away the Home Network, the MN requests the attachment to function as the HA. The MN sends a Binding Update (BU) message with binding registration to the HA. The HA replies a Binding Acknowledgement (BA) message to the MN to complete the registering process, and then packets addressed to this CoA will be routed to the MN. The messages transmit between MNs by building the tunnel from HA and MN. The NEMO Basic Support protocol enhances the Mobile IPv6 protocol by adding Mobile Router (MR).

The MR serves Mobile Networks that access other Mobile Networks. The MR maintains a Bi-directional Tunnel (BT) to a HA and advertises an aggregation of the Mobile Network to all networks. In the NEMO, a Mobile Network also comprises multiple and nested subnets. MRs attach to other MRs owned by different MRs and form a graph. MNs in the Mobile Network transmit packets through the MR as the default gateway. Each MR attaches to another MR by a single interface, so the graph is a tree without loops. The MR has a unique Home Address which is configured from a prefix aggregated and advertised by its HA. The MR has more than one Home Address and advertises one or more prefixes in the Mobile Network attached to it. When the MR moves away the Home Network and attaches to a new MR, it acquires a new CoA from the new link. Then, the MR sends the BU and get the BA from its HA, and completes this movement, and starts to serve its Mobile Network.

NEMO Basic Support Protocol bases on Mobile IPv6 (MIPv6) for Layer 3. Mobile IPv6 protocol is defined on RFC3775 by IETF. This protocol allows nodes in the wireless network to remain reachable using the IPv6 protocol. When the mobile node transfer the packets, the packets addressed to its home address are routed to its home link, using the IPv6 routing mechanisms. When the mobile node attaches other foreign links away from home, it acquires one or more CoA through conventional IPv6 mechanisms. The mobile node binds the association between the home address and the CoA. While the mobile node left away the home network, the mobile node registers its primary CoA by the BU message with a router on its home link and requests this router to function as the home agent. Then the home agent responses the "Binding Acknowledgement" message back to the mobile node.

The Correspondent Node (CN) is an Internet node communicates with the mobile node. If the CN is an mobile node, the communication between the mobile nodes has two ways. One way is the BT which does not require the MIPv6 support from the CN. The mobile node does not register its binding address with the CN. Packets from the CN are routed to the HA and then tunneled to the mobile node and vice versa. The other way is the Route Optimization (RO) which requires the mobile node to register its current binding address at the CN. Packets are routed directly from the CN to the CoA of the mobile node. The routing packets allow using the shortest communications path. This way also eliminates the congestion at the home agent and home link. The possible failure of the home agent or networks is reduced.

NEMO Basic Support Protocol extends from Mobile IPv6 (MIPv6) and is backward compatible with MIPv6. According to this protocol, Fig. 1 shows the packet transmission route. Assume the MIPv6 has optimized in the NEMO. When the CN wants to send a packet to the mobile node (MN₃) managed by the mobile router (MR3) in the nested network, it will first send this packet to the HA of MR3 (MR3_HA). The MR3_HA queries records in the Binding Cache after receiving this packet. After knowing the MR2 currently manages the MR3, the MR3_HA sends this packet to MR2_HA. The MR2_HA does the identical step as MR3_HA after receiving this packet and knows that MR1 currently supervises MR2. Next, MR2_HA sends this packet to MR1_HA. The last, this packet arrives MR1_HA. The MR1_HA administrates the node that is the destination of this packet, and later, it sends this packet to the Access Router (AR) that currently manages MR1 through the tunnel. When this packet arrives AR, the AR knows the destination node of this packet is supervised by itself, and it transmits this packet to MR1. MR1 forwards this packet to MR2 after receiving it, then MR2 also forwards this packet to MR3, and finally, the MR3 forwards the packet to MN.

Fig. 1. The Routing Paths of the NEMO Basic Support protocol

As shown in Fig. 1, if CN wants to forward packets to MN₃, it must pass MR1_HA, MR2_HA, and MR3_HA first. If MN is in a nested network with many layers, the cost of passing through HA is considerable.

For adapting to transmit the real-time audio and video, instant messaging, and video conferencing, etc., the Multicast is the best choice. As mentioned before, when the source in the Multicast Network moves its original position, the multicast protocol will cost large to reconstruct the multicast tree of the transmitting path in the NEMO environment. Therefore, this paper proposed an improved multicast protocol, Mobility-Sensitive Multicast (MSM) protocol, to reduce the overload when the multicast tree is reconstructing. There are two major steps for the MSM protocol. First, the MSM protocol searches the members of Source Tree by flooding. Second, the MSM protocol constructs and maintains the multicast tree by Query and Report exchange the status of members. It will be run smoothly in the MSM protocol environment, which modifies from Multicast Listener Discovery (MLD) and expands the new function, and the loading of the network is lower when the multicast tree is reconstructing after the source moving.

As shown in Fig. 2, initially, MR1 obtains CoA through Top-Level Mobile Router (TLMR), so TLMR is the parent node of the MR1. MN₁ and MN₂ obtain CoA and can access the network through MR1, so MN₁ and MN₂ are the child node of the MR1. And next, MN₁ is the multicast source and sends the multicast flow to MR1 and TLMR. Therefore, MN₁ is the upstream node of the MR1, and MN₂ and TLMR is the downstream node of the MR1.

Fig. 2. An Example of the Multicast Flow

3.2 Mobility-Sensitive Multicast protocol (MSM)

To provide the multicast function in the NEMO, we need the topology information to maintain the multicast tree. The multicast signals are proposed to construct and maintain the multicast tree and reconstruct the multicast tree when the multicast source leaves the MR domain. The functions of the multicast signals are shown as the following and these functions all include Group ID and upstream node address.

. Construct: for the multicast source to establish a new multicast tree by broadcasting. It is always forwarded by the upstream node to the downstream node.

. Query: for the MR to inquire periodically the neighboring node which group or the group packet which need to forward.

. Report: for the MN to report which group joins and the MR forwards to the upstream MR after the MN receives Query.

. Reconstruct: for the multicast source asks the MR to reconstruct the multicast tree when the multicast source moves to link another MR.

. Init: for the MR to inform the multicast source to reconstruct the multicast tree after the MR moving to join another MR link.

To get the topology information of the multicast tree in the NEMO, the TLMR and MRs should maintain a multicast table as shown in Table 1. The table must have the information about the multicast Group ID and a boolean bit Forward to show whether forward the multicast data packet. For avoiding to refrain messages from listening to the Reports from different upstream nodes, the “Upstream Node” field is designed to record the upstream node's address for the Report signal. As shown in Table 1, the Group ID is the group address specified by IPv6. The Upstream Node is the address of upstream node for the node which received multicast data packets. The Forward decides whether the multicast packets needs to be forwarded. When the Forward is 1, the MR or AR will forward the multicast data packets. The Forward is maintained by the control messages of Query/Report periodically. The Upstream Node is maintained by the control messages of Contruct/Reconstruct/Init for the variation of the NEMO topology. The Upstream Node can also be maintained by the Query/Report for the relink of the leaf multicast node.

Table 1. The Multicast Table

The major goal of the MSM protocol is to maintain the validity of the Multicast Table. The Multicast Tables are the key information of the multicast tree. The multicast data packets are forwarded to the multicast members from the multicast source according to the entries of the Multicast Tables. But the nodes in the NEMO are mobile. That is, the topology of the NEMO is variable. Therefore, we need the MSM protocol to maintain the multicast tree to confirm the validity of the multicast flow. The invoke time of the MSM protocol is a new multicast group initialization and the variation of the NEMO topology.

When a new multicast group is initialized by a new multicast source, the multicast source broadcast the Construct to all mobile nodes along the routes in the NEMO and the MR add the record with the corresponding Upstream Node.

The mobility of the mobile node leads to the variation of the NEMO topology. The Query/Report periodically monitors and maintains the multicast tree and updates the Forward field according to the corresponding multicast group. There are two kinds of the mobile node relink for the variation of the NEMO topology. They are the link of the MR, and the link of the multicast source. The Reconstruct scheme reconfigures the multicast trees for the relink of the multicast source. The Init scheme rebuilds the multicast groups for the relink of the MR.

Consider the MNs in the NEMO, the multicast tree must be renewed periodically for the mobility of MNs. The Query/Report messages are tools to maintain the multicast tree. The MSM can pack the multi-group information in a Query message. The multi-group packing strategy for the Query message will reduce the maintaining cost of the multicast tree in the NEMO. The MR and TLMR send the Query periodically to neighbor nodes, and then the downstream nodes will respond the Report to forward or accept the multicast data packet. After a while, if MR and TLMR do not receive the Report of some groups, the multicast table in the MR and TLMR will set the Forward to 0 for the groups and do not forward the multicast data packet. The MSM cannot pack the multi-group information for the Report message. The Report should reply to the Query for every multicast group. To reduce the maintaining cost, a report suppression mechanism modified from MLD [12] is applied in the MSM. This mechanism can filter the duplicated messages. Several MRs and MNs in the NEMO utilize the membership report suppression mechanism to reduce to send Report Messages if they join in the same group.

To build a new multicast tree, the multicast source in the NEMO sends the Reconstruct by broadcasting. Reconstruct is a mechanism to rebuild the multicast tree for the mobility of the multicast source. After receiving the Reconstruct, MRs and TLMR will record the Group ID, Upstream Node in the multicast table for the corresponding multicast group. The TLMR and MRs should maintain the Multicast Tables to keep the multicast tree information for this system. The NEMO is a tree-based topology, so there is no loop in the routing path and the upstream node of the Reconstruct is the upstream node of the multicast packet. We needn’t worry the duplicated packet for the broadcasting of the Reconstruct. Then, the Reconstruct will be sent to other neighboring nodes except the upstream node. The node address will be the upstream node address of the neighboring nodes. The neighboring MRs will repeat these steps until all nodes receive the Reconstruct. After receiving the Reconstruct, AR utilizes the multicast routing protocol (EX: DVMRP, PIM-DM) of the wired network to construct the multicast tree of the wired network. Then, AR could forward the multicast packet from the multicast source in the wireless network to the wired network group members, vice versa. Obviously, the AR plays as a multicast gateway and forwards the multicast packet as the multicast source in the NEMO.

Fig. 3 is an example for multicast registration. At first, the MN₂ sent the Reconstruct as the multicast source to the neighboring node, MR3. The MR3 recorded the MN₁'s CoA including Group ID and Upstream Node, and set the Forward bit to 1 into the multicast table after receiving the Reconstruct. Then, MR3 forwarded the Reconstruct to the next neighboring nodes except the upstream node. The MR1 recorded the MR3's CoA identical to the MR1, and forwarded continuously the Reconstruct. The Reconstruct will keep forwarding to all subnetwork until finding all members. After accepting the Reconstruct, the AR defined itself as the wired multicast source, and constructed the wired multicast tree. When receiving the multicast packet, AR will forward it to the wired members by the wired multicast protocol.

Fig. 3. The Multicast Register of the MSM protocol

Every MR sends the Query interval to inquire the neighboring nodes to join group or the group packet which needs to forward. According the joined Group ID, MN replies the Report to the upstream MR after accepting the Query from the upstream MR. MR is different from MN. MR queries the Multicast Table after accepting the Query whenever if the Upstream Node is the same as the upstream MR's and the Forward bit is 1. MR will inform the upstream MR with the Report.

The MSM protocol mechanism applies the MLD protocol to restrain the duplicated report. When the node, MN or MR, heard before sending the Report that other MNs or MRs around have sent the Report including the same Group ID and Upstream Node address, it will stop to reply the Report for mitigating the network loading. The router only needs to know whether there are downstream members. The group only receives one Report from the downstream nodes. After accepting the Report, the MR sets the Forward bit to 1 in the Multicast Table. When the Report is not including the Group ID, the MR sets the parent node address to the upstream node, and the Forward bit set to 1. After a while, the MR will set the Forward bit of the group that has not received the Report in the Multicast Table to 0, indicating that there is no member of the group downstream. After sending Query and receiving Report, the MR can determine whether forward the multicast packet and the effect of pruning the multicast tree. The multicast source sends the multicast packets after sending the Construct for a while. Then, the MR can determine whether forward these multicast packets according to the Forward bit of the group in the Multicast Table.

After MR sending periodically the Query, a new member can response the Report to join the multicast tree. When MR receives the Report from a new member, it will inspect the Multicast Table. If the Multicast Table has no record about this group, the MR will add one into the Multicast Table. It will record the upstream node address as the parent node's, and the Forward bit sets 1. If the Multicast has the record about this group and the Forward bit is 0, it will change the Forward bit to 1. Then, when the upstream MR resends the Query, the downstream MR will respond the Report. After the upstream MR receiving the Report, it will look for its Multicast Table. If the Multicast Table has a record about this group and the Forward bit is 1, it indicates that the new member has joined the multicast tree. If the Forward bit is 0, it will change the Forward bit to 1 and keep sending the Report to the upstream MR until the member joins the multicast tree.

Fig. 4 is an example to add a new member into the multicast group. After receiving the periodical Query, MN3 responded the Report to MR3. MR3 checked the Multicast Table and set this group's Forward bit to 1. Then, after MR2 sending the Query, the MR3 reported the group's Report to MR2 to assist the MN3 joining the multicast tree. The Forward bit of the group1 in the MR2's Multicast Table is 1, so the MR2 will forward the multicast packet through the MR3 to the MN3.

Fig. 4. The Member Joins in the MSM Protocol

The current member nodes cannot send the group Report while they leave the multicast group after receiving the periodical Query. After a while, the MR will set the Forward bit to 0 in the Multicast Table without receiving the group Report. Similarly, the upstream MR will trim the multicast tree while the downstream MR stops sending back the group Report to the upstream MR.

Fig. 5 is an example for the member leaving the multicast tree. The MN₁ did not respond the group1 Report for leaving the multicast tree while the MR4 sent the Query. After a while, the MR4 set the Forward bit of the group1 to 0 in the Multicast Table. Then, the MR4 will not forward the multicast packet for the group1. When the MR2 sent the multicast packet to the MR5 and MR4, the MR5 will forward the multicast packet and the MR4 will not forward the multicast packet.

Fig. 5. The Members Leave in the MSM Protocol

Of course, the MR will obtain the new CoA after moving to the downstream node of another MR, and the MR should replace the upstream address in the Multicast Table to avoid the error data. If the MR discovers the upstream node is its child, that means the MR is moving with the multicast source, MR should reconstruct the multicast tree. If the MR discovers the upstream address is not its child, that means the upstream node address is the CoA of the previous parent node, the parent node address will replace the old upstream node address at this time. If the Forward bit is 1, re-join the multicast tree employing Query and Report. After MR moves and obtains a new CoA, it will update each group in the Multicast Table. After the multicast source moving, it will get the new CoA and reconstruct the multicast tree by sending the Reconstruct. When MRs receive the Reconstruct, they will look for and renew their Multicast Table according to the following conditions:

1) If the Multicast Table does not have this group record, it will add the group record and set the Forward bit to 1 as default.

2) If the upstream node address recorded in the Multicast Table is different from the Reconstruct, the Multicast Table will overwrite the upstream node address of the group which record in the Reconstruct and the Forward bit will set to 1.

3) If the upstream node address recorded in the Multicast Table is the same as the Reconstruct, the direction of the multicast packets forward without any change.

After the Multicast Table updating, if the Forward bit is 1, the MR will forward the Reconstruct to the neighbor nodes exclude the upstream node, otherwise not. According to these rules, resulting in MR has confirmed no downstream members to lead to reconstructing the multicast tree, the multicast source will reduce the reconstructing cost of the multicast tree.

For instance, as Fig. 6, MN₁ was the multicast source of group1. After the MN₁ moved from MR3 to near MR2 and obtained a new CoA, it needed to reconstruct the multicast tree. The MN₁ sent the Reconstruct to MR2 to reconstruct the multicast tree. After receiving the Reconstruct, the MR2 looked for the record in its Multicast Table. Then, the MR2 discovered that the upstream address records were different between its Multicast Table and the Reconstruct. The MR2 substituted "MN₁_CoA" from the Reconstruct for "TLMR_CoA" from the Multicast Table, set the Forward bit to 1, and forwarded the Reconstruct to the neighbor nodes exclude the upstream node. When MR5 received the Reconstruct and looked for its Multicast Table, it discovered the upstream address was identical, and the Forward bit is 0. Then the MR5 will not forward the Reconstruct. Others utilized the same rules to reconstruct the multicast tree.

Fig. 6. The Location Change of the Multicast Source.

As mentioned above, the multicast source understands its mobility by renewing the CoA and requires to reconstruct the multicast tree. But the multicast source will not renew the CoA while the MR is moving with the multicast source. The mobility does not result in reconstructing the multicast tree. Therefore, when the MR renews its CoA should inform the multicast source to reconstruct the multicast tree. At the moment, the MR will send the Init involving the Group ID to the Upstream Node recording in the Multicast Table. After the upstream node receiving the Init, if the upstream node is the multicast source of this group, it will forward the Reconstruct to reconstruct the multicast tree. Otherwise, according to the Upstream Node address recorded in the Multicast Table, the node forwards the Init until the multicast source receives and reconstructs the multicast tree.

Fig. 7 is an example of the MR mobility with the multicast source. The MR3 moved with MN1 as the multicast source from MR1 to the near MR2 and obtained a new CoA. When the MR3 obtained the new CoA, the MR3 should notice the upstream node MN1 to reconstruct the multicast tree. At the moment, the MR3 sent the Init to MN1 according to the Multicast Table. The MN1 as the multicast source will reconstruct the multicast tree after receiving the Init.

Fig. 7. The MR Carries the Souce to Change the Location.

In the NEMO environment, if a mobile node wants to be another multicast source to transfer multicast packets, it can utilize this wireless constructure and follow the MSM protocol to create the multicast tree and construct the multicast group. This source can use the same Multicast Table in the MR and combine the different group id to the same Query to save the number of the packages. This benefit is very obvious than other multicast protocols.

We draw a brief flow diagram, Fig. 8, to describe roughly the process of the MSM protocol. Another way, the MSM protocol ignores the risk of network security and will discuss in the future.

Fig. 8. The brief flow diagram of the process of the MSM protocol

4. Performance Evaluations And Analyses

The performance evaluations and analyses of MSM are discussed in the NEMO scene. Three multicast routing protocols, MSM, ODMRP, and ODMRP-LR are selected as the performance compared protocols. These three protocols are similar for multicast in the NEMO environment. In the specifications, these three protocols stipulate both the query and response packets required to maintain the multicast tree. In terms of the MSM protocol, the query packet is referred to as Query; the response packet is referred to as Report. To avoid the confusion for the analysis discussion, we have the same terms to represent the message packets for the other protocols. That is, for the compared protocols, ODMRP and ODMRP-LR, the query packet is called Query and the response packet is called Report. We evaluate the transmission hop number of Query and Report to analyze the performance of the multicast protocols. The transmission hop number of the multicast maintain signal messages Query/Report is the load performance evaluation issue in this section.

4.1 The analysis of the topology

In the NEMO environment, the multicast protocols are all based on the tree-based structure. To obtain the influences of the topology of the multicast tree, we analyze the multicast tree in the grid topology. To facilitate analysis and observation, we focus on the atomic 3x3 and 4x4 grid topology, such as shown in Fig. 9 and in Fig. 12. The node number of the 3x3 grid topology is odd and the 4x4 grid topology is even. They are different analysis statuses when the TLMR is at the center location or top location of the grid. More complex grids can be simplified from atomic grids, such as the 3x3 and 4x4 grid topologies.

Fig. 9. The 3x3 Grid Topology

In Fig. 9, we let the red double-line circular node at the top be the TLMR in the NEMO environment, and the remaining blue single-line circular nodes are all MRs. In this grid topology, we suppose that the communication range of TLMR, MR, and MN are all γ, and the distance between MR and neighboring TLMR or MR is also about γ. That is, the communication range of MR or TLMR can only reach neighboring nodes at the farthest.

In Fig. 9, we utilize the TLMR as the starting point and use the Breadth-First-Search (BFS) algorithm to build the NEMO tree-based structure. The paths of all MRs connect to TLMR in the topology should be the shortest distances, so the solid-line connection in Fig. 9 is necessary. The remaining four unconnected MRs can connect to the two-parent nodes, as the dashed-line shows. As mentioned above rule, there are eight different topological structures after excluding the similar topologies. Those topologies are shown in Fig. 10.

Fig. 10. The 8 Different Topological Structures in the 3x3 Grid Topology.

Next, we configure the source nodes and group members of the multicast tree in the grid topology. We calculate the number of the hops of Query and Report when the MSM, ODMRP, and ODMRP-LR protocols respectively maintain the multicast tree. To eliminate unexpected variables and facilitate analysis, we overlap the group member nodes in the source nodes and the MR nodes. Consider Fig. 11 as an example, the MRs and TLMR are labelled as a unique number. The TLMR is labelled the number 1. We assume that the source node is located in the MR labelled as 7. Two members are located respectively in the MR 3 and 6. The dashed line means the path of the multicast tree. The path from the source node for sending packets to Member 1 is that Source->7->4->5->6->Member 1. This means that the source sends the packet to MR 7 and then forwards it, and Member 1 receives the forwarded packet from MR 6.

Fig. 11. The Relative Location of the Source and the Members.

We can easily calculate the total number of hops that the source node sends a multicast data packet to all group members. The multicast hops from Source to Member 1 are Source- >7, 7->4, 4->5, 5->6, 6->Member 1. The total hop number is 5. In the following subsections, we use this calculation method for analysis.

In Fig. 9, if we distribute a source in the topology and the source node may be attached to any point of the nine nodes, so there are nine situations. Similarly, there are nine possible distributions for all members. For example shown in Fig. 11, if we distribute one source and two group members in a 3x3 grid topology, there are a total of 9x9x9=729 possible situations.

Then, we consider the 4x4 grid topology, as shown in Fig. 12. The establishment of the 4x4 grid topology is the same as that of the 3x3 grid topology. In the MRs numbered 1 to 9 in Fig. 12, each MR can choose one of the two-parent nodes to connect, which means that there are 2^9=512 kinds of topologies in total.

Fig. 12. The 4x4 Grid Topology

We analyze all the topologies for the transmission hop number of Query and Report as the analysis results. We calculate all circumstances, such as all possible node positions and multicast tree topological shapes, and calculate the average of the hop number sent by the three protocols for comparison and discussion.

4.2 The Performance Evaluation of the Multicast Tree Maintenance

First, we observe the hop numbers of the Query. When members only join one group, the hop numbers are the same. In the following the Query analysis, all group members in the topology have joined into two groups. In other words, there are two multicast sources in the topology. We count the average hop number of the Query sent to maintain the multicast tree when the number of members increases. For statistical convenience, we assume that the same MR is connected to only one member. For the multiple members to connect to the same MR, the result of the average hop number is the same as one member in the MR.

Fig. 13 shows the average hop number of the Query for the three protocols when the source and group members assign into the topology of Fig. 11 and Fig. 12. In Fig. 13, the average hop number of the Query for ODMRP and ODMRP-LR are the same, no matter 3x3 or 4x4 grid topology. This is because these two protocols have the same query mechanism. The MSM protocol is better than ODMRP and ODMRP-LR for the Query. In the MSM, the groups share the Query message in the message transmission. Whether there are two groups or more in the subnet, these groups are shared the same Query. The ODMRP and ODMRP-LR both send the Query from the group source to query for each group. Therefore, they need more hops to send the Query. For 4x4 grid topology, the average hop number is larger than that of the 3x3 grid topology. The results are obvious, since the large topology size needs the large route to do the query works.

Fig. 13. The Variety of the Average Hop Number of the Query with the Number of Members Increasing.

When the number of members increases, the average hop number of the Query will increase. The increment of the average hop number of the Query results from the averages coverage of the multicast tree in the topology increase with the members increase. Consider the protocols for the number of the Query, the ODMRP and ODMRP-LR have a higher growth rate than the MSM without the group shared message scheme.

Next, we only consider one group in analysis for the Report message. The transmission hop analysis of the Report does not have the same problem of two groups analysis for the Query. It is easy to observe the differences between protocols in one group analysis.

Fig. 14 shows the transmission hops of the Report when the source and group members assign into the 3X3 and 4X4 topologies. In Fig. 14, when the number of members increases, the average hop number of the Report increases. The Report transmission hops of the ODMRP and ODMRP-LR are the same due to the same Report mechanism, no matter in 3x3 or 4x4 grid topology. The average hop number of the Report of MSM is less than that of ODMRP and ODMRP-LR. This is because that the MSM utilizes the membership report suppression mechanism. When the number of members increases in the topology, the more opportunities to use the suppression mechanism. A larger topology leads to a larger multicast tree, so the average hop number is also larger.

Fig. 14. The Variety of the Average Hop Number of the Report with the Number of Members Increasing.

4.3 Analysis of the Location of the TLMR

In this section, we analyze the impacts of the location of TLMR for the 3x3 and 4x4 grid topology. If the TLMR located at the center position in the specified topology, the maximum path of the multicast tree will be shortened compared with that at the top position.

Fig. 15 is a 3x3 grid topology and the TLMR locates in the center. The way to create the topology is identical to that described in Fig. 9. The only difference is the location of the TLMR. According to the topology establishment method, there are sixteen types of topologies created. After excluding similar topologies, there are four different topological structures, as shown in Fig. 16.

Fig. 15. The TLMR Location at the Center in the 3x3 Grid Topology.

Fig. 16. The 4 Different Topological Structures in the 3x3 Grid Topology with the TLMR Location in the Center of the Topology.

In Fig. 17, the network topology is a 4x4 grid in which the TLMR locates at the center. Since there is no so-called center node in the 4x4 grid topology, we classify the middle four nodes as center nodes. Regardless of middle nodes to be selected as the central node, the wireless connection topologies are affected by the topology angular differences.

Fig. 17. The TLMR Location at the Center in the 4x4 Grid Topology

In Fig. 17, the solid lines is a wireless transmission connection. As the analysis of the top node topology, we can find 2^9=512 different topologies totally.

Fig. 18 shows the average hop number of the Query sent by the multicast protocols when the source and group members assign in the 3x3 and 4x4 grid topology. In the analysis, all group members in the topology also have joined two groups. The transmission lengths for the Query of ODMRP and ODMRP-LP are the unanimous due to the same Query mechanism, no matter in 3x3 or 4x4 grid topology. The Query transmission trend for the TLMR located the center location is similar to that located the top location.

Fig. 18. The Variety of the Average Hop Number of the Sent Query with the Number of Members Increasing.

Fig. 19 shows the Query load results of the TLMR at different locations on the 3x3 grid topology. In Fig. 19, M means that the TLMR locates in the center of the topology, and T means the TLMR sits at the top of the topology. Fig. 19 shows the Query transmission load for the TLMR location at the center of the topology is less than that at the top. These results are because that the TLMR center location has the shorter average distance between the source and group members. That is, when the TLMR locates at the center location, the hop numbers of sending Query are less than those at the top location. For the 4x4 grid topology, we have the same results as Fig. 19.

Fig. 19. The Variety of the Average Hop Number of the Sent Query for the TLMR at Different Location in the 3x3 Grid Topology.

Fig. 20 shows the Report transmission loads of the TLMR at different locations on the 3x3 grid topology. The results are the same as the Query transmission loads in Fig. 19. The messages loads of ODMRP and ODMRP-LR are larger than that of MSM. The Report transmission load at top location is larger than that at center location. Consider Fig. 20 for the MSM protocol of the TLMR at the top and at the center location, the Report transmission loads are closer when the number of members is five. When MSM has more than five members, the Hop numbers of the Report for the TLMR at the top of the topology is less. This is because that the multicast tree utilizes more shared edges of the membership report suppression mechanism.

Fig. 20. The Variety of the Average Hop Number of the Sent Report for the TLMR at Different Location in the 3x3 Grid Topology.

Fig. 21 shows the Report transmission loads of the TLMR at different locations on the 4x4 grid topology. These results show that the average hop number of the Report sent by the multicast protocols. The figure has the same results as Fig. 20. That is, the large size of the multicast topology leads to the large message load. The less hop number of the Report results from the fewer response packets. A most obvious difference between the trend shown in Fig. 21 and Fig. 20 is that the Report message load difference is less than the Query message load for the same TLMR locations. Let’s have a detailed observation for the analysis data for MSM in Fig. 21. When the number of members is 3, the gap of the hop number of the Report is about 1.20 packets between the top location and the center location. When the number of members is 4, the gap becomes 1.01 packets less. When the number of members is 5, the gap is about 0.95 packets. In other words, when the number of members increases, the improvement of the message load for little size of the multicast topology is less. The gap reduction is getting violent for the large number of multicast members. For our inference in Fig. 21, when the number of members increases to a certain amount, the hop number of the Report for the TLMR at the top of the topology will be less than that at the center of the topology. Namely, when the number of the multicast members exceeds a certain amount, the large size of multicast tree topology should have large number of the shared edges with the membership report suppression mechanism. Therefore, the hop number of the Report messages for the large size of topology will be less than that for the little size of topology.

Fig. 21. The Variety of the Average Hop Number of the Sent Report for the TLMR at Different Location in the 4x4 Grid Topology.

5. Conclusion

The MSM protocol provides a reconstruct scheme to reconstruct the multicast tree for the mobility of the multicast source. When the NEMO topology is modified for the mobility of the multicast source, the topology of the multicast tree should be completely destroyed for the disappearance of the multicast source. The main advantage of the multicast routing protocol, MSM, effectively reduces the cost of maintaining the multicast tree in the NEMO. When the MSM protocol maintains the multicast tree, it reduces the hop number of the Query and Report messages. According to the performance analysis, traditional multicast protocols require more hops of the Query and Report to maintain the multicast tree. MSM proposed the multi-group ID shared packet and message suppression mechanisms to reduce the signal message number. Therefore, this article shows that the proposed MSM protocol reduces the resource consume and the network bandwidth. In the performance analysis, we also find that the large number of group members leads the less cost to the large multicast topology size for the large number of shared packets and suppression messages. In the NEMO environment, the MSM outperforms the traditional multicast protocols for the multicast tree maintenance and designed a reconstruct scheme to maintain the multicast tree for the mobility of the multicast source.