Method for managing multicast subscribers in a mobile network

The present invention relates to a method for managing multicast subscribers in a mobile network.

[0002] Multicast is traffic that is widely used within the Internet. Multicast traffic saves network resources by sending data packets within the same route only once according to the content of the traffic, rather than being sent multiple times according to the number of different subscribers. Similarly, multicast traffic can be used within a mobile network to save network resources. Due to the mobility of the subscribers within the mobile network, the multicast groups at the nodes of the network vary dynamically, so there is only a one-way connection between the system and the subscribers. Therefore, it is difficult to confirm the dynamic fluctuation of the multicast group members in the current node. Currently, the typical way to perform multicast in a mobile network is to manage the subscribers in a multicast group by querying the subscriber's data (ie, the HLR in the mobile network (ie, mobile network HLR). To determine the distribution of subscribers within a multicast group by querying the subscriber data stored in the home location register), and then forwarding for each subscriber. path) is set separately. The dynamic distribution of the members in the group within the network is obtained by querying the HLR, and the HLR is queried each time a multicast data packet is received to determine the forwarding path. Will be done. Such a method degrades processing efficiency and can result in overload in the HLR. Furthermore, since each subscriber exclusively occupies the forwarding path and the multicast mode is basically a combination of unicast traffic within the mobile network, the wireless channel is required to carry out the multicast traffic by the above method. The result is that it is established and deactivated without interruption, and therefore conventional methods for managing multicast subscribers in a mobile network significantly affect and consume resources in the mobile network.

[0003] The key to overcoming the above problem is the topological distribution of subscribers in the network. The distribution) is to be determined in addition to the transfer route. In the Internet environment, the conventional method is to establish the topology of a multicast subscriber group in the network by periodically sending inquiry packets and receiving response messages by the system. A similar method is used in mobile networks (ie, establishing a forwarding table for multicast subscribers by periodically querying the current state of the multicast subscriber group at the node). This allows the network and radio resource occupancy to increase exponentially with increasing subscribers in the group (to the local database at the nodes of the network) if the current location and status of the subscribers is determined through paging. If the multicast route is determined through queries, the query requests and network resource occupancy of the entire network will increase rapidly as the number of nodes increases). In addition, processing efficiency declines with increasing subscriber groups due to the increasing number of inquiries to be processed at the node (for mobile subscribers, real-time fluctuations in the current distribution of subscribers within the group. Since it is difficult to obtain by the inquiry method of, it is not possible to adjust the forwarding route for multicast data in a timely manner). At the same time, the movement of subscribers makes the total number of subscribers at the nodes of the network uncertain, so either point-to-multipoint channels should be used for the wireless interface, or point-to -point) It is difficult for the wireless interface side to determine whether to use the channel.

[0004] In conclusion, an effective solution for the application of multicast traffic in mobile networks is not yet available.

[0005] An object of the present invention is to provide a highly effective method for managing multicast subscribers in a mobile network in order to improve the utilization efficiency of system resources. ..

[Means for Solving the Problems] The method for managing multicast subscribers in a mobile network provided in the present invention in order to achieve the above object is (1) related to multicast traffic. The data are multicast-related record data and multicast route data.<u style="single">And categorize</u>, The multicast-related recorded data<u style="single">Multicast traffic that determines subscriber membership within a multicast subscriber group</u>System for inquiries<u style="single">General Packet Radio Service (</u><u style="single">General Packet Radio Service</u><u style="single">: GPRS) Serving GPRS Support Node (</u><u style="single">Serving GPRS Support Node</u><u style="single">: SGSN)</u>On the other hand, the multicast route data is stored in<u style="single">Multicast data forwarding route</u>In order to determine the stage, which is stored in the system hierarchically, and (2) when the multicast subscriber joins the multicast group or when the multicast subscriber leaves the multicast group, in the system. The hierarchical multicast route data and<u style="single">The stage of correcting the multicast-related recorded data and</u>(3) Multicast subscribers<u style="single">Move</u>In the network<u style="single">Location registration</u>If you do<u style="single">While the multicast-related recorded data does not change, the multicast route data is updated as appropriate, and when the multicast subscriber updates the location in the mobile network, it is determined whether or not the location update is inside the original SGSN. , If the location update is inside the original SGSN, the multicast-related recorded data does not change, but if the multicast route data is updated appropriately and the SGSN subscriber moves to another SGSN, the subscriber's multicast-related recorded data Is recovered from the original SGSN by another SGSN, while providing a step of appropriately updating the multicast route data.</u>[0007] The method further comprises the following: The topological structure of the mobile network allows the nodes of the network to be a top-to-bottom tree structure when multicast traffic is carried out. The Serving GPRS Support Node (SGSN) of each General Packet Radio Service (GPRS) is assigned to one or more Radio Access Networks (RANs). Each RAN corresponds to one SGSN).

