WO2009082952A1

WO2009082952A1 - Method for realizing bearer deactivation in a mobile communication system, and the system and node thereof

Info

Publication number: WO2009082952A1
Application number: PCT/CN2008/073670
Authority: WO
Inventors: Zhe Chen; Jinyi Zhou; Lan Liu; Qi Yu
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2007-12-27
Filing date: 2008-12-24
Publication date: 2009-07-09
Also published as: CN101472350B; CN101472350A

Abstract

The embodiments of the present invention disclose a method for bearer deactivation in a mobile communication system, which includes: receiving a bearer deactivation request, which comprises an indication for a bearer type that needs to be deactivated; determining the bearer type that needs to be deactivated according to the bearer deactivation request; carrying out the bearer deactivation for the bearer that needs to be deactivated according to the determined bearer type. The embodiments of the present invention also disclose a network node, which includes: a reception unit for receiving a bearer deactivation request, which comprises an indication for a bearer type that needs to be deactivated; a determination unit for determining the bearer type that needs to be deactivated according to the bearer deactivation request received by the reception unit; a deactivation unit for carrying out the bearer deactivation according to the bearer type determined by the determination unit. The embodiments of the present invention also disclose a network node and a system for realizing bearer deactivation.

Description

Method and system for realizing bearer deactivation of mobile communication system, node The application is submitted to Chinese Patent Office on December 27, 2007, application number is 200710032900.4, and the invention name is "a method for implementing mobile communication system bearer deactivation" The priority of the Chinese Patent Application, the entire disclosure of which is incorporated herein by reference. Technical field

The present invention relates to the field of mobile communication networks, and in particular, to a method and system for carrying a deactivation, and a network node. Background technique

The Universal Mobile Telecommunications System (UMTS) is a third-generation mobile communication system using Wideband Code Division Multiple Access (WCDMA) air interface technology. The UMTS system is also commonly referred to as a WCDMA communication system. The UMTS system includes a Radio Access Network (RAN) and a Core Network (CN), where: the RAN is used to handle wireless related functions, and the CN processes voice calls and data connections in the UMTS system, and implements exchange and routing with external networks. Features.

The Gateway GPRS Support Node (GGSN) acts as a basic network element functional entity that provides routing and encapsulation of data packets with external data networks. Serving the GPRS Support Node (SGSN) as a basic component network element, its main function is to forward the input/output IP packets for the mobile station (MS) of the SGSN service area. The RAN consists of a Radio Network Controller (RNC) and a Base Station (NodeB).

In the prior art, Long Term Evolved (LTE)/System Architecture Evolved (SAE), the purpose of LTE is to provide a method for reducing delay, increasing user data rate, improving system capacity, and Covered low-cost networks, using PS domain services, bearer networks are all IP bearers.

The following describes the SAE evolution network architecture and its functions. In the evolved packet core network, the function of the Mobility Management Entity (MME) is to save the mobility management context of the UE, such as the identity of the user, mobility. Management status, location information, etc., and processing Non-Access Stratum (NAS) signaling, responsible for NAS signaling security.

The SAE gateway includes a two-part Serving Gateway (SGW) and a Packet Data Network Gateway (PDN Gateway, PGW). SGW and PGW are two logical entities that can exist in the same or Different physical entities.

The Policy and Charging Rules Function (PCRF) delivers Quality of Service (QoS) and charging policy control information to the PGW as a Policy and Charging Enforcement Function (PCEF) through the S7 interface.

In the prior art, in order to enable the existing UMTS system to be integrated with the SAE system, the UMTS system must be upgraded to the Release 8 version, so the inter-system convergence architecture is called the R8 UMTS network. In the process of implementing the present invention, the inventor has found that the SAE system supports the UE to access through the UMTS system, that is, the UE can access the Serving Gateway (SGW) in the S AE system through the RAN and SGSN of the UMTS system, but the UMTS and the SAE system. Each has its own process to handle the deactivation process, so it needs to be matched at the two system boundaries (SGSN or SGW). In the process of bearer deletion of the R8 UMTS mobile communication system, the method for bearer deletion across the UMTS system and the S AE system is not currently implemented. Summary of the invention

Therefore, the embodiments of the present invention provide a method, system, and node for implementing bearer deactivation of a mobile communication system, and performing bearer deactivation according to different bearer types, thereby implementing bearer deactivation in the mobile communication system.

In order to solve the above technical problem, the embodiment of the present invention provides a method for implementing bearer deactivation of a mobile communication system, and the method includes the following steps:

Receiving a bearer deactivation request, where the bearer deactivation request includes a bearer type indication that needs to be deactivated by the bearer;

Determining, according to the bearer deactivation request, a bearer type that needs to perform bearer deactivation;

Performing bearer deactivation on the bearer that needs to be deactivated according to the determined bearer type. Correspondingly, an embodiment of the present invention further provides a network node, including:

a receiving unit, configured to receive a bearer deactivation request, where the bearer deactivation request includes a bearer type indication that needs to be deactivated by the bearer;

a determining unit, configured to determine, according to the bearer deactivation request received by the receiving unit, a bearer type to be deactivated;

And a deactivation unit, configured to perform bearer deactivation according to the bearer type determined by the determining unit. Correspondingly, an embodiment of the present invention further provides a network node, including:

a generating unit, configured to determine a bearer that performs bearer deactivation, and generate a bearer deactivation request; And a sending unit, configured to send, by the generating unit, a bearer deactivation request to the network determining node.

Correspondingly, the embodiment of the present invention further provides a network system for carrying and deactivating a mobile communication system, where the network system includes a network requesting node and a network determining node, where:

The network determining node is configured to receive a bearer deactivation request sent by the network requesting node, and determine a bearer type to be deactivated in the bearer deactivation request, and perform bearer deactivation on the bearer to be deactivated according to the bearer type;

The network requesting node is configured to determine a bearer that performs bearer deactivation, generate a bearer deactivation request, and send the generated bearer deactivation request to the network judging node.

In the embodiment of the present invention, the bearer deactivation is performed by the network node identifying the bearer type indication, so that the bearer deactivation is completed according to different bearer type indications, thereby satisfying the bearer deactivation between the UMTS system and the SAE system. The drawings, which are used in the technical description, are described in a single manner. It is obvious that the drawings in the following description are only some embodiments of the present invention, and are not laborious for those skilled in the art. Further drawings can also be obtained from these drawings.

1 is a schematic structural diagram of a fusion of a UMTS system and a SAE system;

2 is a diagram of an R8 UMTS system in an embodiment of the present invention;

3 is a schematic structural diagram of a SAE system in an embodiment of the present invention;

4 is a schematic structural diagram of a network requesting node and a network determining node in the embodiment of the present invention; FIG. 5 is a flowchart of a UE initiating a Detach process in the embodiment of the present invention;

6 is a first flowchart of UE-initiated bearer deactivation in an embodiment of the present invention;

7 is a second flowchart of UE-initiated bearer deactivation in an embodiment of the present invention;

8 is a first flowchart of a Detach process initiated by an SGW in an embodiment of the present invention; FIG. 9 is a second flowchart of a Detach process initiated by an SGW in an embodiment of the present invention; FIG. 10 is a UE in an embodiment of the present invention; The third flowchart of the initiated bearer deactivation;

11 is a fourth flowchart of UE-initiated bearer deactivation in the embodiment of the present invention;

FIG. 12 is a fifth flowchart of UE-initiated bearer deactivation in the embodiment of the present invention; 13 is a first flowchart of a PGW-initiated Detach process in an embodiment of the present invention; FIG. 14 is a second flowchart of a PGW-initiated Detach process in an embodiment of the present invention; FIG. 15 is a UE in an embodiment of the present invention; The sixth flowchart of the initiated bearer deactivation;

FIG. 16 is a first flowchart of the bearer deactivation initiated by the SGSN in the embodiment of the present invention; FIG. 17 is a second flowchart of the bearer deactivation initiated by the SGSN in the embodiment of the present invention; The third flowchart of the bearer deactivation initiated by the SGSN; FIG. 19 is a first flowchart of the bearer deactivation initiated by the PGW in the embodiment of the present invention; FIG. 20 is the bearer deactivation initiated by the SGW in the embodiment of the present invention. FIG. 21 is a seventh flowchart of UE-initiated bearer deactivation in an embodiment of the present invention;

22 is a flowchart of a Detach process initiated by an SGSN in an embodiment of the present invention;

23 is an eighth flowchart of UE-initiated bearer deactivation in the embodiment of the present invention;

24 is a ninth flowchart of UE-initiated bearer deactivation in the embodiment of the present invention;

25 is a tenth flowchart of UE-initiated bearer deactivation in the embodiment of the present invention;

FIG. 26 is a fourth flowchart of UE-initiated bearer deactivation in the embodiment of the present invention; FIG. 27 is a fourth flowchart of bearer deactivation initiated by the SGSN in the embodiment of the present invention; FIG. The second flowchart of the bearer deactivation initiated by the PGW in the embodiment; FIG. 29 is a second flowchart of the bearer deactivation initiated by the SGW in the embodiment of the present invention; FIG. 30 is a bearer deactivation initiated by the PGW in the embodiment of the present invention; FIG. 31 is a flowchart of MME-initiated bearer deactivation in the embodiment of the present invention. detailed description

