KR101407669B1 - network-based mobility management system and method for mobile multicast service handover - Google Patents

Abstract

A network-based mobility management system and a mobile multicast service handover method are disclosed. In a network-based mobility management system according to an embodiment of the present invention, when a mobile node performs a heterogeneous network handover while being provided with a multicast service, a mobile node is excluded and a network directly performs a multicast group join / Performs a routing reset of the cast traffic. Accordingly, the mobile node can support seamless handover of the multicast service traffic used when performing the heterogeneous network handover using the multicast service.

Description

[0001] The present invention relates to a network-based mobility management system and a mobile multicast service handover method,

One aspect of the invention relates to network-based technologies, and more particularly, to network-based mobility management techniques.

Unicasting technology transfers data to one recipient. Broadcasting technology transmits data to all recipients in the network. On the other hand, multicasting technology transmits data to restricted recipients who join the group. In the case of IP multicasting, when a multicast source transmits one data packet, the network copies the source packet to the number of desired recipients, and delivers the copied data packet. Accordingly, it is possible to reduce the overhead to be transmitted by the number of receivers from the source as compared with the case where the packet is not transmitted, and it is possible to save bandwidth because it is not necessary to transmit a plurality of packets on the network.

Various application services using multicast are being provided. As a mobile terminal such as a smart phone rapidly develops, a service range is extended to a moving host rather than a fixed host of a multicast receiver. A mobile host moves between cells from one network to another or within the same network. Accordingly, a multicast technology targeting fixed hosts is required to further process a continuous multicast traffic even in a handover situation.

To use multicast service, multicast group membership protocol should be used. These protocols include Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) protocols. The IGMP / MLD protocol is a signaling protocol for group management that allows a router and hosts to know what multicast group they belong to on a sub-network consisting of one router and several hosts. The IGMP protocol is used in the IPv4 environment, and the MLD protocol is used in the IPv6 environment. The IGMP / MLD protocol was developed based on the wired network environment. Therefore, a modified IGMP / MLD protocol considering wireless mobile network environment has been researched / developed for multicast service in wireless network environment.

In the wireless mobile environment, the security and performance of the multicast service are most affected by the wireless section. The radio section is very limited in resources, and the data transmission speed is much lower than the wired section. The limited environment of the wireless zone also results in the loss of IGMP / MLD protocol messages used between the mobile host and the router to use the multicast service. This situation can occur even in a situation where a mobile host user watches a multicast video, and a handover occurs while a user watches a multicast video, which is a more serious problem It is inevitable to be considered.

Fortunately, even if the IGMP / MLD protocol message lost in the handover situation does not occur, the handover delay time of the multicast traffic may become longer due to the slow data transmission rate of the wireless section itself, This is a phenomenon that is displayed.

According to an aspect of the present invention, there is provided a technique for supporting fast seamless handover of multicast service traffic used when a mobile node performs a heterogeneous network handover using a multicast service.

The network-based mobility management system according to one aspect collects multicast group information, provides the collected information to a handover control agent (HCA), and upon receiving a request from the handover control agent (HCA) And a multicast router (MR) for performing multicast routing between the MN and the mobility information control server (MICS), and for managing multicast group information between the multicast router (MR) A handover control agent (HCA) for supporting multicast traffic handover of the mobile node by performing a cast group re-entry and a cancellation, a multicast group management module for receiving and managing multicast group information from the handover control agent (HCA) HCA) for supporting the multicast traffic handover of the mobile node through communication with the mobility information control server (MICS).

According to one embodiment, in a situation where a mobile node performs a heterogeneous network handover while receiving a multicast service, a mobile node is excluded and a network directly performs a multicast group join / drop procedure and a routing reset of multicast traffic . Accordingly, messages related to multicast group join / unsubscribe occurring in a wireless zone are unnecessary for a situation in which a mobile node performs a heterogeneous network handover while being provided with a multicast service, so that resource utilization of a wireless zone can be increased.