[0008] In the step (1), the multicast route data is classified into several layers (that is, two layers) for storage in the system, and the data in the first layer is the received multicast data. The data in the second tier is stored in the GGSN (Gateway GPRS Support Node) to record how the multicast data is forwarded to the SGSN, while the received multicast data joins the multicast data. Stored in the SGSN to record how it is transferred to the user cell and to act as a reference to the transfer mode for multicast data.

The method of the present invention further comprises: The GGSN multicast route table is for recording how the received multicast data forwards the multicast data to the SGSN. In addition, such a table is established in the GGSN node and is used to store the multicast groups that can be broadcast within the GGSN'group number (<u style="single">Group Number</u>)'To identify the'Traffic Node'field, which is used to store the destination SGSN in which multicast data can be broadcast within the GGSN, and whether the record has been updated. It has an'Update Flag'field used for.

[0010] The SGSN multicast route table is for recording how the received multicast data forwards the multicast data to the subscriber cell and to serve as a reference to the forwarding mode for the multicast data. Established at the node of the SGSN, the table is used to store the'group number'field used to store the multicast groups that can be broadcast within the SGSN and the GGSN corresponding to the multicast group. A'Gateway Node'field, a'Cell' field used to store destination cells to which multicast data can be broadcast within the SGSN, and an optional field. , The'Amount of Subscribers' field used to store the total number of multicast group subscribers in the destination cell, and the'update flag used to identify if the record was updated. 'Equipped with a field.

[0011] According to the features of the present invention, the multicast data is stored in the system in order to determine how the multicast data is transferred and to determine the cell to which the multicast data is transferred. It is classified into several layers for the purpose. When a multicast subscriber joins a multicast group or exits a multicast group, the hierarchical multicast route data in the system and the multicast-related recorded data are appropriately modified. To. At the same time, when the multicast subscriber performs location registration or location update in the network, the hierarchical multicast route data is appropriately updated, whereby the present invention has the following advantages: 1. Multicast subscriber When the location is registered or updated, the multicast route data is updated as appropriate, so that neither extra radio resources nor network resources are occupied. Network resources and radio resources are not consumed as the number of nodes and groups increases, which further reduces the occupancy of network and radio resources. 2. Every time the multicast subscriber updates the location, the data in the multicast route table is updated in a timely manner. Therefore, the data in the multicast route table reflects the dynamic variation of the multicast subscribers in the group. Compared to the periodic query method, this method can further ensure that the multicast route table reflects the topological variation of the multicast subscribers in the group. 3. Since the multicast route table remembers the total number of subscribers in each cell, the forwarding mode for radio resources can be determined directly. Compared to traditional methods where the total number of subscribers in each cell is evaluated through pre-paging, this method does not result in severe radio resource depletion as the number of subscribers increases. Four. This method stores multicast data hierarchically and provides an update method so that any failure or data on any node can be automatically recovered, and the reliability and security of the multicast routing table. Is improved. At the same time, hierarchical management of the multicast routing table reduces the complexity of individual nodes processing and managing the routing table, and improves the processing efficiency and accuracy of the routing table. 5. Since the other multicast-related data is not included in the multicast route table, the other multicast-related data is separated from the data in the multicast route table to be processed, so that when the route is forwarded. Processing efficiency at the node is greatly improved without querying the subscriber data. At the same time, the heavy waste of network resources due to joint responsibility in the conventional inquiry method is avoided.