Embodiments of the present invention provide a method, system, and node for implementing bearer deactivation of a mobile communication system, and performing bearer deactivation according to different bearer types, thereby realizing bearer activation in a mobile communication system.

Figure 1 shows the structure of the UMTS system and the SAE system. In order to integrate the existing UMTS system with the SAE system, the UMTS system must be upgraded to the Release 8 version. Therefore, the inter-system convergence architecture is called the R8 UMTS network. . The user equipment (UE) accesses the serving gateway (SGW) through the SGSN, where the SGSN to the UE is the UMTS system, and the SGW to the packet data network gateway (PGW) is the SAE system, and the UE passes the mobility management entity. (MME) accesses the SGW, from the UE to the MME, from the MME to the PGW belongs to the SAE system. Because there are default bearers and private bearers in the SAE system, where: the default bearer is the first bearer established by the user node to an access point name (APN), and one user node can be connected to multiple APNs. Each APN points to a packet data network (PDN); the dedicated bearer is all other bearers on the APN after the default bearer is established, and one default bearer may correspond to multiple private bearers. Therefore, in the bearer deactivation process, special consideration is required for the processing of the two bearer types. In the UMTS system and the SAE system, the messages and parameters for bearer deletion are different. The bearer deactivation in the UMTS system is through packet data. The protocol context (PDP CONTEXT) message is implemented, and in the S AE system is a Bearer Context message.

The embodiment of the present invention is configured to receive a bearer deactivation request, where the bearer deactivation request includes a bearer type indication that needs to be deactivated by the bearer; and determine, according to the bearer deactivation request, a bearer type that needs to be deactivated by the bearer; The determined bearer type performs bearer deactivation on the bearer that needs to perform bearer deactivation.

It should be noted that the bearer type here may be the last default bearer, the default bearer, the dedicated bearer, and the like. The network requesting node first needs to decide to carry the bearer deactivated bearer, generate a bearer deactivation request, and send the bearer deactivation request to the network judging node. If the network determining node determines that the bearer type is the last default bearer, the calling network determines the detaching process of the node to perform bearer deactivation. If the network determining node determines that the bearer type is a default bearer and accepts the bearer deactivation request, all bearers are deactivated; if the bearer deactivation request is not accepted, the bearer deactivation request is rejected. If the network determining node determines that the bearer type is a dedicated bearer, all the dedicated bearers associated with the default bearer are deactivated.

Preferred embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

Referring to FIG. 2, FIG. 2 is a system diagram of bearer deactivation in the embodiment of the present invention. The implementation of the bearer deactivation method is located in the UMTS system and the SAE system. In the UMTS system and the SAE system, the bearer deletion message is not The same is true, and the parameters (PDP CONTEXT in UMTS and Bearer Context in SAE) are also inconsistent. In the process of network deletion of R8 UMTS system, the default bearer and the dedicated bearer should be distinguished. Therefore, the bearer deactivation between the UMTS system and the SAE system can be successfully completed by providing two conversion schemes in the embodiment of the present invention. When carrying out the bearer deletion of the R8 UMTS system, the embodiment of the present invention provides two methods for message conversion. One is that when the bearer is deleted, the SGW node of the upstream SAE system performs message conversion, and transfers between the SGW and the SGSN. The message is in UMTS format; another method is to delete in the bearer At the time, the SGSN node of the downstream UMTS system is responsible for message conversion, and the message format between the SGW and the SGSN is the message format of the SAE.

The bearer deactivation method in the embodiment of the present invention can also be implemented in a SAE system. FIG. 3 shows another system diagram of bearer deactivation in the embodiment of the present invention.

Applicable to the foregoing FIG. 2 and FIG. 3, the embodiment of the present invention provides a method for distinguishing a default bearer from a dedicated bearer and a method for deleting a default bearer, and the system FIG. 2 and the system FIG. 3 include at least a network requesting node and a network determining node, the network determining unit is configured to receive a bearer deactivation request sent by the network requesting node, and determine a bearer type to be deactivated in the bearer deactivation request, and carry the bearer according to the bearer type. The activated bearer is bearer deactivated, and the network requesting node may be a user equipment or an SGSN in the UTMS system; or a user equipment, a mobility management entity, a service gateway, a policy and charging rule module, a packet data network gateway in the SAE system; Wait. The network requesting node is configured to determine a bearer that performs bearer deactivation, generate a bearer deactivation request, and send the generated bearer deactivation request to the network judging node, where the network judging node is a user equipment in the UTMS system, or serving GPRS support. Node; or service gateway, packet data network gateway in the SAE system.

4 is a schematic structural diagram of a network requesting node 10 and a network determining node 20 in the embodiment of the present invention, where: the network determining node 20 includes a receiving unit 21, a determining unit 22, and a deactivation unit 23, and the receiving unit 21 is configured to receive The bearer deactivation request sent by the network requesting node 10, the bearer deactivation request includes a bearer type indication that needs to be deactivated by the bearer, and the deactivated bearer type includes a dedicated bearer, a default bearer, or a last default bearer. The determining unit 22 is configured to determine the bearer type for which bearer deactivation is to be performed; the deactivation unit 23 is configured to perform bearer deactivation according to the bearer type determined by the determining unit 22. The network requesting node 10 includes a generating unit 11 and a sending unit 12, where: the generating unit 11 is configured to generate a bearer deactivation request according to the bearer that is determined to perform bearer deactivation; and the sending unit 12 is configured to use the bearer deactivation request generated by the generating unit 11 Sending to the network judgment node 20, if the deactivation request occurs in the cross-network system, that is, when the network requesting node is the SGSN or the SGW, the bearer deactivation request packet sent by the network requesting node 10 needs to be converted. The SGSN or the SGW is further provided with a converting unit 13 for implementing bearer deactivation request packet conversion between the UMTS and the SAE, and converting the UMTS bearer deactivation request packet in the bearer deactivation request generated by the generating unit 11. The SAE bearer deactivates the request packet, or when the downstream node is notified to delete the corresponding bearer type, the SAE bearer deactivation packet is converted into the corresponding UMTS bearer deactivation packet. The conversion unit 13 is used to implement The conversion of the bearer deactivation request message between the UMTS system and the SAE system can be transmitted between the systems and converted into the UMTS by the SAE bearer deactivation request message after being converted into the corresponding system message. The bearer deactivation request message message is carried, or the bearer deactivation request message message of the UMTS is converted into a bearer deactivation request message message of the SAE. In the specific conversion process, if the bearer deactivation request message includes carrying all the bearers to be deactivated, the request parameter in the bearer deactivation request message message of the UMTS system is added to the bearer deactivation request message of the SAE system. In the message, the request parameter in the bearer deactivation request message of the UMTS system is converted into a request parameter corresponding to the bearer deactivation request message of the SAE system.

The bearer deactivation method implemented in the R8 UMTS system will be described in detail below with reference to Figs. Flowchart 5 to flowchart 20 are used to convert the bearer deactivation request message by the SGW node in the SAE system. When a request message is sent to the corresponding network judgment node, the message between the SGW nodes needs to be converted. Implement bearer deactivation.

FIG. 5 is a flowchart of a detachment initiated by a user equipment (UE) in an embodiment of the present invention, where the detachment process is a Detach process initiated by a corresponding network node, where the UE already knows the bearer type and learns The bearer type is the last default bearer, and the UE directly initiates the Detach process to implement bearer deactivation. The specific steps are as follows:

Step S101: The user equipment (UE) sends a Detach Request message to the serving GPRS support node (SGSN);

Step S102: The SGSN receives the Detach Request message sent by the UE, and sends a Delete PDP contest Request message to the serving gateway (SGW).

Step S103: The SGW receives the Delete PDP contest Request message sent by the SGSN, and sends a Delete Bearer Request message to the packet data network gateway (PGW).

Step S104: The PGW receives the Delete Bearer Request message sent by the SGW, and returns a Delete Bearer Response message to the SGW.

Step S105: The information exchange between the PGW and the Policy and Charging Rules Module (PCRF) is implemented by using a message in the PCRF Interaction;

It should be noted that the step S105 can complete the interaction after the step S103, and the step S104 is also performed after the step S103. After the step S104 is completed, the step S106 can be performed.

Step S106: The SGW receives the returned Delete Bearer Response message, and sends a Delete PDP contest Response message to the SGSN. Step S107: The SGSN receives the Delete PDP bet Response message sent by the SGW, and sends a Detach Accent message to the UE.

Step S108: If there is a radio access bearer (RAB) on the radio network side, the RAB is released. By calling the Detach process initiated by the UE, when the UE knows that the bearer that needs to be deactivated is the last default bearer, the R8 UMTS system bearer deactivation can be implemented.

When the UE initiates the bearer deactivation, the UE knows the bearer type, and the bearer deactivates the bearer of the default bearer and the dedicated bearer by using the SGW. The bearer deactivation method initiated by the user equipment (UE) shown in FIG. , Specific steps are as follows:

