WO2008144991A1

WO2008144991A1 - An implementing method and a communication system for saving the address of network anchor point to the network server

Info

Publication number: WO2008144991A1
Application number: PCT/CN2007/071260
Authority: WO
Inventors: Jian Zhang; Wenruo Zhu; Lan Liu; Sihong Zhou; Yanglai Shuai; Haining Wang
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2007-05-28
Filing date: 2007-12-18
Publication date: 2008-12-04

Abstract

An implementing method for saving the address of network anchor point to the network server, includes following steps: the terminal initiates an attach request or a bearer establishment request, and the network side selects the network anchor; during the process that said anchor point distributes the first bearer context to the terminal or creates a connection with the terminal at first time, the network side registers the address of said network anchor point to the network server. An implementing method for deleting the address of network anchor from the network server, includes following steps: during the delete bearer process that the terminal or the entity of the network side initiates, the network side notifies the network server to delete the address of network anchor point that has registered to the network server and no loner served said terminal; said network server unregisters the address of said network anchor point. A communication system is also provided by this invention.

Description

Implementation method and communication system for saving network anchor address to network server This application claims to be submitted to the Chinese Patent Office on May 28, 2007, application number 200710074594.0, and the invention name is "network anchor address saved to the network server" The priority of the Chinese patent application of the method and communication system is required to be submitted to the Chinese Patent Office on August 13, 2007, the application number is 200710140572.X, and the invention name is "the method of saving the address of the network anchor to the network server and The priority of the Chinese Patent Application for the communication system is hereby incorporated by reference in its entirety.

Technical field

The present invention relates to a wireless communication technology, and in particular, to a technique for saving and deleting a network anchor address, and specifically relates to an implementation method and a communication system for saving an address of a network anchor point to a network server.

Background technique

In future communication technologies, it is an important research topic for terminals to seamlessly switch between 3GPP access technologies and non-3GPP (non-3GPP) access technologies.

At present, since the two access technologies have differences in air interface, authentication, user plane establishment, etc., and the control plane entities of the core technologies of the two access technologies have no relevant interfaces, the terminal is in the 3GPP access technology. The handover between the non-3GPP access technology and the non-3GPP access technology is a rigid forward handover procedure, that is, when the terminal in the activated state accesses a heterogeneous access network, an attach procedure is re-executed.

After attaching to an access network, the terminal will select a network anchor to connect to the external packet data network (PDN, Packet Data Network). The IP address used by the terminal will be assigned by the network anchor or by the external PDN network. provide. In the 3GPP access technology, the network side entity can obtain the address of the network anchor point by using an Access Point Name (APN), and in the non-3GPP access technology, the terminal can be connected at the terminal. The APN obtained when the authentication is obtained or obtained through the access authentication obtains the address of the network anchor to the domain name server (DNS, Domin Name Server). It can be seen that the way to obtain the network anchor address between different access technologies is different. Thus, when the terminal is attached to the 3GPP network, a network anchor will be selected and the address of this network anchor will be obtained. When the active terminal moves from the 3GPP network to the non-3GPP network, a reattachment process will be triggered and a process of reselecting a packet data network gateway (PDN GW, PDN Gateway) is required. If the party obtains the network anchor address in the non-3GPP network Then, the acquired network anchor may not be the network anchor obtained in the 3GPP network, which will cause the connection at the user IP level to change and the data to be lost. Therefore, when the terminal switches between different access networks, keeping the network anchor unchanged does a basic condition for maintaining business continuity.

In order to keep the network anchor from changing, a person skilled in the art proposes an idea to save the address of the network anchor obtained in an access network in the network server, when the terminal switches from the access network. When another access network is obtained, the address of the network anchor point is obtained from the network server, so that the terminal can obtain the address of the same network anchor point regardless of which network is switched, thereby ensuring the user. The data will not be lost.

However, there is currently no feasible technical solution for saving the address of the network anchor to the network server, and there is no feasible technical solution for deleting the address of the network anchor from the network server. Summary of the invention

A technical problem to be solved by the embodiments of the present invention is to provide an implementation method and a communication system for saving an address of a network anchor to a network server, so as to provide a feasible technical solution for saving an address of a network anchor to a network server. .

The embodiment of the invention provides an implementation method for saving an address of a network anchor point to a network server, which includes:

The terminal initiates attaching or initiates bearer establishment, and the network side selects a network anchor point;

The network anchor allocates a first bearer context to the terminal or in a process in which the network anchor establishes a connection with the terminal for the first time, the network side registers the address of the network anchor to the network server.

The embodiment of the invention further provides a communication system, including:

a bearer context assigning entity, configured to allocate a first bearer context to the terminal by the network anchor; and an address registration entity, configured to register the address of the network anchor point in the process of assigning the first bearer context to the terminal by the network anchor point Network Server.

a connection establishment entity, configured to establish a connection with the terminal for the first time by the network anchor point;

An address registration entity is configured to register an address of the network anchor to the network server in a process in which the network anchor establishes a connection with the terminal for the first time.

Another technical problem to be solved by embodiments of the present invention is to provide an address of a network anchor point. The implementation method and the communication system are deleted from the network server to provide a feasible technical solution for deleting the address of the network anchor from the network server, and propose a scenario in which the network side server entity initiates the bearer deletion and gives relevant specific Process.

An embodiment of the present invention provides an implementation method for deleting an address of a network anchor from a network server, including:

When the terminal or the network side entity initiates the bearer deletion process, the network side notifies the network server to delete the address of the network anchor that has been registered to the network server and is no longer serving the terminal;

The network server deregisters the address of the network anchor.

An address deletion notification entity, configured to send, in a terminal or network side entity initiate bearer deletion process, a notification for deleting an address of a network anchor that has been registered to the network server and is no longer served by the terminal; The address deletion notification entity notifies the address of the network anchor.

A method for carrying release, comprising:

The network server issues a bearer release request;

After receiving the bearer release response, the network server deletes the address of the network anchor corresponding to the bearer stored on the network server.

Another technical problem to be solved by the embodiments of the present invention is to provide a method for implementing the terminal to retire the network, to provide a feasible technical solution for the terminal to quit the network, and to provide a specific process for the terminal to quit the network.

A method for retiring a terminal includes:

Triggering a network exiting process, releasing the access network resources corresponding to the terminal;

Undoing the mobile IP binding corresponding to the terminal;

The address information of all network anchors related to the terminal saved in the network server is deleted. In some embodiments of the present invention, since the network anchor can assign the first bearer context to the terminal or establish a connection with the terminal for the first time, and the network side registers the address of the network anchor to the network server, the present invention Embodiments provide a feasible technical solution for registering the address of a network anchor to a network server.

In some other embodiments of the present invention, when the network anchor is no longer serving a certain terminal, the network server may receive a notification of deleting the address of the network anchor, and may anchor the network The address is de-registered. Therefore, the embodiment of the present invention provides a feasible technical solution for deleting the address of the network anchor from the network server, and a technical solution for the initiated bearer release initiated by the network server.

In other embodiments of the present invention, when the terminal needs to disconnect from the network, the address information of all network anchors related to the terminal saved in the network server is deleted, and the mobile IP corresponding to the terminal is released. Bind, thus disconnecting the terminal from the network.

DRAWINGS

1 is a schematic diagram of an existing wireless evolved network architecture;

2 is a flowchart of a first preferred embodiment of an implementation method for saving an address of a network anchor point to a network server according to the present invention;

3 is a flow chart of a second preferred embodiment of an implementation method for saving an address of a network anchor point to a network server according to the present invention;

4 is a flowchart of a third preferred embodiment of an implementation method for saving an address of a network anchor to a network server according to the present invention;

5 is a flowchart of a fourth preferred embodiment of an implementation method for saving an address of a network anchor point to a network server according to the present invention;

6 is a flowchart of a fifth preferred embodiment of an implementation method for saving an address of a network anchor to a network server according to the present invention;

7 is a flowchart of a sixth preferred embodiment of an implementation method for saving an address of a network anchor point to a network server according to the present invention;

8 is a flowchart of a seventh preferred embodiment of an implementation method for saving an address of a network anchor point to a network server according to the present invention;

9 is a flowchart of an eighth preferred embodiment of an implementation method for saving an address of a network anchor point to a network server according to the present invention;

10 is a flowchart of a ninth preferred embodiment of an implementation method for saving an address of a network anchor point to a network server according to the present invention;

11 is a flowchart of a first preferred embodiment of an implementation method for deleting an address of a network anchor point from a network server according to the present invention;

12 is a second preferred implementation method for deleting an address of a network anchor point from a network server according to the present invention Selected flow chart of the embodiment;

13 is a flowchart of a third preferred embodiment of an implementation method for deleting an address of a network 4 seed point from a network server according to the present invention;

14 is a flowchart of a fourth preferred embodiment of an implementation method for deleting an address of a network 4 seed point from a network server according to the present invention;

15 is a flowchart of a fifth preferred embodiment of an implementation method for deleting an address of a network 4 seed point from a network server according to the present invention;

16 is a flowchart of a sixth preferred embodiment of an implementation method for deleting an address of a network 4 seed point from a network server according to the present invention;

17 is a flowchart of a seventh preferred embodiment of an implementation method for deleting an address of a network 4 seed point from a network server according to the present invention;

18 is a flowchart of an eighth preferred embodiment of an implementation method for deleting an address of a network 4 seed point from a network server according to the present invention;

19 is a flowchart of a ninth preferred embodiment of an implementation method for deleting an address of a network 4 seed point from a network server according to the present invention;

20 is a flowchart of an embodiment of an implementation method of a bearer release initiated by a network server according to the present invention;

21 is a flowchart of a tenth preferred embodiment of an implementation method for deleting an address of a network anchor point from a network server according to the present invention;

FIG. 22 is a flowchart of a first preferred embodiment of a method for implementing a network retreat of a terminal according to the present invention; FIG. 23 is a flowchart of a second preferred embodiment of a method for implementing a network retiring of a terminal according to the present invention; FIG. 25 is a flowchart of a fourth preferred embodiment of a method for implementing terminal network retreat according to the present invention; FIG. 26 is a fifth preferred embodiment of a method for implementing terminal network retreat according to the present invention; FIG. 27 is a flowchart of a sixth preferred embodiment of a method for implementing a network retreat of a terminal according to the present invention; FIG. 28 is a flowchart of a seventh preferred embodiment of a method for implementing a network retiring of a terminal according to the present invention; FIG. 30 is a flowchart of a ninth preferred embodiment of a method for implementing a terminal network retreating according to the present invention; FIG. 31 is a flowchart of a method for implementing a terminal network retreating according to the present invention; A flowchart of a tenth preferred embodiment; FIG. 32 is a flowchart of an eleventh preferred embodiment of a method for implementing a network disconnection of a terminal according to the present invention.

detailed description

Since some embodiments to be described below relate to wireless evolved network technologies, the wireless evolved network architecture will first be described in conjunction with FIG.

As shown in FIG. 1, the core network of the wireless evolved network mainly includes a mobility management entity (MME,

Logic function modules such as Mobility Management Entity), Serving GW (Serving Gateway), PDN GW, etc., where the MME is responsible for mobility management of the control plane, including user context and mobility state management, assigning user temporary identity and security. Function, etc., which corresponds to the control plane part of the current Universal Mobile Telecommunications System (UMTS, Served GPRS Support Node); Serving GW is the user plane entity, responsible for idle state Initiating paging for downlink data, managing and storing IP bearer parameters and intra-network routing information, etc., which corresponds to the data plane portion of the current UMTS internal SGSN and Gateway GPRS Support Node (GGSN, Gateway GPRS Support Node); ePDG is equivalent to non - The access gateway of the 3GPP network; the PDN GW is equivalent to the network anchor between different access networks. The interface between the PDN GW and the 3GPP access network is S5 in Figure 1, and the interface between the PDN GW and the non-3GPP access network is the S2 series, which is not shown in Figure 1.