BEST MODE FOR CARRYING OUT THE INVENTION The present invention will be described in more detail with reference to the drawings and the following embodiments.

[0013] With reference to FIGS. 2 and 3, the network is typically a gateway GPRS support node (GGSN) 2, a serving GPRS support node (SGSN) 3, a radio access network (RAN) 4, and a mobile station 5. And.

[0014] A specific multicast subscriber group can always be considered to be connected to a specific GGSN group when viewed from the SGSN side. In the actual case, the GGSN2 receives the multicast data through the external network 1 and transfers the multicast data to the SGSN3, and then the SGSN3 transmits the multicast data to the mobile station 5 through the RAN4. How many to ensure that an SGSN is only associated with a particular GGSN for a particular multicast subscriber group to avoid receiving the same multicast data from several GGSNs and wasting network resources. Optimization strategy (optimization) Strategies) are available, and the topology structure of such mobile networks is shown in Figure 2. In Figure 3, for multicast data, the same set of multicast data can actually come from different SGSNs due to the many-to-many relationship between SGSNs and RANs, which causes the RANs to You may receive the same data from different nodes. If the method is used to manage multicast data and routes without any simplification of the network topology structure, it will result in wasted system resources and chaotic management. Therefore, regarding the logical relationship between the nodes in Fig. 3, the relationship between SGSN and RAN should be simplified so that it is a one-to-many relationship as shown in Fig. 2. Through determining the topology structure of the mobile network, the nodes in the network form a superior-to-substrate tree structure (ie, each SGSN in the network corresponds to one or more RANs. On the other hand, each RAN corresponds to only one SGSN). Taking Fig. 3 as an example, it is necessary to change the network-like topology structure to a tree-like topology structure.

[0015] For example, in general one-to-one data transmission, the data of the RAN subscriber registered in node E is usually subjected to the SGSN of node B and the SGSN of node C according to the original node registered by the subscriber. It can be transmitted via the SGSN and the SGSN of node D. In multicast data transmission, the data of the RAN subscriber registered in node E can be transmitted only via the SGSN of node B. In this way, each RAN can be associated with only one SGSN, which transforms the network topology of FIG. 3 into the form of a tree-like topology structure as shown in FIG. In this way, the RAN subscriber registered at node E can correspond to two nodes, the SGSN of node C and the SGSN of node B, in which case the former is for handling normal traffic. Used and referred to as'registered SGSN', the latter used to handle multicast traffic and referred to as'multicast SGSN'.

