WO2004112328A1

WO2004112328A1 - Method for performing route area update of ue with mbms service in communication system

Info

Publication number: WO2004112328A1
Application number: PCT/KR2004/001406
Authority: WO
Inventors: Sung-Ho Choi; Kook-Heui Lee; Soeng-Hun Kim; Chang Duan; Detao Li; Lixiang Xu
Original assignee: Samsung Electronics Co., Ltd.; Beijing Samsung Telecom R & D Center
Priority date: 2003-06-13
Filing date: 2004-06-12
Publication date: 2004-12-23
Also published as: CN101384005A; CN1567757A

Abstract

The method for performing the route area update of the UE with the MBMS service in communication system is provided. This invention solves the problems existing in the conventional technology by the signaling interactions between the New U-GGSN and the Old SGSN/New SGSN as well as those between the M-GGSN and the Old SGSN/New SGSN. The UE can continue to use the MBMS service after entering the new RA. The SGSN not supporting the MBMS can also provide the MBMS service to the UE indirectly. The U-GGSN can provide the MBMS service to the UE in point-to-point PS mode. Thus, the MBMS Contexts in the UE, the SGSN and the GGSN are kept consistent.

Description

METHOD FOR PERFORMING ROUTE AREA UPDATE OF UE WITH MBMS SERVICE IN COMMUNICATION SYSTEM

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to a method for performing route area update of UE with MBMS service in WCDMA communication system.

2. Description of the Related Art

Multimedia Broadcast and Multicast Service (simplified as MBMS) is a new service under the standardization by 3^r Generation Partnership Project

(simplified as 3 GPP). MBMS service is a unidirectional point-to-multipoint

(p-t-m) service, whose most remarkable characteristic is that it can make use of radio resources and network resources efficiently.

To explain the MBMS in more details, Figure 1 describes a system architecture of the MBMS, Figure 2 exemplifies the flow for a UE to set up a MBMS multicast service, Figure 3 describes the flow for performing the Route area update with the UE in conventional technology (hereinafter referred to as RA update), and Figure 4 describes the flow for the UE to leave the MBMS multicast service.

As shown in Fig. 1, the MBMS network structure is based on the core network of General Packet Radio Service (hereinafter referred to as GPRS and added new network elements). Broadcast and multicast service center 101 (hereinafter referred to as BM-SC) is the service control center of the MBMS system. Gateway GPRS Supporting Node 102 (hereinafter referred to as GGSN) and Service GPRS Supporting Node 103 (hereinafter referred to as SGSN) compose the transmission network of the MBMS service and provide routes for data transfer. UMTS Terrestrial Radio Access Network 104 (hereinafter referred to as RAN) provides radio resources for the MBMS service over the air-interface. User Equipment 105 (hereinafter referred to as UE) is the terminal device used . for receive data. Home Location Register 106 (hereinafter referred to as HLR) saves the data related to users and can provide services like user's authentication. Gn/Gp 107 represents an interface between the SGSN and the GGSN. Gi 108 represents an interface between the BM-SC and the GGSN, and the interface protocol is Internet Group Management Protocol (hereinafter referred to as IGMP). Gmb 109 represents an interface between the BM-SC and the GGSN, and the interface protocol is specifically used to transfer MBMS signaling parameters. Radio resources used by the MBMS service are not dedicated for one user, but for all users using this service.

The flow as shown in Figure 2 is explained in the following:

201 The UE initiates a process that sets up a PDP Context. After the PDP Context is set up successfully, save the PDP Context in the UE, SGSN and GGSN, and set up a signaling connection in PS domain between the UE and the GGSN, the intermediate devices for the signaling connection are the RAN and the SGSN.

202 The UE sends an IGMP Joining message to the GGSN, which arrives at the GGSN through the signaling connection set up in step 201. The message comprises the parameter of IP multicast address, which can indicate a certain MBMS multicast service or a certain multicast service in the external data network.

203 The GGSN and the BM-SC perform the signaling interaction to authenticate the UE.

204 The GGSN sends a MBMS Notification Request message to the SGSN, which comprises following parameters: IP multicast address, APN and Linked NSAPI. Here, the IP multicast address and the APN indicate the MBMS service, and the NSAPI indicates a specific PDP Context, and the UE sends the IGMP Joining message exactly through this PDP Context in 202. Moreover, the APN here may resolve out another different GGSN, i.e. the GGSN that receives the IGMP message in 202 may be not the GGSN that provides the MBMS service. 205 The SGSN sends a MBMS Context Activation Request message to the UE after receiving the message in step 204, this message comprises following parameters: IP multicast address, APN and Linked NSAPI. The meanings of the parameters here are the same as those in 204.

206 The UE sends an Activate MBMS Context Request message to the SGSN after receiving the message in step 205, this message comprises IP multicast address and APN. The APN here may resolve out another different GGSN, i.e. the GGSN that receives the IGMP message in 202 may be not the GGSN that provides the MBMS service.

207 If necessary, an encryption process is performed between the UE and the SGSN. 208 The SGSN sends a Create MBMS Context Request message to the GGSN₅ which comprises IP multicast address and APN.

209 The GGSN performs the signaling interaction with the BM-SC to authenticate the MBMS service and the UE after receiving the message in step 208.

210 If the authentication is admitted, then the GGSN sets up a MBMS Context for the UE. If the GGSN has not set up a MBMS Bearer Context before, or it is the first time that sets up the MBMS Context for the UE using this MBMS service in the GGSN, then the GGSN sends a Bearer Request message to the BM-SC, which includes parameters of IP multicast address and APN. After receiving the Bearer Request message sent from the GGSN, the BM-SC sets up the Bearer Context if there is no Bearer Context in the BM-SC. The BM-SC adds the identification of the GGSN to the parameter of the Bearer Context, i.e. list of downstream nodes, and sends a Bearer Response message to the GGSN, which contains parameters as IP multicast address, APN, Session Attribute, state and TMGI.

211 After receiving the message sent from the BM_SC in above 210, the GGSN sets up the Bearer Context and sends a Create MBMS Context Response message to the SGSN.

212 After receiving the message sent from the GGSN in above 211, the SGSN sets up a MBMS Context for this UE. If the SGSN has never set up a MBMS

Bearer Context before, or it is the first time for the SGSN to set up the MBMS Bearer Context for this UE who uses the MBMS service, then SGSN sends a MBMS Bearer Request message to the GGSN, which contains parameters as IP multicast address, APN and TEID. After receiving above MBMS Bearer Request message sent from the SGSN, the GGSN adds the identification of the SGSN to the parameter of Bearer Context, i.e. list of downstream nodes, and then sends a MBMS Bearer Response message to the SGSN, which contains parameters as IP multicast address, APN, Session Attribute, state and TMGI.

213 The SGSN provides the MBMS Context of the UE for the RAN. 214 The SGSN sends an Activate MBMS Context Accepted message to the UE, and after receiving this message, the UE also sets up the MBMS Context, and the activation process completes.

During the process described in above Figure 2, after the UE activates the MBMS service, the MBMS Context of the UE saved in the SGSN and the GGSN is as shown in Table 1 : Table 1

During the process described in above Figure 2, after the UE activates MBMS, the Bearer Context of the MBMS service saved in the SGSN and the GGSN is as shown in Table 2:

Table 2

Figure 3 describes the method for performing the route area update of the UE.

The RA update may happen in two different situations in the view of the SGSN, i.e. between the different SGSNs and within the same SGSN. The aim of this invention is the RA update process performed between the different SGSNs, thus

Figure 3 describes the situations for the RA update performed between the different SGSNs in the conventional technology. Moreover, main activities of this invention happen on the core network side, i.e. between the SGSNs, or between the SGSN and the GGSN, therefore, no explanation will be given for the activities of the RAN in conventional technology as well as concerned in this invention.

301 When the UE enters a new route area that is under the control of a New SGSN, the UE sends a RA Update Request message to the New SGSN. This message contains parameters necessary for the New SGSN to identify the UE and to find the Old SGSN who manages the UE. 302 The New SGSN sends a SGSN Context Request message to the Old SGSN. This request message is used to notify the Old SGSN to send a UE related Context to the New SGSN.

303 The Old SGSN sends a SGSN Context Response message to the New SGSN. This message contains the UE related context saved in the Old SGSN. 304 After the New SGSN receives this context message, it performs security check on the UE. This process needs the participation of the HLR of central database who saves the UE registration information.

305 The New SGSN sends a SGSN Context Confirm message to the Old SGSN, indicating that the New SGSN has received the context.

306 After receiving the confirmation message in Step 305, the Old SGSN sends a Forward Data Packet message to the New SGSN₅ the message contains those data temporarily suspended by the Old SGSN due to the UE mobility. 307 The New SGSN sends an Update PDP Context Request message to the GGSN.

308 The GGSN sends an Update PDP Context Response message to the New

SGSN.

309 The New SGSN and the Old SGSN interact with the HLR to update the location as well insert the user data.

310 The New SGSN sends a RA Update Admitted message to the UE, the message contains parameters like P-TMSI and P-TMSI signature.

311 The UE sends a RA Update Complete message to the SGSN to confirm the P-TMSI having been received, and the whole RA update process completes. The flow as shown in Figure 4 is explained in the following:

401 When the UE wants to leave a certain MBMS multicast service, if the UE stays in idle state (PMM-IDLE), the UE initiates a service request process to set up a signaling connection from the UE to the GGSN in PS domain, and this process is an existing process, the UE can send the uplink data after the process completes.

402 When the UE wants to leave a certain MBMS multicast service, the UE sends an IGMP Leaving message to the GGSN via the PDP Context set up, and the parameter of the IP multicast address comprised in this message indicates the multicast service group that the UE wants to leave. 403 The signaling interaction is executed between the GGSN and BM-SC to make the BM-SC delete the information on the UE.

404 The GGSN sends a MBMS Context Request message to the SGSN, and this message comprises IP multicast address and APN.

405 The SGSN sends a Deactivate MBMS Context Request message to the UE. 406 The UE deletes the MBMS Context and sends a Deactivate MBMS Context Accepted message to the SGSN.

407 The SGSN deletes the MBMS Context and sends a Teardown MBMS Context Response message to the GGSN after receiving the message in step 406. The GGSN deletes the MBMS Context also after receiving the message, and at this time the deactivation process completes.