Furthermore, by excluding the mobile node and performing the multicast group join / drop procedure directly by the network, it is possible to secure the reliability of completion of the multicast group joining / leaving procedure, which is a disadvantage of the multicast group join / . Furthermore, it is possible to reduce the delay time required for multicast group re-entry / exit procedures.

Furthermore, since the mobile node can support seamless handover of the multicast service, the mobile node can receive continuous multicast service even if handover is performed while the multicast service is provided.

FIG. 1 is a block diagram illustrating a network-based mobility management system for fast seamless handover of mobile multicast traffic according to an embodiment of the present invention.
2 is a detailed configuration diagram of MR, HCA, and MICS according to an embodiment of the present invention,
FIG. 3 is a flow chart illustrating a process in which an MN performs inter-device communication in a multicast group join according to an embodiment of the present invention;
FIG. 4 is a flow chart illustrating a process in which an MN performs inter-device communication in a multicast group leave according to an embodiment of the present invention;
5A and 5B are diagrams illustrating a process in which an MN that has used a multicast service joins a multicast group according to an embodiment of the present invention between devices in a handover situation in which the MN moves to another access network Flow chart,
6A and 6B are flowcharts illustrating processes performed by the IGMP / MLD unit and the MGMF unit of the MR of FIG. 2 to support seamless handover of mobile multicast traffic according to an exemplary embodiment of the present invention;
FIGS. 7A through 7F are flowcharts illustrating a process performed in the HCA of FIG. 2 to support fast seamless handover of mobile multicast traffic according to an embodiment of the present invention;
8A to 8D are flowcharts illustrating a process performed in the MICS of FIG. 2 to support fast seamless handover of mobile multicast traffic according to an embodiment of the present invention.

Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings. In the following description of the present invention, a detailed description of known functions and configurations incorporated herein will be omitted when it may make the subject matter of the present invention rather unclear. In addition, the terms described below are defined in consideration of the functions of the present invention, and this may vary depending on the intention of the user, the operator, or the like. Therefore, the definition should be based on the contents throughout this specification.

1 is a block diagram illustrating a network-based mobility management system 1 for fast seamless handover of mobile multicast traffic according to an embodiment of the present invention.

Referring to FIG. 1, a network-based mobility management system 1 includes an IP core network 100 and access networks (AN) 110, 120 and 130. The core network 100 includes a Mobility and Information Control Server (MICS) 102, a Converged User Profile Server (CUPS) 104, and a Handover Control Agent ControlAgent: hereinafter referred to as HCA) 107, 108, 109. The MICS 102, the CUPS 104 and the HCAs 107, 108 and 109 are control plane functional devices that support mobility of a mobile node (hereinafter referred to as MN) 140 on the IP core network 100. Access networks (ANs) 110, 120, and 130 each include a multicast router (hereinafter referred to as MR) 112, 122, and 132, respectively.

Specifically, the MICS 102 manages location information on the MN 140 and information on data tunneling and the like for a Correspondent Node (CN) 150 that the MN 140 is currently communicating with . In order to support the MN 140 in which the various access networks 110, 120 and 130 are located at the overlapped positions to select an appropriate access network, an information service through an IEEE 802.21 MIH (Media Independent Handover) And performs management functions. In addition, the MN 140 performs a mobile multicast group information management function. Details of the above-mentioned functions will be described later in Figs. 2, 3, 4, 5 and 8A to 8D.

When the HCA 107 recognizes that the new MN 140 is connected to the access networks 110, 120 and 130, the HCA 107 registers the L2 ID information (MAC address) of the MN 140 and updates the location information (CoA, Care of Address) to request the location registration of the MN 140 to the MICS 102. Also, it manages the mobile multicast group information for the MN 140 and performs communication with the MRs 112, 122, and 132 that perform the multicast function. Details of the above-described functions will be described later with reference to Figs. 2, 3, 4, 5 and Figs. 7A to 7F.

The MRs 112, 122, and 132 and the HCAs 107, 108, and 109 may be physically separated as shown in FIG. 1, but may be physically in the same location according to the implementation method. In the present invention, a physically separated shape will be described. The MRs 112, 122, and 132 basically perform a multicast service function and perform a function of supporting seamless handover of mobile multicast traffic.