Step S201: The UE sends a Deactivate PDP context request (TI, Teardown Ind, DBD) message to the SGSN, where the message is stored in the message, where: Teardown Ind is a disassembly identifier, which is used to identify whether all bearers are deleted. The identity of the bearer is deactivated; the identifier used by the DBD to identify whether all private bearers are deleted. If the UE wants to activate the default bearer, the value of the Tearerdown lnd is set to 1 in this message. The value of the setting indicates that all bearers are deleted. The value can also be represented by other custom values or symbols. The parameter and the set value indicate that the UE wants to deactivate all the default bearers. If the UE wants to delete all the private bearers of this PDN connection, the DBD value is set to 1 in this message, and the value is deleted by the set value. For all proprietary bearers, this value can also be represented by other custom values or symbols. This parameter and the set value indicate that the UE wants to deactivate all the dedicated bearers. The setting of the parameter values and the message body of the parameters can be based on The custom setting of the requirement, by the set parameters and values, enables it to delete all bearers and delete all the dedicated bearers;

Step S202: The SGSN sends a Delete PDP context request (TEID, NSAPI, Teardown Ind, DBD) to the SGW, where: the TEID is the tunnel endpoint identifier, and the NSAPI is the network layer service access point identifier. If the Teardown Ind parameter in the message sent by the UE is set to delete all bearers, then the SGSN is ready to deactivate all PDP contexts. If the DBD is set to delete all dedicated bearers, then the SGSN is ready to deactivate all the dedicated bearers;

Step S203: After the SGW receives the information of the SGSN, whether the Bearer ID obtained by the NSAPI is the bearer ID of the default bearer, and if it is the Bearer ID of the default bearer, the SGW will handle the matter in the following three possible ways:

A: The SGW rejects the deactivation request;

B: The SGW prepares to delete all bearers between the SGW and the PGW; C: The SGW deletes all the private bearers associated with this default bearer.

If the SGW confirms that it is not the deactivation of the default bearer and satisfies the C processing mode, the SGW sends a Request Bearer Deactivation (Bearer ID, DBD) to the PGW.

If the message sent in step S202 has a Tearerdown Ind parameter and the value is deleted for all bearers, and the B processing mode is satisfied, the SGW can have two processing methods:

a) You can use Tearerdown Ind in this message and set it to delete all the bearers;

b) The Bearer ID can be set to the default Bearer ID instead of Tearerdown Ind.

After the SGW confirms that the default bearer is deactivated, the SGW sends a Request Bearer Deactivation (Bearer ID) message or a Request Bearer Deactivation (Tearer Down Ind, Bearer ID) message to the PGW.

Step S204: If the PCC architecture is deployed, PCC interaction is required;

Step S205: The PGW sends a Delete Bearer Request message (Bearer ID, DBD) to the SGW to notify the SGW to delete the bearer. If it is the a) processing method in step S203, the message includes a Tearerdown Ind parameter instead of the Bearer ID parameter. The SGW responds to the PGW with a Delete Bearer Response message. If the DBD value in the Delete Bearer Request message is 1, then delete all the dedicated bearers on the PDN connection.

Step S206: The SGW sends a Delete PDP Context Response message to the SGSN. If the message in the S203 has a Teardown lnd value of 1, the SGSN deletes all bearers.

Step S207: The SGSN sends a response message to the UE. Deactivate PDP Context Response;

Step S208: If the RAB exists on the wireless side, the RAB is released.

By determining the type of deactivation required in the UE, each network element in the system determines the required deactivated bearer type, thereby deleting the corresponding bearer type in the network element.

When the UE initiates the bearer deactivation, the UE does not know the bearer type, and the SGW knows the type of the bearer, and processes the deactivated response request to return to the UE. The bearer deactivation method initiated by the user equipment (UE) shown in FIG. 7 can be implemented. The bearer is deactivated. The specific steps are as follows:

Step S301: The UE sends a Deactivate PDP context Request (TI, Teardown Ind) to the SGSN, and the UE cannot save the parameter indicating the bearer type. If the UE wants to activate all bearers, set Tearerdown Ind to delete all bearers in this message.

Step S302: The SGSN sends a Delete PDP context Request (TEID, NSAPI, Teardown Ind). If the message sent by the UE contains Teardown Ind and the value is 1, the SGSN is ready to deactivate all PDP contexts;

Step S303: If the SGW finds that the UE requests to deactivate the UE is not the last bearer, the SGW will have three possible ways to process the message:

A: The SGW rejects the deactivation request;

B: The SGW prepares to delete all bearers between the SGW and the PGW;

C: The SGW deletes all the private bearers associated with this default bearer.

If the SGW receives the deletion request, the SGW determines whether the last default bearer is deactivated. If it is the last default bearer, the SGW may choose to reject the deactivation request, or directly invoke the Detach process initiated by the SGW. The flowchart is as shown in FIG. 8 or FIG. 9, or all the dedicated bearers on the bearer are deleted and the default bearer is reserved; otherwise, the SGW sends a Delete PDP context Response to the SGSN, and the message has a corresponding cause parameter;

Step S304: The SGSN sends a Deactivate PDP context Response to the UE, where the message has a corresponding cause parameter;

Step S305: If the Bearer ID obtained by the SGW through the NSAPI is the Bearer ID of the default bearer, the SGW sends a Request Bearer Deactivation (Bearer ID, Tearer Down Ind, DBD) to the PGW. If the SGW wants to delete all the dedicated bearers of the IP/APN, Then set the DBD to remove all proprietary bearers;

Step S306: If the PCC architecture is deployed, the PCRF sends a PCC policy to the PGW.

Step S307: The PGW sends a Delete Bearer Request (Bearer ID) to the SGW. If the received message contains the Tearerdown Ind parameter, the PGW can have two processing methods:

a) You can use Tearerdown Ind in this message and set it to delete all bearers;

b) The Bearer ID can be set to the default Bearer ID instead of Tearerdown Ind.

Step S308: The SGW determines that all the default bearers of the default bearer are deleted and the default bearer is reserved. Then, the SGW sends multiple Delete PDP Context Requests until the last Delete PDP Context Response message is received and all defaults are deleted. After the dedicated bearer is carried, step S312 can be performed. If the message sent by the PGW contains the Bearer ID of the default bearer, the SGW prepares to delete all IP/APN bearers, and then sends a Delete PDP context Request (NSAPI, Tearerdown Ind, DBD) message to the SGSN, and puts the message inside. Teaeardown Ind is set to remove all bearers; Step S309: If the message sent by the SGW includes the Tearerdown Ind and the value is the deletion of all the bearers, the SGSN prepares to delete all the bearers of the IP/APN, and then sends the Deactivate PDP context to the UE.

Request(NSAPI, Tearerdown Ind, DBD);

Step S310: If the message received by the UE includes Tearerdown Ind and the value is all bearers deleted, the UE deletes all bearers of the IP/APN, and then sends a Deactivate PDP context to the UE.

Request(NSAPI, Tearerdown Ind);

Step S311: If the message sent by the UE includes Tearerdown Ind and the value is all bearers deleted, the SGSN deletes all bearers, otherwise deletes the bearer corresponding to the NS API, and then sends a Delete to the SGW.

PDP context Response(Bearer ID);

Step S312: If the Bearer ID of the message sent by the SGSN is the Bearer ID of the default bearer, the SGW deletes all the bearers, otherwise the SGW deletes the bearer corresponding to the Bearer ID, and then sends a Delete PDP context Response message to the PGW.

Step S313: If the request for deleting the bearer is initiated by the PCC system, then the PGW

The PCRF sends a Provision Ack to inform the PCRF that the request has been executed;

Step S314: If there is an RAB bearer, the RAB may be deleted after the end of step S310. FIG. 8 is a flowchart of a Detach process initiated by an SGW according to an embodiment of the present invention. The specific steps are as follows: Step S401: The SGW sends a Delete PDP context Request message to the SGSN.

Step S402: The SGSN sends a Detach Request message to the UE.

Step S403: The SGW sends a Delete Bearer Request message to the PGW.

Step S404: The PGW sends a Delete Bearer Response message to the SGW.

Step S405: The PCRF and the PGW perform an information exchange process between the PCRF interactions. Step S406: The UE sends a Detach Accent message to the SGSN.

Step S407: The SGSN sends a Delete PDP context Response message to the SGW. Step S408: If there is an RAB bearer, the RAB is deleted.

FIG. 9 is another flowchart of the Detach process initiated by the SGW in the embodiment of the present invention, and the specific steps are as follows:

Step S501: The SGW sends an Initial Detach Request message to the SGSN.

Step S502: The SGSN sends a Detach Request message to the UE.

Step S503: The SGSN sends a Delete PDP context Request message to the SGW.

Step S504: The SGW sends a Delete Bearer Request message to the PGW. Step S505: The PGW sends a Delete Bearer Response message to the SGW.

Step S506: The PCRF and the PGW perform the information exchange process between the PCRF interactions. Step S507: The SGW sends a Delete PDP context Response message to the SGSN. Step S508: After step S502, the UE may send a Detach Accent message to the SGSN. Step S509: If there is an RAB bearer, the RAB is deleted.