In conventional technology, when the UE performs the RA update, it should be enabled to keep receiving MBMS service due to the appearance of the MBMS service. But due to the particularity of the MBMS service, i.e. MBMS is a common service, the GGSN that provides the MBMS service may be not the same GGSN that saves the PDP Context of the UE and the New RA that the UE enters may be controlled by the SGSN that doesn't support the MBMS service, the network unable to well provide the MBMS service to the UE when the UE enters a new RA and this RA is controlled by a new SGSN in the conventional technology.

SUMMARY OF THE INVENTION

The object of this invention is to provide a method for performing route area update of a UE with MBMS service in communication system, which makes the UE keep on utilizing the MBMS service after performing the route area update.

In order to realize above object, according to one aspect of this invention, a method for performing route area update of a UE with MBMS service in communication system comprises following steps of, when a U-GGSN is not the same one as a M-GGSN:

(1) sending a RA Update Request message to a New SGSN by the UE;

(2) sending a SGSN Context Request message by the New SGSN to an Old SGSN after receiving the message sent by the UE in Step (1); (3) after receiving the message sent by the New SGSN in Step (2), sending a SGSN Context Response message by the Old SGSN to the New SGSN, the message containing MM Context and PDP Context of the UE;

(4) performing a security check and authentication on the UE by the New SGSN after receiving the message sent by the Old SGSN in Step (3); (5) sending a SGSN Context Confirm message by the New SGSN to the Old SGSN;

(6) sending a Forward Data Packet message by the Old SGSN to the New SGSN after receiving the message sent by the New SGSN in Step (5); (7) sending an Update PDP Context Request message by the New SGSN to the U-GGSN;

(8) sending an Update PDP Context Response message by the U-GGSN to the New SGSN after receiving the message sent by the New SGSN in Step (7); (9) performing processes of updating location and inserting user data by the New SGSN and the Old SGSN as well as the HLR;

(10) sending a MBMS Notification Request message by the U-GGSN to the New SGSN, the message containing parameters as IP multicast address, APN, NSAPI;

(11) after the New SGSN receiving the message sent by the U-GGSN in Step (10), entering Step (12) if the New SGSN supports the MBMS, otherwise, entering

Step (18);

(12) sending a MBMS Notification Response message by the New SGSN to the U-GGSN, the message containing such parameters as Cause indicating reason;

(13) checking the SGSN Context Response message sent by the Old SGSN in Step (3) by the New SGSN, and if the message contains MBMS Context, entering

Step (14); otherwise, entering Step (16);

(14) sending an Update MBMS Context Request message by the New SGSN to the M-GGSN, the message containing parameters as New SGSN address, data field TEID and NSAPI; (15) after receiving the Update MBMS Context Request message sent by the New SGSN in Step (14), the M-GGSN finding the MBMS Context that needs to be updated according to the parameter contained in the receiving message and updating the corresponding parameter field; thereafter, the M-GGSN sending an Update MBMS Context Response message to the New SGSN, the message containing parameters as TEID of GGSN, Cause; then entering Step (24);

(16) sending a MBMS Context Activation Request message by the New SGSN to the UE;

(17) after receiving the message sent by the New SGSN in Step (16), executing a process of activating the MBMS Context by the UE; after that, entering Step (24); (18) sending a Teardown MBMS Context Notification Request message by the U-GGSN to the Old SGSN, the message containing parameters as IP multicast address, APN, Linked NSAPI and Cause;

(19) After receiving the Teardown MBMS Context Notification Request message sent by the U-GGSN in Step (18), sending a Teardown MBMS Context Notification Response message by the Old SGSN to the U-GGSN, the message contains parameters as Cause indicating reason;

(20) the Old SGSN finding the corresponding MBMS Context according to the parameter contained in the Teardown MBMS Context Notification Request message sent by the U-GGSN in Step (18), and sending a Teardown MBMS Context Request message to the M-GGSN, the message containing parameters as TEID, NSAPI and Teardown Ind;

(21)the M-GGSN finding the corresponding MBMS Context according to the parameter contained in the message sent by the Old SGSN in Step (20) and deleting it, and then sending a Teardown MBMS Context Response message to the Old SGSN, the message containing parameters as TEID and Cause;

(22) the U-GGSN exchanging information with the BM-SC to join the MBMS multicast service; (23) sending a MBMS Point-to-point PS Mode Notification message by the U-GGSN to the UE, the message containing parameters as IP multicast address and APN, and the purpose of sending this message is to let the UE choose to pause the use of MBMS Context or delete the MBMS Context according to its specific implementation after receiving this message, after that, the UE uses the MBMS service in Point-to-point PS mode;

(24) admitting the existence of the UE in the new RA by the New SGSN and sending a RA Update Receive message to the UE, the message containing parameters as P-TMSI and P-TMSI Signature assigned by the New SGSN to the UE as its identity indication in this RA; and (25) after receiving the message . sent by the New SGSN in Step (24), the UE confirming the P-TMSI as well as P-TMSI Signature assigned by this message and sending a RA Update Complete message to the New SGSN.

According to another aspect of this invention, a method for performing route area update of a UE with MBMS service in communication system comprises following steps of, when a U-GGSN is the same as a M-GGSN:

(1) sending a RA Update Request message by the UE to a New SGSN;

(2) sending a SGSN Context Request message by the New SGSN to an Old SGSN after receiving the message sent by the UE in Step (1);

(3) After receiving the message sent by the New SGSN in Step (2), sending a SGSN Context Response message by the Old SGSN to the New SGSN₅ the message containing MM Context and PDP Context of the UE;

(4) performing a security check and authentication on the UE by the New SGSN after receiving the message sent by the Old SGSN in Step (3); (5) sending a SGSN Context Confirm message by the New SGSN to the Old

SGSN;

(6) sending a Forward Data Packet message by the Old SGSN to the New SGSN after receiving the message sent by the New SGSN in Step (5);

(7) sending an Update PDP Context Request message by the New SGSN to the GGSN;

(8) sending an Update PDP Context Response message by the GGSN to the New SGSN after receiving the message sent by the New SGSN in Step (7);

(9) performing processes of updating location and inserting user data by the New SGSN and the Old SGSN as well as the HLR; (10) sending a MBMS Notification Request message by the GGSN to the New SGSN, the message containing parameters as IP multicast address, APN, NSAPI;

(11) after the New SGSN receiving the message sent by the U-GGSN in Step (10), entering Step (12) if the New SGSN supports the MBMS, otherwise, entering Step (18); (12) sending a MBMS Notification Response message by the New SGSN to the U-GGSN, the message containing parameters as Cause indicating reason;

(13) checking the SGSN Context Response message sent by the Old SGSN in Step (3) by the New SGSN, and if the message contains MBMS Context, entering Step (14), otherwise, entering Step (16); (14) sending an Update MBMS Context Request message by the New SGSN to the M-GGSN, the message containing parameters as New SGSN address, data field TEID and NSAPI;

(15) after receiving the Update MBMS Context Request message sent by the New SGSN in Step (14), the GGSN finding the MBMS Context that needs to be updated according to the parameter contained in the receiving message and updating the corresponding parameter field; thereafter, the GGSN sending an Update MBMS Context Response message to the New SGSN, the message containing parameters as TEID of GGSN, Cause; then entering Step (24); (16) sending a MBMS Context Activation Request message by the New SGSN to the UE;

(17) after receiving the message sent by the New SGSN in Step (16), executing a process of activating the MBMS Context by the UE; after that, entering Step (24); (18) sending a Teardown MBMS Context Notification Request message by the GGSN to the Old SGSN, the message containing parameters as IP multicast address, APN, Linked NSAPI and Cause;

(19) After receiving the Teardown MBMS Context Notification Request message sent by the GGSN in Step (18), sending a Teardown MBMS Context Notification Response message by the Old SGSN to the U-GGSN, the message containing parameters as Cause indicating reason;

(20) the Old SGSN finding the corresponding MBMS Context according to the parameter contained in the Teardown MBMS Context Notification Request message sent by the GGSN in Step (18), and sending a Teardown MBMS Context Request message to the M-GGSN, the message containing parameters as TEID, NSAPI and Teardown Ind;

(21)the GGSN finding the corresponding MBMS Context according to the parameter contained in the message sent by the Old SGSN in Step (20) and deleting it, and then sending a Teardown MBMS Context Response message to the Old SGSN, the message containing parameters as TEID and Cause;

(22) the U-GGSN exchanging information with the BM-SC to join the MBMS multicast service;

(23) sending a MBMS Point-to-point PS Mode Notification message by the GGSN to the UE, the message containing parameters as IP multicast address and APN, and the purpose of sending this message is to let the UE choose to pause the use of MBMS Context or delete the MBMS Context according to its specific implementation after receiving this message, after that, the UE uses the MBMS service in Point-to-point PS mode;

(24) admitting the existence of the UE in the new RA by the New SGSN and sending a RA Update Receive message to the UE, the message containing parameters as P-TMSI and P-TMSI Signature assigned by the New SGSN to the UE as its identity indication in this RA; and

(25) after receiving the message sent by the New SGSN in Step (24), the UE confirming the P-TMSI as well as P-TMSI Signature assigned by this message and sending a RA Update Complete message to the New SGSN. This invention solves the problems existing in conventional technology by signaling interactions between the New U-GGSN and the Old SGSN/New SGSN as well as those between the M-GGSN and the Old SGSN/New SGSN. The UE can continue to use the MBMS service after entering the new RA. The SGSN not supporting the MBMS service can also provide the MBMS to the UE indirectly. The U-GGSN can provide the MBMS service to the UE in point-to-point PS mode. Thus, the MBMS Contexts in the UE, the SGSN and the GGSN are kept consistent.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 describes a system structure of a MBMS.

Figure 2 exemplifies the process for a UE to set up a MBMS multicast service.

Figure 3 describes the process of performing route area update (referring to RA update hereinafter) for a UE in conventional technology.

Figure 4 describes the process of leaving the MBMS multicast service for the UE.

Figure 5 describes the process of a RA update process for the UE when U-GGSN is not the same GGSN as M-GGSN.

Figure 6 describes the activity process of the node Old SGSN in above Figure 5. Figures 7A and 7B describe the activity process of the node New SGSN in above Figure 5.

Figure 8 describes the activity process of the node U-GGSN in above Figure 5. Figure 9 describes the activity process of the node M-GGSN in above Figure 5.

Figure 10 describes the process of a RA update process for the UE when U-GGSN is the same GGSN as M-GGSN.

Figure 11 describes the activity process of the node Old SGSN in above Figure 10.