2 is a detailed configuration diagram of the MR 20, HCA 22, and MICS 24 according to an embodiment of the present invention.

The MR 20 is connected to the IGMP / MLD unit 200 and the Multicast Group Management Function Unit (MGMF) to support seamless handover of the mobile multicast traffic to the MN 26 Quot;).

The IGMP / MLD unit 200 may transmit IGMP / MLD messages (e.g., ALLOW_NEW_SOURCES or BLOCK_OLD_SOURCES record type of the State Change Report type) reported from the MN 26 to the MR 20 in addition to the basic IGMP / MLD processing function of the MR 20 Message: see RFC 3376). The collected messages are reported to the HCA 22 and the MICS 24 through the MGMF unit 202. In addition, the IGMP / MLD unit 200 processes the multicast group re-entry / cancellation for the specific MN 26 from the HCA 22 via the MGMF unit 202. More detailed functions of the IGMP / MLD unit 200 will be described later with reference to FIG. 6A.

The MGMF unit 202 transmits a control message between the IGMP / MLD unit 200 and the HCA 22. The MGMF unit 202 configures the multicast group re-entry / revoke request message for the specific MN 26 received from the HCA 22 in the form of an IGMP / MLD message. More detailed functions of the MGMF unit 202 will be described later with reference to FIG. 6B.

The HCA 22 and the MICS 24 also include MGMF units 226 and 246, respectively, like the MR 20. The functions of the HCA 22 and the MGMFs 226 and 246 of the MICS 24 are different from those of the MGMF 202 of the MR 20 in detail. The HCM 22 and the MGMF units 226 and 246 of the MICS 24 manage the multicast group information for each MN 26 and transmit and receive messages for handover processing of the multicast traffic of the MN 26 And post-processing functions. The HCA 22 and the MICS 24 include location and handover management units 222 and 242 and signaling processing units (LSP Signaling Forwarding units) 224 and 244, respectively.

3 is a flowchart showing a process in which the MN 30 is performed between devices in a multicast group join according to an embodiment of the present invention.

Referring to FIG. 3, MR_mn 32 denotes a multicast router (MR) to which the MN 30 is connected. MR_cn 34 denotes a multicast router (MR) to which the CN 36 is connected. The CN 36 is a multicast stream server (MSS) that provides a multicast service. The HCA_mn 39 means an HCA that manages the mobility of the MN 30.

The MN 30 to receive a multicast service first performs an initial registration process of the MN 30 to complete a network connection and then transmits a message (IGMP / MLD multicast group join message) for joining a specific multicast group to the IGMP / And transmits it to the network using the MLD protocol (302).

Then, the MR_mn 32 receiving the multicast group join message transmits the multicast group join information of the MN 30 to the HCA_mn 39 while performing the join process for the multicast group (MulticastGroupReqToHCA (SCR, HoA, PoAvif, S, G)) (304). The multicast group subscription information of the MN 30 includes the IP address HoA of the MN 30, the multicast group record type information SCR = allow, the multicast router access port or interface identifier PoAvif, (S, G).

The HCA_mn 39 receiving the MulticastGroupReqToHCA (SCR, HoA, PoAvif, S, G) message 304 stores the received information (Multicast Group & Source Registration) 306 and transfers the stored contents to the MICS 38 (MulticastGroupReqToMICS) 308.

The MICS 38 having received the MulticastGroupReqToMICS message 308 stores the corresponding information (Multicast Group & Source Registration) 310 and delivers a message to the HCA_mn 39 indicating that the process for the information transfer has been completed (MulticastGroupReqToMICSACK) 312 ).

Meanwhile, the MR_mn 32, which has received the multicast group join message 302 from the MN 30, transmits the corresponding information to the HCA_mn 39, and transmits the process for joining the multicast group to the related multicast routers . This follows the normal multicast group join process. The MN 30 receives the multicast service through the multicast network from the CN 36 performing the multicast service and the multicast service utilization information of the MN 30 is received from the HCA_mn 39 through the above- And MICS 38, respectively.