When the UE initiates the bearer deactivation, the UE does not know the bearer type, and the SGW knows the type of the bearer, and processes the deactivation and does not respond to the request and returns it to the UE. The bearer deactivation method initiated by the user equipment (UE) shown in FIG. 10 can be implemented. The bearer is deactivated. The specific steps are as follows:

Step S601: The UE sends a Deactivate PDP context Request (TI, Teardown Ind) to the SGSN, and the UE cannot save the parameter indicating the bearer type. If the UE wants to activate all bearers, set Tearerdown Ind to delete all bearers in this message;

Step S602: The SGSN sends a Delete PDP context Request (TEID, NSAPI, Teardown Ind) to the SGW. If the message sent by the UE includes Teardown Ind, the SGSN is ready to deactivate all PDP contexts;

Step S603: If the Bearer ID obtained by the SGW through the NSAPI is the Bearer ID of the default bearer, and is the last default bearer, the SGW may reject, or directly initiate the Detach process, and the specific implementation flowchart is as shown in FIG. 8 or FIG. As shown, or delete all proprietary bearers above the bearer and retain the proprietary bearers.

If it is not the last default bearer, the SGW will have three possible ways to handle this:

A: The SGW rejects the deactivation request;

B: The SGW prepares to delete all bearers between the SGW and the PGW;

C: The SGW deletes all the private bearers associated with this default bearer.

If the SGW is ready to deactivate all the bearers, the SGW-initiated bearer deactivation is invoked, that is, steps S603 to S612 are performed, where steps S604 to S612 are the same as steps S305 to S314 in FIG.

When the UE initiates the bearer deactivation, the UE knows the bearer type, and the bearer is deactivated by the PGW to process the default bearer and the dedicated bearer. The bearer deactivation method can be implemented by the bearer deactivation method initiated by the user equipment shown in FIG. as follows:

Step S701: The UE sends a Deactivate PDP context Request message (TI, Teardown Ind) to the SGSN, and the UE saves a parameter indicating the bearer type. The value of this parameter includes the default bearer and the dedicated bearer. If the UE wants to activate the default bearer, set the Tearerdown Ind to delete all bearers in this message;

Step S702: The SGSN sends a Delete PDP context Request message (TEID, NSAPI, Teardown Ind) to the SGW. If the message sent by the UE includes Teardown Ind, the SGSN prepares to deactivate all PDP contexts.

Step S703: The SGW sends a Request Bearer Deactivation message (Bearer ID) to the PGW, and the SGW obtains a Bearer ID according to the NSAPI, and the SGW prepares to delete the bearer associated with the Bearer ID. If the message sent in step S702 has a Tearerdown Ind parameter and the value is deleted. For all bearers, the SGW can have two methods of processing:

b) The Bearer ID can be set to the default Bearer ID instead of Tearerdown Ind.

Step S704: Perform PCC interaction if the PCC architecture is deployed.

Step S705: If the PGW determines that the Bearer ID is the bearer ID of the default bearer, then the PGW has three possible ways to handle the matter:

A: The PGW rejects the deactivation request;

B: The PGW deletes all bearers of the IP/APN corresponding to the default bearer.

C: The PGW deletes all the private bearers associated with this default bearer.

The PGW sends a Delete Bearer Request (Bearer ID) to the SGW to delete the bearer. If the processing mode is used in step S703, the message further includes a Tearerdown Ind parameter.

Step S706: The SGW deletes the corresponding bearer according to the Bearer ID. If the Bearer ID of the Delete Bearer Request (Bearer ID) received from the PGW is the Bearer ID of the default bearer, all the bearers are deleted, and then a Delete Bearer Response message is sent to the PGW. , the PGW deletes the bearer corresponding to the Bearer ID;

Step S707: The SGW sends a Delete PDP Context Response to the SGSN. If the message in step S702 has Teardown Ind, or the SGW knows to delete the default bearer, the Tearerdown Ind value of the message is 1, and then the SGSN deletes all bearers.

Step S708: The SGSN sends a response message to the UE Deactivate PDP Context Response (TI) „ Step S709: If the RAB exists on the wireless side, the RAB is released.

When the UE initiates bearer deactivation, the UE does not know the bearer type, and the PGW knows the type of bearer, and The device can be deactivated by the bearer deactivation method initiated by the user equipment shown in Figure 12 by using the PGW to process the default ^ ^ load and the exclusive ^ ^ load deactivation. The specific steps are as follows:

Step S801: The UE sends a Deactivate PDP context Request (TI, Teardown Ind) to the SGSN. If the UE wants to deactivate all bearers, set the Tearerdown lnd to delete all bearers in this message.

Step S802: The SGSN sends a Delete PDP context Request (TEID, NSAPI, Teardown Ind) to the SGW. If the message sent by the UE includes Teardown Ind, the SGSN prepares to deactivate all PDP contexts.

Step S803: The SGW sends a Request Bearer Deactivation (Bearer ID) to the PGW. The SGW obtains the Bearer ID based on NSAPI. The SGW prepares to delete the bearer associated with the Bearer ID. If the message sent in step S802 has the Tearerdown Ind parameter and the value is to delete all bearers, the SGW can have two methods of processing:

b) The Bearer ID can be set to the default Bearer ID instead of Tearerdown Ind.

Step S804: If the PCC architecture is deployed, the PGW performs PCC information interaction with the PCRF. Step S805: If the PGW determines that the Bearer ID is the bearer ID of the default bearer, the PGW has three possible ways to handle the matter:

A: The PGW rejects the deactivation request;

C: The PGW deletes all the private bearers associated with this default bearer.

If the PGW continues to delete the bearer, then the PGW determines whether it is the last default bearer. If yes, then the PGW can reject, or directly enter the Detach initiated by the calling PGW, as shown in the flowchart shown in Figure 13 or Figure 14, or delete this. The default bearer is reserved by default, and if it is not the last default bearer, the bearer deactivation process initiated by the PGW is invoked, that is, step S805 to step S812 are performed, and a Delete Bearer Request message is sent to the SGW. Steps S805 to S812 are the same as steps S307 to S314 in FIG. 7, and details are not described herein again.

13 is a flowchart of a Detach process initiated by a PGW according to an embodiment of the present invention. The specific steps are as follows: Step S901: If a PCC architecture exists, PCC information exchanges between the PCRF and the PGW; Step S902: The PGW sends a Delete Bearer Request to the SGW. Message Step S903: The SGW sends a Delete PDP context Request message to the SGSN.

Step S904: The SGSN sends a Detach Request message to the UE.

Step S905: The UE sends a Detach Accent message to the SGSN.

Step S906: The SGSN sends a Delete PDP contex Response message to the SGW.

Step S907: The SGW sends a Delete Bearer Response message to the PGW.

Step S908 If there is an RAB bearer, the RAB is deleted.

FIG. 14 is another flowchart of a Detach process initiated by a PGW according to an embodiment of the present invention, and the specific steps are as follows:

Step S1001: The PGW sends an Initial Detach Request message to the SGW.

Step S1002: The SGW sends an Initial Detach Request message to the SGSN.

Step S1003: The SGSN sends a Detach Request message to the UE.

Step S1004: The SGSN sends a Delete PDP context Request message to the SGW. Step S1005: The SGW sends a Delete Bearer Request message to the PGW.

Step S1006: The PGW sends a Delete Bearer Response message to the SGW.

Step S1007: The information exchange process between the PCRF and the PGW performs PCRF Interaction; Step S1008: The SGW sends a Delete PDP context Response message to the SGSN; Step SI 009: After step SI 003, the UE may send a Detach Accent message to the SGSN; S1010: If there is an RAB bearer, the RAB is deleted.

When the UE initiates the bearer deactivation, the UE does not know the bearer type, and the PGW knows the bearer type, and the bearer is deactivated by the PGW to process the default bearer and the dedicated bearer. The bearer deactivation method initiated by the user equipment shown in FIG. To implement bearer deactivation, the specific steps are as follows:

Step S1101: The UE sends a Deactivate PDP context Request (TI, Teardown Ind) to the SGSN. If the UE wants to deactivate all bearers, set the Tearerdown lnd to delete all bearers in this message.

Step S1102: The SGSN sends a Delete PDP context Request (TEID, NSAPI, Teardown Ind) to the SGW. If the message sent by the UE includes Teardown Ind, the SGSN prepares to deactivate all PDP contexts.

Step S1103: The SGW sends a Request Bearer Deactivation (Bearer ID) to the PGW, and the SGW obtains a Bearer ID according to the NSAPI, and the SGW prepares to delete the bearer related to the Bearer ID. If the message sent in step 81102 with D _{6 ^ «^ (10 \ ¥} 11 Ind parameter value and delete all bearers, the SGW may There are two ways to deal with it:

b) The Bearer ID can be set to the default Bearer ID instead of Tearerdown Ind.

Step S1104: If the PCC architecture is deployed, perform PCC interaction;

Step S1105: If the PGW determines that the Bearer ID is the Bearer ID of the default bearer, the PGW will have three possible ways to handle the matter:

A: The PGW rejects the deactivation request;

C: The PGW deletes all the private bearers associated with this default bearer.