[0016] FIG. 1 is a flowchart of an embodiment of the present invention. According to FIG. 1, data related to multicast traffic is classified into two formats: multicast-related recorded data and multicast route data. The multicast-related record data is used to store information related to subscribers who have joined the multicast subscriber group and to make inquiries about multicast traffic instead of forwarding multicast data, thereby multicast. The distribution of subscribers within the subscriber group can be determined. Data is stored in both the HLR and SGSN to avoid repetitive queries to the HLR and overloading of the HLR. The multicast route data is used to determine how a node transfers data within the topology structure of the network. Multicast route data is used to determine the transfer route of data, and a hierarchical storage method is used in the present invention. The basic concept in managing multicast route data is that in order to maintain and update multicast route data, mobile network characteristics (ie, the location of subscribers that require registration, and, if changed, need to be updated. It is to use the position of the subscriber. Multicast route data is only relevant to the topological distribution of subscribers in groups within the network and has nothing to do with the actual information of each subscriber.

[0017] The multicast-related recorded data and the multicast route data complement each other, and thus it is possible to determine not only the topological distribution of the subscriber group at the node of the network but also the distribution of the subscriber at the node of the network. Therefore, high efficiency and effectiveness regarding multicast data transfer can be guaranteed. Due to the simple management of multicast-related recorded data, the present invention is primarily related to the management of multicast route data.

[0018] Specifically, in order to better manage the multicast route data, the multicast route data is classified into two layers, and the data in the first layer is such that the received multicast data transfers the multicast data to the SGSN. The data in the second tier is stored in the GGSN (Gateway GPRS Support Node) to record how it is forwarded, while the data in the second tier is how the received multicast data transfers the multicast data to the subscriber cell. Stored in SGSN to record whether to transfer. The multicast route data stored in the SGSN tells the total number of subscribers whether one-to-many channels or one-to-one channels are used for the air interface when forwarding multicast messages to cells. Therefore, the total number of subscribers within each cell can be further included to determine.

[0019] Therefore, a GGSN multicast route table is established at the nodes of the GGSN to record how the received multicast data forwards the multicast data to the SGSN, and the table is broadcast within the GGSN. Records are updated with the'group number'field used to store multicast groups that can be communicated and the'traffic node' field used to store destination SGSNs within which multicast data can be broadcast within the GGSN. It has a'update flag'field that is used to identify whether or not it is.

[0020] The SGSN multicast route table is established at the SGSN node to record how the received multicast data forwards the multicast data to the subscriber cell, and the table is broadcast within the SGSN. Multicast data can be broadcast within the SGSN with the'group number'field used to store the multicast groups that can be communicated and the'gateway node' field used to store the GGSN corresponding to the multicast group. The'cell'field used to store the destination cell, the'total number of subscribers' field used to store the total number of multicast group subscribers in the destination cell, and whether the record has been updated. It has an'update flag'field used to identify it.

[0021] For example, two subscribers who participated in the subscriber group 100 exist in the first SGSN and the second SGSN, respectively, and the subscriber group 100 corresponds to the first GGSN according to the optimization policy. , The following GGSN multicast route table is established in the 1st GGSN.

[table 1]<img file="JP4115852B2_D0001.tif" />The following SGSN multicast route table is established in the first SGSN.

[Table 2]<img file="JP4115852B2_D0002.tif" />[0023] Regarding the received multicast data with'group number 100', the first GGSN queries its own GGSN multicast route table, and the subscriber with'group number 100'is the first SGSN and the second SGSN. It is judged that it is distributed in. The first GGSN then forwards the multicast data to the first SGSN and the second SGSN. When receiving multicast data with'group number 100', the first SGSN queries its own multicast routing table and decides to forward the multicast data to C1 and C2. At the same time, the first SGSN determines the transfer mode of multicast data for the air interface according to the total number of subscribers in the cell. Recognizing that more subscribers are in the cell, SGSN informs the RAN of the group number to identify and assign one-to-many channels, noting that fewer subscribers are in the cell. If recognized, the SGSN searches for subscribers in the cell and allocates one-to-one channels for each subscriber. As a result, the subscribers distributed in C1 and C2 can receive the multicast data.

Note that the SGSN multicast routing table does not include the'total subscribers' field to simplify the complexity of data management within the multicast routing table. In this case, since it is not possible to determine the multicast data transfer mode for the wireless interface for the SGSN, the multicast data transfer on the network side is not affected. The SGSN transfers the multicast data to the associated cells, which in turn determine the transfer mode of the multicast data for the air interface.

[0025] In step (2), the SGSN determines whether the subscriber joins or leaves the multicast subscriber group. If'Yes', the hierarchical multicast route data is modified as appropriate in step (3). That is, during the process of establishing the route table, the SGSN first determines if a subscriber-related route item exists, and if not, the item is added to the route table. To. At the same time, the SGSN determines whether to notify the GGSN that it should modify the multicast routing table, and if yes, adds the'update'flag. If the SGSN multicast route table needs to calculate the total number of subscribers in each cell, the'total number of subscribers' data item in the SGSN multicast route table will be modified. In this way, the multicast route table can be established and maintained in order in SGSN and GGSN.

[0026] When a multicast subscriber leaves the multicast subscriber group, if the SGSN multicast route table does not include the'total number of subscribers', there is no need to modify the SGSN multicast route table and the GGSN multicast route table. , Only the multicast-related record data in SGSN will be modified, and the HLR will be notified that the subscriber's multicast-related record data will be modified. Possible modifications to the data in the multicast route table can be made in subsequent location registrations. If the SGSN multicast route table includes the'total number of subscribers' field, in addition to the above steps, the SGSN will determine whether the relevant item should be deleted and the GGSN multicast route table in the SGSN multicast route table. Determine if GGSN should be notified that it will be renewed according to the renewal of'Total number of subscribers'.

[0027] When a subscriber leaves the subscriber group or becomes a member of the subscriber group, it can be processed in the same manner as in the'user exit'mode.

[0028] Thus, when receiving a group of multicast data from the external network, the GGSN queries the GGSN multicast route table (first layer) and then transfers the multicast data to the corresponding SGSN. After receiving the multicast data, the related SGSN makes an inquiry to the SGSN multicast route table (second layer), determines the distribution of the corresponding subscriber group, and transfers the multicast data to the corresponding cell. Transfers multicast data. If the SGSN multicast route table contains a record of the'total number of subscribers' for each cell, the SGSN can further determine the transfer mode of multicast data for the wireless interface. If more subscribers are present in the cell, the SGSN will notify RAN that it will establish a one-to-many channel with the associated group ID and recognize that fewer subscribers are present in the cell. , SGSN notifies RAN that it will establish a one-to-one channel with a subscriber ID.

[0029] At this stage, the process by which the subscriber joins the subscriber group comprises the following steps, with reference to FIG.

[0030] First, in step 11, the subscriber sends a request to a multicast subscriber group having the group number to which the subscriber intends to join. Then, in step 12, the SGSN parses out only the corresponding GGSN according to the group number and optimization strategy, and forwards the subscriber's request to the GGSN. In step 13, the GGSN performs the corresponding process at the request of the subscriber to determine whether to allow the subscriber to join the multicast subscriber group, and the GGSN implements the corresponding process ( If you decide to allow a subscriber to join a multicast subscriber group through (contact HLR for subscriber multicast records to determine if the subscriber has the appropriate privileges), 'Multicast Subscriber Group Activation indication)'is fed back to SGSN. In step 14, after receiving the'multicast subscriber group activation indication', the SGSN instructs the RAN to perform a step (eg, transfer of multicast parameters) to add the subscriber to the subscriber group. And, this result is returned to SGSN. The SGSN modifies the corresponding SGSN multicast-related recorded data and the SGSN multicast route table according to the current position of the subscriber to indicate that the subscriber has joined the subscriber group in the subscriber group within the SGSN domain. It reflects in addition to the topological distribution of subscribers. At step 15, the SGSN'multicast activated response (multicast activated) response)'Feed back the message to the GGSN, which modifies the GGSN multicast route table according to the message. In stage 16, the SGSN notifies the HLR of a message that the subscriber has joined the subscriber group, and the HLR modifies the subscriber's multicast-related record data to the fact that the subscriber has joined the subscriber group. To reflect.