4 is a flowchart showing a process in which the MN 30 is performed between devices in a multicast group Leave according to an embodiment of the present invention.

Referring to FIG. 4, the MN 30 receiving the multicast service transmits an IGMP / MLD multicast group leave message for leaving the multicast group to the network using the IGMP / MLD protocol (402). The MR_mn 32 receiving the multicast group withdrawal message 402 transmits the multicast group withdrawal information of the MN 30 to the HCA_mn 39 while performing the withdrawal process for the multicast group (MulticastGroupReqToHCA (SCR , HoA, PoAvif, S, G)) 404. The multicast group withdrawal information of the MN 30 includes the IP address HoA of the MN 30, the multicast group record type information (SCR = block), the multicast router access port or interface identifier PoAvif, (S, G).

The HCA_mn 39 receiving the MulticastGroupReqToHCA (SCR, HoA, PoAvif, S, G) message 404 finds the multicast group information of the previously stored MN 30 to delete or update the corresponding information (406) To the MICS 38 (MulticastGroupReqToMICS) (408).

The MICS 38 retrieves the received information, deletes or updates the corresponding information (410), and transmits a message (MulticastGroupReqToMICSACK) (412) to the HCA_mn 39 indicating that the processing for the information transfer is completed.

On the other hand, the MR_mn 32 receiving the multicast group withdrawal message from the MN 30 transmits the corresponding information to the HCA_mn 39 as described above, and transmits the process for leaving the multicast group to the related multicast routers . The MN 30 leaves the used multicast service through the above process and the multicast group withdrawal information of the MN 30 is deleted or updated in the HCA_mn 39 and the MICS 38. [

5A and 5B are diagrams illustrating a process in which an MN 30 joining a multicast group joins a multicast group and is generated between devices in a handover situation in which the MN 30 moves to another access network according to an embodiment of the present invention Fig.

5A and 5B, the Old_MR_mn 32a indicates an MR connected before the MN 30 performs a handover, and the Old_HCA_mn 39a indicates that the MN 30 has been connected to the MN 30 before handover, Means the HCA managing the mobility of the mobile terminal 30. The New_MR_mn 32b indicates an MR in which the MN 30 is finally connected by being handed over and the New_HCA_mn 39b indicates an HCA managing the mobility of the MN 30 after the MN 30 performs handover it means.

Referring to FIG. 5A, the MN 30 which is attempting a handover while receiving a multicast service first performs a Layer 2 handover process (Handover? MBT update? LocReg) (500, 502, 504).

Upon receipt of the LocReg message, the MICS 38 determines whether the corresponding MN 30 is receiving a multicast service in the database (Global Binding Table: GBT) (506). As a result of the determination, if the multicast service is not provided, only the handover process is performed. However, if the multicast service is provided, the MICS 38 stores the value of the CoA (Care of Address), which indicates the address of the Old_HCA_mn 39a stored in the database, and the PoAvif, which indicates the connection port or interface identifier of the Old_MR_mn 32a. And updates the new CoA value storing the address value of New_HCA_mn 39b to the database. Thereafter, the MICS 38 transmits to the New_HCA_mn 39b (LocRegACK) 508 the multicast group information together with the fact that the corresponding MN 30 has performed the handover using the multicast service.

The New_HCA_mn 39b having received the LocRegACK message 508 searches 510 the connection port or the interface identifier PoAvif of the router connected to the MN 30 and transmits the New_MR_mn 32b newly accessed by the MN 30, (MulticastGroupReqToMR) 512, which requests the MN 30 to re-enter the multicast group. At this time, a value (Allow) indicating re-entry of the multicast group is set in the parameter (SCR) indicating the multicast group record type information and delivered. The New_HCA_mn 39b that transmitted the MulticastGroupReqToMR message 512 newly registers the multicast group information of the corresponding MN 30 (513).

On the other hand, the New_MR_mn 32b receiving the multicast group re-entry request message of the MN 30 from the New_HCA_mn 39b generates an IGMP / MLD message and executes the re-entry process to the multicast group using this message (514). Through the above-described process, the MN 30 can continuously receive the multicast traffic that it has been using without involvement of the MN 30. When the multicast group re-entry process is completed, New_MR_mn 32b reports completion to New_HCA_mn 39b (MulticastGroupReqToMRACK) (516).

Referring to FIG. 5B, the New_HCA_mn 39b receiving the MulticastGroupReqToMRACK message 516 transmits a message indicating that multicast traffic handover of the corresponding MN 30 is completed to the MICS 38 (Multicasting MobileHandover) 518 ).