In order to facilitate the implementation or reproduction of the solution of the present invention for realizing the address of the network anchor to the network server, a preferred embodiment of the technical solution will be described below with reference to the accompanying drawings.

The embodiments shown in FIG. 2, FIG. 3 and FIG. 4 respectively describe how to implement the process of registering the address of the PDN GW to the Home Subscriber Server (HSS) when the terminal is attached to the 3GPP access network.

Specifically, in the embodiment shown in FIG. 2, the address of the PDN GW is registered by the MME to the HSS. As shown in Figure 2, it includes:

Step S201: User equipment (UE, User Equipment) initiates an attach request (Attach)

Request), the request includes an International Mobile Subscriber Identity (IMSI), an S-Temporary Mobile Subscriber Identity (S-TMSI), and a Tracking Area Identity (TAI, Tracking Area). Identity) and select parameters such as network identification. Step S202: The evolved base station (eNodeB) forwards the attach request to the new MME (new MME), and the attach request carries the identifier of one cell. Specifically, the eNodeB may query the address of the MME from the selected network identifier and the S-TMSI. If the MME cannot be inferred, an MME may be selected.

Step S203: The new MME sends an identifier request to the original MME (old MME).

(Authentication Request) To request IMSI, the old MME can provide IMSI to respond to the identification request (Identification Response). After being detached or de-attached from the network, the S-TMSI and the MME identifying the UE have changed, and the new MME may send the S-TMSI and the old TAI to the old MME to request the IMSI.

Step S204: If neither the new MME nor the old MME identify the UE, the new MME sends an identity request to the UE to request the IMSI, and the UE may provide the IMSI to the new MME to respond to the identity request.

Step S205: If the context of the UE does not exist in the network, an authentication message (Authentication) needs to be enforced.

Step S206: If there are some bearer contexts of the active state related to the UE in the new MME, the new MME needs to send a Delete Bearer Request to the relevant gateway (such as the PDN GW in the figure), and the related gateway can respond. The Delete Bearer Response is deleted, so that the new MME deletes the bearer context.

Step S207: The new MME sends a location update message (Update Location) to the HSS, where the location update message includes the identifier of the new MME and the IMSI.

Step S208: The HSS sends a Cancel Location message to the old MME, and the old MME responds with a Cancel Location Ack message and removes the mobility management and bearer context.

Step S209: If there are some bearer contexts of the active state related to the UE in the old MME, the old MME needs to send a delete bearer request to the relevant gateway, and the related gateway may respond to the request to delete the bearer, so that the old MME deletes the bearers. The context is gone.

Step S210: The HSS sends an Insert Subscriber Data message to the new MME. If the new MME verifies that the UE access is allowed to attach, the new MME constructs a context for the UE, and returns an Insert Subscriber Data Ack message to the HSS. . Step S211: The HSS sends an Update Location Ack message to the new step S211a: The new MME selects an appropriate PDN GW according to information such as an APN or a Fully Qualified Domain Name (FQDN). The policy of selecting the PDN GW can be based on the APN mode, and refer to the configuration of the user data plane physical pool (UPE pool), the location relationship of the PDN GW, the device load, the operator's subscription information, and the roaming protocol. The HSS can also provide a set of PDN GW addresses. The new MME can directly select the appropriate PDN GW according to the configuration of the UPE pool, the location relationship of the PDN GW, the device load, the operator's subscription information, and the roaming agreement. Of course, this step is optional. When the address of the PDN GW can be directly provided by the HSS, for example, in the scenario where the UE in the active state switches from the non-3GPP network to the 3GPP network or when the UE first attaches in the 3GPP network and the HSS only provides a unique PDN GW address to the MME .

Step S212: The new MME sends a Create Default Bearer Request to the selected Serving GW, where the default bearer request may include the context identifiers of the IMSI and the new MME.

Step S213: The Serving GW establishes a new entity in the Evolved Packet System (EPS) bearer table, and sends a default bearer request message to the PDN GW.

Step S214: If the Policy Control and Charging (PCC) system is applied to the network, the PDN GW may need to interact with a Policy Charging Rule Function (PCRF) to obtain The default PCC rule set by the UE.

Step S215: The PDN GW returns a Create Default Bearer Response message to the Serving GW. If the PDN GW has been assigned an address, the Established Default Bearer Response message may include the address of the PDN GW.

Step S216: The Serving GW returns a default bearer response message to the new MME.

Step S216 a: If the UE subscribes to the non-3GPP mobility capability, the new MME may register the address of the PDN GW and the corresponding APN to the HSS. Of course, the new MME may also set the address of the PDN GW according to its own configuration parameters. Registered to the HSS to maintain business continuity when the UE switches between the 3GPP network and the non-3GPP network. Specifically, when obtained from step S211a After taking the address of a group of PDN GWs, new ΜΜΕ will select an appropriate PDN GW according to the description in step S211a. After the bearer between the Serving GW and the PDN GW is successfully established, the new MME can set a selected PDN GW address. The flag is registered to the HSS to indicate that this PDN GW has been selected by the new MME as the user PDN anchor.

Since the HSS needs to provide the address of the PDN GW to the new MME and the address of the registered PDN GW, the following subscription data can be added to the HSS:

Step S217: The new MME sends an Attach Accept message to the eNodeB, where the attach accept message may include information such as a security context, a quality of service (QoS), an uplink tunnel information, and an address of a PDN GW assigned to the UE. .

Step S218: The eNodeB sends a radio bearer setup request (Radio Bearer Establishment)

The Request and the attach accept message are sent to the UE. Of course, the attach accept message may be included in the radio bearer setup request. Otherwise, the radio bearer setup request may also be included in the attach accept message.

Step S219: The UE sends a Radio Bearer Establishment Response (Radio Bearer Establishment Response) to the eNodeB. In addition, the UE may also send an attach complete message to the eNodeB. Of course, the attach accept message may be included in the radio bearer setup response, and vice versa, the radio bearer The setup response can also be included in the attach accept message.

Step S220: The eNodeB forwards the attach complete message to the new MME, where the attach complete message may be included in the control message of the S1-MME interface, and the control message also includes the downlink tunnel information.

Step S221: The new MME sends an Update Bearer Request message to the Serving GW, where the Update Bearer Request message may include an eNodeB address, a downlink tunnel parameter, and the like.

Step S222: The Serving GW returns an Update Bearer Response message (Update Bearer Response) to the new MME.

It should be noted that, in the embodiment shown in FIG. 2, if multiple bearers need to be established, different bearers may be triggered by different network side entities, for example, a pre-established virtual personal network. (VPN, Virtual Private Network) scenario, proprietary signaling bearer, etc. These network side entities may be MME, Serving GW, PCRF, PDN GW, etc. Therefore, it is also necessary to register the address of the PDN GW selected when establishing a new bearer. To the HSS. In this way, the addresses of the PDN GWs of different bearers need to be saved in the HSS, and the addresses of the PDN GWs selected by different bearers may be different.

In addition, HSS and authentication, authorization, and accounting (AAA, Authority, Authentication,

The Accounting server can be an entity or a separate entity. Similarly, the HSS and the Subscription Profile Repository can be either an entity or a separate entity.

In addition, if the UE is attached to the non-3GPP network, the foregoing MME may be equivalent to an access gateway entity such as an ePDG, an Access Serving Network Gateway (ASN GW, Access Serving Network Gateway), etc., after the bearer is successfully established, These entities register the address of the PDN GW with the AAA server.

In the embodiment shown in FIG. 2, since the MME is a control plane entity and has an interface with the HSS, the MME can select the relevant PDN GW for the first time when the UE selects the relevant PDN GW by using the parameters configured by itself. The address of a good PDN GW is registered in the HSS.

In the embodiment shown in Figure 3, the address of the PDN GW is registered to the HSS by the PCC system. As shown in Figure 3, it includes:

Steps S301-S311, these steps are the same as steps S201-S211 shown in Fig. 2.

Step S311a: The new MME selects an appropriate PDN GW according to information such as APN or FQDN. The policy of selecting the PDN GW can be based on the APN mode, and refer to the UPE pool configuration, the PDN GW location relationship, the device load, the operator's subscription information, and the roaming protocol. The HSS can also provide a set of PDN GW addresses. The new MME can directly select the appropriate PDN GW according to the configuration of the UPE pool, the location relationship of the PDN GW, the device load, the operator's subscription information, and the roaming agreement. Of course, this step is optional, for example, in the scenario where the UE in the active state switches from the non-3GPP network to the 3GPP network or when the 3GPP network first attaches the HSS to only provide a unique PDN GW address to the new MME.

In addition, the new MME needs to determine whether to trigger the registration of the address of the PDN GW to the HSS/SPR through the PCC system, and the condition of the determination may be the subscription data of the UE or the parameter configured by the new MME itself. Step S312: The new MME sends a setup default bearer request to the Serving GW, where the establishing the default bearer request may include a parameter for registering the address of the PDN GW to the HSS/SPR, where the parameter indicates that the PDN GW selects the selected PDN GW through the PCC system. The address is registered in the HSS/SPR. The parameters are optional, ie the PDN GW can directly configure the relevant options to ensure that the address of the PDN GW is registered to the HSS/SPR/AAA through the PCC system.

Step S313: The Serving GW sends a setup default bearer request message to the PDN GW, where the setup default bearer request may include the parameters mentioned in step S312 to trigger the PDN GW to register its own address to the HSS/SPR.

Step S314: If the PCC is applied to the network, the PDN GW may need to interact with the PCRF to obtain the default PCC rule set for the UE (including the local breakout, that is, the scenario for accessing the local service), when the PDN GW is located at the roaming place, The PCRF (V-PCRF, Visit-PCRF) of the visited network interacts with the PCRF (H-PCRF, home-PCRF) of the home network.

In the message that the PDN GW interacts with the PCRF, an associated attribute value pair (AVP, Attribute Value Pair) attribute may be added to trigger the PCRF to register the address of the PDN GW to the HSS/SPR, as follows:

<CC-Request>:: = < Diameter Header: 272, REQ, PXY >

< Session-Id >

CC-Request-Type }

CC-Request-Number }

Destination-Host ]

Origin-State-Id ]

Subscription-Id ]

Bearer-Control-Mode ]

Network-Request-Support ]

Bearer-Identifier ] [ Bearer-Operation ]

[ Framed-IP- Address ]

[ Framed-IPv6-Prefix ]

[ 3GPP-RAT-Type ]

[ Termination-Cause ]

[ User-Equipment-Info ]

[ 3GPP-GPRS-Negotiated-QoS-Profile ]

[ 3GPP-SGSN-MCC-MNC ]

[ 3GPP-SGSN-Address ]

[ 3GPP-SGSN-IPv6-Address ]

[ Called-Station-ID ]

[ Bearer-Usage ]

* [TFT-Packet-Filter-Information ]

* [ Charging-Rule-Report]

* [ Event-Trigger]

[ Access-Network-Charging- Address ]

* [ Access-Network-Charging-Identifier-Gx ]

*[Flag of Register PCEF address to HSS/SPR ]

* [ Proxy-Info ]

*[ Route-Record ]

*[ AVP ]

Step S314a: The PCRF may initiate a process of acquiring the subscription data of the UE to the HSS/SPR, and register the address of the PDN GW to the HSS/SPR. In addition, if the PCRF has the subscription data of the UE, the PCRF may only initiate the process of registering the address of the PDN GW to the HSS/SPR.

Steps S315-S322 may be the same as steps S215-S222 of FIG. 2, except that, in step S312, the establishment of the default bearer request sent by the new MME to the Serving GW includes the parameter of registering the address of the PDN GW to the HSS/SPR. Then, the setup default bearer response message in steps S315 and S316 may include parameters for successfully registering the PDN GW to the HSS/SPR.

It should be noted that, in the embodiment shown in FIG. 3, the prior art process can be followed, Introduce additional messages.