Figures 12A and 12B describe the activity process of the node New SGSN in above Figure 10. Figure 13 describes the activity process of the node GGSN in above Figure 10. Figure 14 describes the sub-process of setting up the MBMS Bearer Context initiated by the SGSN.

Figure 15 describes the sub-process of deleting the MBMS Bearer Context initiated by the SGSN.

DETAILED DESCRIPTION OF TKDB PREFERRED EMBODIMENTS

As the GGSN that provides the MBMS service may be not the same GGSN as the that saving the PDP Context of the UE, this invention defines following terms in order to distinguish the GGSN saving the PDP Context of the UE from that saving the MBMB Context of the UE:

♦ U-GGSN: the GGSN that saves the PDP Context of the UE, this GGSN also provides other data services to the UE in point-to-point mode.

♦ M-GGSN: the GGSN that saves the MBMS Context of the UE, this GGSN provides MBMS service dedicatedly, and what needs to be explained is that if a certain UE sets up its own PDP Context in the M-GGSN, the U-GGSN and the M-GGSN are the same GGSN in point of this UE.

♦ Old SGSN: the SGSN that actually controls the UE before the UE enters a new RA;

♦ New SGSN: the SGSN that actually controls the UE after the UE enters a new RA;

The process of performing the route area update (RA update) for the UE when the U-GGSN is not the same GGSN as the M-GGSN comprises following steps:

- The whole flow from the UE to the New SGSN, the Old SGSN, the U-GGSN, and the M-GGSN.

- The activity process of the node New SGSN.

- The activity process of the node Old SGSN.

- The activity process of the node U-GGSN.

- The activity process of the node M-GGSN. The process of performing the route area update (RA update) for the UE when the U-GGSN is the same GGSN as the M-GGSN comprises following steps:

- The whole flow from the UE to the New SGSN, the Old SGSN, the U-GGSN and the M-GGSN; - The activity process of the node New SGSN.

- The activity process of the node Old SGSN.

- The activity process of the node U-GGSN. The activity process of the node M-GGSN.

The process of RA update when U-GGSN is not the same GGSN as M-GGSN ♦ Figure 5 describes the flow of the RA update for the UE when the U-GGSN is not the same GGSN as the M-GGSN.

In 501 of Figure 5 described above, when the UE enters a new RA, it finds that it is in the new RA by comparing with the route area indication (RAI) in the broadcast message of current cell, then it sends the RA Update Request message to the SGSN, the message contains parameters as P-TMSI, Old RAI, TMGI, Old P-TMSI Signature, etc. Here, the TMGI is a new parameter after introducing the MBMS service, which is used by the UE to distinguish the different MBMS service when receiving the paging message.

In 502 of Figure 5 described above, after receiving the message, the New SGSN estimates the address of the Old SGSN from the parameter Old RAI or Old

P-TMSI by using the conventional technology, and sends the SGSN Context

Request message to the Old SGSN. This message contains parameters as IMSI,

Old RAI, etc.

In 503 of Figure 5, after the Old SGSN receives the SGSN Context Request message from the New SGSN, the SGSN puts the MM Context and PDP Context of the UE as well as the MBMS Context into the message of SGSN Context

Response and sends them to the New SGSN. The MM Context saves the parameters for mobility management and access of the UE. The PDP Context saves the parameters about data field connection of the UE. And the MBMS saves the parameters about using the MBMS service of the UE.

In 504 of Figure 5, after receiving the SGSN Context Response message from the Old SGSN, the New SGSN performs the security check as well as authentication on UE by exchanging information with the UE and the HLR. In 505 of Figure 5, the New SGSN sends the SGSN Context Confirm message to the Old SGSN after completing the security process, whose function is to give a confirmation to the Old SGSN that the New SGSN has received the context message. After receiving this confirmation message, the Old SGSN marks the MM Context and PDP Context of the UE as well the MBMS Context it saves as invalid, and will delete them after waiting a period of time, the waiting time is determined by implementation.

In 506 of Figure 5, the Old SGSN sends those data packets not having delivered to the UE yet to the New SGSN via GTP tunnel through the message, then the data packets will be sent to the UE by the New SGSN after the RA process is completed.

In 507 and 508 of Figure 5, the New SGSN sends the Update PDP Context Request message to the U-GGSN, the message contains parameters as the address of New SGSN, GTP tunnel address of the New SGSN, etc. The U-GGSN updates the corresponding parameters of the PDP Context saved by its own according to the parameters in the message received, and sends the Update PDP Context Response message to the New SGSN, the message contains GTP tunnel address of the U-GGSN, and after the New SGSN receives this response message, it also updates the corresponding parameters of the PDP Context saved by its own. In 509 of Figure 5, this process makes the location information on UE saved in the HLR to get updated through information exchange between the Old SGSN, the New SGSN and the HLR by using the conventional technology, and deletes the UE information saved in the Old SGSN at same time, in addition, some perpetual subscription information on the UE saved in the HLR is delivered to the New SGSN.

In 510 of Figure 5, the U-GGSN sends the MBMS Notification Request message to the New SGSN, which is used to notify the New SGSN that the described UE has activated the MBMS service, and this message comprises parameters as IP multicast address, APN and NSAPI. Here, the IP multicast address and APN indicate the MBMS service, and the NSAPI indicates a specific PDP Context. The UE initially activates the MBMS service through sending the IGMP Joining message via this PDP Context, as shown in Figure 2, thus this specific PDP Context is exactly the PDP Context set up in 201 of Figure 2.

In 511 of Figure 5, after the New SGSN receives the message sent from the U-GGSN, if the New SGSN supports the MBMS, it sends the MBMS

Notification Request message to the U-GGSN, the message contains the parameter of Cause that comprises some explanation about the message itself. If the New SGSN doesn't support the MBMS, it just ignores this message or sends an error message to the U-GGSN.

In 512 of Figure 5, if the U-GGSN didn't receive the MBMS Notification Response message in the 511 described, or receives the error message, the

U-GGSN sends the Teardown MBMS Context Notification Request message to the Old SGSN, the message contains parameters as IP multicast address, APN,

Linked NSAPI and Cause. The IP multicast address and APN indicate a certain

MBMS service. The Linked NSAPI indicates a certain PDP Context, which is the context used to send the IGMP message when the UE activates the MBMS service. The Cause indicates reason, i.e. the reason why the GGSN requires the

Old SGSN to delete the MBMS Context.

In 513 of Figure 5, after receiving the MBMS Context Notification Request message sent from the U-GGSN, the Old SGSN sends the Teardown MBMS Context Notification Response message to the U-GGSN, the message contains parameters as Cause that indicates reason.

In 514 of Figure 5, the Old SGSN finds the corresponding MBMS Context according to the parameter contained in the message received in above 512 of Figure 5, and sends the Teardown MBMS Context Request message to the M-GGSN, the message contains parameters as TEID, NSAPI and Teardown Ind. The combination of the TEID and NSAPI indicates the MBMS Context that will be deleted. The Teardown Ind indicates a Teardown indicator. If the Teardown Ind is contained, it means to delete all MBMS Contexts of the UE that have the same PDP Context as that of the MBMS Context to be deleted. In 515 of Figure 5, the M-GGSN finds the corresponding MBMS Context according to the message sent from the Old SGSN in 514, and sends the Teardown MBMS Context Response message to the Old SGSN, the message contains parameters as TEID and Cause. After receiving the Teardown MBMS Context Response message, if the Old SGSN finds that there has no MBMS Context of the UE and the List of Downstream Nodes parameters in the Bearer Context of the Old SGSN is empty, then the sub-process of deleting the MBMS Bearer Context as shown in Fig. 15 is initiated by the Old SGSN.

In 516 of Figure 5, if the New SGSN supports the MBMS, after completing actions in above 511 of Figure 5, it sends the Update MBMS Context Request message to the M-GGSN, the message contains parameters as address of New

SGSN, data field TEID of and NSAPI. The address of New SGSN indicates the PDP address of the New SGSN. The NSAPI may indicate the MBMS Context together with the control field TEID in the message header. The data field TEID is used to set up a common downlink data tunnel between the New SGSN and the M-GGSN, and each MBMS has the common downlink data tunnel, in the case where it was no downlink data tunnel of MBMS between the New SGSN and the M-GGSN before, this message should contain the data field TEID.

In above 517 of Figure 5, after receiving the Update MBMS Context Request message sent from the New SGSN in above 516 of Figure 5, the M-GGSN finds the MBMS Context that needs to be updated according to the parameter contained in the message received, thereafter t, the M-GGSN sends the Update MBMS Context Response message to the New SGSN, the message contains parameters as TEID of GGSN and Cause. The TEID of GGSN is used to set up an uplink tunnel between the New SGSN and the M-GGSN, and the Cause indicates reason. After receiving the Update MBMS Context Response message, if the New SGSN finds that it has no MBMS Bearer Context yet, then the sub-process of creating the MBMS Bearer Context as shown in Fig. 14 is initiated by the New SGSN.

In 518 of Figure 5, if the U-GGSN didn't receive a correct response message after above 510 of Figure 5, the U-GGSN assumes that it should provide the

MBMS for the UE in current point-to-point mode, so it exchanges information with the BM-SC, whose purpose is to enable the BM-SC to authenticate the

U-GGSN when the U-GGSN joins the multicast service of the BM-SC, after 518, the U-GGSN joins the multicast service of the BM-SC, and from them on, the

U-GGSN can provide MBMS for the UE in point-to-point mode.

In 519 of Figure 5, if the steps in above 518 of Figure 5 are successful, then the U-GGSN sends the MBMS Point-to-point PS Mode Notification message to the UE, the message contains parameters as IP multicast address and APN. After receiving this message, the UE will choose to pause the use of MBMS Context or to delete MBMS Context according to the specific implementation.

In 520 of Figure 5, if the New SGSN supports the MBMS, and it knows that the UE is the one that subscribes to use the MBMS after above 510 of Figure 5 while the SGSN Context Response message received in above 503 of Figure 5 didn't contain the MBMS Context, then the New SGSN sends the MBMS Context Activation Request message to the UE, which is the same as that sent by the SGSN in above 205 of Figure 2. In 521 of Figure 5, the UE executes the process of activating MBMS Context, which is basically the same as that from 206 to 214 of above Figure 2 except that in Figure 5, the GGSN is classified into U-GGSN and M-GGSN.

In 522 of Figure 5, the New SGSN admits the existence of the UE in the New RA and sends the RA Update Receive message to the UE. The message comprises the parameter: P-TMSI and P-TMSI Signature. The two parameters are assigned to the UE by the New SGSN as its identity indication in this RA;