The MICS 38 having received the MulticastingMobileHandover message 518 updates 520 the new access port or interface value of the MN 30 to the database and updates the multicast group information of the MN 30 to the New_HCA_mn 39b (MulticastingMobileHandoverACK) (522).

Meanwhile, the MICS 38 transmits a message to the Old_HCA_mn 39a (MulticastGroupReqFromMICSToHCA) (524) requesting the withdrawal of the multicast group used in the Old_MR_mn 32a before the MN 30 handover. MulticastGroupReqFromMICSToHCA message 524 is for releasing resources that are occupied by multicast traffic that is no longer provided in Old_MR_mn 32a. At this time, a value (Block) indicating a multicast group withdrawal and a connection port or an interface value (oldPoAvif) to which the MN 30 is connected are set in a parameter (SCR) indicating the multicast group record type information, .

Next, the Old_HCA_mn 39a receiving the MulticastGroupReqFromMICSToHCA message 524 transfers the multicast group information to the Old_MR_mn 32a (MulticastGroupReqToMR) 526 so that the quick resource release 530 can be executed. Lt; RTI ID = 0.0 > (528). ≪ / RTI >

On the other hand, the Old_MR_mn 32a which has received the multicast group leave request message used by the MN 30 which has moved from the Old_HCA_mn 39a to another access network generates an IGMP / MLD message, And executes the withdrawal process of the multicast group. Through the above-described process, the Old_MR_mn 32a can release the resources used by the multicast traffic, irrespective of the MN 30. When the multicast group withdrawal process is completed, Old_MR_mn 32a reports completion to Old_HCA_mn 39a (MulticastGroupReqToMRACK) (532).

Upon receiving the MulticastGroupReqToMRACK message 532, the Old_HCA_mn 39a transmits a message (MulticastGroupReqFromMICSToHCAAck) 534 to the MICS 38 indicating that the multicast group withdrawal of the corresponding MN 30 is completed.

Upon receiving the MulticastGroupReqFromMICSToHCAAck message 534, the MICS 38 updates the field indicating that the multicast group withdrawal is completed in the database (536).

FIG. 6A is a flowchart illustrating a process performed by the IGMP / MLD unit 200 of the MR 20 of FIG. 2 to support fast seamless handover of mobile multicast traffic according to an exemplary embodiment of the present invention. For convenience of explanation, the reference numerals in Fig. 2 are cited.

6A, the IGMP / MLD unit 200 of the MR 20 transmits an IGMP / MLD function, multicast group join / release information requested to the MR 20 from the MN 26 to the HCA 22 And a function of processing a multicast group join / release message received from the HCA 22. For convenience of explanation, the reference numerals in Fig. 2 are cited.