If the PGW continues to delete the bearer, it is judged whether it is the last default bearer. If yes, then directly call the Detach initiated by the PGW, as shown in the flowchart shown in FIG. 13 or FIG. 14, if not, then send the Response Bearer Deactivation to the SGW. Message, with a cause of response;

Step S1106: The SGW sends a Delete PDP Context Response message to the SGSN with a response cause)

Step SI 107: The SGSN sends a Deactivate PDP Context Response message to the UE, with a response cause;

The process of the bearer deactivation initiated by the PGW is invoked, and the process is performed in steps S1108 to S1116. The implementation process is the same as the steps S306 to S314 shown in FIG. 7, and details are not described herein again.

When the SGSN initiates the bearer deactivation, the SGW knows the bearer type, and the bearer is deactivated by the SGW to process the bearer of the default bearer and the dedicated bearer. The bearer deactivation method can be implemented by the bearer deactivation method initiated by the SGSN shown in FIG. as follows:

Step S1201: The SGSN sends a Delete PDP Context Request message (NS API, Tearerdown Ind) to the SGW. If the SGSN wants to activate the default bearer, set Tearerdown Ind to delete all bearers in this message.

Step S1202: The SGW obtains a Bearer ID according to the NS API of the Delete PDP Context Request sent by the SGSN, and detects whether the bearer to be activated is the default bearer. If it is the default bearer and is the last default bearer, the SGW is called. The Detach process initiated by the SGW, the specific implementation flow chart is shown in Figure 8 or Figure 9.

If the SGW detects that the bearer to be activated is the default bearer, and is not the last default bearer, The SGW can have the following processing methods:

A: The SGW rejects the deactivation request;

B: The SGW prepares to delete all bearers between the SGW and the PGW;

C: The SGW deletes all the private bearers associated with this default bearer.

The SGW sends a Request Bearer Deactivation message (Bearer ID) to the PGW. If the first message contains Tearerdownlnd and the value is to delete all bearers, that is, to deactivate all bearers, the SGW can have two processing methods:

b) The Bearer ID can be set to the default Bearer ID instead of Tearerdown Ind.

Step S1203: If the PCC architecture is deployed, perform PCC interaction;

Step S1204: The PGW sends a Delete Bearer Request (Bearer ID) to the SGW. If the a) processing method in step S1202 is adopted, the message further includes a Tearerdown Ind parameter, and the SGW deletes

Bearer ID corresponds to the load.

Step S1205: After receiving the Delete Bearer Request (Bearer ID) message sent by the PGW, the SGW sends a Delete PDP context Response to the SGSN, and the SGSN deletes the corresponding bearer.

Step S1206: After receiving the Delete Bearer Request (Bearer ID) message sent by the PGW, the SGW sends a message

The PGW sends a Delete Bearer Response, and the PGW deletes the bearer corresponding to the Bearer ID. If the PGW confirms that the Bearer ID is the default bearer, all bearers are deleted.

Step S1207: The SGSN sends a Deactivate PDP context Request (TI) message to the UE. Step S1208: The UE sends a Deactivate PDP context Accept message to the SGSN.

Step S1209: If the radio side has an RAB bearer, the RAB is released.

When the SGSN initiates the bearer deactivation, the PGW knows the bearer type, and the PGW processes the bearer of the default bearer and the dedicated bearer to be deactivated. The bearer deactivation method initiated by the SGSN shown in FIG. as follows:

Step S1301: The SGSN sends a Delete PDP Context Request message to the SGW (NSAPI,

Tearerdown Ind), if the SGSN wants to activate the default bearer, then Tearerdown in this message

Ind is set to delete all bearers;

Step S1302: The SGW obtains a Bearer ID according to the NSAPI of the Delete PDP Context Request sent by the SGSN, and then the SGW sends a Request Bearer Deactivation (Bearer ID) to the PGW. If the message contains Tearerdownlnd in the message in step S1302 and the value is to delete all bearers, that is, to deactivate all the bearers, the SGW can have two processing methods:

b) The Bearer ID can be set to the default Bearer ID instead of Tearerdown Ind. Step S1303: If the PCC architecture is deployed, perform PCC interaction;

Step S1304: If the PGW detects that the bearer to be deactivated is the default bearer and is the last default bearer, then the Detach process initiated by the PGW is invoked, and the specific implementation flowchart is as shown in FIG. 13 or FIG.

If the PGW detects whether the bearer to be deactivated is the default bearer, if yes, and not the last default 7 load, then the PGW can have the following three ways:

A: The PGW rejects the deactivation request;

B: The PGW is ready to delete all bearers on the PGW;

C: The PGW deletes all the private bearers associated with this default bearer.

The PGW deletes the Bearer ID bearer and sends a Delete Bearer Request (Bearer ID) to the SGW. If the a) processing method in step S1202 is adopted, the message further includes a Tearerdown Ind parameter, and the SGW deletes the bearer corresponding to the Bearer ID.

Step S1305: After receiving the Delete Bearer Request message of step S1204, the SGW sends a Delete PDP context Response to the SGSN. If the SGW confirms that the default bearer is deleted in step S1304 or all bearers are to be deleted, the SGW puts in the message. Teardown Ind is set to 1.

Step S1306: After receiving the Delete Bearer Request message of step S1204, the SGW sends a Delete Bearer Response to the PGW. The PGW deletes the bearer corresponding to the Bearer ID. If the PGW confirms that it is the Bearer lD of the default bearer, all the bearers are deleted.

Step S 1307: The SGSN sends a Deactivate PDP context Request (TI) message to the UE. Step S 1308: The UE sends a Deactivate PDP context Accept (TI) to the SGSN.

Step S1309: If the radio side has an RAB bearer, the RAB is released.

When the SGSN initiates the bearer deactivation, the PGW knows the bearer type and deactivates the bearer of the default bearer and the dedicated bearer through the PGW. When the SGW receives the Detete PDP Request message sent by the SGSN, the SGW finds that the deactivated bearer is the last one. When the bearer is enabled, the bearer deactivation method can be implemented by the bearer deactivation method initiated by the SGSN shown in Figure 18. The specific steps are as follows:

Step S1401: The SGSN sends a Delete PDP Context Request message (NSAPI, to the SGW, Tearerdown Ind), if the SGSN wants to activate the default bearer, set the Tearerdown Ind to delete all bearers in this message;

Step S1402: After receiving the Detete PDP Context Request message sent by the SGSN, the SGW finds that the deactivated bearer is the last default bearer, and returns a Delete PDP Context Response message to the SGSN, with a response error reason;

Step S1403 to step S1412 are the bearer deletion process initiated by the SGW, and the implementation process is the same as step S305 to step S314 shown in FIG. 7, and details are not described herein again.

When the PGW initiates the bearer deactivation, the PGW knows the bearer type, and the bearer is deactivated by the PGW to process the bearer of the default bearer and the dedicated bearer. The bearer deactivation method can be implemented by the bearer deactivation method initiated by the PGW shown in FIG. as follows:

Step S1501: If the PCC architecture is deployed, the PCRF sends a PCC policy to the PGW.

Step S1502: The PGW sends a Delete Bearer Request (Bearer ID) to the SGW. If the PGW intends to delete all bearers of the PDN connection, the PGW may have two processing methods:

b) The Bearer ID can be set to the default Bearer ID instead of Tearerdown Ind.

If the PGW detects that the bearer to be deleted is the last default bearer, directly invoke the Detach process initiated by the PGW, as shown in the flowchart shown in FIG. 13 or FIG. 14; if it is detected that the default bearer is not the last default bearer, It is also possible for the SGW to delete all of the default bearers of the default bearer and retain the default bearer.

Step S1503: If the SGW decides to delete the default bearer of all the default bearers and retains the default bearer, the SGW sends multiple Delete PDP Context Request messages to the SGSN, and deletes the last Delete PDP Context Response after receiving the last one. All of the default bearers of the default bearer can proceed to step S1507. If the message sent by the PGW contains the Bearer ID of the default bearer, the SGW prepares to delete all IP/APN bearers, and then sends a Delete PDP context Request (NSAPI, Tearerdown Ind, DBD) to the SGSN and puts the inside of the Bearerdown. Ind is set to delete all bearers;

Step S1504: If the message sent by the SGW includes the Tearerdown Ind and the value is deleted, the SGSN prepares to delete all the bearers of the IP/APN, and then sends a Deactivate PDP context Request (NSAPI, Tearerdown Ind, DBD) to the UE. Step S1505: If the message received by the UE includes the Tearerdown Ind and the value is the deletion of all the bearers, the UE deletes the bearers of all the IP/APNs, and then sends a Deactivate PDP context Request (NSAPI, Tearerdown Ind) to the UE.

Step S1506: If the message sent by the UE includes Tearerdown Ind and the value is all bearers deleted, the SGSN deletes all bearers, otherwise deletes the bearer corresponding to the NSAPI, and then sends a Delete PDP context Response (Bearer ID) to the SGW.

Step S1507: If the Bearer ID of the message sent by the SGSN is the bearer ID of the default bearer, the SGW deletes all bearers, otherwise the SGW deletes the bearer corresponding to the Bearer ID, and then sends a Delete PDP context Response to the PGW.