In addition, if the UE is attached to the non-3GPP network, the foregoing MME may be equivalent to an access gateway entity such as ePDG, ASN GW, etc., and after the bearer is successfully established, the PDN GW may use the PCC system to the HSS/AAA/SPR server. Register the address of the PDN GW.

In the flow shown in Figure 3, when the PDN GW address is registered to the HSS/SPR, if the network supports multiple PDNs or one PDN GW has multiple PDNs, the APN information also needs to be registered with the PDN GW to the HSS/SPR. The HSS shall store the correspondence between the APN and the PDN GW.

In the embodiment shown in Figure 4, the PDN GW registers its own address directly with the HSS. The embodiment shown in Figure 4 can include a scenario of Local breakout.

As shown in Figure 4, it includes:

Steps S401-S411, these steps are the same as steps S201-S211 shown in Fig. 2.

Step S411a: The new MME selects an appropriate PDN GW according to information such as APN or FQDN. The policy of selecting the PDN GW can be based on the APN mode, and refer to the UPE pool configuration, the PDN GW location relationship, the device load, the operator's subscription information, and the roaming protocol. The HSS can also provide a set of PDN GW addresses. The new MME can directly select the appropriate PDN GW according to the configuration of the UPE pool, the location relationship of the PDN GW, the device load, the operator's subscription information, and the roaming agreement. Of course, this step is optional, for example, when the UE in the active state switches from the non-3GPP network to the 3GPP network or when the 3GPP network first attaches, the HSS only provides a unique PDN GW address to the new MME.

In addition, new MME needs to determine whether to trigger the PDN GW to register its own address to

The condition of the HSS/SPR, the judgment may be based on the subscription data of the UE or the parameter configured by the new MME itself.

Step S412: The new MME sends a setup default bearer request to the Serving GW, where the establishment of the default bearer request may include a parameter for registering the address of the PDN GW to the HSS/SPR. The parameters are optional, that is, the PDN GW can directly configure the relevant option parameters to ensure that its own address is directly registered to the HSS/SPR/AAA.

Step S413: The Serving GW establishes a new entity in the EPS bearer table, and transparently transmits the default 7-load request sent by the new MME to the PDN GW.

Step S414: The PDN GW registers its own address to the HSS/AAA, and the HSS/AAA returns the phase. The indication of the off is given to the PDN GW.

Steps S415-S422 may be the same as steps S215-S222 of FIG. 2, except that, in step S412, the establishment of the default bearer request sent by the new MME to the Serving GW includes a parameter for registering the address of the PDN GW to the HSS/SPR. Then, the setup default bearer response message in steps S415 and S416 may include parameters for successfully registering the PDN GW to the HSS/SPR.

It should be noted that, in the embodiment shown in FIG. 4, the flow of the prior art can be used without introducing additional messages.

In addition, in the embodiment shown in FIG. 4, if the HSS and the AAA are separate entities, the PDN GW can register its own address to the AAA server, and the AAA server then passes the address of the PDN GW to the HSS.

In addition, if the UE is attached to the non-3GPP network, the foregoing MME may be equivalent to an access gateway entity such as ePDG, ASN GW, etc., after the bearer is successfully established, the PDN GW may directly register its own address with the HSS/AAA server. .

It should be noted that the network side entity that triggers the PDG GW to register its own address in the HSS may be the MME, the Serving GW, the PDN GW, the ePDG, the ASN GW, etc., of course, and is not limited to these entities.

In the flow shown in Figure 4, when the PDN GW address is registered to the HSS/SPR, if the network supports multiple PDNs or one PDN GW has multiple PDNs, the APN information also needs to be registered with the PDN GW to the HSS/SPR. The HSS shall store the correspondence between the APN and the PDN GW.

The embodiments shown in FIG. 5, FIG. 6 and FIG. 7 respectively describe how to implement the process of registering the address of the PDN GW to the HSS/SPR when the terminal initiates bearer setup in the 3GPP access network.

Specifically, in the embodiment shown in FIG. 5, if the UE first accesses an external PDN network from the 3GPP network to initiate service, the PDN GW registers its own address directly into the HSS. This embodiment contains a scenario of Local breakout.

As shown in Figure 5, it includes:

Step S501: The UE initiates an Active PDP context Request message to the SGSN.

Step S502: The SGSN selects the related Serving GW and the PDN GW according to the subscription data of the UE and the APN information carried in the activated PDP context request message, and determines the PDN GW. Whether it is necessary to register its own address to the HSS, the condition for the judgment may be based on the subscription data of the UE. It should be noted that the process of determining the condition is optional. For example, the PDN GW can also directly determine whether to register its own address to the HSS according to the parameters configured by itself.

Step S503: The SGSN sends a PDP context request message to the Serving GW, where the Activate PDP context request message may include the address of the PDN GW and the APN information, and may also include an indication of whether the PDN GW needs to register its own address to the HSS. It should be noted that this indication is optional.

Step S504: The Serving GW sends a SAE (System Architecture Evolution) request (Create SAE Bearer Request) to the PDN GW, where the activated SAE bearer request may include information such as a registration indicator bit and an APN.

Step S504a: The PDN GW requests the PCC rule from the V/H PCRF.

Step S504b: If the UE establishes a bearer to the PDN GW for the first time, the PDN GW directly registers its own address with the HSS. The PDN GW may decide whether to register its own address to the HSS according to the indication of the registration parameter bit or the configuration parameter provided in the received SAE bearer request message.

It should be noted that there is no necessary order relationship between step S504a and step S504b.

Step S505: The PDN GW returns a setup SAE bearer response to the Serving GW (Create SAE)

Bearer Response), the establishment of the SAE bearer response may include a PDN GW successfully registered to

The parameters of the HSS.

Step S506: The Serving GW returns a Create PDP context response to the SGSN, where the PDP context response may include a parameter that the PDN GW successfully registers with the HSS.

Step S507: The SGSN returns an Active PDP context accept message to the UE.

It should be noted that, in step S502, the selection of the PDG GW address may also be by Serving.

The GW performs the selection. In this scenario, the SGSN sends a message to the Serving GW to establish a bearer request, which only includes the address of the APN or a group or a PDN GW. The Serving GW may select the PDN GW according to some conditions. In addition, a parameter may also be added in step S504 to instruct the PDN GW to register its own address into the HSS/AAA server. In the embodiment shown in FIG. 6, if the UE initiates the establishment of a bearer to the PDN GW for the first time on the 3GPP network, the address of the PDN GW is registered by the SGSN to the HSS. This embodiment contains a scene of Local breakout.

As shown in Figure 6, it includes:

Step S601: The UE sends an Activate Packet Data Protocol Context Request message to the SGSN.

Step S602: The SGSN selects the related Serving GW and the PDN GW according to the subscription data of the UE and the APN information carried in the activated PDP context request message.

Step S603: The SGSN sends a PDP context request message to the Serving GW, where the PDP context request message may include the address of the PDN GW and the APN information. It should be noted that the PDN GW may also be selected by the Serving GW according to the APN information and other conditions. For example, the SGSN may also provide a set of PDN GW addresses, and the Serving GW integrates some conditions such as load, network configuration, etc. to select the PDN GW.

Step S604: The Serving GW sends a setup SAE bearer request to the PDN GW, where the activated SAE bearer request may include the APN information or the address of the PDN GW.

Step S604a: The PDN GW can interact with the PCRF to obtain a PCC rule.

Step S605: The PDN GW returns a setup SAE bearer response to the Serving GW.

Step S606: The Serving GW returns a PDP context response message to the SGSN, where the message may include a PDN W address if the address is selected by the Serving GW.

Step S607: The SGSN may determine whether the address of the PDN GW needs to be registered to the HSS according to the subscription data of the UE, whether the UE has a non-3GPP mobility capability, or a parameter configured by itself.

The address of the PDN GW may be obtained by the SGSN by querying the APN information, or may be provided by the Serving GW in step S606.

Step S608: The SGSN returns an Activate PDP context accept message to the UE.

In the flow shown in Figure 6, when the PDN GW address is registered to the HSS/SPR, if the network supports multiple PDNs or one PDN GW has multiple PDNs, the APN information also needs to be registered with the PDN GW to the HSS/SPR. The HSS shall store the correspondence between the APN and the PDN GW.

In the embodiment shown in FIG. 7, if the UE initiates a service on the 3GPP network for the first time and establishes a bearer to the external PDN network, the address of the PDN GW is registered to the HSS/AAA/SPR through the PCC system. This embodiment contains a scene of Local breakout. Step S701: The UE sends an Activate PDP context request message to the SGSN.

Step S702: The SGSN selects the related Serving GW and the PDN GW according to the APN information, and determines whether the PCC system is triggered to register the address of the PDN GW to the HSS/SPR, and the determined condition may be based on the subscription data of the UE or the parameter configured by the SGSN itself. In addition, the SGSN may also determine whether to register the address of the PDN GW to the HSS/SPR through the PCC system by directly determining the configuration parameters on the PDN GW.

Regarding the choice of Serving GW and PDN GW, there are the following requirements:

A. The SGSN can select the Serving GW and the PDN GW by using the DNS query mode according to the APN information, the parameters configured by itself, or the subscription data of the UE. For example, the Serving GW and the PDN GW are selected by two DNS query methods. In addition, the SGSN provides the address information of the PDN GW to the Serving GW;

B. The Serving GW may select the PDN GW by using the DNS query mode according to the parameters configured by itself or the subscription data of the UE. For example, the SGSN may provide the APN information to the Serving GW, and the Serving GW queries the DNS system to obtain the PDN GW information.

The HSS directly provides the information of the PDN GW to the SGSN. If a set of IP addresses or FQDNs is provided, the SGSN may select the PDN GW according to the information such as the APN, or the Serving GW may select the PDN according to the APN information and the parameters configured by itself. GW.

Step S703: The SGSN sends an activation PDP context request message to the Serving GW, where the activation PDP context request message includes a parameter for registering the address of the PDN GW to the HSS/SPR, and is used to indicate that the address of the PDN GW is registered to the HSS through the PCC system. /SPR. Of course, the parameters are optional. It should be noted that the PDN GW can also be selected by the Serving GW according to information such as APN.

Step S704: The Serving GW sends an activation SAE bearer request to the PDN GW, where the activated SAE bearer request may include a parameter such as a registration indicator bit and APN information. Of course, the Serving GW can also trigger the PDN GW to register the address of the PDN GW through the PCC system into the HSS/AAA/SPR.

Step S704a: An interaction process involving the PCRF, where the Local breakout scenario is included. When the PDN GW is located at the roaming place, it can interact with the H-PCRF through the V-PCRF.

In the CCR message that the PDN GW interacts with the PCRF, a related AVP genus may be added. The property triggers the PCRF to register the address of the PDN GW to the HSS/SPR.

Step S704b: The PCRF may initiate a process of acquiring the subscription data of the UE to the HSS/SPR, and register the address of the PDN GW to the HSS/SPR. If the PCRF has subscription data for the UE, the PCRF only initiates the process of registering the address of the PDN GW to the HSS/SPR.

Step S705: The PDN GW returns an activated SAE bearer response to the Serving GW, where the response message may include a parameter identifier for successful registration.

Step S706: The Serving GW returns an Activate PDP context response message to the SGSN, where the response message may include a parameter identifier for successful registration.

Step S707: The SGSN returns an Activate PDP context accept message to the UE.

The embodiments shown in FIG. 8 , FIG. 9 and FIG. 10 respectively describe how to implement the process of registering the address of the PDN GW to the HSS/SPR when the terminal initiates the bearer setup in the SAE/LTE access network.

Specifically, in the embodiment shown in FIG. 8, if the UE initiates the establishment of the service to the external PDN network from the SAE/LTE network for the first time, the MME registers the address of the PDN GW to the HSS. This embodiment contains a scenario of Local breakout.

In the flow shown in Figure 8, when the PDN GW address is registered to the HSS/SPR, if the network supports multiple PDNs or one PDN GW has multiple PDNs, the APN information also needs to be registered with the PDN GW to the HSS/SPR. The HSS shall store the correspondence between the APN and the PDN GW.