The MR 20 receives a join or a leave request of a specific multicast group from the MN 26. [ The MR 20, which has received the IGMP / MLD message, transmits the IGMP / MLD message to the IGMP / MLD unit 200. The IGMP / MLD unit 200 receives the IGMP / (600) and starts message processing (602).

The IGMP / MLD unit 200 determines whether the IGMP / MLD message is a message received from the MN 26 or a message received from the HCA 22 (604). Set each case to be known during IGMP / MLD message processing (HCAMessage = true or false) (606,608).

Then, the IGMP / MLD unit analyzes (610) the IGMP / MLD message, extracts (612) the record type in the message, and extracts a multicast group (614), and requests (616) a multicast forwarding path configuration / release. IGMP / MLD protocol and multicast traffic forwarding path configuration / revocation protocol (eg PIM-SM / DM, SSM, etc.) can be used from IGMP / MLD message analysis to forwarding path configuration / release.

The IGMP / MLD unit 200 determines whether the IGMP / MLD message is a message received from the MN 26 or a message received from the HCA 22 (618) (MGMF :: MulticastGroupReqToHCA) 620 to the MGMF unit 202 when receiving the multicast group information report (HCAMessage = false). On the other hand, when the corresponding message is received from the HCA 22 through the MGMF unit 202 (HCAMessage = true), the multicast group setup / release request completion report of the HCA 22 is transmitted to the MGMF unit 202 MGMF :: MulticastGroupReqToMRACK) 622.

6B is a flowchart illustrating a process performed by the MGMF unit 202 of the MR 20 of FIG. 2 to support fast seamless handover of mobile multicast traffic according to an exemplary embodiment of the present invention. For convenience of explanation, the reference numerals in Fig. 2 are cited.

Referring to FIG. 6B, the MGMF unit 202 transmits a control message between the IGMP / MLD unit 200 of the MR 20 and the HCA 22. The MGMF unit 202 analyzes the message received in the idle state 640 (642). At this time, the MGMF unit 202 transmits a message (MulticastGroupReqToMR) requesting the MN 26 to re-enter or cancel the multicast group used by the corresponding MN 26 when the handover situation of the MN 26 occurs, And generates an IGMP / MLD message (644) and transmits it to the IGMP / MLD unit (IgmpMld :: IgmpMldReport) (646).

When the transmitted message is processed in the IGMP / MLD unit 200, the MGMF unit 202 receives the processing result (MulticastGroupReqToMRACK) and transmits the processing result to the HCA 22 (HCA :: MulticastGroupReqToMRACK) (649).

The MN 26 also receives a report on a join request or a leave request of the multicast group requested by the IGMP / MLD unit 200 (MulticastGroupReqToHCA) and reports it to the HCA 22 HCA :: MulticastGroupReqToHCA) (648).

FIGS. 7A through 7F are flowcharts illustrating a process performed by the HCA 22 of FIG. 2 to support fast seamless handover of mobile multicast traffic according to an embodiment of the present invention. For convenience of explanation, the reference numerals in Fig. 2 are cited.

Referring to Figures 7A-7F, the MGMF portion 226 of the HCA 22 may be functionally linked or integrated with other blocks 220,222, 224 of the HCA 22, which may vary depending on the method of implementation. The HCA 22 collects multicast group management information for each MN 26 between the MR 20 and the MICS 24 and transmits the multicast group management information to the MN 26 when a handover situation of the MN 26 occurs And supports the mobility of multicast traffic so that the multicast service used can be seamlessly used.

To this end, the HCA 22 connects to a mobile node binding table (MNT), which is a database, and creates a message socket and enters a message reception waiting state. Then, upon receiving the message, it analyzes the message and processes the required function for each message. There are three types of messages: ACK, Report, and Request. Hereinafter, the message processing process of the HCA 22 for each message received in the message reception standby state will be described in detail with reference to FIGS. 7A to 7F.

7A, the HCA 22 receives a join or leave request processing message of a specific multicast group requested by an MN 26 from the MR 20 in a message reception waiting state (MulticastGroupReqToHCA ) 700. The HCA 22 having received the MulticastGroupReqToHCA message 700 stores / updates / deletes 704 the multicast group information of the corresponding MN 26 and reports this content to the MICS (MICS :: MulticastGroupReqToMICS) 704, . After the reporting, the HCA 22 enters a state of waiting for receiving a message again (706).

7B, when the HCA 22 receives an ACK message (MulticastGroupReqToMICSACK) 710 from the MICS 24 (MICS :: MulticastGroupReqToMICS) 704 in a message reception waiting state, the HCA 22 Stores / updates / deletes the multicast group information of the MN 26 (712), and enters the message reception waiting state (714).