In 523 of Figure 5, after receiving the message sent by the New SGSN in above 522 of Figure 5, the UE confirms the P-TMSI and T-TMSI Signature assigned in this message and sends the RA Update Complete message to the New SGSN. Till now, the RA update process completes. ♦ Figure 6 describes the action flow of node Old SGSN in above flow of Figure

5.

Step 601 in Figure 6 described above corresponds to above Step 502 in Figure 5. In Step of 601, the Old SGSN receives the SGSN Context Request message from the New SGSN, which requests the Old SGSN to send all UE related context message saved to the New SGSN. This message comprises the parameter: Old P-TMSI₅ Old RAI and Old P-TMSI Signature. These parameters are used to let the Old SGSN find corresponding context information on the UE.

Step 602 in Figure 6 corresponds to above Step 503 in Figure 5. In 602, after finding all saved context information on the UE, the Old SGSN sends the SGSN Context Response message to the New SGSN. This message contains all UE related context information, such as MM Context and PDP Context, and if the UE has activated the MBMS service, this message also contains the MBMS Context.

Step 603 in Figure 6 corresponds to above Step 505 in Figure 5. In 603, the Old SGSN receives the SGSN Context Confirmation message from the New SGSN, which is used to give a confirmation to the Old SGSN that the New SGSN has received the UE related context information.

Step 604 in Figure 6 corresponds to above Step 506 in Figure 5. In 604, the Old SGSN sends the data saved for suspending the transmission to the UE to the New SGSN via the Forward Data Packet message, which will then forwarded to the UE by the New SGSN at a proper time.

Step 605 in Figure 6 corresponds to above Step 509 in Figure 5. In 605, the

Old SGSN interacts with the HLR to update the UE related context information, and releases the UE related Iu connections with the RAN, according to the specific implementation, after the Step 605, the Old SGSN may select to delete all the UE related context information right away or to delete after a period of time. Step 606 in Figure 6 is a judge condition, and if the New SGSN in above Figure 5 supports MBMS, then the Old SGSN enters Step 607; otherwise, it enters Step 611.

Step 607 in Figure 6 corresponds to above Step 512 in Figure 5. In Step 607, the Old SGSN receives the Teardown MBMS Context Notification Request message sent from the U-GGSN, the message contains parameters as IP multicast address, APN, Linked NSAPI and Cause. The IP multicast address and APN indicate a certain MBMS service. The Linked NSAPI indicates a certain PDP Context, which is used to send the IGMP message when the UE activates the MBMS service. The Cause indicates reason, i.e. the reason why the U-GGSN requires the Old SGSN to delete the MBMS Context. The purpose of Step 607 is that, if the New SGSN doesn't support the MBMS, then at this time the MBMS should continue to be provided for the UE in point-to-point PS mode, however, as the New SGSN doesn't support the MBMS, it won't interact with the M-GGSN to update the MBMS Context information in the M-GGSN, which results in incorrectness of the MBMS Context saved in the M-GGSN, so that the Old SGSN is required to interact with the M-GGSN to delete the MBMS Context saved in the M-GGSN.

Step 608 in Figure 6 corresponds to above Step 513 in Figure 5. In 608, the Old SGSN sends the Teardown MBMS Context Notification Response message to the U-GGSN, the message contains parameters as Cause that indicate reason.

Step 609 in Figure 6 corresponds to above Step 514 in Figure 5. In 609, the Old SGSN finds the corresponding MBMS Context according to the parameter contained in the message received in above 607, and sends the Teardown MBMS Context Request message to the M-GGSN, the message contains parameters as TEID, NSAPI and Teardown Ind. The combination of the TEID and NSAPI indicate the MBMS Context that will be deleted. The Teardown Ind indicates the Teardown indicator. If the Teardown Ind is contained, it means to delete all MBMS Contexts of the UE that have the same PDP Context as that of the MBMS Context to be deleted.

Step 610 in Figure 6 corresponds to above Step 515 in Figure 5. In Step 610, the Old SGSN receives the Teardown MBMS Context Response message sent from the M-GGSN, the message contains parameters as TEID and Cause. This indicates that the M-GGSN has deleted the corresponding MBMS Context. Step 611 of Figure 6 indicates that the actions of the Old SGSN in the flow of

Figure 5 have completed. ♦ Figures 7 A and 7B describes the action process of the node New SGSN in the flow of above Figure 5.

Step 701 in Figure 7A corresponds to above Step 501 in Figure 5. In Step 701, the New SGSN receives the RA Update Request message sent from the UE, the message contains parameters as P-TMSI, Old RAI, TMGI, Old P-TMSI Signature, etc. Here, the TMGI is a new parameter after introducing the MBMS service, and the TMGI is used to make the UE distinguish the different MBMSs when receiving the paging message.

Step 702 corresponds to above Step 502 in Figure 5. In 702, after receiving the message sent from the UE in above 701, the New SGSN estimates the address of the Old SGSN from the parameter Old RAI or Old P-TMSI by using the conventional technology, and sends the SGSN Context Request message to the

Old SGSN. This message contains parameters as IMSI, Old RAI, etc.

Step 703 corresponds to above Step 503 in Figure 5. In Step 703, the New SGSN receives the SGSN Context Response message sent from the Old SGSN, the message contains parameters as MM Context, PDP Context as well as MBMS

Context of the UE. The New SGSN will save the MM Context and PDP Context of the UE received in the message. If the New SGSN supports the MBMS, it will also save the MBMS Context of the UE; otherwise, the New SGSN discards the MBMS Context, or saves it without any processing.

Step 704 corresponds to above Step 504 in Figure 5. In 704, the New SGSN performs the security check as well as authentication on the UE by exchanging information with the UE as well as the HLR.

Step 705 corresponds to above Step 505 in Figure 5. In 705, the New SGSN sends the SGSN Context Confirm message to the Old SGSN after completing the security process, whose function is to give a confirmation to the Old SGSN that the New SGSN has received all contexts about the UE.

Step 706 corresponds to above Step 506 in Figure 5. In 706, the New SGSN receives the Forward Data Packet message sent from the Old SGSN, the message contains those data saved for suspending the transmission to the UE by the Old

SGSN, and after receiving this message, the New SGSN will forward them to the

UE at a proper time.

Steps of 707 and 708 correspond to above steps of 506 and 507 in Figure 5. In

707 and 708, the New SGSN sends the Update PDP Context Request message to the U-GGSN, the message contains parameters as the address of New SGSN, GTP tunnel address of New SGSN, etc. The U-GGSN updates corresponding parameters of PDP Context saved by its own according to the parameters in the message received, and sends the Update PDP Context Response message to the New SGSN, the message contains GTP tunnel address of U-GGSN. After receiving this response message, the New SGSN also updates the corresponding parameters of PDP Context saved by its own.

Step 709 corresponds to above Step 509 in Figure 5. In 709, this process makes the location information on the UE saved in the HLR get updated through information exchange between the Old SGSN, the New SGSN and the HLR by using the conventional technology, and deletes the UE information saved in the Old SGSN at the same time, in addition, some perpetual subscription information on the UE saved in the HLR is delivered to the New SGSN.

Step 710 in Figure 7B corresponds to above Step 510 in Figure 5. In 710, the New SGSN receives the MBMS Notification Request message sent from the U-GGSN, which is used to notify the New SGSN that the described UE has activated the MBMS. This message contains parameters as IP multicast address, APN and NSAPI. The IP multicast address and APN indicate the MBMS service and the NSAPI indicates a specific PDP Context, and the UE initially activates MBMS service through sending the IGMP Joining message via this PDP Context, as shown in Figure 2, then this specific PDP Context is exactly the PDP Context set up in 201 of Figure 2.

Step 711 is a judge condition. If the New SGSN supports the MBMS, then the New SGSN enters Step 712; otherwise, it enters Step 721.

Step 712 corresponds to above Step 511 in Figure 5. In 712, since the New SGSN supports the MBMS, it sends the MBMS Notification Response message to the U-GGSN, the message contains the parameter Cause that comprises some explanation about the message itself.

Step 713 is a judge condition. If the message received by the New SGSN from the Old SGSN in above Step 703 contains the MBMS Context, then the New SGSN enters Step 714; otherwise, it enters Step 719.

Step 714 corresponds to above Step 516 in Figure 5. In 714, the New SGSN sends the Update MBMS Context Request message to the M-GGSN, the message contains parameters as address of New SGSN, data field TEID and NSAPI. The Address of New SGSN indicates PDP address of the New SGSN. The NSAPI can indicate the MBMS Context together with the control field TEID in the message header. The data field TEID is used to set up a common downlink data tunnel between the New SGSN and the M-GGSN and each MBMS has a common downlink data tunnel. In this case where it was no downlink data tunnel of MBMS between the New SGSN and the M-GGSN before, this message should contain the data field TEID. Step 715 corresponds to above Step 517 in Figure 5. In 715, the New SGSN receives the Update MBMS Context Response message sent from the M-GGSN, the message contains parameters as TEID of GGSN and Cause. The TEID of GGSN is used to set up an uplink tunnel between the New SGSN and the M-GGSN, and the Cause indicates reason. Step 716 corresponds to above Step 522 in Figure 5. In 716, the New SGSN admits the existence of the UE in the New RA and sends the RA Update Receive message to the UE. The message comprises the parameter: P-TMSI and P-TMSI Signature. These two parameters are assigned by the New SGSN to the UE as its identity indication in this RA. Step 717 corresponds to above Step 523 in Figure 5. In 717, the New SGSN receives the message of RA Update Complete from the UE, which indicates that the UE has confirmed the P-TMSI and P-TMSI Signature newly assigned.

Step 718 indicates that the actions of the New SGSN in above Figure 5 have been completed. Step 719 corresponds to above Step 520 in Figure 5. In 719, since the receiving SGSN Context Response message sent from the Old SGSN in above 703 didn't contain the MBMS Context, the New SGSN sends the MBMS Context Activation Request message to the UE, which is the same as that sent by the SGSN in above 205 of Figure 2. Step 720 corresponds to above Step 521 in Figure 5. In 720, the actions of the

New SGSN are the same as those of the SGSN from 206 to 214 in above Figure 2 except that in 720, the GGSN that exchanges information with the New SGSN is the M-GGSN but not the U-GGSN.

Step 721 indicates that since the New SGSN doesn't support the MBMS, it won't react to the message received in above Step 710 from the U-GGSN, nor sends an error message to the U-GGSN, and the error message contains the parameter of Cause that indicates the error reason.