[0031] In step 2, if there are no subscribers to join the subscriber group, or if it is determined that the subscriber leaves the group, the process proceeds to step 4.

[0032] In step 4, the system determines whether or not the multicast subscriber is performing location registration and location update, and if'Yes', in step 5, the system's hierarchical multicast route data is appropriate. If not, the process ends.

[0033] For example, when the state of each subscriber in the network changes dynamically, such as when the subscriber's computer malfunctions abnormally, a normal message is not exchanged between the subscriber and the network. As a result, if the multicast route data does not reflect changes in the subscriber status in a timely manner, severe waste of network resources can occur. Therefore, the multicast route table in the system should reflect the dynamic variation of subscribers in the subscriber group at the node and should be updated automatically.

[0034] In step 5, it is possible to achieve hierarchical multicast routing data updates during the location registration of the subscriber terminal. Normally, when a node in the network receives a location registration message from a terminal, the node in the network determines that the terminal is still within its control and the current location of the subscriber is accurately recorded. Judge whether or not. If the network detects that the terminal has not registered its location over several time cycles, the network considers the subscriber to have left for some reason.

[0035] When a subscriber joins a subscriber group, the subscriber's multicast-related record data is added to the SGSN and HLR, so that the SGSN will have its own location each time the subscriber registers its location. By querying the local database according to the ID, the subscriber group in which the subscriber participated can be obtained. The SGSN then updates the SGSN multicast routing table according to the subscriber group in which the subscriber participated. These steps are described as follows: (21) If the SGSN multicast routing table does not have a subscriber-corresponding entry, it is probably an SGSN failure, or the subscriber is the first subscriber. Data discrepancies resulting from other factors resulting from belonging to a group inconsistency). Therefore, the item should be added and the SGSN should determine whether to notify the GGSN that it will update the associated GGSN multicast route table. If the SGSN detects that none of the route information associated with the multicast subscriber group is available, the SGSN should send an update message to the GGSN. (22) If the SGSN multicast route table contains'total number of subscribers', the SGSN can be activated by location registration to calculate the total number of subscribers in the cell at the node over a period of time. Then, the SGSN can correct the SGSN multicast route table according to the calculation result, thereby reflecting the exact total number of subscribers in the cell at that time. (23) If the relevant item is not updated for a long enough time, it indicates that the subscriber may not be accessible for any reason, or that there is some discrepancy. In this case, the SGSN determines whether the item should be deleted from the SGSN multicast route table and the GGSN should be notified that the associated multicast route table will be updated. If'Yes', SGSN sends an update message.