Referring to FIG. 7C, the HCA 22 transmits a Location Registration (LocReg) message to the MICS 24 when a handover situation of the MN 26 occurs in a message reception waiting state, and receives a LocRegAck message in response thereto (720).

If the multicast group information of the MN 26 is included in the LocRegAck message 720, the HCA 22 determines that the MN 26 has handed over using the multicast service, (722) the port or interface identifier value of the MR 20 to which the mobile station 20 has connected.

Subsequently, the HCA 22 transmits a multicast traffic handover process request message according to the handover of the MN 26 to the MR 20 connected to the MN 26 (MR :: MGMF :: MulticastGroupReqToMR) ( 724). The information field indicating that the multicast traffic handover processing request due to the handover has been completed is updated in the MBT (726).

7D, the HCA 22 receives a response message (MulticastGroupReqToMRACK) for the multicast traffic handover processing request according to the handover of the MN 26 from the MR 20 in the message reception waiting state (730) .

Next, the HCA 22 updates (732) the multicast traffic handover processing status field of the MBT and determines whether the corresponding message is a re-entry request (SCR == allow) or a cancellation request (SCR == block) (734).

As a result of the determination, if it is a response to the re-entry request, the MICS 24 transmits a multicast traffic re-entry information processing request message (MICS :: Multicasting Mobile HANDOVER) 736 according to the handover of the MN 26 and enters a waiting state (739).

On the other hand, when the HCA 22 receives a processing completion message (MulticastGroupReqToMRACK (SCR == block)) from the MR 20 that has processed the MR :: MGMF :: MulticastGroupReqToMR message 752 of FIG. 24) transmits a multicast group release processing completion response message (MICS :: MulticastGroupReqFromMICSToHCAACK) (738), and enters the message reception waiting state again (739).

7E, the HCA 22 receives the MICS :: MulticastingMobileHandover message 736 from the MICS 24 and receives a MulticastingMobileHandoverACK message 740 in a message waiting state. (742) the MBT multicast traffic handover processing status field and enters the message reception waiting state (744).

7F, when receiving the multicast group release processing request message (MulticastGroupReqFromMICSToHCA) from the MICS 24 to release the resources occupied by the multicast traffic of the previous MR, the HCA 22 updates the corresponding MR (MR :: MGMF :: MulticastGroupReqToMR) to the MBMS server 20 (752), updates the MBMS multicast traffic handover processing state field (754), and enters the message reception waiting state (756).

7A to 7F, the HCA 22 manages multicast group information for each MN 26 between the MR 20 and the MICS 24, and handover occurs to the MN 26 The multicast group re-entry and the cancellation can be performed without involvement of the MN 26 to support the fast and seamless multicast traffic handover of the MN 26. [

8A to 8D are flowcharts illustrating a process performed by the MICS 24 of FIG. 2 to support fast seamless handover of mobile multicast traffic according to an embodiment of the present invention. For convenience of explanation, the reference numerals in Fig. 2 are cited.

8A to 8D, the MGMF unit 246 of the MICS 24 may be functionally connected or integrated with another block of the MICS 24, which may appear differently depending on the method of implementation. The MICS 24 manages the multicast group management information for each MN 26 and manages the multicast group management information for each MN 26 so that the MN 26 can seamlessly use the multicast service used by the MN 26 when a handover situation of the MN 26 occurs. And supports the mobility of multicast traffic with the HCA 22.

First, the MICS 24 connects the database GBT and enters a state of waiting for a message reception. Then, upon receiving the message, it analyzes the message and processes the required function for each message. There are three types of messages: ACK, Report, and Request. Hereinafter, the message processing process of the MICS 24 for each message received in the message reception standby state will be described in detail with reference to FIGS. 8A to 8D.

8A, the MICS 24 receives (800) a Location Registration (LocReg) message from the HCA 22 in a message reception wait state, extracts the L2 ID and CoA of the MN 26 from the received message 802) to search for a GBT (804), and determines whether a Binding item of the corresponding MN (26) exists (806).