♦ Figure 8 describes the actions process of the node U-GGSN in the flow of above Figure 5. Steps of 801 and 802 in Figure 8 correspond to above steps of 507 and 508 in Figure 5. In Step 801 and 802, the U-GGSN receives the Update PDP Context Request message sent from the New SGSN, the message contains parameters as the address of New SGSN, GTP tunnel address of New SGSN, etc. The U-GGSN updates the corresponding parameters of the PDP Context saved by its own according to the parameters in the message received, and sends the Update PDP Context Response message to the New SGSN, the message contains GTP tunnel address of U-GGSN to make the New SGSN also update the corresponding parameters of its PDP Context after the New SGSN receives the response message. Step 803 in Figure 8 corresponds to above Step 510 in Figure 5. In 803, the

U-GGSN sends the MBMS Notification Request message to the New SGSN, which is used to notify the New SGSN that the described UE has activated the MBMS service, and this message comprises such parameters as IP multicast address, APN and NSAPI. Here, the IP multicast address and APN indicate the MBMS service. The NSAPI indicates a specific PDP Context, and the UE initially activates MBMS service through sending the IGMP Joining message via this PDP Context, as shown in Figure 2, then this specific PDP Context is exactly the PDP Context set up in 201 of Figure 2.

Step 804 in Figure 8 corresponds to above Step 511 in Figure 5. At the same time, Step 804 in Figure 8 is a judge condition. If the U-GGSN receives the correct message of MBMS Notification Response from the New SGSN in Step 804, then it enters Step 805. If the U-GGSN didn't receive the correct message of MBMS Notification Response or receives an error message from the New SGSN in Step 804, it enters Step 806. Step 805 in Figure 8 indicates the end of the U-GGSN actions in Figure 5.

Step 806 in Figure 8 is a judge condition. If the U-GGSN provides the MBMS for the UE in point-to-point PS mode before Step 801, then the U-GGSN enters Step 805; otherwise, then U-GGSN enters Step 807.

Step 807 in Figure 8 corresponds to above Step 512 in Figure 5. In 807, the U-GGSN sends the Teardown MBMS Context Notification Request message to the Old SGSN, the message contains parameters as IP multicast address, APN,

Linked NSAPI and Cause. The IP multicast address and APN indicate a certain

MBMS service. The Linked NSAPI indicates a certain PDP Context, which is used to send the IGMP message when the UE activates the MBMS service. The Cause indicates reason, i.e. the reason why the U-GGSN requires the Old SGSN to delete the MBMS Context. Step 808 in Figure 8 corresponds to above Step 513 in Figure 5. In 808, the U-GGSN receives the Teardown MBMS Context Notification Response message sent from the Old SGSN, the message contains parameters as Cause that indicates reason. Step 809 in Figure 8 corresponds to above Step 518 in Figure 5. In 809, the

U-GGSN exchanges information with the BM-SC and joins the multicast service of the BM-SC, and the BM-SC authenticates the U-GGSN at the same time.

Step 810 in Figure 8 corresponds to above Step 519 in Figure 5. In 810, the U-GGSN sends the MBMS Point-to-point PS Mode Notification message to the UE, the message contains parameters as IP multicast address and APN. The purpose is to let the UE choose to pause the use of MBMS Context or to delete the MBMS Context according to the specific implementation after the UE receives this message.

Step 811 in figure 8 indicates the end of U-GGSN actions in above Figure 5. ♦ Figure 9 describes the actions of the node M-GGSN in the flow of above Figure 5.

Step 901 in Figure 9 is a judge condition. If the New SGSN in above Figure 5 doesn't support the MBMS, then the M-GGSN enters Step 902; otherwise, it enters Step 906. Step 922 in Figure 9 is also a judge condition. If the message of SGSN

Context Response received by the New SGSN in above Figure 5 contains the MBMS Context, then the M-GGSN enters Step 903; otherwise, it enters Step 908.

Step 903 in Figure 9 corresponds to above Step 516 in Figure 5. In 903, the M-GGSN receives the Update MBMS Context Request message sent from the New SGSN, the message contains parameters as address of New SGSN, data field TEID and NSAPI. The Address of New SGSN indicates PDP address of the New SGSN. The NSAPI can indicate the MBMS Context together with the control field TEID in the message header. The data field TEID is used to set up a common downlink data tunnel between the New SGSN and the M-GGSN, and each MBMS has a common downlink data tunnel. Here when there is no downlink data tunnel of the MBMS between the New SGSN and the M-GGSN, this message should contain the data field TEID.

Step 904 in Figure 9 corresponds to above Step 517 in Figure 5. In 904, the

M-GGSN finds the MBMS Context that needs to be updated according to the parameter contained in the message of Update MBMS Context Request received from the New SGSN in above 903 and updates corresponding parameters, thereafter, the M-GGSN sends the Update MBMS Context Response message to the New SGSN, the message contains parameters as TEID of GGSN and Cause. The TEID of GGSN is used to set up an uplink tunnel between the New SGSN and the M-GGSN, and the Cause indicates reason.

Step 905 in figure 9 indicates the end of the M-GGSN actions in Figure 5.

Step 906 in Figure 9 corresponds to above Step 514 in Figure 5. In 906, the M-GGSN receives the Teardown MBMS Context Request message sent from the Old SGSN, the message contains parameters as TEID, NSAPI and Teardown Ind. The combination of the TEID and NSAPI indicate the MBMS Context that will be deleted. The Teardown Ind indicates the Teardown indicator. If the Teardown Ind is contained, it means to delete all MBMS Contexts of the UE that have the same PDP Context as that of the MBMS Context to be deleted.

Step 907 in Figure 9 corresponds to above Step 515 in Figure 5. In 907, the M-GGSN finds the corresponding MBMS Context according to the parameter contained in the message received in 906 and deletes it, and then sends the

Teardown MBMS Context Response message to the Old SGSN, the message contains parameters as TEID and Cause.

Step 908 in Figure 9 corresponds to above Step 521 in Figure 5. In 908, the actions of the M-GGSN are the same as those of the GGSN from Step 208 to Step 210 in above Figure 2.

The process of RA update when U-GGSN is the same GGSN as M-GGSN:

♦ Figure 10 describes the flow of RA update process when the U-GGSN is the same GGSN as the M-GGSN. In 1001 of Figure 10, when the UE enters a new RA, it finds that it is in the new RA by comparing with the route area indication (RAI) in the broadcast message of the current cell, then it sends the RA Update Request message to the SGSN, the message contains parameters as P-TMSI, Old RAI, TMGI, Old P-TMSI Signature, etc. Here, the TMGI is a new parameter after introducing the MBMS service, which is used by the UE to distinguish the different MBMS service when receiving the paging message.

In 1002 of Figure 10, after receiving the message, the New SGSN estimates the address of the Old SGSN from the parameter Old RAI or Old P-TMSI by using the conventional technology, and sends the SGSN Context Request message to the Old SGSN. This message contains parameters as IMSI, Old RAI, etc. In 1003 of Figure 10, after the Old SGSN receives the SGSN Context Request message sent from the New SGSN, the SGSN puts the MM Context and PDP Context of the UE as well as the MBMS Context into the message of SGSN Context Response and sends them to the New SGSN. The MM Context saves the parameters for mobility management and access of the UE. The PDP Context saves the parameters about data field connection of the UE. And the MBMS saves the parameters about using the MBMS service of the UE.

In 1004 of Figure 10, after receiving the SGSN Context Response message sent from the Old SGSN, the New SGSN performs the security check as well as authentication on UE by exchanging information with the UE and the HLR.

In 1005 of Figure 10, the New SGSN sends the SGSN Context Confirm message to the Old SGSN after completing the security process, whose function is to give a confirmation to the Old SGSN that the New SGSN has received the context message. After receiving this confirmation message, the Old SGSN marks the MM Context and PDP Context of the UE as well the MBMS Context it saves as invalid, and will delete them after waiting a period of time, the waiting time is determined by implementation.

In 1006 of Figure 10, the Old SGSN sends those data packets not having delivered to the UE yet to the New SGSN via GTP tunnel through the message, then the data packets will be sent to the UE by the New SGSN after the RA process is completed.

In 1007 and 1008 of Figure 10, the New SGSN sends the Update PDP Context Request message to the GGSN, the message contains parameters as the address of New SGSN, GTP tunnel address of the New SGSN, etc. The GGSN updates the corresponding parameters of the PDP Context saved by its own according to the parameters in the message received, and sends the Update PDP Context Response message to the New SGSN, the message contains GTP tunnel address of the GGSN, and after the New SGSN receives this response message, it also updates the corresponding parameters of the PDP Context saved by its own. In 1009 of Figure 10, this process makes the location information on UE saved in the HLR get updated through information exchange between the Old SGSN, the New SGSN and the HLR by using the conventional technology, and deletes the UE information saved in the Old SGSN at the same time, in addition, some perpetual subscription information on the UE saved in the HLR is delivered to the New SGSN.

In 1010 of Figure 10, the GGSN sends the MBMS Notification Request message to the New SGSN, which is used to notify the New SGSN that the described UE has activated the MBMS service, and this message comprises such parameters as IP multicast address, APN and NSAPI. Here, the IP multicast address and APN indicate the MBMS service, and the NSAPI indicates a specific PDP Context. The UE initially activates the MBMS service through sending the IGMP Joining message via this PDP Context, as shown in Figure 2, thus this specific PDP Context is exactly the PDP Context set up in 201 of Figure 2.

In 1011 of Figure 10, after the New SGSN receives the message sent from the U-GGSN, if the New SGSN supports the MBMS, it sends the MBMS Notification Request message to the U-GGSN, the message contains the parameter Cause that comprises some explanation about the message itself. If the New SGSN doesn't support the MBMS, it just ignores this message or sends an error message to the U-GGSN.

In 1012 of Figure 10, if the GGSN didn't receive the MBMS Notification Response message in the 1011 described, or receives the error message, the

GGSN sends the Teardown MBMS Context Notification Request message to the

Old SGSN, the message contains parameters as IP multicast address, APN,

Linked NSAPI and Cause. The IP multicast address and APN indicate a certain

Old SGSN to delete the MBMS Context.

In 1013 of Figure 10, after receiving the MBMS Context Notification Request message sent from the GGSN, the Old SGSN sends the Teardown MBMS Context Notification Response message to the GGSN, the message contains parameters as Cause that indicates reason.