As shown in Figure 8, it includes:

Step S801: The UE initiates an activation SAE bearer request. Step S802: The new MME selects a PDN GW, where the scenario includes multiple PDNs.

When the PDN GW is selected, the MME may obtain an indication such as APN information carried by the UE, or may determine the address of the PDN GW by using parameters provided from the HSS through default configuration in the HSS.

Step S803 - S806: Perform a bearer establishment process on the core network side.

Step S807: The new MME initiates the process of registering the address of the PDN GW to the HSS. In addition, before the registration process is initiated, the new MME may determine whether the registration process needs to be initiated according to the subscription data of the UE, the capability of the UE, or the parameters configured by the UE. .

Step S808: The new MME returns an active SAE bearer request response, and the activated SAE bearer request response may include configuration parameters of the relevant wireless side and related uplink tunnel configuration information. eNodeB. The message contains parameters for establishing an air interface radio bearer. The eNodeB will establish an associated radio bearer according to the provided parameters for establishing a radio bearer.

Step S809 - S810: Establish a radio bearer process.

Step S811: The eNodeB sends an Update Bearer Request to the new MME, where the update bearer request may include information about the relevant downlink tunnel between the eNodeB and the Serving GW.

Step S812: After the wireless air interface resource is successfully established, the eNodeB returns an active SAE bearer request response to the UE.

Step S813: The new MME sends an update bearer request to the Serving GW, where the update bearer request may include information about the relevant downlink tunnel between the eNodeB and the Serving GW.

Step S814: The Serving GW returns an Update Bearer Response (Update Bearer Response) to the new MME.

It should be noted that, in the embodiment shown in FIG. 8, the scenario may be included, that is, the UE initiates a pre-configured bearer setup process immediately after the SAE/LTE network is attached, for example, in a pre-configured VPN scenario. .

In addition, in the embodiment shown in FIG. 8, the scenario in which the UE initiates a service on the non-3GPP network, such as a scenario of multiple PDNs and multiple home agents (HAs), may be included, such that the MME is equivalent to the ePDG. An access control plane gateway entity such as the ASN GW may register the address of the PDN GW directly with the HSS/AAA/SPR server by an entity such as the ePDG or the ASN GW after the bearer is successfully established. If the AAA and the HSS are separate entities, the address of the registered PDN GW can be passed from the AAA to the HSS.

In the embodiment shown in FIG. 9, if the UE initiates the establishment of the service of the external PDN GW network for the first time in the SAE/LTE access network, the address of the PDN GW is registered to the HSS through the PCC system. This embodiment contains a scenario of Local breakout.

As shown in Figure 9, it includes:

Step S901: The UE initiates an activation SAE bearer request. Step S902: The new MME selects one PDN GW.

Step S903: The new MME sends a setup SAE bearer request to the Serving GW, where the activated SAE bearer request may include the address of the selected PDN GW.

Step S904: The Serving GW sends a setup SAE bearer request to the PDN GW, where the activated SAE bearer request may include the address of the selected PDN GW.

Step S905: The PDN GW can interact with the PCRF to obtain a default PCC rule set for the UE. When the PDN GW is located at the roaming place, it will interact with the H-PCRF through the V-PCRF.

Step S905a: The PCRF may initiate a process of acquiring the subscription data of the UE to the HSS/SPR, and register the address of the PDN GW to the HSS/AAA/SPR. In addition, if the PCRF has subscription data of the UE, the PCRF may only initiate the process of registering the address of the PDN GW to the HSS/SPR.

Step S906: The PDN GW returns an activated SAE bearer request response to the Serving GW, where the activated SAE bearer request response may include QoS information.

Step S907: The Serving GW returns an activated SAE bearer request response to the new MME, where the activated SAE bearer request response may include the quality of service information.

Step S908: The new MME returns a process of activating the SAE bearer request response and configuring the configuration RB to the UE.

Step S909: The new MME returns an active SAE bearer request response to the eNodeB.

Step S910: The eNodeB sends a radio bearer setup request to the UE.

Step S911: The UE returns a radio bearer setup response to the eNodeB.

Step S912: The eNodeB sends an update bearer request to the new MME.

Step S913: The eNodeB returns an active SAE bearer request response to the UE.

Step S914: The new MME sends an update bearer request to the Serving GW.

Step S915: The Serving GW returns an update bearer response to the new MME.

It should be noted that, in the embodiment shown in FIG. 9, the scenario that the UE initiates a service on the non-3GPP network, such as a scenario of multiple PDNs and multiple HAs, may be included, such that the MME is equivalent to the ePDG, the ASN GW, and the like. The access control plane gateway entity may register the address of the PDN GW with the HSS/AAA/SPR server by the PDN GW through the PCC system after the bearer is successfully established. If the AAA and the HSS are separate entities, the address of the registered PDN GW can be passed from the AAA to the HSS.

In the flow shown in Figure 9, when the PDN GW address is registered to the HSS/SPR, if the network supports If multiple PDNs or one PDN GW have multiple PDNs, the APN information also needs to be registered with the PDN GW to the HSS/SPR. The HSS needs to maintain the correspondence between the APN and the PDN GW.

It should also be noted that, when the entity triggers the PDN GW to interact with the PCRF according to what judgment condition, the indication of the PCRF to the HSS/SPR registration has been mentioned in the previous embodiment, and is not described here.

In the embodiment shown in FIG. 10, if the UE initiates a service to the external PDN network for the first time in the SAE/LTE access network, the PDN GW directly registers its own address to the HSS. This embodiment contains a scene of Local breakout.

Step S1001: The UE initiates an activation SAE bearer request.

Step S1002: The new MME selects a PDN GW.

Step S1003: The new MME sends an activation SAE bearer request to the Serving GW, where the activated SAE bearer request may include the address of the selected PDN GW.

Step S1004: The Serving GW sends an Activate SAE Bearer Request to the PDN GW, where the Activate SAE Bearer Request may include the address of the selected PDN GW.

Step S1005: The PDN GW can interact with the PCRF to obtain a default PCC rule set for the UE.

Step S 1005a: If the UE first establishes a bearer to the PDN GW, the PDN GW registers its own address directly to the HSS/SPR.

Step S1006: The PDN GW returns an activated SAE bearer request response to the Serving GW, where the activated SAE bearer request response may include the quality of service information.

Step S1007: The Serving GW returns an active SAE bearer request response to the new MME, and the activated SAE bearer request response may include the quality of service information.

Step S1008: The new MME returns a process of activating the SAE bearer request response and configuring the wireless bearer to the UE.

Step S1009: The new MME returns an active SAE bearer request response to the eNodeB.

Step S1010: The eNodeB sends a radio bearer setup request to the UE.

Step S1011: The UE returns a radio bearer setup response to the eNodeB.

Step S1012: The eNodeB sends an update bearer request to the new MME.

Step S1013: The eNodeB returns an active SAE bearer request response to the UE. Step S1014: The new MME sends an update bearer request to the Serving GW.

Step S1015: The Serving GW returns an update bearer response to the new MME.

It should be noted that, in the embodiment shown in FIG. 10, a scenario in which a UE initiates a service on a non-3GPP network, such as a scenario of multiple PDNs and multiple HAs, may be included, such that the MME is equivalent to an ePDG, an ASN GW, or the like. The access control plane gateway entity can directly register its own address to the HSS/AAA/SPR by the PDN GW after the bearer is successfully established. If AAA and HSS are separate entities, the address of the registered PDN GW can be passed from AAA to the HSS.

In the flow shown in Figure 10, when the PDN GW address is registered to the HSS/SPR, if the network supports multiple PDNs or one PDN GW has multiple PDNs, the APN information also needs to be registered with the PDN GW to the HSS/SPR. The HSS shall store the correspondence between the APN and the PDN GW.

Since some of the above embodiments can be applied to a communication system, the present invention also provides an embodiment of a communication system.

A communication system provided by the embodiment of the present invention includes: a bearer context assigning entity, configured to allocate a first bearer context to a terminal by a network anchor point; and an address registration entity, configured to register an address of the network anchor point to the network server.

A communication system provided by the embodiment of the present invention includes: a connection establishment entity, configured to establish a connection with a terminal for the first time; and an address registration entity, configured to register an address of the network anchor to the network server.

In the communication system of the foregoing embodiment, the address registration entity is further configured to: when the access network supports multiple packet data networks PDN, or the network anchor points correspond to multiple PDNs, connect the network anchor points The ingress identification APN is registered to the web server.

The address registration entity is: a mobility management entity, or a serving GPRS support node, or an access network entity, or an entity in the network anchor, or policy control and charging system.

The flow of saving the address of the network anchor to the network server by using the communication system can be referred to the description in the foregoing method embodiments.

In actual applications, the current service of the terminal may need to be terminated, correspondingly, saved in The address of the PDN GW in the HSS can also be deleted. To this end, the present invention also provides a technical solution for deleting the address of the network anchor from the network server.

In order to facilitate the implementation or reproduction of the solution for deleting the address of the network anchor from the network server by a person skilled in the art, several preferred embodiments of this technical solution are described below with reference to the accompanying drawings.

The embodiments shown in FIG. 11 , FIG. 12 and FIG. 13 respectively describe how to delete the address of the PDN GW from the HSS when the terminal initiates bearer deletion in the SAE/LTE access network.

Specifically, in the embodiment shown in FIG. 11, when all bearers on the PDN GW for the UE are released, the address of the PDN GW stored in the HSS/SPR is deleted by the PCC system.

As shown in Figure 11, it includes:

Step S1101: The UE initiates a Deactivate SAE Bearer Request. Step S1102: The new MME sends a deactivation SAE bearer request to the Serving GW, where the deactivated SAE bearer request may include information indicating that the PDN GW deregisters the PDN GW address in the HSS/SPR through the PCC system.

Step S1103: The Serving GW sends a deactivated SAE bearer request to the PDN GW, where the deactivated SAE bearer request may include information indicating that the PDN GW deregisters the PDN GW address in the HSS/SPR through the PCC system. The deregistration message triggering the PDN GW may be provided by the MME or by the Serving GW, or the PDN GW may decide to initiate the behavior of deregistering the PDN GW address through the PCC system according to the network configuration.

Step S1104: The PDN GW interacts with the PCRF to release related binding information.

Step S1104a: The PCRF de-registers the address of the PDN GW (Unregister PDN GW to HSS) stored in the HSS/SPR. Before de-registration, the PDN GW can determine whether the address of the PDN GW saved in the HSS/SPR needs to be deregistered through the PCC system according to the received indication information or according to the parameters configured by itself. If the network supports the same terminal to use multiple PDNs, the original HSS will save the mapping between the PDN GW and the APN. The deregistration process of the PDN GW also includes deleting the PDN GW address and the APN correspondence stored in the HSS/SPR.

Step S1105: The PDN GW returns a Deactive SAE Bearer Response to the Serving GW. If the deactivated SAE bearer request in step S1102 includes an indication, the deactivated SAE bearer response may also include a successful deregistration. Instructions. Step SI 106: The Serving GW returns a deactivated SAE bearer response to the new MME, where the message may include an indication of successful deregistration.

Step S1107: The new MME returns a deactivated SAE bearer response to the UE.

It should be noted that the embodiment shown in FIG. 11 may include a scenario in which the UE ends the service in the non-3GPP network, for example, a scenario of multiple PDNs and multiple HAs. When all services on the PDN GW are completed, all services may be ended. The address of the PDN GW is deregistered by the PDN GW to the HSS/AAA/SPR server through the PCC system. If AAA and HSS are separate entities, the deregistered parameters or information can be passed to the HSS by AAA.

In the embodiment shown in Fig. 12, when all bearers on the PDN GW for the UE are released, the PDN GW directly deletes its own address stored in the HSS/SPR.

As shown in Figure 12, it includes:

Step S1201: The UE initiates a deactivation of the SAE bearer request.