Step S1508: If the request for deleting the bearer is initiated by the PCC system, the PGW sends a Provision Ack to the PCRF to notify the PCRF that the request has been executed;

Step S1509: If there is an RAB bearer, the RAB can be deleted after the end of step S1505.

When the SGW initiates the bearer deactivation, the PGW knows the bearer type and deactivates the bearer of the default bearer and the dedicated bearer through the PGW. When the SGW knows that the deactivated bearer is the last default bearer, the Detach process initiated by the SGW can be initiated. Deactivation of the bearer is implemented, as shown in the flowchart of FIG. 8 or FIG. When the SGW detects that the bearer to be deactivated is not the last default bearer, the bearer deactivation method can be implemented by using the bearer deactivation method initiated by the SGW shown in FIG. 20, and the specific steps are as follows:

Step S1601: If the bearer to be deactivated is not the last default bearer, the SGW sends a Request Bearer Deactivation (Bearer ID, Tearerdown Ind, DBD) to the PGW. ^ The SGW intends to delete all the private bearers of the IP/APN. Then set the DBD to remove all proprietary bearers;

Step S1602 to step S1610 are to invoke the bearer deactivation process initiated by the PGW. The specific implementation steps are the same as steps S1501 to S1509 in FIG. 20, and details are not described herein again.

Flowchart 21 to flowchart 29 are used to perform packet conversion between the UMTS system and the SAE system through the SGSN. When a request message is sent to the corresponding network judgment node, the SGSN node needs to perform conversion between the packets to implement the bearer. Deactivated flow chart.

When the UE initiates the bearer deactivation, the UE knows the bearer type, and the bearer is deactivated by the SGSN to process the bearer of the default bearer and the dedicated bearer, and the bearer deactivation method can be implemented by the bearer deactivation method initiated by the user equipment (UE) shown in FIG. , Specific steps are as follows:

Step S1701: If the UE knows that it is the last default bearer, the UE directly invokes the UE initiated The Detach process, the specific flow chart is shown in Figure 2. The UE sends a Deactivate PDP context Request (Teardown Ind, TI) to the SGSN through the NAS message. If the UE wants to activate all bearers, then the tearerdown lnd is set to delete all bearers in this message, and the UE saves the parameters indicating the bearer type. The value of this parameter includes the default bearer and the dedicated bearer. If the UE wants to activate the default bearer, then set the Tearerdown Ind to delete all bearers in this message;

Step S1702: The SGSN obtains the Bearer ID according to the Delete PDP Context Request sent by the SGSN, and detects whether the bearer to be activated is the default bearer. If yes, the SGSN may have the following three types of processing:

A: The SGSN rejects the deactivation request;

B: The SGSN is ready to delete all bearers between the SGW and the SGSN;

C: The SGSN deletes all proprietary bearers associated with this default bearer.

If all the bearers of the PDN connection need to be deleted, the SGSN sends a Request Bearer Deactivation (Bearer ID, DBD) to the SGW. If all the dedicated bearers associated with the default bearer need to be deleted, the SGSN sets the DBD.

If it is the last default bearer, then the SGSN can handle this:

A: The SGSN refuses to deactivate this time;

B: The SGSN directly calls the Detach process. The process of the specific implementation is shown in Figure 22;

Whether the bearer obtained from the Bearer ID is the default bearer or the Tearerdown Ind is brought in step S1701, the SGSN has two methods:

b) The Bearer ID can be set to the default Bearer ID instead of Tearerdown Ind.

Step S1703: The SGW sends a Request Bearer Deactivation (Bearer ID, DBD) to the PGW. If the processing method a) in step 1702 is adopted, the message further includes a Tearerdown Ind parameter; Step S1704: If the PCC network is deployed, then the PGW is to interact with the PCRF to obtain the PCC policy. If there is no PCC architecture, then the PGW Generate PCC policies locally;

Step S1705: The PGW sends a Delete Bearer Request (Bearer ID) to the SGW, if the step

The S 1702 step adopts a) method, and the message contains a Tearerdown Ind parameter;

Step S1706: The SGW returns a Delete Bearer Response message to the PGW. Step S1707: The SGW sends a Delete Bearer Request (Bearer ID) to the SGSN, if the step

Step S1708: The SGSN sends a Deactivate PDP context Reponse (TI) message to the UE. Step S1709: The SGSN sends a Delete Bearer Response message to the SGW.

Step S1710: If the UE has an RAB bearer, release the RAB bearer.

Figure 22 is a flowchart showing the Detach process initiated by the SGSN in the embodiment of the present invention. The specific steps are as follows: Step S1801: The SGSN sends a Detach Request message to the UE.

Step S 1802: The SGSN sends a Delete PDP context Request message to the SGW. Step S1803: The SGW receives the Delete PDP contest Request message sent by the SGSN, and sends a Delete Bearer Request message to the Packet Data Network Gateway (PGW).

Step S1804: The PGW receives the Delete Bearer Request message sent by the SGW, and returns a Delete Bearer Response message to the SGW.

Step S1805: The information exchange between the PGW and the Policy and Charging Rules Module (PCRF) is implemented by using a message in the PCRF Interaction;

Step S1806: The SGW receives the returned Delete Bearer Response message and sends the message to the SGSN.

Delete PDP contest Response message;

Step S 1807: The SGSN receives the UE sending a Detach Accent message.

Step S1808: If there is a radio access bearer (RAB) on the radio network side, the RAB is released.

The UE initiates bearer deactivation, the UE does not know the bearer type, and the SGSN knows the bearer type, and passes

The SGSN processes the bearer deactivation of the default bearer and the dedicated bearer. The bearer deactivation method can be implemented by the bearer deactivation method initiated by the user equipment (UE) shown in Figure 23. The specific steps are as follows:

Step S1901: The UE sends a Deactivate PDP context to the SGSN through the NAS message.

Request (Teardown Ind, TI), if the UE wants to activate all bearers, then in this message

Tearerdown Ind is set to delete all bearers;

Step S1902: The SGSN obtains a Bearer ID according to the Delete PDP Context Request sent by the UE, and detects whether the bearer to be deactivated is a default bearer. If the default bearer is not the last bearer, the SGSN may have the following three processing manners. :

A: The SGSN rejects the deactivation request;

B: The SGSN is ready to delete all bearers between the SGW and the SGSN;

C: The SGSN deletes all proprietary bearers associated with this default bearer. If the last default bearer is to be deleted, the SGSN can handle this:

Al : SGSN refuses to deactivate this time;

Bl: The SGSN directly enters the Dettach process initiated by the SGSN, and the implementation process is as shown in FIG. 22;

C 1: The SGSN deletes all proprietary bearers associated with this default bearer.

In the Request Bearer Deactivation message sent by the SGSN to the SGW, whether the bearer obtained according to the Bearer ID is the default bearer or the step S 1901 brings the Tearerdo wn Ind, the SGSN has two methods:

b) The Bearer ID can be set to the default Bearer ID instead of Tearerdown Ind.

Step S 1903: The SGSN sends a Request Bearer Deactivation (Bearer ID) to the SGW, if

The SGSN does not activate all bearers. Then delete the corresponding bearer according to the Bearer ID.

The SGW sends a Request Bearer Deactivation (Bearer ID) message to the PGW. If the a) processing mode is used in step S 1902, the message includes a Tearerdown lnd parameter.

Step S1904: If the PCC architecture is deployed, the PCRF interacts with the PGW to generate PCC rules;

Step 1905: If the PCC network is deployed, the PCRF generates a policy to the PGW. If there is no PCC architecture, the PGW generates a local policy.

Step S1906: The PGW sends a Delete Bearer Request (Bearer ID) to the SGW, and prepares to delete all bearers according to the Bearer ID. If the PGW decides to deactivate all bearers connected to the PDN but does not deactivate all bearers, there are two methods:

b) The Bearer ID can be set to the default Bearer ID instead of Tearerdown Ind.

If the PGW wants to activate all the dedicated bearers on all the default bearers and keep the default bearers, then the PGW adds the DBD parameters, ie, the Delete Bearer Request (Bearer ID, DBD), to this message.

Step SI 907: The SGW sends a Delete Bearer Request to the SGSN (Bearer ID, DBD). If the processing mode is used in step S1902, the message includes the Tearerdown Ind parameter.

Step SI 908: The SGSN sends a Deactivate PDP Context Request (Teardown Ind, TI), if there is a DBD in the message in step S1906, the SGSN sends the message multiple times to the UE to ensure that all the dedicated bearers on the default bearer are deleted;

Step S 1909: The UE sends a Deactivate PDP Context Accept (TI) to the SGSN.

Step S1910: The SGSN determines whether all the dedicated bearers on the default bearer are deleted. If all the bearers have been deleted, the SGSN sends a Delete Bearer Response message to the SGW.

Step S 1911: The SGW sends a Delete Bearer Response to the PGW.

Step S1912: If the request for deleting the bearer is initiated by the PCC system, the PGW sends a Provision Ack to the PCRF to notify the PCRF that the request has been executed.

Step S1913: If there is an RAB bearer, the RAB may be deleted after the end of step S1909.