In 1014 of Figure 10, the Old SGSN finds the corresponding MBMS Context according to the parameter contained in the message received in above 1012 of Figure 10, and sends the Teardown MBMS Context Request message to the GGSN, the message contains parameters as TEID, NSAPI and Teardown Ind. The combination of the TEID and NSAPI indicates the MBMS Context that will be deleted. The Teardown Ind indicates a Teardown indicator. If the Teardown Ind is contained, it means to delete all MBMS Contexts of the UE that have the same PDP Context as that of the MBMS Context to be deleted. In 1015 of Figure 10, the GGSN finds the corresponding MBMS Context according to the message sent from the Old SGSN in 1014, and sends the Teardown MBMS Context Response message to the Old SGSN, the message contains parameters as TEID and Cause. After receiving the Teardown MBMS Context Response message, if the Old SGSN finds that there has no MBMS Context of the UE and the List of Downstream Nodes parameters in the Bearer Context of the Old SGSN is empty, then the sub-process of deleting the MBMS Bearer Context as shown in Fig.15 is initiated by the Old SGSN.

In 1016 of Figure 10, if the New SGSN supports the MBMS, after completing actions in above 1011 of Figure 10, it sends the Update MBMS Context Request message to the GGSN, the message contains parameters as address of New SGSN, data field TEID and NSAPI. The address of New SGSN indicates the PDP address of the New SGSN. The NSAPI may indicate the MBMS Context together with the control field TEID in the message header. The data field TEID is used to set up a common downlink data tunnel between the New SGSN and the GGSN, and each MBMS has a common downlink data tunnel, in the case where it was no downlink data tunnel of MBMS between the New SGSN and the GGSN before, this message should contain the data field TEID.

In 1017 of Figure 10, after receiving the Update MBMS Context Request message sent from the New SGSN in above 1016 of Figure 10, the GGSN finds the MBMS Context that needs to be updated according to the parameter contained in the message received, thereafter t, the GGSN sends the Update MBMS Context Response message to the New SGSN, the message contains parameters as TEID of GGSN and Cause. The TEID of GGSN is used to set up an uplink tunnel between the New SGSN and the GGSN, and the Cause indicates reason. After receiving the Update MBMS Context Response message, if the New SGSN finds that it has no MBMS Bearer Context yet, then the sub-process of creating the MBMS Bearer Context as shown in Fig. 14 is initiated by the New SGSN.

In 1018 of Figure 10, if the GGSN didn't receive a correct response message after above 1010 of Figure 10, then the GGSN assumes that it should provide the MBMS for the UE in current point-to-point mode, so it exchanges information with the BM-SC, whose purpose is to enable the BM-SC to authenticate the GGSN when the GGSN joins the multicast service of the BM-SC, after 518, the GGSN joins the multicast service of the BM-SC, and from them on, the GGSN can provide MBMS for the UE in point-to-point mode.

In 1019 of Figure 10, if the steps in the above 1018 of Figure 5 are successful, then the GGSN sends the MBMS Point-to-point PS Mode Notification message to the UE, the message contains parameters as IP multicast address and APN. After receiving this message, the UE will choose to pause the use of MBMS Context or to delete the MBMS Context according to the specific implementation.

In 1020 of Figure 10, if the New SGSN supports the MBMS, and it knows that the UE is the one that subscribes to use the MBMS after above 1010 of Figure 10 while the SGSN Context Response message received in above 1003 of Figure 10 didn't contain the MBMS Context, then the New SGSN sends the MBMS Context Activation Request message to the UE, which is the same as that sent by SGSN in above 205 of Figure 2.

In 1021 of Figure 1, the UE executes the process of activating MBMS Context, which is the same as that from 206 to 214 of above Figure 2. In 1022 of Figure 10, the New SGSN admits the existence of the UE in the

New RA and sends the RA Update Receive message to the UE. The message comprises the parameter: P-TMSI and P-TMSI Signature. The two parameters are assigned to the UE by the New SGSN as its identity indication in this RA.

In 1023 of Figure 10, after receiving the message sent by the New SGSN in above 522 of Figure 5, the UE confirms the P-TMSI and T-TMSI Signature assigned in this message and sends the RA Update Complete message to the New SGSN. Till now, the RA update process completes.

♦ Figure 11 describes the action flow of node Old SGSN in above flow of Figure 10. Step 1101 in Figure 11 described above corresponds to above Step 1002 in

Figure 10. In Step of 1101, the Old SGSN receives the SGSN Context Request message sent from the New SGSN, which requests the Old SGSN to send all UE related context message saved to the New SGSN. This message comprises the parameter: Old P-TMSI, Old RAI and Old P-TMSI Signature. These parameters are used to let the Old SGSN find the corresponding context information on the UE.

Step 1102 in Figure 11 corresponds to above Step 1003 in Figure 10. In 1102, after finding all saved context information on the UE, the Old SGSN sends the SGSN Context Response message to the New SGSN. This message contains all UE related context information, such as MM Context and PDP Context, and if the UE has activated the MBMS service, this message also contains the MBMS Context. The MBMS Context is shown as Table 1.

Step 1103 in Figure 11 corresponds to above Step 1005 in Figure 10. In 1103, the Old SGSN receives the SGSN Context Confirmation message sent from the New SGSN, which is used to give a confirmation to the Old SGSN that the New SGSN has received the UE related context information.

Step 1104 in Figure 11 corresponds to above Step 1106 in Figure 10. In 1104, the Old SGSN sends the data saved for suspending the transmission to the UE to the New SGSN via the Forward Data Packet message, which will then forwarded to the UE by the New SGSN at a proper time.

Step 1105 in Figure 11 corresponds to above Step 1009 in Figure 10. In 1105, the Old SGSN interacts with the HLR to update the UE related context information, and releases the UE related Iu connections with the RAN, according to the specific implementation, after the Step 1105, the Old SGSN may select to delete all the UE related context information right away or to delete after a period of time.

Step 1106 in Figure 11 is a judge condition, and if the New SGSN in above Figure 10 supports MBMS, then the Old SGSN enters Step 1107; otherwise, it enters Step 1111. Step 1107 in Figure 11 corresponds to above Step 1012 in Figure 10. In Step

1107, the Old SGSN receives the Teardown MBMS Context Notification Request message sent from the GGSN, the message contains parameters as IP multicast address, APN, Linked NSAPI and Cause. The IP multicast address and APN indicate a certain MBMS service. The Linked NSAPI indicates a certain PDP Context, which is used to send the IGMP message when the UE activates the MBMS service. The Cause indicates reason, i.e. the reason why the GGSN requires the Old SGSN to delete the MBMS Context. The purpose of Step 1107 is that, if the New SGSN doesn't support the MBMS, then at this time the MBMS should continue to be provided for the UE in point-to-point PS mode, however, since the New SGSN doesn't support the MBMS, it won't interact with the GGSN to update the MBMS Context information in the GGSN, which results in incorrectness of the MBMS Context saved in the GGSN, so that the Old SGSN is required to interact with the M-GGSN to delete the MBMS Context saved in the GGSN. Step 1108 in Figure 11 corresponds to above Step 1013 in Figure 10. In 1108, the Old SGSN sends the Teardown MBMS Context Notification Response message to the GGSN, the message contains parameters as Cause that indicate reason.

Step 1109 in Figure 11 corresponds to above Step 1014 in Figure 10. In 1109, the Old SGSN finds the corresponding MBMS Context according to the parameter contained in the message received in above 1107, and sends the Teardown MBMS Context Request message to the GGSN, the message contains parameters as TEID, NSAPI and Teardown Ind. The combination of the TEID and NSAPI indicate the MBMS Context that will be deleted. The Teardown Ind indicates the Teardown indicator. If the Teardown Ind is contained, it means to delete all MBMS Contexts of the UE that have the same PDP Context as that of the MBMS Context to be deleted.

Step 1110 in Figure 11 corresponds to above Step 1015 in Figure 10. In Step 1110, the Old SGSN receives the Teardown MBMS Context Response message sent from the GGSN, the message contains parameters as TEID and Cause. This indicates that the GGSN has deleted the corresponding MBMS Context.

Step 1111 of Figure 11 indicates that the actions of the Old SGSN in the flow of Figure 10 have completed.

♦ Figures 12A and B describes the action process of the node New SGSN in the flow of above Figure 10. Step 1201 in Figure 12A corresponds to above Step 1001 in Figure 10. In Step

1201, the New SGSN receives the RA Update Request message sent from the UE, the message contains parameters as P-TMSI, Old RAI, TMGI, Old P-TMSI Signature, etc. Here, the TMGI is a new parameter after introducing the MBMS service, and the TMGI is used to make the UE distinguish the different MBMSs when receiving the paging message.

Step 1202 corresponds to above Step 1002 in Figure 10. In 1202, after receiving the message sent from the UE in above 1201, the New SGSN estimates the address of the Old SGSN from the parameter Old RAI or Old P-TMSI by using the conventional technology, and sends the SGSN Context Request message to the Old SGSN. This message contains parameters as IMSI, Old RAI, etc.

Step 1203 corresponds to above Step 1003 in Figure 10. In Step 1203, the New SGSN receives the SGSN Context Response message sent from the Old SGSN, the message contains parameters as MM Context, PDP Context as well as MBMS Context of the UE. The New SGSN will save the MM Context and PDP Context of the UE received in the message. If the New SGSN supports the MBMS, it will also save the MBMS Context of the UE, otherwise, the New SGSN discards the MBMS Context, or saves it without any processing.

Step 1204 corresponds to above Step 1004 in Figure 10. In 1204, the New SGSN performs the security check as well as authentication on the UE by exchanging information with the UE as well as the HLR. Step 1205 corresponds to above Step 1005 in Figure 10. In 1205, the New SGSN sends the SGSN Context Confirm message to the Old SGSN after completing the security process, whose function is to give a confirmation to the Old SGSN that the New SGSN has received all contexts about the UE. Step 1206 corresponds to above Step 1006 in Figure 10. In 1206, the New

SGSN receives the Forward Data Packet message sent from the Old SGSN, the message contains those data saved for suspending the transmission to the UE by the Old SGSN, and after receiving this message, the New SGSN will forward them to the UE at a proper time. Steps of 1207 and 1208 correspond to above Steps of 1006 and 1007 in

Figure 10. In 1207 and 1208, the New SGSN sends the Update PDP Context Request message to the GGSN, the message contains parameters as the address of New SGSN, GTP tunnel address of New SGSN, etc. The GGSN updates corresponding parameters of PDP Context saved by its own according to the parameters in the message received, and sends the Update PDP Context Response message to the New SGSN, the message contains GTP tunnel address of U-GGSN. After receiving this response message, the New SGSN also updates the corresponding parameters of PDP Context saved by its own.

