group and then send a DBT update message2; at the same time N3 will discover that it is
no more a BNR. Hence, this DBT needs update by removing N3 as a BNR and inform
the upstream BNR (N2) of this update. Upon receiving the update message, N2 will
update its MFT table by removing the N3 entry and adding an entry for M1 as a new
branch served by N2. This update process is the same process used in SReM for leaving a
receiver with DBT update. The Rm_in message sent by x to the new point of attachment
(M3) will not cause any DBT changes.
Figure 5.2 Roaming process (case 2)
Nodes |
MFTs | |
Before x roaming |
Afterx roaming | |
S (Source) |
MTI | IP_N1 |
unchanged |
N1 |
MTI | IP_N3 &IP_M4 |
MTI | IP_N2 &IP_M4 |
N2 |
non BNR |
MTI | IP_N3 , IP_M3 |
N3 |
MTI | IP_M1 & IP_M2 |
unchanged |
Roaming messages (Rm in,Rm out)
Moving direction
In case 2 shown in Figure 5.2, when the mobile receiver x detects that it is moving from
oLMR(M2) domain to a nLMR(M3) domain, it will send a roaming messages Rm_out to
M2 and Rm_in message M3. Due to x is the first member of the multicast group
connecting through M3, M3 will set up a MDT for the multicast group and
simultaneously send a DBT update message (as mentioned above, it might be a modified
RqM or Rm_in) towards the multicast source. One of BNRs(N1) in the existing DBT
will receive the DBT update message. N1 will then be responsible of the DBT update
process by the use of the pair of BNMs messages. Meanwhile, all the MFTs at the BNRs
2 As aforementioned, the DBT update message could take a form of modified RqM message or directly use
the rm_out message.
107