The UE initiates bearer deactivation, and the UE does not know the bearer type. The SGSN knows the bearer type, and the bearer is deactivated by the SGSN to process the bearer of the default bearer and the dedicated bearer, and can be deactivated by the bearer initiated by the user equipment (UE) shown in FIG. The method implements bearer deactivation. The specific steps are as follows:

Step S2001: The UE sends a Deactivate PDP context Request (Teardown Ind, TI) to the SGSN through the NAS message. If the UE wants to deactivate all bearers, set the Tearerdown Ind to delete all bearers in this message.

Step S2002: The SGSN sends a Deactivate PDP context Response to the UE, where the message has a corresponding cause;

Step S2003 to step S2014 are the bearer deactivation process initiated by the SGSN, and the implementation method is the same as step S1902 to step S1913 described in FIG. 24, and details are not described herein again.

The UE initiates bearer deactivation, and the UE knows the bearer type, and the bearer is deactivated by the PGW to process the bearer of the default bearer and the dedicated bearer. The bearer deactivation method can be implemented by the bearer deactivation method initiated by the user equipment (UE) shown in FIG. Specific steps are as follows:

Step S2101: The UE sends a Deactivate PDP context Request (Teardown Ind, NSAPI) message to the SGSN by using the NAS message, and the UE saves the parameter indicating the bearer type. The value of this parameter includes the default bearer and the dedicated bearer. If the UE wants to deactivate the default bearer or all bearers, set Tearerdown Ind to delete all bearers in this message.

Step S2102: The SGSN obtains a Bearer ID according to the NSAPI, and the SGSN sends a Request Bearer Deactivation (Bearer ID) to the SGW.

If you want to delete all bearers of this PDN connection, whether the bearer obtained according to the Bearer ID is the default bearer or the teardowndown Ind is brought in step S2102, the SGSN has two methods: a) You can use the Teearerdown Ind in this message and set it to delete all bearers;

b) The Bearer ID can be set to the default Bearer ID instead of Tearerdown Ind.

Step S2103: The SGW sends a Request Bearer Deactivation (Bearer ID) message to the PGW. If a method is used in step S2102, the message further includes a Tearerdown Ind parameter.

Step S2104: If the PCC network is deployed, then the PGW needs to interact with the PCRF to obtain the PCC policy. If there is no PCC architecture, the PGW locally generates the PCC policy.

Step S2105: The PGW detects, according to the Request Bearer Deactivation (Bearer ID) sent by the SGW, whether the bearer to be activated is the default bearer. If yes, the PGW may have the following processes:

A: The PGW rejects the deactivation request;

B: The PGW is ready to delete all bearers between the SGW and the PGW;

C: The PGW reserves this default bearer and deletes all the private bearers on the default bearer.

The PGW is ready to delete the corresponding bearer according to the Bearer ID. If the last default bearer needs to be deleted, then the Detach process initiated by the PGW is directly entered, as shown in the flowchart shown in FIG. 8 or FIG. 9, or the default bearer is deleted. By default, all the dedicated bearers above are hosted, or the deletion is refused.

The PGW sends a Delete Bearer Request (Bearer ID) to the SGW, and the SGW deletes the bearer associated with the Bearer ID. If the method a) is used in step S2102, the message further includes a Tearerdown Ind parameter.

Step S2106: The SGW sends a Delete Bearer Response (Bearer ID) to the PGW, and the PGW deletes the bearer associated with the Bearer ID. If the method a) is used in step S2102, the message further includes a Tearerdown Ind parameter.

Step S2107: The SGW sends a Delete Bearer Request (Bearer ID) to the SGSN. If a method is used in step S2102, the message further includes a Tearerdown Ind parameter.

Step S2108: The SGSN sends a Deactivate PDP context Reponse (Teardown Ind,

TI);

Step S2109: The SGSN sends a Delete Bearer Response (Bearer ID) to the SGW. If a method is used in step S2102, the message further includes a Tearerdown Ind parameter.

Step S2110: If the UE has an RAB bearer, release the RAB bearer.

The UE initiates bearer deactivation, the UE does not know the bearer type, and the PGW knows the bearer type, and passes The PGW processes the bearer deactivation of the default bearer and the dedicated bearer. The bearer deactivation method can be implemented by the bearer deactivation method initiated by the user equipment (UE) shown in FIG. 26, and the specific steps are as follows:

Step S2201: The UE sends a Deactivate PDP context Request (Teardown Ind, NSAPI) to the SGSN through the NAS message. If the UE wants to activate all bearers, set Tearerdown Ind to delete all bearers in this message.

Step S2202: The SGSN obtains a Bearer ID according to the Delete PDP Context Request sent by the SGSN, and detects whether the bearer to be activated is a default bearer.

If the SGSN confirms that it is not the deactivation of the default bearer, then the SGSN sends a Request Bearer Deactivation (Bearer ID) to the SGW. The SGSN gets the Bearer ID based on NSAPI. The SGSN prepares to delete the corresponding bearer according to the Bearer ID. If all bearers need to be deleted, whether the bearer obtained from the Bearer ID is the default bearer or the step S2201 brings Tearerdown Ind, the SGSN has two methods:

b) The Bearer ID can be set to the default Bearer ID instead of Tearerdown Ind.

Step S2203: The SGW sends a Request Bearer Deactivation (Bearer ID) to the PGW. If a method is used in step S2202, the message further includes a Tearerdown Ind parameter.

Step S2204: The PGW detects whether the bearer to be deleted is the default bearer. If yes, the PGW may have the following processes:

A: The PGW rejects the deactivation request;

B: The PGW is ready to delete all bearers between the SGW and the PGW;

C: The PGW reserves this default bearer and deletes all the private bearers on the default bearer. If the PGW finds that this is the last default bearer, then the Detach process initiated by the PGW is invoked, as shown in the flowchart shown in FIG. 9 or FIG. 10, or the default bearer is reserved to delete all the dedicated bearers on the default bearer. Or refuse to deactivate the bearer. Otherwise, proceeding to step S2205 to step S2212, proceeding

The deactivation process initiated by the PGW, the steps S2204 to S2212 are the same as the steps S1905 to S1913 shown in FIG. 23, and details are not described herein again.

The SGSN initiates bearer deactivation. FIG. 27 shows a flow chart of bearer deactivation initiated by the SGSN in the embodiment of the present invention. The specific steps are as follows:

Step S2301: The SGSN sends a Request Bearer Deactivation (Bearer ID) to the SGW; If the SGSN does not activate all bearers, the corresponding bearer is deleted according to the Bearer ID. If the SGSN decides to deactivate all bearers, there are two methods:

b) The Bearer ID can be set to the default Bearer ID instead of Tearerdown Ind.

Step S2302: The SGW sends a Request Bearer Deactivation (Bearer ID) to the PGW. If the method a) is used in step S2301, the message further includes a Tearerdown Ind parameter.

Step S2303: If the PCC architecture is deployed, the PCRF is to interact with the PGW to generate a PCC rules step S2304 to step S2312 for the PGW-initiated bearer deactivation process, which is the same as the steps S1905 to S1913 shown in FIG. I won't go into details here.

After performing step S2303, if the bearer to be deactivated is not the last default bearer, then the bearer deactivation process initiated by the PGW is invoked, that is, step S2304 to step 2312; otherwise, the PGW has the following processing method:

A: PGW refuses to deactivate this time;

B: The PGW directly enters the process of calling the Dettach process, as shown in Figure 10 or Figure 11;

C: The PGW deletes all the private bearers associated with this default bearer.

The PGW initiates bearer deactivation. FIG. 28 shows a flow chart of bearer deactivation initiated by the PGW in the embodiment of the present invention. The specific steps are as follows:

Step S2401: If the PCC network is deployed, the PCRF generates a policy to the PGW. If there is no PCC architecture, the PGW generates a local policy.

Step S2402: The PGW sends a Delete Bearer Request (Bearer ID) to the SGW, and prepares to delete all bearers according to the Bearer ID. If the PGW decides to deactivate all bearers connected to the PDN but does not deactivate all bearers, there are two methods:

b) The Bearer ID can be set to the default Bearer ID instead of Tearerdown Ind.

If the PGW decides to deactivate all bearers, it goes directly to the Detach process initiated by the PGW, as shown in Figure 9 or 10.

If the PGW wants to activate all the dedicated bearers on all the default bearers and keep the default bearers, then the PGW adds the DBD parameters in this message, namely the Delete Bearer Request (Bearer ID, DBD).

Step S2403: The SGW sends a Delete Bearer Request (Bearer ID, DBD) to the SGSN. If a method is used in step S2402, the message further includes a Tearerdown lnd parameter.

Step S2404: The SGSN sends a Deactivate PDP Context Request (Teardown Ind, TI) to the UE. If the message sent in step S2403 carries a DBD, the SGSN sends the message multiple times to the UE to ensure that all the default bearers are deleted. Proprietary bearer

Step S2405: The UE sends a Deactivate PDP Context Accept (TI) to the SGSN.

Step S2406: The SGSN determines whether all the dedicated bearers on the default bearer are deleted. If all the bearers have been deleted, the SGSN sends a Delete Bearer Response to the SGW.

Step S2407: The SGW sends a Delete Bearer Response to the PGW.