Step 1209 corresponds to above Step 1009 in Figure 10. In 1209, this process makes the location information on the UE saved in the HLR get updated through information exchange between the Old SGSN, the New SGSN and the HLR by using the conventional technology, and deletes the UE information saved in the Old SGSN at the same time, in addition, some perpetual subscription information on the UE saved in the HLR is delivered to the New SGSN. Step 1210 in Figure 12B corresponds to above Step 1010 in Figure 10. In

1210, the New SGSN receives the MBMS Notification Request message sent from the GGSN, which is used to notify the New SGSN that the described UE has activated the MBMS. This message contains parameters as IP multicast address, APN and NSAPI. The IP multicast address and APN indicate the MBMS service and the NSAPI indicates a specific PDP Context, and the UE initially activates MBMS service through sending the IGMP Joining message via this PDP Context, as shown in Figure 2, then this specific PDP Context is exactly the PDP Context set up in 201 of Figure 2.

Step 1211 is a judge condition. If the New SGSN supports the MBMS, then the New SGSN enters Step 1212; otherwise, it enters Step 1221.

Step 1212 corresponds to above Step 1011 in Figure 10. In 1212, since the New SGSN supports the MBMS, it sends the MBMS Notification Response message to the GGSN, the message contains the parameter Cause that comprises some explanation about the message itself.

Step 1213 is a judge condition, and if the message received by the New SGSN from the Old SGSN in above Step 1203 contains the MBMS Context, then the New SGSN enters Step 1214; otherwise, it enters Step 1219.

Step 1214 corresponds to above Step 1016 in Figure 10. In 1214, the New SGSN sends the Update MBMS Context Request message to the GGSN, the message contains parameters as address of New SGSN, data field TEID and NSAPI. The Address of New SGSN indicates PDP address of the New SGSN. The NSAPI can indicate the MBMS Context together with the control field TEID in the message header. The data field TEID is used to set up a common downlink data tunnel between the New SGSN and the M-GGSN, and each MBMS has a common downlink data tunnel. In this case where it was no downlink data tunnel of MBMS between the New SGSN and the M-GGSN before, this message should contain the data field TEID.

Step 1215 corresponds to above Step 1017 in Figure 10. In 1215, the New

SGSN receives the Update MBMS Context Response message sent from the

GGSN, the message contains parameters as TEID of GGSN and Cause. The TEID of GGSN is used to set up an uplink tunnel between the New SGSN and the

M-GGSN, and the Cause indicates reason.

Step 1216 corresponds to above Step 1022 in Figure 10. In 1216, the New

SGSN admits the existence of the UE in the New RA and sends the RA Update

Receive message to the UE. The message comprises the parameter: P-TMSI and P-TMSI Signature. The two parameters are assigned to the UE by the New SGSN as its identity indication in this RA.

Step 1217 corresponds to above Step 1023 in Figure 10. In 1217, the New SGSN receives the message of RA Update Complete from the UE, which indicates that the UE has confirmed the P-TMSI and P-TMSI Signature newly assigned.

Step 1218 indicates that the actions of the New SGSN in above Figure 10 have been completed.

Step 1219 corresponds to above Step 1020 in Figure 10. In 1219, since the receiving SGSN Context Response message sent from the Old SGSN in above 1203 didn't contain the MBMS Context, the New SGSN sends the MBMS Context Activation Request message to the UE, which is the same as that sent by the SGSN in above 205 of Figure 2.

Step 1220 corresponds to above Step 1021 in Figure 10. In 1220, the actions of the New SGSN are the same as those of the SGSN from 206 to 214 in above Figure 2 except that in 1220, the GGSN that exchanges information with the New SGSN is the GGSN but not the U-GGSN.

Step 1221 indicates that since the New SGSN doesn't support the MBMS, it won't react to the message received in above Step 1210 from the GGSN, nor sends an error message to the GGSN, and the error message contains the parameter of Cause that indicates the error reason.

♦ Figure 13 describes the action process of the node GGSN in the flow of above Figure 10.

Steps of 1301 and 1302 in Figure 13 correspond to above steps of 1007 and 1008 in Figure 10 respectively. In Step 1301 and Step 1302, the U-GGSN receives the Update PDP Context Request message from the New SGSN, the message contains parameters as the address of New SGSN, GTP tunnel address of New SGSN, etc. The U-GGSN updates the corresponding parameters of PDP Context saved by its own according to the parameters in the message received, and sends the Update PDP Context Response message to the New SGSN, the message contains GTP tunnel address of the U-GGSN to make the New SGSN also update the corresponding parameters of its PDP Context after receiving the response message.

Step 1303 in Figure 13 corresponds to above Step 1010 in Figure 10. In 1303, the U-GGSN sends the MBMS Notification Request message to the New SGSN, which is used to notify the New SGSN that the described UE has activated the MBMS service. This message comprises such parameters as IP multicast address, APN, NSAPI. Here, the IP multicast address and APN indicate MBMS service, the NSAPI indicates certain PDP Context, and the UE initially activates MBMS service by sending the IGMP Joining message via this PDP Context, as shown in Figure 2, then this specific PDP Context is exactly the PDP Context set up in 201 of Figure 2.

Step 1304 in Figure 13 corresponds to above Step 1011 in Figure 10, and at the same time, Step 1304 in Figure 13 is a judge condition. If the U-GGSN receives the correct message of MBMS Notification Response sent from the New SGSN in Step 1304, then it enters Step 1313. If the U-GGSN didn't receive the correct message of MBMS Notification Response or receives the error message firom the New SGSN in Step 1304, it enters Step 1305.

Step 1305 in Figure 13 is a judge condition. If the U-GGSN provides the MBMS service for the UE in point-to-point PS mode before Step 1301, then the U-GGSN enters Step 1316; otherwise, the U-GGSN enters Step 1306. Step 1306 in Figure 13 corresponds to above Step 1012 in Figure 10. In 1306, the U-GGSN sends the Teardown MBMS Context Notification Request message to the Old SGSN, the message contains parameters as IP multicast address, APN, Linked NSAPI and Cause. The IP multicast address and APN indicate a certain MBMS service. The Linked NSAPI indicates a certain PDP Context, which is used to send the IGMP message when the UE activates the MBMS service. The Cause indicates reason, i.e. the reason why the U-GGSN requires the Old SGSN to delete the MBMS Context.

Step 1307 in Figure 13 corresponds to above Step 1013 in Figure 10. In 1307, the U-GGSN receives the Teardown MBMS Context Notification Response message from the Old SGSN, the message contains parameters as Cause that indicate cause.

Step 1308 in Figure 13 corresponds to above Step 1014 in Figure 10. In Step 1308, the M-GGSN receives the Teardown MBMS Context Request message from the Old SGSN, the message contains parameters as TEID, NSAPI and Teardown Ind. The combination of TEID and NSAPI indicates the MBMS Context that will be deleted, the Teardown Ind indicates the Teardown indicator, and if the Teardown Ind is contained, it means to delete all MBMS Contexts of the UE that have the same PDP Context as that of the MBMS Context to be deleted. Step 1309 in Figure 13 corresponds to above Step 1015 in Figure 10. In 1309, the M-GGSN finds the corresponding MBMS Context according to the parameter contained in the message received in 1308 and deletes it, and then sends the Teardown MBMS Context Response message to the Old SGSN, the message contains parameters as TEID and Cause. Step 1310 in Figure 13 corresponds to above Step 1018 in Figure 10. In Step

1310, the U-GGSN exchanges information with the BM-SC, and joins the multicast service of the BM-SC, and the BM-SC authenticates the U-GGSN at the same time.

Step 1311 in Figure 13 corresponds to above Step 1019 in Figure 10. In 1311, the U-GGSN sends the MBMS Point-to-point PS Mode Notification message to the UE, the message contains parameters as IP multicast address and APN. The purpose is to let the UE choose to pause the use of the MBMS Context or to delete the MBMS Context according to the specific implementation after the UE receives this message. Step 1312 in figure 13 indicates the end of the GGSN actions in above Figure

10.

Step 1313 in Figure 13 is also a judge condition. If the message of SGSN Context Response received by the New SGSN in above Figure 10 contains the MBMS Context, then the M-GGSN enters Step 1314; otherwise, it enters Step 1317.

Step 1314 in Figure 13 corresponds to above Step 1016 in Figure 10. In 1314, the M-GGSN receives the Update MBMS Context Request message from the New SGSN, the message contains parameters as address of New SGSN, date field TEID and NSAPI. The address of New SGSN indicates PDP address of the New SGSN. The NSAPI can indicate the MBMS Context together with the control field TEID in the message header. The data field TEID is used to set up a common downlink data tunnel between the New SGSN and the M-GGSN, and each MBMS has a common downlink data tunnel. In the case where it was no downlink data tunnel of MBMS between the New SGSN and the M-GGSN before, this message should contain the data field TEID.

Step 1315 in Figure 13 corresponds to above Step 1017 in Figure 10. In 1315, the M-GGSN finds the MBMS Context that needs to be updated according to the parameter contained in the message of Update MBMS Context Request received from the New SGSN in above 1314 and updates the corresponding parameters, thereafter, the M-GGSN sends the Update MBMS Context Response message to the New SGSN, the message contains parameters as TEID of GGSN and Cause. The TEID of GGSN is used to set up an uplink tunnel between the New SGSN and the M-GGSN, and the Cause indicates reason.

Step 1316 in figure 13 indicates the end of the GGSN actions in above Figure 10.

Step 1317 in Figure 13 corresponds to above Step 1021 in Figure 10. In Step 1317, the actions of the M-GGSN are the same as those of GGSN from Step 208 to Step 210 in above Figure 2.

♦ Figure 14 describes the sub-process of setting up MBMS Bearer Context initiated by the SGSN. When the condition to set up the MBMS Bearer Context in the SGSN is satisfied, the SGSN will initiate a sub-process of set ting up the MBMS Bearer Context. Regarding to the SGSN, the condition satisfying to set up the MBMS Bearer Context contains: If the SGSN finds that it doesn't have the MBMS Bearer Context after it successfully sets up or updates the MBMS Context for a certain UE, it will initiate a sub-process of setting up the MBMS Bearer Context; or when the downstream node of the SGSN, i.e. the RNC, requests the SGSN to set up the MBMS Bearer Context, the SGSN initiates a sub-process of setting up the MBMS Bearer Context. In this invention, if the New SGSN finds that it doesn't have the MBMS Bearer Context yet after Step 516 and Step 517 have been successfully completed, then the New SGSN will initiate a sub-process of setting up the MBMS Bearer Context. In this invention, if the New SGSN finds that it doesn't have the MBMS Bearer Context yet after Step 1016 and Step 1017 in above Figure 10 have been successfully completed, the SGSN will initiate a sub-process of setting up the MBMS Bearer Context.