As a result of the determination, if the Binding item of the corresponding MN 26 does not exist, a new registration process is performed (808) and a message reception waiting state is entered (810). On the other hand, if there is a Binding item of the MN 26, it is determined whether the MN 26 is using the multicast service (812).

As a result of the determination, when the multicast service is in use, the MICS 24 performs a handover process including the multicast traffic of the MN 26 (814), and the MN 26 transmits the multicast service to the HCA 22 (HCA :: LocRegACK (HoA, S, G)) is transmitted (816). At this time, if the corresponding MN 26 transmits multicast group information in use, the MICS 24 enters the message reception waiting state again (810). If the multicast service is not being used, a non-MN multicasting handover procedure is performed (818), and a message reception waiting state is entered again (810).

8B, the MICS 24 receives a join or a leave request process message (MulticastGroupReqToMICS) of a specific multicast group requested by an MN 26 from the HCA 22 in a message reception waiting state (820), the MICS 24 performs a save / delete / update operation on the GBT 822, transmits a processing completion response message (HCA :: MulticastGroupReqToMICSACK) to the HCA 22 (824) And enters the standby state (826).

8C, the MICS 24 indicates that the re-entry process for the multicast group used by the MN 26 from the new HCA 22 handed over by the MN 26 in the message reception waiting state is completed The MICS 24 updates the GBT 832 and transmits a processing completion response message (HCA :: MulticastingMobileHandoverACK) to the new HCA 22 (834). Then, a message (HCA :: MulticastGroupReqFromMICSToHCA) indicating a multicast group release request being used by the MN 26 is transmitted (836) to the HCA 22 before the MN 26 performs handover, (838).

8D, the MICS 24 receives a multicast group release request processing response message (MulticastGroupReqFromMICSToHCAACK) that the corresponding MN 26 is using from the HCA 22 before the MN 26 performs handover in the message reception waiting state Upon receipt (840), the GBT is updated (842) and again enters a message reception wait state (844).

The MICS 24 manages the multicast group information for each MN 26 as described above with reference to FIGS. 8A to 8D. When a handover occurs to the MN 26, the MICS 24 manages multicast group information for the MN 26 together with the HCA 22, The multicast group re-entry and the cancellation are performed without involvement of the MN 26 to support the fast and seamless multicast traffic handover of the MN 26. [

The embodiments of the present invention have been described above. It will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims. Therefore, the disclosed embodiments should be considered in an illustrative rather than a restrictive sense. The scope of the present invention is defined by the appended claims rather than by the foregoing description, and all differences within the scope of equivalents thereof should be construed as being included in the present invention.

Claims (12)

delete delete delete delete delete delete A new HCA performs a second layer handover process to discover the mobile node as a mobile node receiving a multicast service is handed over;
The new HCA sending a location registration message to the MICS for location registration of the mobile node; And
The MICS checks whether the mobile node corresponds to the multicast group using the location information of the mobile node, and transmits a location registration response message to the new HCA together with the multicast group information of the mobile node ;
And transmitting the multicast service to the mobile terminal. delete delete 8. The method of claim 7, wherein the handover-
The new HCA having received the location registration response message transmits a multicast group re-entry request message to a new router accessed through the handover process;
The method of claim 1, further comprising: 11. The method of claim 10, wherein the handover-
Joining a multicast group as a new router receiving the multicast group re-entry request message transmits a group join message to a router of the core network using the multicast group information of the mobile node;
The method of claim 1, further comprising: The method of claim 11, wherein the multicast service providing method at the time of handover comprises:
The MICS sending a multicast group withdrawal request message including multicast group information to a previous HCA before the mobile node handover;
The previous HCA sending a multicast group withdraw request message to a previous router;
Leaving a multicast group as a previous router transmits a join / withdraw message to a router of the core network according to the multicast information of the mobile node; And
When the previous HCA receives the group withdraw response message from the previous router, deletes the mobile node information and notifies the MICS that the group withdrawal is completed;
The method of claim 1, further comprising:

Images