Step S1202: The new MME sends a deactivation SAE bearer request to the Serving GW, where the deactivated SAE bearer request may include information indicating that the PDN GW directly deregisters the self address in the HSS/SPR.

Step S1203: The Serving GW sends a deactivated SAE bearer request to the PDN GW, where the deactivated SAE bearer request may include information indicating that the PDN GW directly deregisters the own address in the HSS/SPR. The de-registration message that triggers the PDN GW may be provided by the MME or by the Serving GW, or the PDN GW may decide to initiate the de-registration of the address in the HSS/AAA according to the network configuration.

Step S1204: The PDN GW interacts with the PCRF to release related binding information. This step is optional and includes a Local breakout scenario, ie, interacting with the HPCRF via the VPCRF.

Step S1204a: The PDN GW directly deregisters the self address (Unregister PDN GW to HSS) in the HSS/SPR. Before de-registration, the PDN GW can determine whether it needs to directly de-register its own address in the HSS/SPR according to the received indication information or its own configured parameters.

Step S1205: The PDN GW returns a deactivated SAE bearer response to the Serving GW. If the deactivated SAE bearer request in step S1202 includes an indication, the deactivated SAE bearer response may also include an indication of successful deregistration.

Step S1206: The Serving GW returns a deactivated SAE bearer response to the new MME. The elimination The information can contain an indication of successful deregistration.

Step S1207: The new MME returns a deactivated SAE bearer response to the UE.

It should be noted that the embodiment shown in FIG. 12 may include a scenario in which the UE ends the service in the non-3GPP network, for example, a scenario of multiple PDNs and multiple HAs. When all services on the PDN GW are completed, the UE may The PDN GW directly deregisters its own address with the HSS/AAA/SPR server. If AAA and HSS are separate entities, the parameters or information for deregistration can be

AAA is passed to the HSS.

If the network supports multiple PDNs for the same terminal, the original HSS saves the mapping between the PDN GW and the APN. The deregistration process of the PDN GW also includes deleting the mapping between the PDN GW address and the APN stored in the HSS/SPR.

In the embodiment shown in Fig. 13, when all bearers on the PDN GW for the UE are released, the MME deletes the address of the PDN GW stored in the HSS/SPR.

As shown in Figure 13, it includes:

Step S1301: The UE initiates a deactivation of the SAE bearer request.

Step S1302: The new MME sends a deactivation SAE bearer request to the Serving GW.

Step S1303: The Serving GW sends a deactivated SAE bearer request to the PDN GW.

Step S1304: The PDN GW interacts with the PCRF to release related binding information. This step is optional and includes a Local breakout scenario, ie, interacting with the HPCRF via the VPCRF.

Step S1305: The PDN GW returns a deactivated SAE bearer response to the Serving GW.

Step S1306: The Serving GW returns a deactivated SAE bearer response to the new MME.

Step S1306a: The new MME de-registers the address of the PDN GW in the HSS/SPR. Before the solution is released, the new MME can determine whether the address of the PDN GW in the HSS/SPR needs to be deregistered according to the subscription data of the UE or the parameters configured by itself.

Step S1307: The new MME returns a deactivated SAE bearer response to the UE.

It should be noted that the embodiment shown in FIG. 13 may include a scenario in which the UE ends the service in the non-3GPP network, for example, a scenario of multiple PDNs and multiple HAs. When all services on the PDN GW are completed, the UE may The address corresponding to the MME, such as ePDG and ASN GW, deregisters the address of the PDN GW to the HSS/AAA/SPR server. If the AAA and HSS are separate entities, the deregistration parameters or information can be passed from the AAA to the HSS. If the network supports the same terminal to use multiple PDNs, the original HSS saves the mapping between the PDN GW and the APN. The deregistration process of the PDN GW also includes deleting the mapping between the PDN GW address and the APN stored in the HSS/SPR.

The embodiments shown in FIG. 14 , FIG. 15 and FIG. 16 respectively describe how to delete the address of the PDN GW from the HS S when the MME initiates the bearer deletion process.

Specifically, in the embodiment shown in FIG. 14, when all bearers on the PDN GW for the UE are released, the PDN GW directly deletes the own address stored in the HSS/SPR.

As shown in Figure 14, it includes:

Step S1401: The new MME sends a deactivation SAE bearer request to the Serving GW. The deactivated SAE bearer request may include a message indicating that the PDN GW is to deregister the PDN GW address in the HSS. The new MME may determine whether it is necessary to send the indication to the Serving GW according to the subscription data of the UE or the parameters configured by itself.

Step S1402: The Serving GW sends a deactivated SAE bearer request to the PDN GW.

Step S1403: The PDN GW interacts with the PCRF to release the related binding information. This step is optional and includes a Local breakout scenario, ie, interacting with the HPCRF via the VPCRF.

Step S1404: The PDN GW directly deregisters the self address stored in the HSS/SPR. Before the solution is released, the PDN GW can determine whether it needs to deregister the own address saved in the HSS/SPR according to the received indication information or the parameters configured by itself. The de-registration message of the triggering PDN GW may be provided by the MME or by the Serving GW, or the PDN GW may decide to initiate the de-registration of the address in the HSS/AAA according to the network configuration.

Step S1405: The PDN GW returns a deactivated SAE bearer response to the Serving GW. If the deactivated SAE bearer request of step S1401 contains an explicit indication, the deactivated SAE bearer response may also contain an indication of successful deregistration.

Step S1406: The Serving GW returns a deactivated SAE bearer response to the new MME. An indication of successful deregistration can be included in the message.

Step S1407: The new MME sends a deactivated SAE bearer request to the UE. In addition, the new MME may also instruct the eNodeB to release the associated radio bearer. Of course, this indication may also be sent after step S1401.

Step S1408: The UE returns a deactivated SAE bearer response to the new MME. It should be noted that the embodiment shown in FIG. 14 may include a scenario in which the UE ends the service in the non-3GPP network, such as a scenario of multiple PDNs and multiple HAs, and may also include a bearer deletion process initiated by an entity such as ePDG or ASN GW. The scenario, when all services on the PDN GW for the UE are terminated, the PDN GW can directly deregister the self address to the HSS/AAA/SPR server. If the AAA and HSS are separate entities, then the de-registered parameters or information need to be passed from the AAA to the HSS.

In the embodiment shown in Fig. 15, when all bearers on the PDN GW for the UE are released, the MME deletes the address of the PDN GW stored in the HSS/AAA/SPR.

As shown in Figure 15, it includes:

Step S1501: The new MME sends a deactivate SAE bearer request to the Serving GW.

Step S1502: The Serving GW sends a deactivated SAE bearer request to the PDN GW.

Step S1503: The PDN GW interacts with the PCRF to release the related binding information. This step is optional and includes a Local breakout scenario, ie, interacting with the HPCRF via the VPCRF.

Step S1504: The PDN GW returns a deactivated SAE bearer response to the Serving GW.

Step S1505: The Serving GW returns a deactivated SAE bearer response to the new MME.

Step S1506: The new MME de-registers the address of the PDN GW in the HSS/SPR. Before the solution is released, the new MM can determine whether the address of the PDN GW needs to be unregistered with the HSS/SPR according to the subscription data of the UE or the parameters configured by itself.

Step S 1507: The new MME sends a deactivated SAE bearer request to the UE. In addition, the new MME may also instruct the eNodeB to release the associated radio bearer. Of course, this indication may also be sent after step S1501.

Step S1508: The UE returns a deactivated SAE bearer response to the new MME.

It should be noted that the embodiment shown in FIG. 15 may include a scenario in which the UE ends the service in the non-3GPP network, such as a scenario of multiple PDNs and multiple HAs, and may also include an ePDG and an ASN GW. When the entity initiates the bearer deletion process, when the PDN GW completes all the services of the UE, the entity corresponding to the MME, such as the ePDG and the ASN GW, can deregister the address of the PDN GW to the HSS/AAA/SPR server. If the AAA and the HSS are separate entities, then the parameters or information for the deregistration need to be passed from the AAA to the HSS.

Conversely, when registering the PDN GW address with the HSS/AAA, when the AAA and the HSS are separate entities, the address of the PDN GW needs to be passed to the HSS through AAA.

In the embodiment shown in Fig. 16, when all bearers on the PDN GW for the UE are released, the address of the PDN GW stored in the HSS/SPR is deleted by the PCC system.

As shown in Figure 16, it includes:

Step S1601: The new MME sends a deactivation SAE bearer request to the Serving GW. The deactivated SAE bearer request may include information indicating that the PDN GW de-registers the PDN GW address in the HSS/SPR through interaction with the PCC system. The new MME may also determine whether the indication needs to be sent to the Serving GW according to the subscription data of the UE or the parameters configured by itself.

Step S1602: The Serving GW sends a deactivated SAE bearer request to the PDN GW.

Step S1603: The PDN GW interacts with the PCRF to release the related binding information. This step is optional and includes a Local breakout scenario, ie, interacting with the HPCRF via the VPCRF. In addition, the PDN GW can also determine whether it is necessary to trigger the PCC system to deregister the address of the PDN GW in the HSS/SPR according to the received indication information or the parameters configured by itself.

Step S1604: The PCRF interacts with the HSS/SPR to deregister the address of the PDN GW in the HSS/SPR.

Step S1605: The PDN GW returns a deactivated SAE bearer response to the Serving GW. If the deactivated SAE bearer request of step S1601 includes an explicit indication, the deactivated SAE bearer response may also include an indication of successful deregistration.

Step S1606: The Serving GW returns a deactivated SAE bearer response to the new MME.

Step S 1607: The new MME sends a deactivated SAE bearer request to the UE. In addition, the new MME may also instruct the eNodeB to release the associated radio bearer. Of course, this indication may also be sent after step S1601.

Step S1608: The UE returns a deactivated SAE bearer response to the new MME.

If the network supports multiple PDNs for the same terminal, the original HSS will save the PDN GW and APN. Corresponding relationship, the deregistration process of the PDN GW further includes deleting the PDN GW address and the APN correspondence stored in the HSS/SPR.

It should be noted that the embodiment shown in FIG. 16 may include a scenario in which the UE ends the service in the non-3GPP network, such as a scenario of multiple PDNs and multiple HAs, and may also include a bearer deletion process initiated by an entity such as ePDG or ASN GW. Scenario, when all services on the PDN GW for the UE are terminated, the PDN GW may deregister the address of the PDN GW from the PSC GW to the HSS/AAA/SPR server through the PCC system. If AAA and HSS are separate entities, then the deregistered parameters or information need to be passed from AAA to the HSS.

The case where the entity de-registers the PDN GW address in the SPR according to what the judgment condition is triggered is described in the foregoing embodiment, and details are not described herein again.

The embodiments shown in FIG. 17, FIG. 18, and FIG. 19 respectively describe how to delete the address of the PDN GW from the HSS when the bearer deletion process is initiated by the network side in the SAE/LTE access network.

Specifically, in the embodiment shown in FIG. 17, when all the bearers on the PDN GW for the UE are released, the PDN GW directly deletes the own address stored in the HSS/SPR.

As shown in Figure 17, it includes:

Step S1701: The PCRF provides PCC Decision Provision to the PDN GW. Step S1702: The PDN GW triggers a bearer deletion procedure according to the received PCC information. In this step, the PDN GW sends a deactivation SAE bearer request to the Serving GW.

Step S1703: The Serving GW sends a deactivate SAE bearer request to the MME.

Step S1704: The MME notifies the eNodeB to delete the related bearer (Deactive Bearer Request). Step S1705: The eNodeB sends a deactivated radio bearer request to the UE (Deactive Radio

Bearer Request )„

Step S1706: The UE removes the related uplink data flow template, and returns a Deactive Radio Bearer Response to the eNodeB.

Step S1707: The eNodeB returns a Deactivate Bearer Response to the MME.

Step S1708: The MME returns a deactivated SAE bearer response to the Serving GW.