Step S2408: If the request for deleting the bearer is initiated by the PCC system, the PGW sends a Provision Ack to the PCRF to notify the PCRF that the request has been executed;

Step S2409: If there is an RAB bearer, the RAB can be deleted after the end of step S2405.

The SGW initiates bearer deactivation. FIG. 29 shows a flowchart of bearer deactivation initiated by the PGW in the embodiment of the present invention. The specific steps are as follows:

Step S2501: The SGW sends a Request Bearer Deactivation (Bearer ID, DBD) to the PGW, and the SGW prepares to delete the bearer related to the Bearer ID. If the SGW decides to deactivate all bearers, there are two ways:

a) You can use Tearerdown Ind in this message and set it to delete all bearers; b) You can set the Bearer ID to the default Bearer ID instead of Tearerdown Ind.

Step S2502 to step S2510 are the bearer deactivation process initiated by the calling PGW, and the implementation process is the same as step S2401 to step S2409 described in FIG. 25, if the first message contains a DBD that is set to delete all the dedicated bearers, Then, all the dedicated bearers on the default bearer should be deleted in the process, and the default bearer is reserved.

In the deactivation method of the existing SAE system, all the dedicated bearers are deleted by adding the DBD parameters, and the default bearer is reserved by using the parameters. FIG. 30 is a bearer deactivation process initiated by the PGW in the embodiment of the present invention. , Specific steps are as follows:

Step S2601: If the operator deploys the PCC network, the PCC policy triggers to delete a certain bearer. If the PCC network is not deployed, the PGW decides to delete a bearer. Step S2602: The LPGW sends a Delete Dedicated Bearer Request (Bearer ID, DBD, Teardown Ind) to the SGW. If the PGW wants to delete all the bearers, then the Teardown Ind is set. If the PGW wants to delete the bearer and all the dedicated bearers of the PDN connection, Then the PGW sets the DBD;

Step S2603: The SGW sends a Delete Dedicated Bearer Request (Bearer ID, DBD, Teardown Ind) to the MME;

Step S2604: The MME sends a Deactivate Bearer Request (Bearer ID, DBD, Teardown Ind) to the eNB.

Step S2605: The eNB sends a Radio Bearer Release Request (RB ID) to the UE.

Step S2606: The UE sends a Radio Bearer Release Response (RB ID) to the eNB.

Step S2607: The eNB sends a Deactivate Bearer Response to the MME.

Step S2608: The MME sends a Delete Dedicated Bearer Response to the SGW.

Step S2609: The SGW sends a Delete Dedicated Bearer Response to the PGW.

Step S2610: If the deletion process is triggered by the PCC, the PGW sends a Provision Ack to the PCRF to respond.

FIG. 31 is a flowchart of a bearer deactivation initiated by an MME according to an embodiment of the present invention, and the specific steps are as follows:

ID, DBD, Teardown Ind), if the MME wants to delete all bearers, then set Teardown Ind, if the MME wants to delete the bearer and all the dedicated bearers of the PDN connection, then the MME sets the DBD;

ID, DBD, Teardown Ind);

Step S2601: If the operator deploys the PCC architecture, the PGW notifies the bearer to be deleted, and performs a PGW-initiated dedicated bearer deactivation process, and proceeds to step S2602 to step S2610.

In summary, the method provided by the embodiment of the present invention implements the bearer deactivation of the R8 UMTS system and the SAE system, and initiates the bearer type that needs to be deleted by using different network nodes, for example, deleting all bearers, that is, deleting the default bearer; Or deleting the dedicated bearer and retaining the default bearer, implementing bearer deactivation between systems, and deleting different bearer types according to different types of the dedicated bearer and the default bearer, if a network node knows the bearer When the bearer type in the activation request is the last default bearer, the de-attachment process of the network node can be directly invoked to implement bearer deactivation. By the stated The method implements deleting a dedicated bearer in the SAE system while preserving the default bearer.

A person skilled in the art can understand that all or part of the process of implementing the above embodiment method can be completed by a computer program to instruct related hardware, and the program can be stored in a computer readable storage medium. In execution, the flow of an embodiment of the methods as described above may be included. The storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

The above disclosure is only the preferred embodiment of the present invention, and the scope of the present invention is not limited thereto, and thus equivalent changes made in the claims of the present invention are still within the scope of the present invention.

Claims

Rights request

A method for implementing bearer deactivation of a mobile communication system, characterized in that the method comprises the following steps:

Performing bearer deactivation on the bearer that needs to be deactivated according to the determined bearer type.

The method for implementing bearer deactivation of a mobile communication system according to claim 1, wherein the bearer type is any one of the following or a combination thereof:

The last default bearer, default bearer, and proprietary bearer.

The method for implementing bearer deactivation of a mobile communication system according to claim 2, wherein the receiving a bearer deactivation request further comprises:

The network requesting node determines to perform bearer deactivation, and generates a bearer deactivation request; and sends the bearer deactivation request to the network determining node.

The method for implementing bearer deactivation of a mobile communication system according to claim 3, wherein the bearer deactivated by the bearer that needs to be deactivated according to the determined bearer type, specifically:

And if the network determining node determines that the bearer type is the last default bearer, invoking the network determining node's detaching process to perform bearer deactivation.

If the network determining node determines that the bearer type is a default bearer and accepts the bearer deactivation request, all bearers are deactivated.

And if the network determining node determines that the bearer type is a default bearer and does not accept the bearer deactivation request, rejecting the bearer deactivation request.

If the network determining node determines that the bearer type is a dedicated bearer, all the dedicated bearers associated with the default bearer are deactivated.

The method for implementing bearer deactivation of a mobile communication system according to any one of claims 4 to 7, wherein the bearer deactivation request is from a universal mobile communication system UMTS, and the bearer deactivation request is sent. When the edge node between the UMTS and the Long Term Evolution Network/System Architecture Evolution Network SAE serves the GPRS Support Node SGSN or the Serving Gateway, the bearer deactivation request of the UMTS is converted into a bearer deactivation request of the SAE.

The method for implementing bearer deactivation of a mobile communication system according to any one of claims 4 to 7, wherein the bearer deactivation request is from an SAE, and the bearer deactivation request is sent to UMTS and SAE. When the edge node SGSN or the serving gateway is between, the bearer deactivation request of the SAE is converted into a bearer deactivation request of the UMTS.

The method for implementing the bearer deactivation of the mobile communication system according to claim 8, wherein the step of converting the bearer deactivation request of the UMTS into the bearer deactivation request of the SAE is specifically: if the bearer is deactivated When the request contains bearer deactivation of all bearers, the request parameter in the bearer deactivation request of the UMTS system is added in the bearer deactivation request of the SAE system.

The method for implementing the bearer deactivation of the mobile communication system according to claim 8, wherein the step of converting the bearer deactivation request of the UMTS into the bearer deactivation request of the SAE is specifically: If the bearer deactivation request includes carrying all the bearers to be deactivated, the request parameter in the bearer deactivation request of the UMTS system is converted into a request parameter corresponding to the bearer deactivation request of the SAE system.

The method for implementing bearer deactivation of a mobile communication system according to claim 5, wherein the step of deactivating the bearer of all bearers by the network determining node is specifically:

If the network determining node determines that the bearer type is the default bearer, the dedicated bearer is first deactivated, and finally the default bearer is deactivated.

The method for implementing bearer deactivation of a mobile communication system according to claim 7, wherein, if the bearer deactivation request is from an SAE system, the network determining node determines that the bearer deactivation type is a dedicated bearer. And performing, by the bearer deactivation, the dedicated bearer corresponding to the SAE system.

14. A network node, comprising:

And a deactivation unit, configured to perform bearer deactivation according to the bearer type determined by the determining unit.

15. A network node, comprising:

And a generating unit, configured to determine a bearer that performs bearer deactivation, to generate a bearer deactivation request, and a sending unit, configured to send a bearer deactivation request generated by the generating unit to the network determining node.

The network node according to claim 15, wherein the network node further comprises a converting unit, wherein the converting unit is configured to implement bearer deactivation request conversion between the UMTS and the SAE, and to carry the bearer of the SAE. The activation request is converted to a bearer deactivation request of the UMTS, or the bearer deactivation request of the UMTS is converted into a bearer deactivation request of the SAE.

A network system for carrying a deactivation of a mobile communication system, characterized in that the network system comprises a network requesting node and a network determining node, wherein:

The network requesting node is configured to determine a bearer that performs bearer deactivation, generate a bearer deactivation request, and send the generated bearer deactivation request to the network judging node;

The network determining node is configured to receive a bearer deactivation request sent by the network requesting node, and determine a bearer type to be deactivated in the bearer deactivation request, and perform bearer deactivation on the bearer to be deactivated according to the bearer type.

The network system according to claim 17, wherein the network requesting node comprises:

The network system according to claim 17 or 18, wherein the network determining node comprises:

The network system according to claim 19, wherein the network requesting node further comprises:

a conversion unit, configured to implement bearer deactivation request conversion between UMTS and SAE, convert a bearer deactivation request of the SAE into a bearer deactivation request of the UMTS, or convert the bearer deactivation request of the UMTS into a bearer deactivation request of the SAE .