In 1401 of Figure 14, when the condition to setting up the MBMS Bearer

Context is satisfied, the SGSN sends the MBMS Bearer Request message to the

GGSN, which contains parameters as IP multicast address, APN and TEID. The function of the TEID assigned by the SGSN is that if the session has been started, the GGSN sends data to the SGSN with this TEID.

In 1402 of Figure 14, If the GGSN has have the MBMS Bearer Context already when it receives the message sent by the SGSN in above 1401, the GGSN responds with the MBMS Bearer Response message to the SGSN, which contains parameters as IP multicast address, APN, Session Attributes, TMGI and State, and if the GGSN hasn't have the MBMS Bearer Context yet, it requests the BM-SC to set up the bearer. As this situation is not related to this invention, explanation of it will be omitted. After receiving the MBMS Bearer Response message, the SGSN sets up the MBMS Bearer Context and adds the parameter received to the Bearer Context. If the state parameter indicates that the session hasn't been started yet, the SGSN deletes the TEID assigned in above 1401.

♦ Figure 15 describes the sub-process of deleting MBMS Bearer Context initiated by the SGSN.

When the condition to delete the MBMS Bearer Context in the SGSN is satisfied, the SGSN will initiate a sub-process of deleting MBMS Bearer Context.

Regarding to the SGSN , the condition satisfying to delete the MBMS Bearer Context contains:

If the SGSN finds that it doesn't have MBMS Bearer Context already and the parameter of "List of Downstream Nodes" in the Bearer Context of the SGSN is empty, i.e. there is no downstream node requiring to receive the MBMS data any more, the SGSN will initiate a sub-process of deleting the MBMS Bearer Context. In this invention, if the Old SGSN finds that it doesn't have the MBMS Context on the UE already and the parameter of "List of Downstream Nodes" in the Bearer Context of the Old SGSN is empty, i.e. there is no downstream node requiring to receive the MBMS data any more after Step 514 and Step 515 have been successfully completed, the Old SGSN will initiate a sub-process of deleting the MBMS Bearer Context. In this invention, if the Old SGSN finds that it doesn't have the MBMS Context on UE already and the parameter of "List of Downstream Nodes" in the Bearer Context of the Old SGSN is empty, i.e. there is no downstream node requiring to receive the MBMS data any more after Step 1014 and Step 1015 in above Figure 10 have been successfully completed, the Old SGSN will initiate a sub-process of deleting the MBMS Bearer Context.

In 1501 of Figure 15, when the condition to delete the MBMS Bearer Context is satisfied, the SGSN sends the MBMS Teardown Bearer Request message to the GGSN, which contains parameters as IP multicast address and APN. In 1502 of Figure 15, after receiving the message sent from the SGSN in above 1501, the GGSN deletes the identification of the SGSN from the parameter "List of Downstream Nodes", and sends the MBMS Teardown Bearer Response message to the SGSN. After receiving the MBMS Teardown Bearer Response message from the GGSN, the SGSN deletes the MBMS Bearer Context.

Claims

WHAT IS CLAIMED IS:

1. A method for performing route area update of a UE with MBMS service in communication system, when a U-GGSN is not the same one as a M-GGSN, comprising steps of:

(1) sending a RA Update Request message to a New SGSN by the UE;

(3) after receiving the message sent by the New SGSN in Step (2), sending a SGSN Context Response message by the Old SGSN to the New SGSN, the message containing MM Context and PDP Context of the UE;

(4) performing a security check and authentication on the UE by the New SGSN after receiving the message sent by the Old SGSN in Step (3);

(5) sending a SGSN Context Confirm message by the New SGSN to the Old SGSN;

(7) sending an Update PDP Context Request message by the New SGSN to the U-GGSN; (8) sending an Update PDP Context Response message by the U-GGSN to the

New SGSN after receiving the message sent by the New SGSN in Step (7);

(9) performing processes of updating location and inserting user data by the New SGSN, the Old SGSN and the HLR;

(10) sending a MBMS Notification Request message by the U-GGSN to the New SGSN, the message containing parameters as IP multicast address, APN,

NSAPI;

(13) checking the SGSN Context Response message sent by the Old SGSN in Step (3) by the New SGSN, and if the message contains MBMS Context, entering Step (14), otherwise, entering Step (16);

(14) sending an Update MBMS Context Request message by the New SGSN to the M-GGSN, the message containing parameters as New SGSN address, data field TEID and NSAPI;

(15) after receiving the Update MBMS Context Request message sent by the New SGSN in Step (14), the M-GGSN finding the MBMS Context that needs to be updated according to the parameter contained in the receiving message and updating the corresponding parameter field, thereafter, the M-GGSN sending an Update MBMS Context Response message to the New SGSN, the message containing parameters as TEID of GGSN, Cause, then entering Step (24);

(17) after receiving the message sent by the New SGSN in Step (16), executing a process of activating the MBMS Context by the UE, thereafter, entering Step (24);

(18) sending a Teardown MBMS Context Notification Request message by the U-GGSN to the Old SGSN, the message containing parameters as IP multicast address, APN, Linked NSAPI and Cause; (19) After receiving the Teardown MBMS Context Notification Request message sent by the U-GGSN in Step (18), sending a Teardown MBMS Context Notification Response message by the Old SGSN to the U-GGSN, the message containing parameters as Cause indicating reason;

(20) the Old SGSN finding the corresponding MBMS Context according to the parameter contained in the Teardown MBMS Context Notification Request message sent by the U-GGSN in Step (18), and sending a Teardown MBMS

Context Request message to the M-GGSN, the message containing parameters as

TEID, NSAPI and Teardown Ind;

(25) after receiving the message sent by the New SGSN in Step (24), the UE confirming the P-TMSI as well as P-TMSI Signature assigned by this message and sending a RA Update Complete message to the New SGSN.

2. The method according to claim 1, wherein in said step of (3), said SGSN

Context Response message contains the MBMS Context of the UE.

3. The method according to claim 1, wherein in said step of (9), the IP multicast address and the APN indicate the MBMS service, and the NSAPI indicates a specific PDP context; and the UE sends the IGMP Joining message through this PDP Context when initially activating the MBMS service.

4. The method according to claim 1, wherein in said step of (14), said address of the New SGSN is the PDP address of the new SGSN.

5. The method according to claim 1, wherein in said step of (14), the NSAPI can indicate the MBMS Context together with the control field TEID in the message header.

6. The method according to claim 1, wherein in said step of (15), the parameter TEID of GGSN is used to set up an upstream tunnel between the New SGSN and the M-GGSN.

7. The method according to claim I₅ wherein in said step of (18), the IP multicast address and the APN indicate a certain MBMS service.

8. The method according to claim I₅ wherein in said step of (18), the Linked NSAPI indicates a certain PDP Context, which is used to send an IGMP message when the UE activates the MBMS service.

9. The method according to claim I₅ wherein in said step of (20), the combination of the TEID and the NSAPI indicates the MBMS Context that will be deleted, and the Teardown Ind indicates a Teardown indicator.

10. A method for performing route area update of a UE with MBMS service in communication system, when a U-GGSN is the same as a M-GGSN, comprising steps of,

(1) sending a RA Update Request message by the UE to a New SGSN;

(2) sending a SGSN Context Request message by the New SGSN to an Old SGSN after receiving the message sent by the UE in Step (1); (3) After receiving the message sent by the New SGSN in Step (2), sending a

SGSN Context Response message by the Old SGSN to the New SGSN, the message contains MM Context and PDP Context of the UE;

SGSN;

(7) sending an Update PDP Context Request message by the New SGSN to the GGSN;

(9) performing process of updating location and inserting user data by the New SGSN₅ the Old SGSN as well as the HLR;

(10) sending a MBMS Notification Request message by the GGSN to the New SGSN, the message containing parameters as IP multicast address, APN,

NSAPI;

(15) after receiving the Update MBMS Context Request message sent by the New SGSN in Step (14), the GGSN finding the MBMS Context that needs to be updated according to the parameter contained in the receiving message and updating the corresponding parameter field, thereafter, the GGSN sending an Update MBMS Context Response message to the New SGSN, the message containing parameters as TEID of GGSN, Cause; then entering Step (24);

(17) after receiving the message sent by the New SGSN in Step (16), executing a process of activating the MBMS Context by the UE, after that, entering Step (24);

(18) sending a Teardown MBMS Context Notification Request message by the GGSN to the Old SGSN, the message containing parameters as IP multicast address, APN, Linked NSAPI and Cause;

(20) the Old SGSN finding the corresponding MBMS Context according to the parameter contained in the Teardown MBMS Context Notification Request message sent by the GGSN in Step (18), and sending a Teardown MBMS Context Request message to the M-GGSN, the message containing parameters as TEID,

NSAPI and Teardown Ind;

11. The method according to claim 10, wherein in said step of (3), said SGSN Context Response message contains MBMS Context of the UE.

12. The method according to claim 10, wherein in said step of (14), the IP multicast address and the APN indicate a MBMS service, the NSAPI indicates a specific PDP Context, and the UE initially activates the MBMS service by sending an IGMP Joining message through this PDP Context.

13. The method according to claim 10, wherein in said step of (14), the address of New SGSN indicates a PDP address of the New SGSN.

14. The method according to claim 10, wherein in said step of (14): the NSAPI indicates a MBMS Context together with the control field TEID in the message header.

15. The method according to claim 10, wherein in said step of (15): the parameter TEID of GGSN is used to set up an upstream tunnel between the New SGSN and the GGSN.

16. The method according to claim 10, wherein in said step of (18), the IP multicast address and the APN indicate a certain MBMS service.

17. The method according to claim 10, wherein in said step of (18), the

Linked NSAPI indicates a certain PDP Context, which is used to send an IGMP message when the UE activates the MBMS service.

18. The method according to claim 10, wherein in said step of (20), the combination of the TEID and the NSAPI indicates the MBMS Context that will be deleted, and the Teardown Ind indicates a Teardown indicator.