Step S1709: The Serving GW returns a deactivated SAE bearer response to the PDN GW. Step S1710: The PDN GW returns a confirmation (Professional Ack) of the relevant PCC information to the PCRF. Step S1711: The PDN GW directly deregisters the own address stored in the HSS/SPR. Before de-registration, the PDN GW may determine whether it is necessary to de-register its own address with the HSS according to the subscription data of the UE or the parameters configured by itself. In addition, the PDN GW may determine whether it is necessary to de-register the address with the HSS according to the request or the indication of the MME. In this manner, the MME may determine whether the PDN GW needs to de-register itself with the HSS according to the subscription data of the UE or the parameters configured by the UE. address.

In addition, the Serving GW may also provide an indication that the PDN GW de-registers the address information of the PDN GW to the HSS/AAA according to the indication provided by the Serving GW.

It should be noted that the embodiment shown in FIG. 17 may include a scenario in which the UE ends the service on the non-3GPP network, such as a scenario of multiple PDNs and multiple HAs, and may also include a bearer deletion scenario initiated by the PDN GW, when the PDN GW is used. When all services on the UE are completed, the PDN GW can directly deregister its own address to the HSS/AAA/SPR server. If the AAA and HSS are separate entities, the parameters or information for the deregistration need to be passed from the AAA to the HSS.

In the embodiment shown in Fig. 18, when all the bearers on the PDN GW for the UE are released, the address of the PDN GW stored in the HSS/SPR is deleted by the PCC system.

As shown in Figure 18, it includes:

Step S 1801: The PCRF provides PCC information to the PDN GW.

Step S1802: The PDN GW triggers a bearer deletion procedure according to the received PCC information. In this step, the PDN GW sends a deactivation SAE bearer request to the Serving GW.

Step S1803: The Serving GW sends a deactivate SAE bearer request to the MME.

Step S1804: The MME notifies the eNodeB to delete the related bearer.

Step S1805: The eNodeB sends a deactivated radio bearer request to the UE.

Step S1806: The UE removes the related uplink data flow template, and returns a deactivated radio bearer response to the eNodeB.

Step S1807: The eNodeB returns a deactivation bearer response to the MME.

Step S1808: The MME returns a deactivated SAE bearer response to the Serving GW. Step S1809: The Serving GW returns a deactivated SAE bearer response to the PDN GW.

Step S1810: The PDN GW returns an acknowledgement of the relevant PCC information to the PCRF, and triggers the PCRF to deregister the address of the PDN GW to the HSS/SPR.

Step S1810a: The PCRF unregisters the address of the PDN GW with the HSS/SPR.

It should be noted that, in step S1810, the PDN GW may trigger the PCRF to initiate the deregistration process according to the parameters configured by itself or the deactivated SAE bearer response returned by the MME in step S1808. Similarly, the MME may according to the subscription data of the UE and itself. The configured parameters determine whether the address of the PDN GW is to be registered in the HSS/SPR through interaction with the PCC system.

Similarly, the Serving GW can determine whether it needs to deregister the address of the PDN GW in the HSS/SPR through interaction with the PCC system according to the parameters configured by itself, and provide relevant indications to the PDN GW to deregister the PDN GW through the PCC system. the address of.

In addition, the embodiment shown in FIG. 18 may include a scenario in which the UE ends the service in the non-3GPP network, such as a scenario of multiple PDNs and multiple HAs, and may also include a bearer deletion scenario initiated by the PDN GW, where the UE is on the PDN GW. When all services are completed, the PDN GW can deregister the address of the PDN GW from the PSC GW to the HSS/AAA/SPR server through the PCC system. If AAA and HSS are separate entities, then the de-registered parameters or information need to be passed from AAA to the HSS.

In the embodiment shown in Fig. 19, when all bearers on the PDN GW for the UE are released, the MME deletes the address of the PDN GW stored in the HSS/SPR.

As shown in Figure 19, it includes:

Step S1901: The PCRF provides PCC information to the PDN GW.

Step S1902: The PDN GW triggers a bearer deletion procedure according to the received PCC information. In this step, the PDN GW sends a deactivation SAE bearer request to the Serving GW.

Step S1903: The Serving GW sends a deactivate SAE bearer request to the MME.

Step S1904: The MME notifies the eNodeB to delete the related bearer.

Step S1905: The eNodeB sends a deactivated radio bearer request to the UE.

Step S1906: The UE removes the related uplink data flow template, and returns deactivation to the eNodeB. Wireless bearer response.

Step S1907: The eNodeB returns a deactivation bearer response to the MME.

Step S1908: The MME returns a deactivated SAE bearer response to the Serving GW.

Step S1908a: The MME de-registers the address of the PDN GW in the HSS/SPR. Before de-registration, the MME may determine, according to the subscription data of the UE and the parameters configured by itself, whether the address of the PDN GW in the HSS/SPR is required to be MME-resolved.

Step S1909: The Serving GW returns a deactivated SAE bearer response to the PDN GW.

Step S1910: The PDN GW returns an acknowledgement of the relevant PCC information to the PCRF, and triggers the PCRF to deregister the address of the PDN GW to the HSS/SPR.

It should be noted that there is no necessary sequence in step S1908 and step S1908a, or step S 1908a may be performed at any time after step S1907.

If the network supports multiple PDNs for the same terminal, the original HSS saves the mapping between the PDN GW and the APN. The deregistration process of the PDN GW also includes deleting the PDN saved in the HSS/SPR.

The correspondence between the GW address and the APN.

In addition, the embodiment shown in FIG. 19 may include a scenario in which the UE ends the service on the non-3GPP network, such as a scenario of multiple PDNs and multiple HAs, and may also include a bearer deletion scenario initiated by the PDN GW, where the UE is on the PDN GW. When all services are completed, the address corresponding to the MME, such as ePDG and ASN GW, can be used to deregister the address of the PDN GW to the HSS/AAA/SPR server. in case

AAA and HSS are separate entities, and the parameters or information for de-registration need to be passed from AAA to HSS.

The embodiment shown in Figure 21 describes how to delete the address of the PDN GW from the HSS when the network side initiates the bearer release procedure in the 3GPP access network. Specifically, when all bearers on the PDN GW for the UE are released, the SGSN deletes the address of the PDN GW stored in the HSS/SPR.

Step S2101: The PCRF provides PCC information to the PDN GW.

Step S2102: The PDN GW triggers a bearer deletion procedure according to the received PCC information. In this step, the PDN GW sends a deactivation SAE bearer request to the Serving GW.

Step S2103: The Serving GW sends a Delete PDP context Request to the SGSN. Step S2104: The SGSN sends a delete PDP context request to the UE.

Step S2105: The UE returns a Delete PDP context Response to the SGSN.

Step S2106: The SGSN returns a delete PDP context response to the Serving GW.

Step S2106a: The SGSN de-registers the address of the PDN GW saved in the HSS/SPR.

Step S2107: The SGSN returns a deactivated SAE bearer response to the PDN GW.

Step S2108: The PDN GW returns a PCC information confirmation to the PCRF.

In addition, when the bearer deletion process initiated by the network side entity such as PCRF, the PCRF can go directly

The PDN-GW address associated with the registration in HSS/AAA/SPR. The specific process is basically the same as the embodiment mentioned in the present document and will not be described here.

The correspondence between the GW address and the APN.

The embodiment shown in FIG. 20 describes how to delete the address of the PDN GW from the HSS when the bearer release process is initiated by the HSS in the SAE/LTE access network. It should be noted that, in the actual application, the terminal can open or close the service through a subscription manner such as a short message, but when the service is closed, it is necessary to check whether the service is being used in time, and shut down the service from the bearer level in time. The bearer deletion process needs to be initiated by the HSS.

Specifically, as shown in Figure 20, it includes:

Step S2001: The HSS/AAA/SPR sends a deactivate SAE bearer request to the new MME. Step S2002: The new MME sends a deactivation SAE bearer request to the Serving GW.

Step S2003: The Serving GW sends a deactivated SAE bearer request to the PDN GW.

Step S2004: The PDN GW interacts with the PCRF to release the related binding information. This step is optional and includes a Local breakout scenario, ie, interacting with the HPCRF via the VPCRF.

Step S2005: The PDN GW returns a deactivated SAE bearer response to the Serving GW.

Step S2006: The Serving GW returns a deactivated SAE bearer response to the new MME.

Step S2006a: The new MME returns a deactivated SAE bearer response to the HSS/SPR to deregister the address of the PDN GW in the HSS/SPR. Before the de-registration, the new MM can determine whether the address of the PDN GW needs to be registered to the HSS/SPR according to the subscription data of the UE or the parameters configured by itself. It should be noted that the network side entity that de-registers the PDN GW may be an MME, a PDN GW, a PCRF, an ePDG, an ASN GW, or a Serving GW, but not only these entities are limited.

It should also be noted that the bearer deletion process initiated by the HSS may have de-registered the information of the relevant PDN GW, and the process of de-registering different entities may be optional.

Step S2007: The new MME sends a deactivated SAE bearer request to the UE. In addition, the new MME may also instruct the eNodeB to release the associated radio bearer. Of course, this indication may also be sent after step S2002.

Step S2008: The UE returns a deactivated SAE bearer response to the new MME.

It should be noted that the embodiment shown in FIG. 20 may include a scenario in which the UE ends the service in the non-3GPP network, and the bearer release process may be initiated by the network side service entity, such as the HSS and the AAA, and the ePDG, the ASN GW, and the like are equivalent. The entity of the MME or the PDN GW may deregister the address of the PDN GW to the HSS/AAA/SPR server, and may also decrypt the address of the registered PDN GW through the PCC system. If AAA and HSS are separate entities, then the de-registered parameters or information need to be passed from AAA to the HSS.

An embodiment of the present invention provides a communication system, including: an address deletion notification entity, configured to send a notification for deleting an address of the network anchor point when the network anchor point is no longer serving a certain terminal, where the network anchor The address of the point has been previously registered to the web server; the deregistration entity is configured to deregister the address of the network anchor according to the notification of the address deletion notification entity.

The de-registration entity is further configured to delete the access point identifier when an access point corresponding to the anchor point identifies that the APN has been registered to the network server. The address deletion notification entity is: a mobility management entity, or a serving GPRS support node, or an access network entity, or an entity in the network anchor, or policy control and charging system.

In practical applications, in order to effectively manage and utilize network resources, the telecommunications network has established a complete network management and control mechanism. When the terminal exits the network, the resources allocated to the user need to be released in time, including the wireless channel, the bearer, and various tunnels. Correspondingly, the PDN GW saved in the HSS The related management information such as the address is also deleted. To this end, the present invention also provides a technical solution for retiring the terminal.

In order to facilitate the technical solution for the person skilled in the art to implement or reproduce the network retreat of the terminal, several preferred embodiments of the technical solution are described below with reference to the accompanying drawings.

The embodiments shown in Fig. 22, Fig. 23, Fig. 24, Fig. 25, Fig. 26, Fig. 27, and Fig. 28 respectively describe the flow of the terminal exiting the network when the terminal accesses through the non-3GPP access network.

Specifically, in the embodiment shown in FIG. 22, the network revocation process initiated by the UE. In this embodiment, the UE accesses two PDNs at the same time, the UE uses HoAl to access the PDN1 identified by the APN1, and the UE uses the HoA2 to access the PDN2 identified by the APN2.

As shown in FIG. 22, the UE initiated the network retreat process includes:

Step 2201: The access gateway/ePDG receives the release tunnel request message sent by the UE, and the message may carry a parameter such as a UE address.

Step 2202: The access gateway/ePDG sends a binding update message to the PDN GW. The lifetime parameter is set to 0, and the care-of address parameter is set to HoAl, indicating that all bindings corresponding to HoAl are to be logged out.

Step 2203: The PDN GW notifies the AAA/HSS to deregister the PDN GW address information corresponding to the APN1.

In step 2203, the access gateway /ePDG may also notify the AAA/HSS to deregister the PDN GW address information. In this case, step 2203 can be performed simultaneously with steps 2202 and 2204.

