Implementation of M3U on NS-3 for source mobility support in SSM

Currently in NS-3, there is no support for IP multicast dynamic membership (i.e., IGMP or MLD) where an IP node can join or leave a multicast group. In NS-3 reception of multicast datagrams was only possible by simply enabling static multicast routing on an interface leading to receiver or on a system as whole. This makes it impossible for a receiver to dynamically join or leave a multicast session. Since dynamic membership is central to the design and operation of the M3U, a multicast group management protocol which operates similarly to IGMP protocol was first developed for the M3U simulation. The IGMP protocol implemented uses two types of messages; IGMP-Join and IGMP-Leave for joining or leaving any multicast group/channel respectively. Details of each of these messages are as follows:

• IGMP_Join message: RCST1; IGMP-Join_Req; Mcast group addr; mS1; src IP addr

• IGMP_Leave message: RCST1; IGMP-Leave_Req; Mcast group addr; mS1; src IP addr

network

Where RCST1 = RCST permanent identification (ID), Mcast group addr = multicast group address that the RCST is requesting to join/leave, mS1 = permanent ID of mobile multicast source that the RCST is requesting to receive or stop receiving (leave) traffic from, src IP addr = mobile source IP address. The development of this IGMP-like protocol in NS-3 was achieved here by making appropriate modification to the udp-echo-server.cc file in the NS-3 source tree.

The M3U database has 3 tables:

• rx-table: Keeps a record of all multicast receivers (i.e.,

RCSTs/mRCSTs/GWs) and their associated details within the satellite network.

• src-table: Keeps the record of all multicast sources and associated details within the satellite network.

• mgroups-table: Keeps the record of all multicast groups which have at least one receiver within the satellite network.

Upon reception of an IGMP_Join or IGMP_Leave message from a RCST/GW, the M3U processes the message and extracts the required information and stores it in the appropriate table. Tables 6.2, 6.3 and 6.4 show the detailed information (or parameters) stored on the rx-table, src-table and mgroups-table respectively.

Table 6.2 Details of rx-table

rx_ID rx_name rx_IP rx_CoA mgroup src_CoA

1 RCST1 12.1.5.10 12.1.5.10 232.5.10.1 12.1.1.2 2 RCST2 12.1.5.11 12.1.5.11 232.5.10.1 10.1.1.55

Table 6.3 Details of src-table

Table 6.4 Details of mgroups-table

Where rx_ID, src_ID and mg_ID = table ID given to a specific receiver, source or multicast group; rx_name, src_name = permanent name or ID of the receiver or source; rx_IP, src_IP = permanent or home IP address of the receiver or source; rx_CoA, src_CoA = CoA of mobile receiver or source; mgroup, mg_address = multicast group address.

Figure 6.5 Block diagram of M3U implementation in NS-3

Figure 6.5 shows the block diagram of the overall implementation of the M3U developed in NS-3.

The reception of an IGMP packet at the NCC/M3U triggers the NCC to request the multicast source (mRCST) to open a multicast connection to multiple multicast destinations (i.e., NCC initiated point-to-multipoint connection [83]).

Mobile multicast source IGMP Database M3U NCC RCST₁ Multicast Traffic rx-table mgroups-table src-table Point-to-multipoint connection establishment Request/Response RCST_n - - - - Receiving RCSTs

src_ID src_name src_IP src_CoA mgroup

1 mS1 12.1.1.2 12.1.5.20 232.5.10.1 2 mS2 10.1.1.55 10.1.1.55 232.5.10.1

mg_ID mg_address

network

From the IGMP Join/Leave messages presented above, any satellite terminal requesting to receive IP multicast traffic from sources within the satellite network knows the permanent ID of the source as well as its IP address. Here, it is assumed that the requesting RCST/GW already knows the multicast source it wants to receive traffic form. So, when the NCC receives an IGMP Join report, the M3U identifies the source using the source permanent ID contained in the IGMP report as well as it’s IP address. The inclusion of the source permanent ID in the IGMP Join/Leave message is very important for the proposed M3U- based source mobility support as it helps to identify the mobile source no matter whether it is at home or foreign network (home IP address or CoA).

Initially, when the mobile multicast source is at its home network, the src_CoA is equal to the src_IP (permanent home IP address). The src_CoA column in src- table (Table 6.3) indicates the active IP address of the mobile multicast source. The src_CoA column in the Table 6.3 is used as the foreign key [84] in rx-table (Table 6.2). This implies that a change in any value of src_CoA in Table 6.3 (during a GWH/SH) will automatically update the corresponding value in Table 6.2. Any changes in the value of the src_CoA in Table 6.3 triggers the M3U to issue SIUM to all receivers within the satellite network, thus preventing them from sending IGMP report for re-subscription after each GWH/SH. This saves satellite bandwidth resources.

6.2.3 Simulation architecture

Figure 6.6 shows the architecture used for the simulation in NS-3. Beam 1 (B1) and Beam 2 (B2) are served by different GWs and so, GWH will have to take place over the overlapping area of the two beams as the mobile multicast source moves from B1 to B2.

Figure 6.6 Simulation scenario

Table 6.5 shows the simulation parameters used [11, 85, 86].

Table 6.5 Simulation parameters

The simulation beam radius of 5 Km does not reflect the radius of a real satellite beam. The 5 Km is the radius of a wireless terrestrial network in NS-3 that was used in place of a satellite network. However, the wireless links were set to have real satellite data rate and propagation delay. Considering the performance metric that was to be measured (e.g., GWH latency, packet end- to-end delay, etc.) and the fact that these were to be measured for just one GWH, a simulation beam radius of 5 Km will not affect the results.