[0036] Further, in order to avoid any discrepancy between the GGSN multicast route table and the SGSN multicast route table, the SGSN detects a restart of the GGSN according to the multicast route group information stored in itself. Or, periodically submit a'Subscriber Group Exist'message to the relevant GGSN. If the GGSN does not receive a message for a period of time, the GGSN considers the relevant item to be invalid and can be deleted. If the GGSN receives the message and recognizes the message as new to the existing data, the GGSN will reflect the current topological distribution of the subscriber group and avoid discrepancies between different multicast data tables. It is considered that the update data in GGSN needs to be updated.

[0037] The hierarchical multicast route data shown in step 5 can also be updated when the position of the subscriber terminal is updated. For example, assuming that the SGSN transfers multicast data to a cell at a particular moment, but all subscribers in that cell move out of that cell at the next moment, the SGSN multicasts to that cell. Data should not be transferred. Therefore, the multicast routing table should reflect dynamic fluctuations in subscriber location.

[0038] If the location of the multicast subscriber fluctuates, the multicast route data can be updated through the following steps: (31) Whether the location update of the multicast subscriber is internal to the SGSN. To judge. If yes, SGSN updates the SGSN multicast route table only with multicast-related recorded data and location information submitted by the subscriber. If the'total number of subscribers' needs to be calculated in the SGSN multicast routing table, the SGSN updates the corresponding subscriber entry according to the updated subscriber location. (32) If the subscriber's location moves to another SGSN, the terminal will have the original International Mobile Station identifier. Identifier: IMSI) is submitted to the ID of the original SGSN, and the new SGSN retrieves all the subscriber's data from the original SGSN, in which case the data collects all the subscriber's multicast-related recorded data. Including. At the same time, the original SGSN updates the multicast routing table, and the original SGSN determines whether related items should be removed from the multicast routing table, and the original SGSN multicast routing table is'subscriber's. If the total number'is included, it is determined whether or not the original GGSN should be notified that the GGSN multicast route table will be updated according to the total number of updated subscribers. The new SGSN has its own SGSN multicast routing table, with the current subscriber group to which the subscriber has joined, the current cell in which the subscriber resides, and whether the current subscriber group supports roaming. Determine if it should be updated according to the information about whether or not. If the subscriber group to which the subscriber participates supports roaming, the new SGSN updates the corresponding GGSN multicast routing table in addition to the SGSN multicast routing table according to the current state of the SGSN multicast routing table. However, the process comprises the following steps: (41) If the subscriber is in the'idle'state, the new SGSN will select the GGSN according to the current optimization strategy and then whether the item is in its SGSN multicast routing table. It determines whether or not, and also determines whether or not to notify the selected GGSN that it will update the corresponding GGSN multicast route table. (42) If the subscriber is in a'connection'state and the subscriber group to which the subscriber has joined does not need to support uninterrupted data transmission, the new SGSN will optimize the GGSN today. Whether to select according to the strategy, then determine if the item is in its own SGSN multicast routing table, and notify the selected GGSN that it will update the corresponding GGSN multicast routing table. Also judge whether or not. (43) If the subscriber is in a'connected'state and the subscriber group to which the subscriber has joined should support uninterrupted data transmission, the new SGSN will be a GGSN multicast route to add items. Determine if the original GGSN needs to be notified that the table will be updated. If'Yes', a temporary data channel is established between the original GGSN and the new SGSN to support uninterrupted multicast data transmission. When the transmission of multicast data is complete, the new SGSN notifies the original GGSN that it will remove the temporary item and then selects the GGSN according to the current optimization strategy. The SGSN should then determine if the corresponding item exists in its SGSN multicast route table and further notify the selected GGSN that it will update the corresponding GGSN multicast route table. Also judge. If new data transmissions should be supported, the new SGSN determines if the original GGSN needs to be notified that it will update the GGSN multicast route table to add items. If'Yes', a temporary data channel is established between the original GGSN and the new SGSN to support uninterrupted multicast data transmission. When the transmission of multicast data is complete, the new SGSN notifies the original GGSN that it will remove the temporary item and then selects the GGSN according to the current optimization strategy. The SGSN should then determine if the corresponding item exists in its SGSN multicast route table and further notify the selected GGSN that it will update the corresponding GGSN multicast route table. Also judge. If new data transmissions should be supported, the new SGSN determines if the original GGSN needs to be notified that it will update the GGSN multicast route table to add items. If'Yes', a temporary data channel is established between the original GGSN and the new SGSN to support uninterrupted multicast data transmission. When the transmission of multicast data is complete, the new SGSN notifies the original GGSN that it will remove the temporary item and then selects the GGSN according to the current optimization strategy. The SGSN should then determine if the corresponding item exists in its SGSN multicast route table and further notify the selected GGSN that it will update the corresponding GGSN multicast route table. Also judge.

Throughout the steps, the hierarchical multicast route table is provided to ensure consistency between the contents of the multicast route table and the current topological distribution of multicast subscribers without subscriber groups. It can be adjusted automatically, which avoids any discrepancies and resource waste caused by anomalies when forwarding multicast data.

Finally, note the following: 1. The location registration of the subscriber terminal in the present invention is the location registration that accompanies first and is performed periodically. 2. The method described in the present invention is within circuit-switched (CS) due to the similarity between the circuit-switched (CS) structure and the packet-switched (PS) structure. It can also be used to manage the multicast subscribers of.

BRIEF DESCRIPTION OF THE DRAWINGS [FIG. 1] FIG. 1 is a flowchart of an embodiment of the present invention.

FIG. 2 is a network topology diagram of a mobile network of the first type in the present invention.

FIG. 3 is a network topology diagram of a mobile network of the second type in the present invention.

FIG. 4 is a flowchart of a process in which a multicast subscriber joins a multicast subscriber group.

[Code description] 1 External network 2 GGSN (Gateway GPRS support node) 3 SGSN (Serving GPRS support node) 4 RAN (Radio access network) 5 Mobile station