Step 2204: The PDN GW sends a binding update confirmation message to the access gateway /ePDG, and confirms that all bindings corresponding to HoAl are deleted. The PDN GW and the access gateway /ePDG delete the binding indicated in step 2202.

Step 2205: The access gateway/ePDG sends a binding update message to the PDN GW. The lifetime parameter is set to 0, and the care-of address parameter is set to HoA2, indicating that all bindings corresponding to HoA2 are to be logged out.

Step 2206: The PDN GW notifies the AAA/HSS to deregister the PDN GW address information corresponding to the APN2.

In step 2206, the access gateway/ePDG may also notify the AAA/HSS to deregister the PDN GW address information. In this case, step 2206 can be performed simultaneously with steps 2205, 2207. Step 2207: The PDN GW sends a binding update confirmation message to the access gateway/ePDG, and confirms that all bindings corresponding to HoA2 are deleted. The PDN GW and the Access Gateway/ePDG delete the binding indicated by step 2205.

Step 2208: The access gateway /ePDG replies to the UE with a release tunnel acknowledgement message. If the UE indicates that the reason for the network disconnection is in the release tunnel request message, step 2208 may not be performed.

The resource release process is performed to release resources between the UE and the access gateway /ePDG.

If there is a secure tunnel connection between the UE and the ePDG, steps 2201, 2208 may be to release the tunnel request/acknowledgement message. If the connection between the UE and the access gateway is Layer 3, such as an IP-based connection, steps 2201, 2208 may be a layer 3 based trigger/acknowledgement message or trigger/acknowledgement process, or access technology. Specific triggering process.

If the UE has multiple HoAs, the binding and PDN GW address information corresponding to each HoA may be sequentially released according to the method in this embodiment. The above method of deregistering PDN GW address information with HoA granularity is also applicable to other embodiments.

Specifically, in the embodiment shown in FIG. 23, the network exit process initiated by the access gateway /ePDG. As shown in Figure 23, it includes:

Step 2301: The access gateway /ePDG sends a release tunnel request message to the UE, requesting to release the tunnel. The message may include parameters such as the reason for the release.

Step 2302: The UE replies to the access gateway /ePDG to release the tunnel acknowledgement message, performs a resource release process, and releases the tunnel resource and the access network resource between the UE and the access gateway/ePDG.

The access gateway /ePDG may directly perform the resource release process without notifying the UE, that is, steps 2301 and 2302 are not executed.

If the UE and the access gateway/ePDG are secure tunnel connections, steps 2301, 2302 may be a release tunnel request/acknowledgement message; if the UE and the access gateway are connected by Layer 3, such as IP-based Connect, then steps 2301, 2302 can be a layer 3 based trigger/acknowledgement message or trigger/acknowledgement process, or an access technology specific triggering process.

Step 2303: The access gateway /ePDG sends a binding update message to the PDN GW. The lifetime of the message is 0, and the care-of address parameter is set to the home address, indicating that all the bindings of the home address are to be logged off.

Step 2304: The PDN GW replies to the access gateway/ePDG with a binding update confirmation message. The PDN GW and the access gateway/ePDG delete the binding indicated in step 3. Step 2305: The PDN GW notifies the AAA/HSS to deregister the PDN GW address information.

If the network supports the same terminal to use multiple PDNs, the original AAA/HSS will maintain the mapping between the PDN GW and the APN. The deregistration process of the PDN GW also includes deleting the PDN GW address and the APN correspondence stored in the AAA/HSS.

The step 2305 may also notify the AAA/HSS to deregister the PDN GW address information by the access gateway /ePDG.

Moreover, there is no strict timing relationship between the steps 2301, 2302, 2303, 2304, and 2305.

Specifically, in the embodiment shown in FIG. 24, the network retreating process initiated by the PDN GW.

As shown in Figure 24, it includes:

Step 2401: The PDN GW sends a binding revocation indication message to the access gateway/ePDG, where the message may include the following parameters: UE identifier, revocation reason, revocation type, and the like.

Step 2402: The access gateway /ePDG sends a release tunnel request message to the UE, and the message may include parameters such as a release reason.

Step 2403: The UE replies to the access gateway /ePDG to release the tunnel acknowledgement message, and performs a resource release process to release resources between the UE and the access gateway /ePDG.

The access gateway /ePDG may directly perform the resource release process without notifying the UE, that is, steps 24202 and 2403 are not executed.

If there is a secure tunnel connection between the UE and the ePDG, steps 2402, 2403 may be to release the tunnel request/acknowledgement message. If the UE and the access gateway are Layer 3 (L3) connections, such as IP-based connections, then steps 2402, 2403 may be a layer 3 based trigger/acknowledgement or trigger/acknowledgement process, or access technology specific Trigger process.

Step 2404: The access gateway /ePDG replies to the PDN GW with a binding revocation acknowledgement message, and the access gateway /ePDG and the PDN GW delete all the bindings indicated in step 1.

Step 2405: The PDN GW notifies the AAA/HSS to deregister the PDN GW address information.

Step 2405 may also notify the AAA/HSS to cancel the association information by the access gateway/ePDG. Specifically, in the embodiment shown in FIG. 25, the TLS/HSS initiates a network retreat procedure to the PDN GW.

As shown in Figure 25, it includes:

Step 2501: The AAA/HSS sends a session suspension message to the PDN GW, and the message may include the following parameters: UE identity, abort reason, abort type, and the like.

Step 2502: The PDN GW sends a binding revocation indication message to the access gateway, where the message may include the following parameters: UE identifier, revocation reason, revocation type, and the like.

Step 2503: The access gateway sends a release tunnel request message to the UE.

Step 2504: The UE replies to the access gateway with a release tunnel acknowledgement message. The access network specific resource release process is performed to release the access network resources.

The access gateway /ePDG may directly perform the resource release process without notifying the UE, that is, steps 2503 and 2504 are not performed.

If there is a secure tunnel connection between the UE and the access gateway /ePDG, then steps 2503, 2504 may be to release the tunnel request/acknowledgement message. If there is a layer 3 (Layer 3) connection between the UE and the access gateway, such as an IP-based connection, steps 2503, 2504 may be a layer 3 based trigger/acknowledgement message or trigger/acknowledgement process, or access technology. Specific triggering process.

Step 2505: The access gateway replies to the PDN GW with a binding revocation confirmation message. The access gateway and PDN GW delete all the bindings indicated in step 2502.

Step 2506: The PDN GW notifies the AAA/HSS to deregister the PDN GW address information.

Specifically, in the embodiment shown in FIG. 26, the TLS/HSS initiates a network revocation process to the access gateway/ePDG. As shown in Figure 26, it includes:

Step 2601: The AAA/HSS sends a session abort message to the ePDG, and the message includes the following parameters:

UE identification, abort reason, abort type, etc.

Step 2602: The access gateway /ePDG sends a release tunnel request message to the UE, and the message may include parameters such as a release reason.

Step 2603: The UE replies to the access gateway/ePDG to release the tunnel acknowledgement message, and performs resource release. The process releases resources between the UE and the access gateway/ePDG.

The access gateway /ePDG may directly perform the resource release process without notifying the UE, that is, steps 2602 and 2603 are not performed.

If there is a secure tunnel connection between the UE and the ePDG, then steps 2602, 2603 may be to release the tunnel request/acknowledgement message. If the UE and the access gateway are Layer 3 (Layer 3) connections, such as IP-based connections, then steps 2602, 2603 may be a layer 3 based trigger/acknowledgement or trigger/acknowledgement process, or access technology specific Trigger process.

Step 2604: The access gateway /ePDG sends a binding update message to the PDN GW. The lifetime of the message is 0, and the care-of address parameter is set to the home address, indicating that all the bindings of the home address are to be logged off.

Step 2605: The PDN GW replies to the ePDG with a binding update confirmation message. The PDN GW and the Access Gateway /ePDG delete all the bindings indicated in step 2604.

Step 2606: The access gateway /ePDG replies to the AAA/HSS with a session abort acknowledgement message.

After receiving the message, the AAA/HSS deregisters the associated information, such as the PDN GW address information that provides the UE with the service. If the network supports multiple PDNs for the same terminal, the original AAA/HSS will store the mapping between the PDN GW and the APN. At this time, the AAA/HSS will also delete the saved PDN GW address and APN correspondence.

Specifically, in the embodiment shown in FIG. 27, in the case of Co-CoA mode CMIP (Client Mobile IP, Client Mobile IP), the network exit process initiated by the UE. Among them, CMIP is a terminal-based mobile IP technology, that is, a technology that requires the terminal to participate in the binding process of the mobile IP. Among them, CMIP is divided into two modes: foreign agent care-of address mode (FA-CoA mode) and collocated care-of address mode (Co-CoA mode). In the FA-CoA mode, the care-of address of the terminal is the IP address of the access link mobile agent. At this time, the two endpoints of the mobile IP tunnel are the access link mobile agent and the home link mobile agent. In the Co-CoA mode, the care-of address of the terminal is the terminal IP address obtained by some means. At this time, the two endpoints of the mobile IP tunnel are the terminal and the home link mobile agent respectively, and the access link mobile agent only serves as the ordinary route. The role, that is, the mobile agent may not be deployed in the access link.

As shown in Figure 27, it includes:

Step 2701: The PDN GW receives the binding update request message sent by the UE, where the lifetime of the message is 0, and the care-of address parameter is set to the home address, indicating that all bindings of the home address are cancelled.

Step 2702: The PDN GW feeds back a binding update confirmation message to the UE. The UE and the PDN GW release the binding relationship between the home address and the care-of address, and release the CMIP tunnel. Step 2703: The PDN GW notifies the AAA/HSS to deregister the PDN GW address information.

Step 2704a: The PDN GW notifies the access gateway /ePDG to release the access link resources. Or after step 2703, the AAA/HSS notifies the access gateway/ePDG to release the access link resources (steps)

2407b).

Step 2705: After receiving the indication of releasing the access link resource, the access gateway/ePDG notifies the AAA/HSS to deregister the PDN GW address information.

Step 2703 and step 2705 are two ways to delete the associated information on the AAA/HSS, and one of the options is selected.

Specifically, in the embodiment shown in FIG. 28, in the case of Co-CoA mode CMIP, the network revocation process initiated by the PDN GW. As shown in Figure 28, it includes:

Step 2801: The PDN GW sends a binding revocation indication to the UE.

Step 2802: The UE feeds back a binding confirmation message to the PDN GW.

The UE and the PDN GW release the binding relationship between the home address and the care-of address, and release the CMIP tunnel. Step 2803: The PDN GW notifies the AAA/HSS to deregister the PDN GW address information.

Step 2804a: The PDN GW notifies the access gateway /ePDG to release the access link resources. Or after step 2803, the access gateway /ePDG is notified by the AAA/HSS to release the access link resources (step 2804b).

Step 2805: After receiving the indication of releasing the access link resource, the access gateway/ePDG notifies the AAA/HSS to deregister the PDN GW address information. If the network supports multiple PDNs for the same terminal, The original AAA/HSS saves the mapping between the PDN GW and the APN. The deregistration process of the PDN GW also includes deleting the mapping between the PDN GW address and the APN saved in the AAA/HSS.

Step 2803 and step 2805 are two ways to delete the associated information on the AAA/HSS, and one of the options is selected.

The embodiment shown in FIG. 29, FIG. 30, FIG. 31, and FIG. 32 respectively describe the flow of the terminal exiting the network when the terminal accesses the evolved 3GPP core network through 3GPP.

Specifically, in the embodiment shown in FIG. 29, the retiring procedure initiated by the Serving GW. As shown in Figure 29, it includes:

Step 2901: The Serving GW sends a network revocation request message to the MME, and the message may include parameters such as a UE identifier, a network revocation reason, and a network revocation type.

Step 2902: The MME sends a network revocation request message to the eNodeB, where the message may include parameters such as a UE identifier, a reason for retiring the network, and a type of the network to be retired.

Step 2903: The eNodeB sends a network revocation request message to the UE, where the message may include a network revocation reason, a network revocation type, and the like.

Step 2904: The UE replies to the eNodeB with a retiring confirmation message.

The radio resources between the UE and the eNodeB are released.

The eNodeB may directly release the radio resource without notifying the UE, that is, steps 2903 and 2904 are not performed.

Step 2905: The eNodeB replies to the MME with a reply to the network.

Step 2906: The MME returns a retiring confirmation message to the Serving GW.

Release the resources between the eNodeB and the Serving GW.

Step 2907: The Serving GW sends a binding update message to the PDN GW. The lifetime of the message is 0, and the care-of address parameter is set to the home address, indicating that all bindings of the home address are cancelled.

Step 2908: The PDN GW notifies the AAA/HSS to deregister the PDN GW address information.

If the UE accesses multiple PDNs at the same time, that is, the UE has multiple home addresses (HoAs), in step 2907, the PDN GW may be instructed to delete all the bindings corresponding to all the HoAs of the UE, and then the PDN GW notifies the AAA in step 2908. The HSS de-registers all the PDN GW address information of the UE. The PDN GW may be notified to delete the binding corresponding to each HoA in turn according to the method in Embodiment 22, and the PDN GW sequentially notifies the AAA/HSS to de-register each APN correspondingly. PDN GW address information. Step 2908 may also be notified by the Serving GW or the MME that the AAA/HSS de-registers the PDN GW information.

Step 2909: The PDN GW replies to the Serving GW with a Binding Update Confirm message.

The PDN GW and serving GW delete all the bindings indicated in step 2907.

Specifically, in the embodiment shown in FIG. 30, the network retreating process initiated by the PDN GW or the AAA/HSS. As shown in Figure 30, it includes:

Step 3001a: The PDN GW sends a binding revocation indication message to the serving GW, and the message may include the following parameters: UE identifier, revocation reason, revocation type, and the like.

If the AAA/HSS initiates the network retreat procedure, the first step is that the AAA/HSS sends a back-off indication message to the PDN GW (step 3001b), and the PDN GW sends a binding revocation indication message to the serving GW.

Step 3002: The serving GW sends a network revocation request message to the MME, and the message may include parameters such as a UE identifier, a network revocation reason, and a network revocation type.

Step 3003: The MME sends a network revocation request message to the eNodeB, where the message may include parameters such as a UE identifier, a network revocation reason, and a network revocation type.

Step 3004: The eNodeB sends a network revocation request message to the UE, where the message may include a reason for retiring the network, a type of network retreat, and the like.

Step 3005: The UE replies to the eNodeB with a retiring confirmation message. Release the radio resources between the UE and the eNodeB.

The eNodeB may directly release the radio resource without notifying the UE. That is, step 3004 is not performed.

3005.

Step 3006: The eNodeB replies to the MME with a retiring confirmation message.

Step 3007: The MME returns a retiring confirmation message to the serving GW.

Release the resources between the eNodeB and the serving GW.

Step 3008: The serving GW replies to the PDN GW with a binding confirmation message.

The PDN GW and the serving GW delete all the bindings indicated in step 3001.

Step 3009: The PDN GW notifies the AAA/HSS to deregister the PDN GW address information.

If the network supports multiple PDNs for the same terminal, the original AAA/HSS will save the mapping between the PDN GW and the APN. The deregistration process of the PDN GW also includes deleting the AAA/HSS. Correspondence between the PDN GW address and the APN.

The step 3009 may also notify the AAA/HSS to deregister the PDN GW address information by the serving GW or the MME.

Specifically, in the embodiment shown in FIG. 31, the network exit process initiated by the MME. As shown in Figure 31, it includes:

Step 3101: The MME sends a network revocation request message to the eNodeB, where the message may include parameters such as a UE identifier, a reason for retiring the network, and a type of the network to be retired.

Step 3102: The eNodeB sends a network revocation request message to the UE, where the message may include a network revocation reason, a network revocation type, and the like.

Step 3103: The UE replies to the eNodeB with a retiring confirmation message.

The radio resources between the UE and the eNodeB are released.

The eNodeB may directly release the radio resource without notifying the UE, that is, steps 3102 and 3103 are not performed.

Step 3104: The eNodeB replies to the MME with a retiring confirmation message.

Step 3105: The MME sends a retiring request message to the serving GW.

Step 3106: The serving GW sends a binding update message to the PDN GW. The lifetime of the message is 0, and the care-of address parameter is set to the home address, indicating that all bindings of the home address are cancelled.

Step 3107: The PDN GW notifies the AAA/HSS to deregister the PDN GW address information.

The step 3107 may also notify the AAA/HSS to deregister the PDN GW address information by the serving GW or the MME.

Step 3108: The PDN GW replies to the serving GW with a binding update confirmation message.

The PDN GW and serving GW delete all the bindings indicated in step 3106.

Step 3109: The serving GW replies to the MME with a retiring confirmation message.

Release the resources between the eNodeB and the serving GW.

Specifically, in the embodiment shown in FIG. 32, the network exit process initiated by the UE. As shown in Figure 32, it includes: Step 3201: The eNodeB receives the network revocation request message sent by the UE, and the message may include parameters such as a UE identifier, a reason for retiring the network, and a type of the network to be retired.

Step 3202: The eNodeB sends a network revocation request message to the MME, where the message may include parameters such as a UE identifier, a reason for retiring the network, and a type of the egress.

Step 3203: The MME sends a network revocation request message to the Serving GW, where the message may include parameters such as a UE identifier, a network revocation reason, and a network revocation type.

Step 3204: The Serving GW sends a binding update request to the PDN GW. The lifetime of the message is 0, and the care-of address parameter is set to the home address, indicating that all bindings of the home address are cancelled.

Step 3205: The PDN GW notifies the AAA/HSS to deregister the PDN GW address information.

Step 3205 may also notify the AAA/HSS to deregister the PDN GW address information by the Serving GW or the MME.

Step 3206: The PDN GW replies to the Serving GW with a binding update confirmation message.

The Serving GW and PDN GW delete all the bindings indicated in step 4.

Step 3207: The Serving GW replies to the MME with a reply confirmation message.

Step 3208: The MME returns a network confirmation message to the eNodeB, and releases the resource between the eNodeB and the Serving GW.

Step 3209: The eNodeB replies to the UE with a network acknowledgment message, and releases the radio resource.

The foregoing network retreat scheme is a method for releasing resources for releasing a network by using a terminal in a network that is integrated with a broadband wireless access and a mobile communication network. In an evolved network, when the terminal needs to disconnect from the network, or When the network wants to disconnect from the terminal, it can release network resources in time, make up the management control mechanism of the evolved network, and improve resource utilization.

The above description is only a preferred embodiment of the present invention, and it should be noted that those skilled in the art can also make several improvements and retouchings without departing from the principles of the present invention. It is considered as the scope of protection of the present invention.

Claims

Rights request

A method for saving an address of a network anchor to a network server, comprising: a terminal initiating attachment or initiating a bearer establishment, and a network side selecting a network anchor point;

2. The method for saving an address of a network anchor to a network server according to claim 1, wherein the method further comprises:

When the access network supports multiple packet data networks (PDNs), or the network anchor points correspond to multiple PDNs, the network side device registers the access point identifier APN corresponding to the network anchor point to the network. server.

3. The method for saving an address of a network anchor to a network server according to claim 1, wherein: by a mobility management entity, or a serving GPRS support node, or an access network entity, or a network anchor, or Entities in the policy control and billing system register the address of the network anchor to the network service crying o

The method for saving the address of the network anchor to the network server according to claim 1, wherein before the registering the address of the network anchor to the network server on the network side, the method further comprises:: signing data according to the terminal Or a parameter configured by the mobility management entity, or a parameter configured by the serving GPRS support node, or a parameter of the network anchor configuration, or an indication issued by the mobility management management entity whether the address of the network anchor needs to be registered to the network server, Determine whether to register the address of the network anchor to the network server.

The method for saving an address of a network anchor to a network server according to any one of claims 1 to 4, wherein: the network anchor is a packet data network gateway PDN GW, and the network server is a home network Sign up for a server, or an AAA server, or a contracted data repository server.

6. A communication system, comprising:

The communication system according to claim 6, wherein the address registration entity is further configured to: when the access network supports the plurality of packet data networks PDN, or the network anchor point corresponds to multiple PDNs, Registering an access point identifier APN corresponding to the network anchor to the network server.

8. The communication system according to claim 6 or 7, wherein the address registration entity is: a mobility management entity, or a serving GPRS support node, or an access network entity, or the network anchor, or An entity in a policy control and billing system.

A communication system, comprising:

The communication system according to claim 9, wherein the address registration entity is further configured to: when the access network supports the plurality of packet data networks PDN, or the network anchor point corresponds to multiple PDNs, The access point identifier APN corresponding to the network anchor is registered to the network server.

The communication system according to claim 9 or 10, wherein the address registration entity is: a mobility management entity, or a serving GPRS support node, or an access network entity, or the network anchor, or An entity in a policy control and billing system.

12. An implementation method for deleting an address of a network anchor from a network server, comprising:

The network server deregisters the address of the network anchor.

The method for removing the address of the network anchor from the network server according to claim 12, wherein the method further comprises:

If the access point corresponding to the anchor point identifies that the APN has been registered to the network server, the network server deletes the access point identifier.

14. The method for implementing deletion of an address of a network anchor from a network server according to claim 12, wherein: by a mobility management entity, or a serving GPRS support node, or an access network entity, or said network anchor The entity in the point, or policy control and accounting system, notifies the network server to delete the address of the network anchor.

The method for implementing the deletion of an address of a network anchor from the network server according to claim 12, wherein before the network side notifies the network server to delete the address of the network anchor point The method further includes: according to the subscription data of the terminal, the parameter configured by the mobility management entity, the parameter of the network anchor configuration, and/or the indication sent by the mobility management management entity whether the address of the network anchor needs to be registered to the network server, Determining whether to notify the web server to delete the address of the network anchor.

The method for implementing the deletion of the address of the network anchor from the network server according to claim 12, wherein: the network side entity that initiates the bearer deletion process is a mobility management entity or a home subscription server.

17. A communication system, comprising:

The communication system according to claim 17, wherein the deregistration entity is further configured to delete the access when an access point corresponding to the anchor point identifies that an APN has been registered to the network server. Point identification.

The communication system according to claim 17 or 18, wherein the address deletion notification entity is: a mobility management entity, or a serving GPRS support node, or an access network entity, or the network anchor point, Or entities in the policy control and billing system.

20. A method of carrying release, characterized in that the method comprises:

The network server issues a bearer release request;

The method for claim release according to claim 20, wherein the network server triggers the bearer release request by the terminal.

The method for claim release according to claim 20, wherein the network anchor is a packet data network gateway PDN GW, and the network server is a home subscription server, or an AAA server, or a subscription data repository server. .

A method for retiring a terminal, which is characterized by comprising:

Dissolving the mobile IP binding corresponding to the terminal; The address information of all network anchors related to the terminal saved in the network server is deleted.

The method for retiring a terminal according to claim 23, wherein the method further comprises: deleting the terminal-related authentication information, authorization information, and control information in the network server.

The method for retiring a terminal according to claim 23, wherein when the terminal is in the 3GPP access network, the terminal exiting the network is triggered by the terminal, the mobility management entity, the network anchor or the network server.

The method for retiring a terminal according to claim 23, wherein when the terminal is in a non-3GPP access network, the terminal, the access network entity, the network anchor or the network server triggers the network to exit the network. .

The method for retiring a terminal according to claim 25 or 26, wherein the network anchor notifies the network server to delete address information of all network anchors associated with the terminal.

The method for retiring a terminal according to claim 25 or 26, wherein the session suspension message sent by the network server triggers the network withdrawal process, and after the network server receives the session suspension confirmation message, The address information of all network anchors related to the terminal is deleted.