WO2008000182A1

WO2008000182A1 - Method and system of movement management within evolved network architecture

Info

Publication number: WO2008000182A1
Application number: PCT/CN2007/070143
Authority: WO
Inventors: Jian Zhang; Xiaolong Guo; Zhiming Zhu; Weihua Hu
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2006-06-20
Filing date: 2007-06-20
Publication date: 2008-01-03

Abstract

A movement management method within evolved network architecture includes: confirming user equipment needs to be transferred between anchors, and the destination anchor provides communication resources to user equipment for later communication. A movement management system within evolved network architecture includes: network server that provides services to user equipment, which requests communication resources from destination anchor for user equipment's later communication when confirming the user equipment needs to be transferred between anchors; the destination anchor to which user equipment is transferred provides communication resources to user equipment. The movement management project within evolved network architecture can enhance user equipment's communication quality and improve user's satisfaction enormously.

Description

Mobility management method and management system under evolution network architecture

The present invention relates to mobile communication technologies, and in particular, to a mobility management method and management system under an evolved network architecture. Background of the invention

With the development of communication technology, the evolution network architecture is gradually being studied in depth; among them, a widely accepted evolution network architecture is shown in Fig. 1, and Fig. 1 is an evolution network structure diagram of the prior art. In FIG. 1, a user equipment (UE, User Equipment) 101 may access a Mobility Management Entity (MME) 103 and a user through a Long Term Evolution-Radio Access Network (LTE-RAN) 102. A UPE (User Plane Entity) 104, and communicates with an anchor 109 connected to the UPE 104. Similarly, the UE 101 can also access the MME 107 and the UPE 108 through the LTE-RAN 106, and with the UPE 108. The connected Anchor 109 communicates. The MME and the UPE may be two independent logical entities, or may be an MME/UPE that is combined into one logical entity. The following describes the MME/UPE as an example.

As the UE moves, the UE may move from the service area providing the service to itself to another service area; in this case, it is possible for the UE to perform the MME/UPE reselection process. For non-real-time services and real-time services, the MME/UPE re-election process performed by the UE may be different. The MME/UPE re-election process is briefly introduced through Figure 2 and Figure 3.

Referring to FIG. 2, FIG. 2 is a schematic diagram of an MME/UPE reselection process for non-real-time services in the prior art. In FIG. 2, when the UE 201 receiving the non-real time service moves from the first service area to the second service area, the UE 201 may access the LTE-RAN entity (Entity) at different locations. 1. LTE-RAN Entity 2. LTE -RAN Entity 3, LTE-RAN Entity 4 or LTE-RAN Entity 5. Moreover, when located in the first service area, the UE 201 accesses the MME/UPE 202 through the LTE-RAN Entity; and when located in the second service area, the UE 201 accesses the MME/UPE 203 through the LTE-RAN Entity. However, regardless of whether the UE 201 accesses the MME/UPE 202 or the MME/UPE 203, the UE 201 will communicate with the Anchor 204 that originally served the UE 201 through the MME/UPE to which it is connected, without going to Communicate with other Anchors.

The case where the UE 201 is fixed to communicate with the Anchor 204 inevitably causes some communication problems: As the UE 201 moves, the Anchor 204 may no longer be the Anchor that is most advantageous for the UE 201 communication, such as: Anchor 204 to UE 201 The route is no longer the best route, etc.; this obviously leads to waste of network transmission resources, and the communication delay of the UE 201 is also significantly increased due to routing deterioration, so that the communication quality of the UE 201 is significantly reduced, thereby seriously reducing user satisfaction. .

Referring to FIG. 3, FIG. 3 is a schematic diagram of an MME/UPE reselection process for real-time services in the prior art. In FIG. 3, when the UE 301 accepting the real-time service moves from the first service area to the second service area, the UE 301 may access the LTE-RAN entity (Entity) at different locations. 1. LTE-RAN Entity 2. LTE- RAN Entity 3, LTE-RAN Entity 4 or LTE-RAN Entity 5. Moreover, when the real-time service has not ended, the UE 301 will always access the MME/UPE 302; and when the real-time service ends and the UE 301 is located in the second service area, the UE 301 will be connected through the LTE-RAN Entity. Enter the MME/UPE in the second service area

The UE 301 will communicate with the Anchor 304, which was originally served by the UE 301, through the MME/UPE to which it is connected, and will not in turn communicate with other Anchors.

As with the problem set forth with respect to Figure 2, the fixed communication of UE 301 with Anchor 304 inevitably leads to some communication problems: With the movement of UE 301, Anchor 304 may no longer be the Anchor that is most beneficial to UE 301 communication. For example, the route from Anchor 304 to UE 301 is no longer the best route; this obviously leads to waste of network transmission resources, UE 301 The communication delay is also significantly increased due to routing degradation, so that the communication quality of the UE 301 is significantly reduced, thereby seriously reducing user satisfaction.

In addition, as shown in FIG. 3, if the UE 301 is in the idle (Idle) state and is always located within the first service area or the second service area, the UE 301 will always pass the MME/UPE 302 it accesses when it is activated. Anchor 304 communication for UE 301. However, when the load of the Anchor 304 is too heavy, for example, the number of valid connections on the Anchor 304 is too large, the route of the Anchor 304 to the UE 301 is no longer the best route; this obviously makes the communication quality of the activated UE 301. Significantly lower, which in turn severely reduces user satisfaction. At the same time, a single Anchor is overloaded, which can also cause network devices to be unbalanced. In addition, when the maintenance of the anchor is required, all the UEs connected to the anchor need to be migrated out. However, since the existing technical solution has not proposed a specific solution for the anchor migration of the UE, the anchor after the jH1 operation is not suitable for maintenance. Summary of the invention

In view of this, the embodiment of the present invention provides a mobility management method in an evolved network architecture, which can improve communication quality of a UE, and the method includes:

Determining that the user equipment UE needs to perform anchor migration;

The anchor point to which the UE is to migrate provides communication resources for supporting subsequent communication by the UE. The embodiment of the present invention further provides a mobility management system in an evolved network architecture, which can improve communication quality of the UE, and the system includes: a network server serving the UE and an anchor point to which the UE is to be migrated;

When the network server determines that the UE needs to perform anchor migration, the anchor point to which the UE is to be migrated requests to provide the UE with communication resources supporting subsequent communication of the UE;

The anchor point to which the UE is to be migrated is the communication resource provided by the UE.

Applying the mobility management solution under the evolved network architecture provided by the embodiment of the present invention, When the UE needs to perform the Anchor migration, the new Anchor to be migrated by the UE provides communication resources for supporting subsequent communication of the UE, and the communication resources are generally: a user plane and a communication address for supporting subsequent communication of the UE.

When the UE migrates to the new Anchor that is most conducive to communication, not only does the network transmission resource waste and the UE communication delay increase occur in the prior art, but also the network transmission resource can be obviously saved and the UE communication can be effectively reduced. The delay makes the communication quality of the UE significantly improved, thereby significantly improving user satisfaction.

In addition, when the anchor that is currently serving the UE is overloaded, the UE in the idle state is migrated to the other anchor according to the load condition, thereby reducing the load of the Anchor serving the UE before the Anchor migration and realizing load balancing. The implementation of load balancing can also significantly improve the communication quality of the UE, thereby significantly improving user satisfaction.

In addition, by migrating the UE on the Anchor to other Anchors in batches, smooth migration of UEs in the Anchor can also be implemented. After the migration is complete, you can take the anchor that needs to be maintained.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a structural diagram of an evolution network of the prior art.

2 is a schematic diagram of an MME/UPE reselection process for non-real-time services in the prior art. FIG. 3 is a schematic diagram of an MME/UPE reselection process for real-time services in the prior art. 4 is a schematic diagram of a mobility management process of the present invention.

FIG. 5 is a schematic diagram of another mobility management process of the present invention.

FIG. 6 is a schematic diagram of still another mobility management process of the present invention.

Figure 7 is a flow chart showing mobility management according to Embodiment 1 of the present invention.

Figure 8 is a flow chart showing the mobility management of the second embodiment of the present invention.

FIG. 9 is a flowchart of mobility management according to Embodiment 3 of the present invention. FIG. 10 is a flowchart of mobility management according to Embodiment 4 of the present invention.

Figure 11 is a flow chart showing mobility management according to Embodiment 5 of the present invention.

Figure 12 is a flow chart showing the mobility management of the embodiment 6 of the present invention.

Figure 13 is a flow chart showing the mobility management of the seventh embodiment of the present invention.

Figure 14 is a flow chart showing the mobility management of the eighth embodiment of the present invention.

Figure 15 is a flow chart showing the mobility management of the ninth embodiment of the present invention.

Figure 16 is a flow chart showing mobility management according to Embodiment 10 of the present invention.

Figure 17 is a flow chart showing the mobility management of the eleventh embodiment of the present invention.

Figure 18 is a flow chart showing the mobility management of the embodiment 12 of the present invention.

Figure 19 is a flow chart showing the mobility management of the thirteenth embodiment of the present invention.

Figure 20 is a flow chart showing the mobility management of the embodiment 14 of the present invention.

Figure 21 is a flow chart showing the mobility management of the embodiment 15 of the present invention.

Figure 22 is a flow chart showing the mobility management of the embodiment 16 of the present invention.

FIG. 23 is a schematic diagram showing the basic composition of a mobility management system according to an embodiment of the present invention. Mode for carrying out the invention

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

The mobility management method in the evolved network architecture provided by the present invention, when determining that the UE needs to perform the Anchor migration, the new Anchor to be migrated by the UE provides communication resources for supporting subsequent communication of the UE, and the communication resource is usually: User plane and communication address supporting subsequent communication of the UE.

The foregoing determining that the UE needs to perform the Anchor migration may be triggered by the UE, for example, the UE triggers by initiating the location area update request; or the core network side network server or Anchor serving the UE determines the trigger according to related instructions and parameters of the real-time interaction. The UE to which the latter is to perform the Anchor migration is the UE in the idle state. Here are the different reasons to touch The Anchor migration process is described.

Referring to FIG. 4, FIG. 4 is a schematic diagram of a mobility management process according to the present invention, where the process includes the following steps:

Step 401: The UE applies a prior art to initiate a location area update; and, the access network selects a new Network Server for the UE.

Specifically, the UE usually initiates a location area update in a manner of sending a location area update request to the access network; the access network may apply a new Network Server to the UE by applying the widely used Flex principle.

It can be seen that in this process, the Anchor migration operation triggered by the location area update request initiated by the UE is performed. Due to the update of the UE location area, the anchor that originally communicated with the UE may not be the anchor that is most advantageous for communication with the UE. Therefore, it is necessary to determine whether the UE needs to perform Anchor migration.

Step 402: The old Network Server transfers the context (Context) for the UE to the new Network Server.

Specifically, the new network server may obtain the identifier of the location area before the UE initiates the location area update from the location area update request from the UE, and find the old network registered by the UE before the location area update is initiated according to the identifier. Server address. Based on this, the request includes a Packet-Temporary Mobile Subscriber Identity (P-TMSI) of the UE, a TAI (Track Area Identifier), and a Temporary Retrieval Link Identifier ( Temporary Logical Link Identity (TLLI), new Network Server address and other parameters; When the old Network Server receives the Context Transfer Request from the new Network Server, it sends the Context of the UE to the new Network Server.

Step 403: The new Network Server determines through logic that the UE needs to perform an Anchor migration. In an actual application, the new Network Server may determine whether the UE needs to perform an Anchor migration according to the anchor migration information preset in a static manner and/or the anchor migration parameter obtained in a dynamic manner.

For the static mode, the route metric between the Network Server and its associated Anchors can be pre-set in the new Network Server; thus, the new Network Server can determine the Anchor with its own optimal route metric, and Determine whether the Anchor is the Anchor currently communicating with the UE. If yes, the new Network Server determines that the UE does not need to perform the Anchor migration; otherwise, the new Network Server determines that the UE needs to perform the Anchor migration, and determines the Anchor with the optimal route metric as the UE. Anchor should be migrated to.

For the dynamic mode, the new Network Server can acquire the state parameters of each Anchor connected to itself, such as: system resource load status, number of UE connections, link resource load status, etc., in real time or periodically, and will obtain One or more of the each of the Anchor state parameters are compared to obtain an Anchor that has the most dominant state parameter, and the Anchor is determined as the Anchor that is most favorable for UE communication, and then it is determined whether the Anchor is the Anchor currently communicating with the UE. If yes, the new Network Server determines that the UE does not need to perform the Anchor migration; otherwise, the new Network Server determines that the UE needs to perform the Anchor migration, and determines that the Anchor whose state parameter is most dominant is the Anchor to which the UE should migrate.

Of course, in addition to the Anchor status parameter described above, the new Network Server can also take into account the routing metrics between itself and the connected Anchors, such as: The new Network Server obtains the state parameters of each Anchor and between itself and each Anchor. The route metric, when the Anchor with the most dominant state parameter is obtained, determine whether the route metric between the Anchor and the new Network Server is lower than the preset route metric limit, and only when the judgment result is not lower than Anchor is determined as the Anchor that is most conducive to UE communication, and further determines whether the Anchor is the Anchor currently communicating with the UE, and if so, new Network Server to determine the UE does not need to Anchor migration; No shellfish ¹ J, the new Network Server determines that the UE needs to Anchor migration, and to determine the route and measure up to not less than routing metric floor of Anchor dominant state parameters are to be migrated to the UE Anchor.

In addition, when the new Network Server obtains the state parameters of each Anchor and the route metric between itself and each Anchor, it can also select an Anchor whose route metric is optimal and determine whether the state parameter of the Anchor is better than a preset threshold. The status parameter, and only determines the Anchor as the Anchor that is most beneficial to the UE communication when the judgment result is yes, and further determines whether the Anchor is the Anchor currently communicating with the UE, and if so, the new Network Server determines that the UE does not need to perform the Anchor. Migration; otherwise, the new Network Server determines that the UE needs to perform an Anchor migration, and determines that the route metric is optimal and the state parameter is better than the threshold state parameter. Anchor is the Anchor to which the UE should migrate.

In a practical application, the route metric may be pre-configured, or may be obtained by a new network server through a routing protocol; and, in determining an operation of whether the UE needs to perform an Anchor migration and migrate to which Anchor, the route metric Usually a very important parameter.

In this step, before the new network server determines whether the UE needs to perform the anchor migration in a static manner and/or a dynamic manner, it may first determine whether to allow Anchor migration according to the subscription data of the UE; if not, the new network The Server does not perform an Anchor migration on the UE; if it is allowed, the subsequent judgment is required for the migration.

Or, after the new network server determines that the UE needs to perform the anchor migration in a static manner and/or a dynamic manner, it is determined whether the Ocean migration is allowed according to the subscription data of the UE. If not, the new Network Server does not perform the Anchor for the UE. Migration; if allowed, the subsequent actions of the new Anchor to be migrated are determined.

Or, after determining the new Anchor that the UE needs to migrate to, according to the number of subscriptions of the UE It is determined whether to run the migration to the new Anchor.

When it is judged whether or not the anchor migration is allowed according to the subscription data of the UE, the determination may be made according to the migration restriction information set in the subscription data of the UE in advance. The migration restriction information may be location information that allows the UE to perform Anchor migration. For example, when a UE located in area one has its migration restriction information indicating that it is allowed to migrate to the anchor of the area 2, it is not allowed to migrate to the anchor of the area three. The migration restriction information may be an indication that the UE is allowed to perform an Anchor migration, such as permission or disallow.

The migration restriction information may be set in the roaming protocol of the UE in addition to the subscription data; the migration restriction information may also be used as information included in an access point network (APN) structure; or, as a policy And the judgment information in the PCC (Policy and Charging Control) rule, but not only the specific implementation of the migration restriction information listed above.

As apparent from the above, the new Network Server generally determines the anchor that is most advantageous for UE communication as a new anchor to which the UE needs to migrate; relatively speaking, the anchor currently communicating with the UE is considered to be the old anchor.

Step 404: After determining that the UE needs to perform the Anchor migration, the current authentication authentication process may be further performed between the UE, the new Network Server, and even the Home Subscriber Server (HSS); For security reasons, for example: When the key of the UE has expired, in order to ensure communication security, the authentication and authentication process needs to be performed.

Of course, in the actual application, the authentication and authentication process may not be performed, but the UE may be served by default, and then directly proceeds to step 405.

Step 405: The new Network Server requests the new Anchor to allocate a new user plane and service layer address to the UE, and the new Anchor allocates a new user plane and a service layer address to the UE when receiving the request from the new Network Server. The service layer address is usually an internet protocol (IP, Internet Protocol) address.

Specifically, the new network server sends a user plane allocation request including the UE Context to the new Anchor. When the new Anchor receives the user plane allocation request from the new Network Server, the new user establishes a corresponding user plane according to the UE Context included in the request. Information, and assign a service layer address to the UE. The operation of allocating the service layer address can be performed by querying a domain name resolution server (DNS, Domain Name Server) and the like.

After the user plane information is established for the UE, a connection relationship between the new Network Server and the new Anchor is established to support UE communication.

Step 406: The new Network Server requests the old Anchor to delete the old user plane for the UE.

Specifically, the new network server sends a user plane deletion request including the UE Context to the old anchor; when the old anchor receives the user plane deletion request from the new network server, the user plane information that was established for the UE is deleted. In this way, there is no longer a connection relationship between the new Network Server and the old Anchor to support UE communication.

Step 407: The new Network Server notifies the HSS UE that the location area update has occurred.

Specifically, the new Network Server sends a location update message for the UE to the HSS, and when the HSS receives the location update message, the HSS sends a location cancel message for the UE to the old network server; when the old Network Server receives the location cancel message from the HSS, Deleting the location information of the stored UE and returning a location cancellation confirmation message to the HSS, the HSS sends the subscription data of the UE to the new Network Server when receiving the location cancellation acknowledgement message; the new Network Server creates a new UE for the UE according to the received UE subscription data. Context, and send an insert user data confirmation message to the HSS; when receiving the insert user data confirmation message, the HSS returns a location update confirmation message to the new Network Server.

Step 408: The new Network Server notifies the UE of the service layer address allocated by the new Anchor for the UE. Specifically, the new network server obtains the service layer address allocated by the new Anchor for the UE, and carries the service layer address in the location area update accept message and sends the message to the UE. In practical applications, the new Network Server may also allocate some new parameters to the UE, such as: Ρ-TMSL· New Location Area Identifier (TAI). The new Network Server can carry these parameters and the new user IP address in the location area update accept message or send it to the UE in other message formats.

Step 409: After receiving the service layer address of the new network server, the UE applies the existing technology to the upper layer service network registration by using the service layer address, so that the upper layer service network learns the newly allocated service layer address of the UE, and ensures the upper layer service. The network can subsequently apply the service layer address to communicate with the UE normally.

At this point, the process ends.

In the above process, there is no obvious chronological order between step 405 and step 406, and step 405 or step 406 may be performed first, or step 405 and step 406 may be performed simultaneously.

As can be seen from FIG. 4, when the UE initiates a location area update, it is possible to select a new Network Server for the UE to support UE communication; the new Network Server can determine whether the UE needs to perform an Anchor migration and which Anchor should be migrated, and can also request the UE. The new Anchor to be migrated establishes a new user plane for the UE and allocates a service layer address to the UE, so that the UE can apply the newly allocated service layer address for subsequent operations of the upper layer service network registration, and ensure that the upper layer service network can subsequently apply the service. The layer address communicates with the UE normally.

Of course, if the new Network Server determines that the UE does not need to perform the Anchor migration, then the subsequent operations involving the new Anchor need not be performed, but only the prior art is used to perform the location area update operation of the UE.

Obviously, the process shown in FIG. 4 can ensure that the UE is migrated to the currently most convenient communication, so that not only the waste of network transmission resources and the delay of UE communication delay occur in the prior art, but also obvious Save network transmission resources and effectively reduce The UE communication delay makes the communication quality of the UE significantly improved, thereby significantly improving user satisfaction. For example, when the user's anchor point is located in the area, when the user moves to the area 2, if the user calls a user of the area 2, in the scenario where the anchor point migration is not adopted, the call path of the user plane is from the area 2 Go to the area one, and then return to the area two again, which obviously causes the transmission surface path to be unoptimized, wastes network resources, and increases the communication delay. Therefore, the technical solution of the anchor point migration in the embodiment of the present invention can migrate the anchor point of the user to the area 2, thereby using the optimized path for communication, saving network resources, reducing communication delay, and solving the defects of the prior art.

Referring to FIG. 5, FIG. 5 is a schematic diagram of another mobility management process according to the present invention, where the process includes the following steps:

Step 501: The UE applies the prior art to initiate location area update, but the access network does not select a new Network Server for the UE.

It can be seen that, in this process, the operation of triggering to determine that the UE needs to perform the anchor migration is still a location area update request initiated by the UE.

Step 502: The Network Server currently serving the UE determines by logic that the UE needs to perform Anchor migration.

In practical applications, the Network Server can determine whether the UE needs to perform Anchor migration according to the anchor migration information preset in a static manner and/or the dynamically obtained anchor migration parameters.

For the static mode, the route metric between the Network Server and its associated Anchors can be preset in the Network Server; thus, the Network Server can determine the Anchor with its own optimal route metric, and determine the Whether Anchor is the Anchor currently communicating with the UE. If yes, the Network Server determines that the UE does not need to perform the Anchor migration; otherwise, the Network Server determines that the UE needs to perform the Anchor migration, and determines the Anchor with the optimal route metric as the UE should be migrated to. Anchor. For the dynamic mode, the network server can acquire the state parameters of each Anchor connected to itself, such as: system resource load status, number of UE connections, link resource load status, etc., and obtain the real-time or periodic manner. One or more of the Anchor state parameters are compared to obtain an Anchor that has the most dominant state parameter, and the Anchor is determined as the Anchor that is most favorable for UE communication, and then it is determined whether the Anchor is the Anchor currently communicating with the UE, if Yes, the Network Server determines that the UE does not need to perform the Anchor migration; otherwise, the Network Server determines that the UE needs to perform the Anchor migration, and determines that the Anchor whose state parameter is most dominant is the Anchor to which the UE should migrate.

Of course, in addition to the above-mentioned Anchor state parameters, the Network Server can also take into account the route metric between itself and each Anchor connected. For example, the Network Server obtains the state parameters of each Anchor and the route between itself and each Anchor. The metric determines whether the route metric between the Anchor and the Network Server is lower than a preset route metric limit when the Anchor with the most dominant state parameter is obtained, and determines the Anchor as only when the judgment result is not lower than The Anchor, which is most advantageous for UE communication, further determines whether the Anchor is the Anchor currently communicating with the UE. If yes, the Network Server determines that the UE does not need to perform the Anchor migration; otherwise, the Network Server determines that the UE needs to perform the Anchor migration and determines the status parameter. The Anchor that has the most dominant and the routing metric is not lower than the routing metric threshold is the Anchor that the UE should migrate to.

In addition, when the Network Server obtains the state parameters of each Anchor and the route metric between itself and each Anchor, it can also select the Anchor whose route metric is optimal and determine whether the state parameter of the Anchor is better than the preset threshold state. The parameter, and only determines the Anchor as the Anchor that is most beneficial to the UE communication when the judgment result is yes, and further determines whether the Anchor is the Anchor currently communicating with the UE, and if so, the Network Server determines that the UE does not need to perform the Anchor migration; Otherwise, the Network Server determines that the UE needs to perform an Anchor migration and determines that the route metric is optimal and the state parameters are better than the bottom limit. The Anchor of the state parameter is the Anchor to which the UE should be migrated.

In practical applications, the routing metric may be pre-configured or obtained by the Network Server through a routing protocol; and in determining whether the UE needs to perform the Anchor migration and the migration to which Anchor, the routing metric is usually It is a very important parameter.

In this step, the network server determines whether the UE needs to perform an Anchor migration according to the subscription data of the UE before or after the Anchor migration in a static manner and/or a dynamic manner. If not, the Network Server is not allowed. The Anchor migration is not performed on the UE; if so, the subsequent operations are performed. Alternatively, after determining the new anchor to which the UE needs to migrate, it is determined whether to migrate to the new anchor according to the subscription data of the UE. The migration restriction information is also included in the subscription data. For details about the implementation of the migration restriction information, refer to the detailed description in step 403.

It can be clearly seen from the above that the Network Server usually determines the Anchor that is most advantageous for UE communication as the new Anchor to which the UE needs to migrate; relatively speaking, the Anchor currently communicating with the UE is considered to be the Old Anchor.

Step 503: After determining that the UE needs to perform the anchor migration, the current authentication authentication process may be further performed between the UE, the Network Server, and even further with the HSS.

Of course, in the actual application, the authentication and authentication process may not be performed, but directly proceeds to step 504.

Step 504: The Network Server requests the new Anchor to allocate a new user plane and service layer address to the UE, and the new Anchor allocates a new user plane and a service layer address to the UE when receiving the request from the Network Server. The operation method of this step is the same as the corresponding operation method of step 405.

After the user plane information is established for the UE, the Network Server and the new Anchor are built. A connection relationship is established to support UE communication.

Step 505: The Network Server requests the old Anchor to delete the old user plane for the UE. The specific deletion method is the same as the corresponding deletion method in step 406.

After this step is completed, there is no longer a connection relationship between the Network Server and the old Anchor to support UE communication.

Step 506: The Network Server notifies the UE of the service layer address assigned by the new Anchor to the UE. The specific notification method is the same as the corresponding notification method in step 408.

Step 507: After receiving the service layer address from the Network Server, the UE applies the existing technology to the upper layer service network registration by using the service layer address. The specific registration method is the same as the corresponding registration method in step 409.

At this point, the process ends.

In the above process, the operation of assigning a new user plane and a service layer address to the UE is performed in step 504, and there is no obvious chronological order between the operations of deleting the old user plane for the UE, and step 504 may be performed first. In step 505, step 504 and step 505 can also be performed simultaneously.

It can be seen from FIG. 5 that when the UE initiates the location area update, it is possible that the new network server is not selected for the UE, but the Network Server that is currently the UE monthly service is still used; the Network Server can determine whether the UE needs to perform the Anchor migration and should be migrated. To which Anchor, the new Anchor that the UE is to be migrated to establish a new user plane for the UE and allocate a service layer address to the UE, so that the UE can apply the newly allocated service layer address for subsequent operations of the upper layer service network, and ensure that the operation is performed. The upper layer service network can subsequently apply the service layer address to communicate with the UE normally.

Of course, if the Network Server determines that the UE does not need to perform the Anchor migration, then the subsequent operations involving the new Anchor need not be performed, but only the existing technology is used to perform the location area update operation of the UE. Obviously, the process shown in FIG. 5 can ensure that the UE is migrated to the currently most convenient communication, so that there is no problem of waste of network transmission resources and increased UE communication delay in the prior art. The network transmission resource is saved and the UE communication delay can be effectively reduced, so that the communication quality of the UE is significantly improved, thereby significantly improving user satisfaction.

As shown in FIG. 4 and FIG. 5, the processes shown in FIG. 4 and FIG. 5 both trigger the operation of the Network Server to determine whether to perform the Anchor migration for the UE due to the UE initiating the update request of the location area. The UE performing the Anchor migration is the UE that initiates the location area update. The difference between the flow shown in FIG. 4 and FIG. 5 is only whether the new network server is selected for the UE that initiates the location area update; however, whether the new network server is selected for the UE that initiates the location area update, the UE that initiates the location area update is The ability to migrate to the current Anchor, which is most conducive to communication, enables the UE's communication quality to be significantly improved, thereby significantly improving user satisfaction.

The following describes the management mobility method of the user's Anchor migration initiated by the Network Server on the core network or the Anchor that is currently the user's monthly service. It should be noted that, for the migration of the user that is triggered by the network server or the anchor, one or more UEs that are served by the anchor are migrated out of the anchor, and the migrated UE is the UE in the idle state.

Referring to FIG. 6, FIG. 6 is a schematic diagram of still another mobility management process according to the present invention. The process includes the following steps:

Step 601: The Network Server or the Anchor determines, by using a logical judgment, the UE in an idle state that needs to perform the anchor migration.

In actual applications, the core network device that needs to be anchored can be either Network Server or Anchor. The determination mode can be divided into the following types: Mode 1: The anchor determines whether there is a UE that needs to carry out the Anchor migration according to its own load.

Specifically, Anchor can obtain Anchor status information according to the number of UEs that are effectively connected. It is determined whether the self load exceeds a preset bottom limit. When it is determined to be exceeded, it is determined that the UE on the Anchor needs to be migrated. An Anchor migration request is sent to the Network Server, where the request carries the parameters of the UE to be migrated, and the Network Server enters the subsequent migration process after receiving the migration request.

An example is given for this situation: The anchor is pre-stored with a judging rule, and the judging rule is that when the actual number of excess connections exceeds the preset number of excess connections, it is determined that the UE connected to the anchor needs to be anchored. When the number of Anchor rated connections is 100 and the actual number of connections is 120, according to the pre-set judgment rules, it is judged whether the excess connection number exceeds the excess load limit. If the underload limit is 0, it can be judged as exceeding; if the underload limit is 30, it can be judged as not exceeded. Of course, the judgment rule can also be set according to other Anchor parameters. When Anchor determines that an anchor migration is required, it sends an anchor migration request to the Network Server and adds the UE parameters to be migrated to the sent request. After the Network Server selects a new anchor for the UE that needs to migrate the Anchor, it enters the process of subsequently migrating the Anchor.

Mode 2: The Network Server interacts with the Anchor to determine whether there is a UE that needs to migrate the Anchor.

Specifically, the Network Server can make decisions based on the Anchor timing or the information sent under the trigger of the trigger event.

The information sent by the anchor is usually information related to the Anchor load, including: indication of the UE load, indication that the UE is not ready to access the new UE, and/or parameters of the UE in the idle state that need to be migrated in batches. The indication of the UE load includes the number of the number of the connected UEs and the number of the UEs that are actually connected. The indication that the UE is not ready to access the new UE indicates that the Anchor does not currently allow access to the new UE. The parameters determined by the anchor need to migrate the UE. Based on the information and the pre-set judgment rules, the Network Server determines whether the Anchor is overloaded. If yes, it determines that it needs to be The Anchor-connected UE performs an Anchor migration, and determines the UE that needs to perform the Anchor migration according to the information sent by the Anchor. After the network server selects a new Anchor for the UE that needs to migrate the Anchor, it enters the process of migrating the Anchor. The judgment rule based on the Network Server judgment can be the same as or different from the judgment rule set in the Anchor.

Mode 3: When the anchor fails or receives the command of the network management maintenance anchor, the anchor needs to perform the Anchor migration on the UE connected to the anchor. At this point, Anchor will perform an Anchor migration for some or all of the UEs connected to it. However, these UEs that need to be migrated may be partially idle and may be migrated; some are active and cannot be migrated immediately. Therefore, Anchor needs to migrate UEs in batches. The UE in the idle state is migrated first, and then the UE in the active state is switched to the idle state and then migrated. When all UEs connected to the Anchor are migrated, the Anchor can be maintained or repaired, thus completing the smooth migration of the UE.

Of course, the Network Server can also periodically determine whether the UE needs to perform Anchor migration according to the statically pre-set anchor migration information and/or the dynamically obtained anchor migration parameters.

In the above multiple modes, the network server needs to select a new anchor for the UE before the subsequent migration process can be performed. The operation of selecting a new Anchor may use the foregoing according to the routing metric and/or the state parameter of the Anchor to select the Anchor that is most beneficial to the UE communication as the new Anchor. If the Anchor that is most beneficial to the UE communication is the Anchor currently serving the UE, the selection is performed. The Anchor that facilitates UE communication is used as the new Anchor. The UE can also be migrated to the specified Anchor. The specified Anchor can be pre-configured or specified by the network administrator.

Step 602: The Network Server requests the new Anchor to allocate a new user plane and a service layer address to the UE. The new Anchor assigns a new UE to the UE when it receives a request from Network Server. User plane and business layer address. The service layer address is usually an IP address.

Specifically, the network server sends a user plane allocation request to the new Anchor that includes the UE that needs to perform the Anchor migration, and the request also includes the address of the Network Server, the Quality of Service Negotiated, and the Serving Network Identity. ), global cell identification/service area identification (CGI/SAI, Cell Global Identification/ Service Area Identification), radio access technology type (RAT type, Radio Access Technic Type) and other parameters, and request the new Anchor to allocate a service layer to the UE address. When receiving a user plane allocation request from the network server, the new anchor establishes corresponding user plane information for the UE according to the UE Context included in the request, and allocates a service layer address for the UE. The operation of assigning the service layer address can be performed in various ways such as querying DNS.

Step 603: The Network Server requests the old Anchor to delete the old user plane for the UE. The specific deletion method is the same as the corresponding deletion method in step 406.

It should be noted that there is no inevitable sequence between this step and other steps in the process. That is, this step may also be performed before the Network Server establishes a connection relationship with the UE's new Anchor, or, in step 604 to the step. 607 is executed at any time.

Step 604: The Network Server pages the anchored UE in the paging area. Specifically, since the UE performing the Anchor migration is the UE in the idle state, it is necessary to perform paging in the paging area of the UE to find the UE, so as to establish a new user plane and an allocated service layer for it. The address is notified to the UE.

Step 605: The Network Server notifies the UE of the user plane and the service layer address allocated by the new anchor for the UE.

Specifically, Network Server passes the non-access stratum (NAS, Non Access Stratum) The signaling notifies the UE of the new service layer address assigned by the new Anchor.

Step 606: The UE initiates a service request to the Network Server.

In this step, after the UE initiates the service request, the current authentication authentication process may be further performed between the UE, the Network Server, and even the HSS.

Of course, in the actual application, the authentication and authentication process may not be performed, but directly proceeds to step 607.

Step 607: After receiving the service layer address from the Network Server, the UE applies the existing technology to the upper layer service network registration by using the service layer address. The specific registration method is the same as the corresponding registration method in step 409.

At this point, the process ends.

In the above process, after determining the UE that needs to perform the Anchor migration, the Network Server or the old Anchor may first determine whether to allow the Anchor migration according to the subscription data of the UE. Then, determine the new Anchor for the UE that allows the Anchor migration, and perform the Subsequent migration operations; For UEs that do not allow Anchor migration, do not process and exit this process. The subscription data also includes migration restriction information. For the implementation of the migration restriction information, refer to the detailed description in step 403.

Obviously, the process shown in FIG. 6 can migrate the UE in the idle state to other anchors when the Anchor is overloaded, thereby reducing the load of the Anchor that is the UE's monthly service before the migration, and achieving load balancing. The implementation of load balancing can also significantly improve the communication quality of the UE, thereby significantly improving user satisfaction. After the maintenance device command is issued to the anchor, the administrator can migrate the UE on the anchor to another anchor in batches, thereby implementing smooth migration of the UE in the anchor. After the migration is complete, the Anchor that requires maintenance can be repaired or maintained.

It should be noted that the network servers in FIG. 4, FIG. 5, and FIG. 6 may be MME/UPEs that are combined into one logical entity, or may be separated into two logics in the MME and UPE. The MME in the case of an entity, or other communication entity that can provide communication services for the UE. The Anchor in FIG. 4, FIG. 5 and FIG. 6 may be a 3GPP Anchor, or an Inter Access System Anchor (IASA); and, FIG. 4, FIG. 5 and the Anchor of FIG. 6 may also be provided with a UPE entity; further, the Internet Protocol Multimedia Subsystem (IMS) in FIG. 4, FIG. 5 and FIG. 6 is only one of the upper layer service networks. The upper service network may also be a Microsoft network (MSN, Microsoft Network) or a network content service network.

4, FIG. 5, and FIG. 6 are only a general outline of the mobility management method of the present invention. In practical applications, the Network Server may be an MME/UPE that is a logical entity, or may be in the MME. The MME in the case of UPE separation, in addition, FIG. 4 and FIG. 5 also relate to the possibility of selecting a new Network Server for the UE in the mobility management process, namely: reselecting the MME and/or the UPE; The mobility management process is different; therefore, the mobility management process in different situations is described in detail below through a large number of embodiments to explain the specific operational details of the mobility management method of the present invention as clearly and in detail as possible. It should be noted that although whether to reselect the MME and/or the UPE and whether the MME and the UPE are combined into one logical entity can cause a certain change in the mobility management process, the operations performed by different communication entities for the same message structure are generally not available. How much change.

Embodiments 1 to 13 are all described for the Anchor migration situation triggered by the location area update request initiated by the UE.

Embodiment 1: MME and UPE are combined into one logical entity MME/UPE, and MME/UPE is reselected;

Referring to FIG. 7, FIG. 7 is a flowchart of mobility management according to Embodiment 1 of the present invention, and the process includes the following steps:

Step 701: The UE to be updated by the location area is new to the location area in which it is located The MME/UPE sends a location area update request (TAU Request), where the update request includes P-TMSI, an identifier of the location area (old TAI), and an update type (Update Type) before the UE initiates the location area update.

Generally, the UE may perform location area update due to entering a new location area, or may simply perform location area update periodically.

Step 702: The new MME/UPE queries the address of the old MME registered before the UE initiates the location area update according to the old TAI in the received TAU Request, and sends a context request for the UE to the old MME according to the address. Context request ). The Context request contains some necessary information, such as: P-TMSI, oldTAI, TLLI, new MME address, and so on.

Step 703: The old MME/UPE sends the Context of the UE to the new MME/UPE in the context response (Context response ).

Step 704: The new MME/UPE determines through logic that the UE needs to perform an anchor migration.

Step 705: After determining that the UE needs to perform the anchor migration, the new MME/UPE may further perform a current authentication authentication process with the UE and even the HSS for the UE.

Of course, in the actual application, the authentication and authentication process may not be performed, but the process directly proceeds to step 706.

Step 706: After receiving the Context response from the old MME/UPE, the new MME/UPE may further return a context acknowledgment message (context Acknowledge) to the old MME/UPE. In actual application, the step operation may not be performed, but directly proceeds to step 707.

Step 707: The new MME/UPE sends a Create context request carrying the UE Context to the new Anchor to which the UE is to be migrated, and requests a new request. Anchor assigns a new IP address to the UE.

Step 708: When the new Anchor receives the Create context request from the new MME/UPE, it establishes corresponding user plane information for the UE according to the UE Context included in the request, and allocates a new IP address to the UE; after that, it also establishes for the UE. The user plane information and the assigned IP address are sent to the new MME/UPE. Both the user plane information and the IP address can be carried to the new MME/UPE by being carried in a Create context response.

Step 709: The new MME/UPE sends a Delete PDP context request to the old MME/UPE for the UE.

Step 710: The old MME/UPE sends a Delete PDP context request from the new MME/UPE to the old anchor that the UE communicates with the UE before initiating the location area update.

Step 711: The old anchor deletes the stored UE Context when receiving the Delete PDP context request forwarded by the old MME/UPE, and returns a Delete PDP context response to the old MME/UPE.

Step 712: The old MME/UPE sends the Delete PDP context response from the old Anchor to the new MME/UPE.

Step 713: The new MME/UPE sends an Update Location message to the HSS, which may include the UE's International Mobile Subscriber Identity (IMSI), Cancellation Type, and the like.

Step 714: The HSS sends a location cancel request for the UE to the old MME/UPE.

Step 715: The old MME/UPE deletes the stored UE location information when receiving the Cancel location request from the HSS, and returns a Cancel location Ack to the HSS.

Step 716 to step 718: The HSS carries the subscription data of the UE to the inserted user data. (Insert Subscriber Data) request is sent to the new MME/UPE; when the new MME/UPE receives the Insert Subscriber Data request from the HSS, it confirms that the UE is in the new location area, creates a new context for the UE, and also returns the insertion to the HSS. The Subscribe Subscriber Data Ack message; after receiving the Insert Subscriber Data Ack message from the new MME/UPE, the HSS returns an Update Location Ack message to the new MME/UPE.

Step 719: The new MME/UPE sends the new anchor to the user plane information and the assigned IP address established by the UE. The user plane information and the IP address may be carried in the TA update accept message to the UE, and the user plane information may include a new P-TMSI, a new TAI, etc. for the UE.

Step 720: After receiving the IP address from the new MME/UPE, the UE returns a location update completion (TA update Complete) message to the new MME/UPE.

Step 721: The UE configures its own IP layer related parameters according to the received user plane information and the IP address, and uses the IP address to apply the existing technology to register with an upper service network such as IMS. Embodiment 2: MME and UPE are combined into one logical entity MME/UPE, and MME/UPE is not reselected;

Referring to FIG. 8, FIG. 8 is a flowchart of mobility management according to Embodiment 2 of the present invention, and the process includes the following steps:

Step 801: The UE that performs the location area update sends a TAU Request to the MME/UPE that has been serving it.

Step 802: The MME/UPE determines, by using a logical judgment, that the UE needs to perform an Anchor migration.

Step 803: After determining that the UE needs to perform an Anchor migration, the MME/UPE may enter The authentication authentication process that is currently common to the UE between the UE and the HSS is performed in one step.

Of course, in the actual application, the authentication and authentication process may not be performed, but directly proceeds to step 804.

Step 804: The MME/UPE sends a Create context request to the new anchor to which the UE is to be migrated, and requests the new Anchor to allocate a new IP address to the UE.

Step 805: The new Anchor establishes corresponding user plane information for the UE when receiving the Create context request from the MME/UPE, and allocates a new IP address to the UE. After that, the user plane information and the allocated IP address that are established for the UE are also The address is sent to the MME/UPE. Both the user plane information and the IP address can be carried in the Create context response and sent to the MME/UPE.

Step 806: The MME/UPE sends a Delete PDP context request for the UE to the old anchor.

Step 807: The old anchor deletes the stored UE Context when receiving the Delete PDP context request from the MME/UPE, and returns a Delete PDP context response to the MME/UPE.

Step 808: The MME/UPE sends the UE to the user plane information and the assigned IP address established by the new anchor. The user plane information and the IP address may be carried in a TA update accept message and sent to the UE.

Step 809: After receiving the IP address from the MME/UPE, the UE returns a TA update Complete message to the MME/UPE.

Step 810: The UE configures its own IP layer related parameters according to the received user plane information and the IP address, and uses the IP address to apply the existing technology to register with an upper service network such as IMS. Embodiment 3: The MME and the UPE are separated into two logical entities, and the UPE and the Anchor are combined into one logical entity UPE/Anchor; and, the MME is reselected;

Referring to FIG. 9, FIG. 9 is a flowchart of mobility management according to Embodiment 3 of the present invention, and the process includes the following steps:

Step 901: The UE that performs the location area update sends a TAU Request to the new MME in the location area in which it is located.

Step 902: The new MME sends a Context request for the UE to the old MME according to the received TAU Request. Give the new MME.

Step 904: The new MME determines, by using a logical judgment, that the UE needs to perform Anchor migration. Step 905: After determining that the UE needs to perform the anchor migration, the new MME may further perform a current authentication authentication process with the UE and even the HSS for the UE.

Of course, in the actual application, the authentication and authentication process may not be performed, but directly proceeds to step 906.

Step 906: After receiving the Context response from the old MME, the new MME may further return a context Acknowledge to the old MME. In actual application, it is also possible not to perform this step, but directly proceeds to step 907.

Step 907: The new MME sends a Create context request to the new UPE/Anchor to which the UE is to be migrated, and requests the new UPE/Anchor to allocate a new IP address to the UE.

Step 908: The new UPE/Anchor establishes corresponding user plane information for the UE when receiving the Create context request from the new MME, and allocates a new IP address to the UE. After that, the user plane information and the allocated user plane are also established for the UE. The IP address is sent to the new MME. Both the user plane information and the IP address may be carried in the Create context response and sent to the new MME. Step 909: The new MME notifies the old UPE/Anchor to delete the UE Context.

The specific deletion operation is usually: the new MME sends a Delete PDP context request for the UE to the old MME; the old MME takes the Delete PDP context request from the new MME and sends it to the old UPE/Anchor; the old UPE/Anchor receives the forwarding from the old MME. The Delete PDP context request deletes the stored UE Context and returns a Delete PDP context response to the old MME; the old MME sends the Delete PDP context response from the old UPE/Anchor to the new MME.

Step 910: The new MME sends an Update location message to the HSS.

Step 911: The HSS sends a Cancel location request for the UE to the old MME. Step 912: The old MME deletes the stored UE location information when receiving the Cancel location request from the HSS, and returns a Cancel location Ack to the HSS.

Step 913 to step 915: The HSS carries the subscription data of the UE in the Insert Subscriber Data request and sends it to the new MME. When the new MME receives the Insert Subscriber Data request from the HSS, the new MME confirms that the UE is located in the new location area, and creates a new location for the UE. The context also returns an Insert Subscriber Data Ack message to the HSS. After receiving the Insert Subscriber Data Ack message from the new MME, the HSS returns an Update location Ack message to the new MME.

Step 916: The new MME sends the UE to the new UPE/Anchor for the user plane information and the assigned IP address established by the UE. The user plane information and the IP address may be carried in a TA update accept message and sent to the UE.

Step 917: After receiving the IP address from the new MME, the UE returns a TA update Complete message to the new MME.

Step 918: The UE configures its own IP layer related parameters according to the received user plane information and IP address, and uses the IP address to apply the existing technology to register with an upper layer service network such as IMS. Embodiment 4: The MME and the UPE are separated into two logical entities, and the UPE and the Anchor are combined into one logical entity UPE/Anchor; and, the MME is not reselected;

Referring to FIG. 10, FIG. 10 is a flowchart of mobility management according to Embodiment 4 of the present invention, where the process includes the following steps:

Step 1001: The UE that performs the location area update sends a TAU Request to the MME that has been serving it.

Step 1002: The MME determines, by using logic, that the UE needs to perform Anchor migration. Step 1003: After determining that the UE needs to perform the anchor migration, the MME may further perform a current authentication authentication process with the UE and even the HSS for the UE.

Of course, in the actual application, the authentication and authentication process may not be performed, but the process directly proceeds to step 1004.

Step 1004: The MME sends a Create context request to the new UPE/Anchor to which the UE is to be migrated, and requests the new UPE/Anchor to allocate a new IP address to the UE.

Step 1005: The new UPE/Anchor establishes corresponding user plane information for the UE when receiving the Create context request from the MME, and allocates a new IP address to the UE. After that, the user plane information and the allocated IP address that are established for the UE are also The address is sent to the MME. Both the user plane information and the IP address can be carried in the Create context response and sent to the MME.

Step 1006: The MME sends a Delete PDP context request for the UE to the old UPE/Anchor.

Step 1007: The old UPE/Anchor deletes the stored UE Context when receiving the Delete PDP context request from the MME, and returns a Delete PDP context response to the MME.

Step 1008: The MME sends the new UPE/Anchor to the UE for the user plane information and the assigned IP address established by the UE. The user plane information and IP address can be carried in TA update The accept message is sent to the UE.

Step 1009: After receiving the IP address from the MME, the UE returns a TA update Complete message to the MME.

Step 1010: The UE configures its own IP layer related parameters according to the received user plane information and the IP address, and uses the IP address to apply the existing technology to register with an upper service network such as IMS. Embodiment 5: The MME, the UPE, and the anchor are separated into three logical entities respectively; the MME is reselected, and the UPE migration does not occur;

Referring to FIG. 11, FIG. 11 is a flowchart of mobility management according to Embodiment 5 of the present invention, and the process includes the following steps:

Step 1101: The UE that performs the location area update sends a TAU Request to the new MME in the location area in which it is located.

Step 1102: The new MME sends a Context request for the UE to the old MME according to the received TAU Request. Send it to the new MME.

Step 1104: The new MME determines, by using a logical judgment, that the UE needs to perform an anchor migration. Step 1105: After determining that the UE needs to perform the anchor migration, the new MME may further perform a current authentication authentication process with the UE and even the HSS for the UE.

Of course, in the actual application, the authentication and authentication process may not be performed, but directly proceeds to step 1106.

Step 1106: After receiving the Context response from the old MME, the new MME may further return the context Acknowledge < to the old MME. In actual application, the operation may not be performed, but directly proceeds to step 1107. Step 1107: The new MME interacts with the new Anchor to which the UE is to be migrated, and the new Anchor establishes a new user plane for the UE and allocates a new IP address.

The specific operation is as follows: the new MME sends a Create context request to the new Anchor, and requests the new Anchor to allocate a new IP address to the UE. When the new Anchor receives the Create context request from the new MME, it establishes corresponding user plane information for the UE and allocates the UE information. The new IP address is also sent to the new MME for the user plane information established by the UE and the assigned IP address. Both the user plane information and the IP address can be carried in the Create context response and sent to the new MME.

Step 1108: The new MME notifies the old Anchor to delete the UE Context.

The specific deletion operation is usually: the new MME sends a Delete PDP context request for the UE to the old MME; the old MME takes the Delete PDP context request from the new MME and sends it to the old Anchor; the old Anchor receives the Delete PDP context request forwarded by the old MME. The stored UE Context is deleted, and the Delete PDP is returned to the old MME and sent to the new MME.

Step 1109: The new MME sends an Update location message to the HSS.

Step 1110: The HSS sends a Cancel location request for the UE to the old MME. Step 1111: The old MME deletes the stored UE location information when receiving the Cancel location request from the HSS, and returns a Cancel location Ack to the HSS.

Step 1112 to step 1114: The HSS carries the subscription data of the UE in the Insert Subscriber Data request and sends it to the new MME. When the new MME receives the Insert Subscriber Data request from the HSS, the new MME confirms that the UE is located in the new location area, and creates a new location for the UE. The context also returns an Insert Subscriber Data Ack message to the HSS. After receiving the Insert Subscriber Data Ack message from the new MME, the HSS returns an Update location Ack message to the new MME. Step 1115: The new MME sends the new Anchor to the UE for the user plane information and the assigned IP address established by the UE. The user plane information and the IP address may be carried in the TA update accept message and sent to the UE.

Step 1116: After receiving the IP address from the new MME, the UE returns a TA update Complete message to the new MME.

Step 1117: The user plane information and the IP address received by the UE are configured with their own IP layer related parameters, and the existing technology is used to register with the upper service network such as IMS. Embodiment 6: The MME, the UPE, and the Anchor are separated into three logical entities, and the MME is not reselected, and no UPE migration occurs.

Referring to FIG. 12, FIG. 12 is a flowchart of mobility management according to Embodiment 6 of the present invention, where the process includes the following steps:

Step 1201: The UE that performs the location area update sends a TAU Request to the MME that has been serving it.

Step 1202: The MME determines, by using logical judgment, that the UE needs to perform Anchor migration. Step 1203: After determining that the UE needs to perform the anchor migration, the MME may further perform a current authentication authentication process with the UE and even the HSS for the UE.

Of course, in the actual application, the authentication and authentication process may not be performed, but directly proceeds to step 1204.

Step 1204: The MME interacts with the new anchor to which the UE is to be migrated, and the new anchor establishes a new user plane for the UE and allocates a new IP address.

The specific operation is as follows: The MME sends a Create context request to the new Anchor, and requests the new Anchor to allocate a new IP address to the UE. The new Anchor establishes corresponding user plane information for the UE when receiving the Create context request from the MME, and allocates a new IP address for the UE. address, The user plane information established for the UE and the assigned IP address are also sent to the MME. Both the user plane information and the IP address may be carried in the Create context response and sent to the MME.

Step 1205: The MME notifies the old Anchor to delete the UE Context.

The specific deletion operation is usually: the MME sends a Delete PDP context request for the UE to the old anchor; the old Anchor deletes the stored UE Context when receiving the Delete PDP context request from the MME, and returns a Delete PDP context response to the MME.

Step 1206: The MME sends the new anchor to the user plane information and the assigned IP address established by the UE. The user plane information and the IP address may be carried in a TA update accept message and sent to the UE.

Step 120 ⁷ : After receiving the IP address from the MME, the UE returns a TA update Complete message to the MME.

Step 1208: The UE configures its own IP layer related parameters according to the received user plane information and the IP address, and uses the IP address to apply the existing technology to register with an upper service network such as IMS. Embodiment 7: MME, UPE, and Anchor are separated into three logical entities respectively; the MME is reselected and UPE migration occurs;

Referring to FIG. 13, FIG. 13 is a flowchart of mobility management according to Embodiment 7 of the present invention, where the process includes the following steps:

Step 1301: The UE that performs the location area update sends a TAU Request to the new MME in the location area in which it is located.

Step 1302: The new MME sends a Context request for the UE to the old MME according to the received TAU Request. Step 1303: Old

Send it to the new MME.

Step 1304: The new MME determines, by using a logical judgment, that the UE needs to perform Anchor migration. Step 1305: After determining that the UE needs to perform the anchor migration, the new MME may further perform a current authentication authentication process with the UE and even the HSS for the UE.

Of course, in the actual application, the authentication and authentication process may not be performed, but the process directly proceeds to step 1306.

Step 1306: After receiving the Context response from the old MME, the new MME may further return the context Acknowledge < to the old MME. In actual application, the operation may not be performed, but the process directly proceeds to step 1307.

Step 1307: The new MME selects a new UPE to be served by the UE, and interacts with the new anchor to which the UE is to be migrated. The new anchor establishes a new user plane for the UE and allocates a new IP address. Specifically, the new MME selects the new UPE in multiple ways, for example, the new MME obtains the load of each UPE, and determines that the lightest UPE is the new UPE to be served by the UE; or, the new MME obtains each UPE. A route metric with the UE, and determining, according to the obtained route metric, that the route optimal with the UE is a new UPE to be served for the UE.

Of course, the new MME can also consider the UPE load and the route metric. For example, the new MME obtains the load of each UPE and selects the lightest UPE, and then obtains the route metric between the UPE and the UE and determines the obtained metric. Whether the route metric is lower than a preset route metric bottom limit, and determining that the UPE is a new UPE to be served by the UE only when the judgment result is not lower; or, the new MME acquires a route metric between each UPE and the UE and The UPE that is optimally routed to the UE is selected according to the obtained route metric, and the load of the UPE is obtained, and it is determined whether the acquired load is higher than a preset load limit, and the UPE is determined only when the judgment result is not higher. Is the new UPE to serve the UE.

Step 1308: The new MME notifies the old Anchor to delete the UE Context. This step The same as the operation of step 1008.

Step 1309: The new MME sends an Update location message to the HSS.

Step 1310: The HSS sends a Cancel location request for the UE to the old UPE. Step 1311: The old UPE deletes the stored UE location information when receiving the Cancel location request from the HSS, and returns a Cancel location Ack to the HSS.

Step 1312 to step 1314: The HSS carries the subscription data of the UE in the Insert Subscriber Data request and sends it to the new MME. When the new MME receives the Insert Subscriber Data request from the HSS, the new MME confirms that the UE is located in the new location area, and creates a new location for the UE. The context also returns an Insert Subscriber Data Ack message to the HSS. After receiving the Insert Subscriber Data Ack message from the new MME, the HSS returns an Update location Ack message to the new MME.

Step 1315: The new MME sends the UE to the user plane information and the assigned IP address established by the new anchor. The user plane information and the IP address may be carried in a TA update accept message and sent to the UE.

Step 1316: After receiving the IP address from the new MME, the UE returns a TA update Complete message to the new MME.

Step 1317: The UE configures its own IP layer related parameters according to the received user plane information and the IP address, and uses the existing IP address to register with the upper service network such as IMS.

The method of selecting a new UPE as described in FIG. 13 can also be applied to other flowcharts as long as there is an operation in the flowchart involving a new UPE to be served to the UE. Embodiment 8: MME, UPE, and Anchor are separated into three logical entities respectively; the MME is not reselected and UPE migration occurs;

Referring to FIG. 14, FIG. 14 is a flowchart of mobility management according to Embodiment 8 of the present invention. Includes the following steps:

Step 1401: The UE that performs the location area update sends a TAU Request to the MME that has been serving it.

Step 1402: The MME determines, by using logic, that the UE needs to perform Anchor migration. Step 1403: After determining that the UE needs to perform the anchor migration, the MME may further perform a current authentication authentication process with the UE and even the HSS for the UE.

Of course, in the actual application, the authentication and authentication process may not be performed, but the process directly proceeds to step 1404.

Step 1404: The MME selects a new UPE to be served for the UE, and interacts with the new anchor to which the UE is to be migrated. The new anchor establishes a new user plane for the UE and allocates a new IP address.

Step 1405: The MME notifies the old Anchor to delete the UE Context.

Step 1406: The MME sends the UE to the user plane information and the assigned IP address established by the new anchor. The user plane information and the IP address may be carried in a TA update accept message and sent to the UE.

Step 140 ⁷ : After receiving the IP address from the MME, the UE returns a TA update to the MME.

Complete message.

Step 1408: The UE configures its own IP layer related parameters according to the received user plane information and the IP address, and uses the IP address to apply the existing technology to register with an upper service network such as IMS.

In the above-mentioned FIG. 7 to FIG. 14 , when the MME and the UPE are reselected, whether the MME is combined with the UPE as a logical entity, the old MME may be further included in the process of deleting the UE Context by the new Anchor. , the old UPE deletes the saved UE Context

Furthermore, the MME interacts with the new Anchor to enable the new Anchor to establish a user plane and allocate for the UE. The operation of the IP address is usually performed by the UPE; the UPE is the UPE that has been serving the UE, or the new UPE that is selected to serve the UE. Specifically, the MME needs to establish a user plane for the UE and allocate an IP address through the UPE, and the user plane generally refers to a user plane between the UPE and the new Anchor to support UE communication, and establish the user plane. The UPE and the new Anchor are required to communicate and negotiate with each other. The user plane information and IP address to be sent to the UE are also forwarded to the MME through the UPE and then sent to the UE.

In the actual application, when the MME, UPE, and Anchor are separated into three logical entities, the processes shown in FIG. 15 to FIG. 19 can also be performed.

Specifically, in FIG. 15 to FIG. 19, there may be a case where the MME and/or the UPE are reselected, which makes the mobility management process different in different situations, and even different communication entities may be performed for the same message structure. The case of logical operations; however, it should be noted that the operations performed by different communicating entities for the same message structure usually do not change much. Embodiment 9: UPE migration occurs but MME is not reselected;

Referring to FIG. 15, FIG. 15 is a flowchart of mobility management according to Embodiment 9 of the present invention, and the process includes the following steps:

Step 1501: The UE sends a TAU Request to the LTE-RAN, and the LTE-RAN adds the location area identifier of the UE in the message header of the TAU Request to the MME that has been serving the UE.

Step 1502: The MME and the UE perform a current common security authentication process, and the security authentication process is similar to the previously described authentication authentication process, and is to determine whether the UE is eligible to receive the service.

Of course, in the actual application, the security authentication process may not be performed, but the UE may be served by default, and then directly proceeds to step 1503. Step 1503: The MME determines, by using a logical judgment, that the UE needs to perform an Anchor migration, and then sends a Delete Session Context Request carrying the UE identifier to the old Anchor.

Step 1504: When receiving the Delete Session Context Request from the MME, the old anchor releases the resources occupied by the UE according to the UE identifier included therein, and then sends a Delete Session Context Response to the MME. The resources occupied by the UE usually include an IP address, a data channel resource, and the like.

Step 1505: The MME selects a new UPE to be served by the UE, and sends a Deactivate Session Context Request carrying the UE identifier to the old UPE.

Step 1506: The old UPE receives the Deactivate Session Context from the MME and returns a Deactivate Session Context Response to the MME.

Step 1507: The MME sends an Activate Session Context Request to the new UPE, where the request includes a UE identifier, a QoS (Quality of Service), a UE capability, an encryption key, and the like.

Step 1508: When the new UPE receives the Activate Session Context Request from the MME, the new UPE selects the force to be used according to the UE capability contained therein and the encryption algorithm supported by itself. The secret algorithm allocates the transmission channel resource to the UE according to the QoS included in the Activate Session Context Request, and then carries the transmission channel resource and the selected encryption algorithm and the like in the Activate Session Context Response (Activate Session Context Response) Send to the MME.

Taking the General Packet Radio Service Tunneling Protocol (GTP) tunnel as an example, the transmission channel resources allocated for the UE usually include new UPE reception from the new The IP address, port, and tunnel end identifier (TEID) used by Anchor's downlink data also include the IP address, port, and TEID used by the new UPE to receive upstream data from the LTE-RAN.

Step 1509: The MME saves the parameters included in the Activate Session Context Response, and sends a Create Session Context Request to the new Anchor. The request usually carries the UE identifier, the QoS required to establish the bearer, and the new UPE is The parameters such as the channel identifier assigned by the downlink data of the new Anchor are received.

The GTP tunnel is used as an example. The parameters carried in the Create Session Context Request include the IP address, port, and TEID used by the new UPE to receive the downlink data of the new anchor.

Step 1510: When the new Anchor receives the Create Session Context Request from the MME, it allocates an IP address for the bearer to be newly created, and allocates the QoS allocation data transmission channel resource in the Create Session Context Request, and then allocates the IP address and data. The transport channel resource is carried in the Create Session Context Response and sent to the MME. The Create Session Context Response usually includes the allocated IP, the QoS that the new Anchor can allow, and the allocated data transmission channel resources.

Taking the GTP tunnel as an example, the parameters carried in the Create Session Context Response include: The new anchor uses the newly created bearer to receive the IP address, port, and TEID used for the uplink data from the new UPE.

Step 1511: The MME saves the parameters included in the Create Session Context Response from the new Anchor, and applies the existing technology to initiate the radio access bearer setup process to the LTE-RAN, and receives the received QoS and the new UPE as the uplink from the LTE-RAN. The data channel resource identifier assigned by the data is notified to the LTE-RAN.

Taking a GTP tunnel as an example, the new UPE is configured to receive the data channel resource identifier from the LTE-RAN uplink data. The new UPE is received by the newly created bearer. IP address, port, and TEID used when LTE-RAN uplink data.

The LTE-RAN completes the air interface bearer setup according to the QoS application prior art and the UE negotiation from the MME; and allocates the data channel resource for receiving the downlink data from the new UPE, and also negotiates the successful QoS and the allocated downlink data channel resource. The identity is returned to the MME.

Taking the GTP tunnel as an example, the downlink data channel resource identifier is usually: an IP address, a port, and a TEID used by the LTE-RAN to receive downlink data from the new UPE.

Step 1512: The MME saves information such as the negotiated QoS returned by the LTE-RAN and the allocated downlink data channel resource identifier, and the final determined QoS, the LTE-RAN is allocated to receive the downlink data from the new UPE. The data channel resource identifier is carried in the Update Session Context message and the message is sent to the new UPE.

Taking the GTP tunnel as an example, the data channel resource identifier allocated by the LTE-RAN to receive downlink data from the new UPE is generally: The IP address, port, and TEID used by the LTE-RAN to receive downlink data from the new UPE.

In a certain step of the above operation, the new anchor also allocates a new IP address for subsequent communication to the UE, and notifies the MME of the IP address.

Step 1513: The MME sends a TA Update Accept message to the UE, where the message includes an IP address allocated by the new Anchor for the UE, an IP address corresponding to the bearer established to support the UE communication, and a data encryption algorithm used by the terminal specified by the new UPE. User temporary identity, etc.

Step 1514: The UE returns a TA Update Complete message to the MME, and notifies the MME that the newly assigned IP address and the temporary identifier of the user identity are received.

After the UE receives the IP address assigned to it, it uses the IP address to apply the existing technology to initialize the IP link layer. At this point, the UE can successfully communicate with the new Anchor.

Of course, the UE may further apply the existing technology to perform in an upper layer service network such as IMS. Registration process.

It can be seen that, in the embodiment 9, the operation of creating or deleting an IP bearer is controlled by the MME, and no signaling interaction involving the creation of an IP bearer is performed between the UPE and the anchor.

In an actual application, the establishment or release of an IP bearer can also be completed by interacting between the UPE and the anchor as in Embodiment 10.

Referring to FIG. 16, FIG. 16 is a flowchart of mobility management according to Embodiment 10 of the present invention, where the process includes the following steps:

Step 1601: The UE sends a TAU Request to the MME that has been serving the UE through the LTE-RAN.

Step 1602: The MME and the UE perform a current common security authentication process. Of course, in the actual application, the security authentication process may not be performed, but directly proceeds to step 1603.

Step 1603: The MME determines, by using a logical judgment, that the UE needs to perform the anchor migration. The MME also selects a new UPE to be served by the UE, and sends a Deactivate Session Context Request to the old UPE.

Step 1604: The old UPE releases the user plane resource allocated to the UE when receiving the Deactivate Session Context Request from the MME, and sends a Delete Session Context Request to the old anchor.

Step 1605: The old Anchor releases the resources occupied by the UE when receiving the Delete Session Context Request from the old UPE, and then sends a Delete Session Context Response to the old UPE.

Step 1606: The old UPE sends a Deactivate Session Context Response ₀ to the MME when receiving the Deactivate Session Context Request from the old Anchor.

Step 1607: When the MME receives the Deactivate Session Context Response from the old UPE, the MME sends an Activate Session Context Request to the new UPE. Step 1608: The new UPE receives the transmission channel resource and performs the encryption algorithm selection for the UE when receiving the Activate Session Context Request from the MME. Moreover, the new UPE sends a Create Session Context Request to the new Anchor.

Step 1609: When the new Anchor receives the Create Session Context Request from the new UPE, allocates an IP address for the newly created bearer and allocates a data transmission channel resource, and then carries the allocated IP address and the data transmission channel resource to the Create Session Context. The Response is sent to the new UPE.

Step 1610: The new UPE saves the parameters contained in the Create Session Context Response from the new Anchor, and allocates the transmission channel resources and forces that have been allocated to the UE. Parameters such as the secret algorithm are carried in the Activate Session Context Response and sent to the MME.

Step 1611: The MME saves the parameters included in the Activate Session Context Response from the new UPE, and applies the existing technology to initiate a radio access bearer establishment process to the LTE-RAN.

Step 1612: The MME saves the parameters related to establishing the bearer with the LTE-RAN, and carries the parameters in the Update Session Context message and sends the parameters to the new UPE.

Step 1613: The MME sends a TA Update Accept message containing at least the newly assigned IP address to the UE.

Step 1614: The UE returns a TA Update Complete message to the MME, and notifies the MME that the newly assigned IP address and other parameters are received.

As can be seen from the above, the key difference between Figure 15 and Figure 16 is that the method of creating an IP bearer is different.

In practical applications, the time sequence between creating and deleting IP bearers may be different from the corresponding order in FIG. 15 and FIG. 16, as shown in Embodiment 11.

Referring to FIG. 17, FIG. 17 is a flowchart of mobility management according to Embodiment 11 of the present invention, and the process includes the following steps:

Step 1701: The UE sends a TAU Request to the MME that has been serving the UE through the LTE-RAN.

Step 1702: The MME and the UE perform a current common security authentication process. Of course, in the actual application, the security authentication process may not be performed, but the process directly proceeds to step 1703.

Step 1703: The MME determines, by using logical judgment, that the UE needs to perform Anchor migration; the MME also selects a new UPE to be served for the UE, and sends an Activate Session Context Request to the new UPE.

Step 1704: When receiving the Activate Session Context Request from the MME, the new UPE selects an encryption algorithm to be used and allocates a transmission channel resource to the UE, and then carries the transmission channel resource and the selected encryption algorithm and other parameters in the Activate Session Context Response. Sent to the MME.

Step 1705: The MME saves the parameters included in the Activate Session Context Response and sends a Create Session Context Request to the new Anchor.

Step 1706: When the new Anchor receives the Create Session Context Request from the MME, allocates an IP address to the newly created bearer and allocates a data transmission channel resource, and then carries the allocated IP address and the data transmission channel resource in the Create Session Context Response. Send to the MME. Step 1707: The MME saves the parameters included in the Create Session Context Response from the new Anchor, and applies the existing technology to initiate a radio access bearer setup process to the LTE-RAN.

Step 1708: The MME saves the parameters related to establishing the bearer with the LTE-RAN, and carries the parameters in the Update Session Context message and sends the parameters to the new UPE.

Step 1709: The MME sends a Delete Session Context Request to the old anchor. Step 1710: The old anchor releases the resources occupied by the UE when receiving the Delete Session Context Request from the MME, and then sends a Delete Session Context Response to the MME.

Step 1711: The MME sends a Deactivate Session Context Request. to the old UPE, step 1712: The old UPE receives the Deactivate Session Context from the MME.

Release the user plane resource allocated to the UE when Request, and return Deactivate to the MME.

Session Context Response.

Step 1713: The MME sends a TA Update to the UE that includes at least the newly assigned IP address.

Accept message.

Step 1714: The UE returns a TA Update Complete message to the MME, and notifies the MME that the newly assigned IP address and other parameters are received.

Of course, the UE can further apply the prior art to perform a registration process in an upper layer service network such as IMS. Embodiment 12: A UPE migration occurs and the MME is reselected;

FIG. 18 is a flowchart of mobility management according to Embodiment 12 of the present invention, where the process includes the following steps: Step 1801: The UE sends a TAU Request to the LTE-RAN, and the LTE-RAN selects a new MME to be served by the UE, and adds the location area identifier of the current location of the UE to the new MME.

Step 1802: The new MME searches for the address of the old MME registered before the UE initiates the location area update according to the location area identifier in the received TAU Request, and sends a Context request for the UE to the old MME according to the address. Moreover, the new MME determines by logic that the UE needs to perform Anchor migration, and the new MME also selects a new UPE to be served for the UE. Send it to the new MME.

Step 1804: The new MME and the UE perform a current common security authentication process. Of course, in the actual application, the security authentication process may not be performed, but directly proceeds to step 1805.

Step 1805: The new MME performs a location update process for the UE and the HSS application prior art.

The specific operation is usually: the new MME sends an Update location message for the UE to the HSS; the HSS sends a Cancel location request for the UE to the old MME; the old MME deletes the stored UE location information when receiving the Cancel location request from the HSS, and The HSS returns the Cancel location Ack. Afterwards, the HSS carries the subscription data of the UE in the Insert Subscriber Data request and sends it to the new MME. When the new MME receives the Insert Subscriber Data request from the HSS, the new MME confirms that the UE is located in the new location area and is the UE. A new context is created, and an Insert Subscriber Data Ack message is also returned to the HSS. After receiving the Insert Subscriber Data Ack message from the new MME, the HSS returns an Update location Ack message to the new MME.

In FIG. 15 to FIG. 17, the new MME may also perform the above location for the UE and the HSS. Update process.

Step 1806: When receiving the Cancel location request from the HSS, the old MME sends a Deactivate Session Context Request to the old UPE served by the UE before initiating the location area update to the UE.

Step 1807: The old UPE releases the user plane resource allocated to the UE when receiving the Deactivate Session Context Request from the old MME, and returns a Deactivate Session Context Response to the old MME.

Step 1808: The new MME sends a Delete Session Context Request to the old anchor that the UE communicates with the UE before initiating the location area update.

Step 1809: The old anchor releases the resources occupied by the UE when receiving the Delete Session Context Request from the MME, and then newly sends a Delete Session Context Response to the MME.

Step 1810: The new MME sends an Activate Session Context Request < to the new UPE. Step 1811: When the new UPE receives the Activate Session Context Request from the new MME, selects an encryption algorithm to be used and allocates a transmission channel resource to the UE, and then transmits the transmission channel. The parameters such as the resource and the selected encryption algorithm are carried in the Activate Session Context Response and sent to the new MME.

Step 1812: The new MME saves the parameters included in the Activate Session Context Response and sends a Create Session Context Request to the new Anchor.

Step 1813: When the new Anchor receives the Create Session Context Request from the new MME, allocates an IP address to the newly created bearer and allocates a data transmission channel resource, and then carries the allocated IP address and the data transmission channel resource in the Create Session Context Response. Sent to the new MME.

Step 1814: The new MME saves the parameters included in the Create Session Context Response from the new Anchor, and applies the existing technology to initiate wireless access to the LTE-RAN. The bearer establishment process.

Step 1815: The new MME saves the parameters related to establishing the bearer with the LTE-RAN, and carries the parameters in the Update Session Context message and sends the parameters to the new UPE.

In a certain step of the above operation, the new anchor also allocates a new IP address for subsequent communication to the UE, and notifies the new MME of the IP address.

Step 1816: The new MME sends a TA Update Accept message containing at least the newly assigned IP address to the UE.

Step 1817: The UE returns a TA Update Complete message to the new MME, and notifies the new MME that the newly assigned IP address and other parameters are received.

Of course, the UE can further apply the prior art to perform a registration process in an upper layer service network such as IMS. Example 13: UPE is not migrated and MME is not reselected;

Referring to FIG. 19, FIG. 19 is a flowchart of mobility management according to Embodiment 13 of the present invention, where the process includes the following steps:

Step 1901: The UE sends a TAU Request to the MME that has been serving the UE through the LTE-RAN.

Step 1902: The MME and the UE perform a current common security authentication process. Of course, in the actual application, the security authentication process may not be performed, but the process directly proceeds to step 1803.

Step 1903: The MME determines, by using logical judgment, that the UE needs to perform an Anchor migration, and sends a Delete Session Context Request to the old Anchor that communicates with the UE before initiating the location area update to the UE. Step 1904: The old Anchor releases the resources occupied by the UE when receiving the Delete Session Context Request from the MME, and then sends a Delete Session Context Response to the MME.

Step 1905: The MME sends a Deactivate Session Context Request to the UPE. Step 1906: The UPE releases the user plane resource allocated to the UE when receiving the Deactivate Session Context Request from the MME, and returns a Deactivate Session Context Response to the MME.

Step 1907: The MME sends an Activate Session Context Request to the UPE. Step 1908: When receiving the Activate Session Context Request from the MME, the UPE selects an encryption algorithm to be used and allocates a transmission channel resource to the UE, and then carries the transmission channel resource and the selected encryption algorithm and other parameters in the Activate Session Context Response. And sending to the MME to ensure that the transmission channel resource and the encryption algorithm can support a normal communication process performed after the UE updates the location area.

Step 1909: The MME saves the parameters included in the Activate Session Context Response and sends a Create Session Context Request to the new Anchor.

Step 1910: When the new Anchor receives the Create Session Context Request from the MME, allocates an IP address to the newly created bearer and allocates a data transmission channel resource, and then carries the allocated IP address and the data transmission channel resource in the Create Session Context Response. Send to the MME.

Step 1911: The MME saves the parameters included in the Create Session Context Response from the new Anchor, and applies the existing technology to initiate a radio access bearer establishment process to the LTE-RAN.

Step 1912: The MME saves parameters related to establishing a bearer with the LTE-RAN, and carries the parameters in the Update Session Context message and sends the parameters to the UPE.

In a step of the above operation, the new Anchor is also allocated for the UE for subsequent The new IP address of the communication, and notifies the MME of the IP address.

Step 1913: The MME sends a TA Update Accept message including at least the newly assigned IP address to the UE.

Step 1914: The UE returns a TA Update Complete message to the MME, and notifies the MME that the newly assigned IP address and other parameters are received.

Of course, the UE can further apply the prior art to perform a registration process in an upper layer service network such as IMS.

In Figure 19, the MME may also perform a location update procedure for the UE and HSS application prior art.

It can be seen that the steps of deleting the session context request, deleting the session context response, deactivating the session context request and deactivating the session context response in FIG. 15 to FIG. 19 complete the foregoing operation of notifying the old Anchor to delete the UE Context; activating the session context request, activating The steps of the session context response, the creation of the session context request, and the creation of the session context response complete the aforementioned operation of notifying the new Anchor to establish a new user plane for the UE.

In fact, in FIG. 7 to FIG. 14, the radio access bearer setup procedure shown in FIG. 15 to FIG. 19 is also performed; the radio access bearer setup procedure is not indicated in FIG. 7 to FIG. 14, just because the process It is not a key part to be described in Figures 7 to 14. In an actual application, when the radio access bearer setup process is completed, the IP address allocated to the UE may be sent to the UE through the established radio access bearer.

It can be known from the mobility management brief flow shown in FIG. 4 and FIG. 5 and the embodiments of FIG. 7 to FIG. 19 whether or not the MME is reselected, whether the UPE is migrated, and at least the MME, the UPE, and the Anchor. Whether the two communication entities are combined into one logical entity, the mobility management method of the present invention can select the Anchor that is most beneficial for communication for the UE; When the UE communicates with the Anchor, there is no shortage of network transmission resources and increased communication delay in the prior art, but the network transmission resources are saved, and the communication delay is effectively reduced, thereby significantly improving the UE. Communication quality, which in turn significantly increases user satisfaction.

It should be noted that the operation of the Anchor that is most advantageous for communication is triggered by the location area update operation initiated by the UE. In an actual application, the UE may also periodically initiate an anchor migration. It is judged that the command is triggered or triggered by a transition between the active state and the idle state of the UE.

In the following, the embodiment 14 to the embodiment 16 are directed to the Anchor migration situation triggered by the Network Server or the Anchor, and specifically describes the process of performing Anchor migration on the UE in the idle state initiated by the core network side. Embodiment 14: The MME and the UPE are combined into one logical entity MME/UPE.

Referring to FIG. 20, FIG. 20 is a flowchart of mobility management according to Embodiment 14 of the present invention, where the process includes the following steps:

Step 2001: The MME/UPE determines by logic, or the old anchor determines the UE in the idle state that needs to perform the anchor migration by logically determining or receiving the relevant trigger command from the outside.

In this step, one of the three methods described in step 601 of FIG. 6 may be used to determine whether there is an idle UE in the old anchor that needs to perform anchor migration. If so, the idle UEs that need to perform the Anchor migration can be determined in a corresponding manner and the new Anchor to which the UE is to be migrated is determined.

Step 2002: After the old Anchor determines the UE that needs to perform the Anchor migration, it sends an Anchor Relocation Request to the MME/UPE. The anchor migration request may carry parameters of the UE that needs to migrate the Anchor. Step 2003: The MME/UPE returns an Anchor Relocation Response to the old Anchor.

In the above step 2001, if it is determined by the old anchor that an anchor migration is required and an Anchor migration process is initiated, steps 2002 and 2003 are performed. Since the MME/UPE can also determine whether to initiate the anchor migration process of the UE by using the information exchanged with the old anchor, in the case where the MME/UPE determines and initiates the Anchor migration process, steps 2002 and 2003 are omitted.

Step 2004: The MME/UPE sends a Create context request to the new anchor to which the UE is to be migrated, and requests the new Anchor to allocate a new IP address to the UE.

Step 2005: The new Anchor establishes corresponding user plane information for the UE when receiving the Create context request from the MME/UPE, and allocates a new IP address to the UE; after that, the user plane information and the allocated IP address that are also established for the UE are also The address is sent to the MME/UPE. Both the user plane information and the IP address can be carried in the Create context response and sent to the MME/UPE.

Step 2006: The MME/UPE sends a Delete PDP context request for the UE to the old Anchor.

Step 2007: The old Anchor deletes the stored UE Context when receiving the Delete PDP context request from the MME/UPE, and returns a Delete PDP context response to the MME/UPE.

Step 2008: The MME/UPE starts paging the UE (Paging UE) in the paging area. The UE that performs the anchor migration is the UE in the idle state. Therefore, after being activated by the MME/UPE, the user can receive the user plane information and the assigned service layer address established by the new anchor sent by the MME/UPE.

Step 2009: The UE returns a Paging Response.

Step 2010: The user plane information and allocation established by the MME/UPE for the new Anchor for the UE The service layer address is sent to the UE. The MME/UPE sends the user plane information and the IP address to the UE by using non-access stratum signaling. In this step, the MME/UPE further instructs the UE to divide the network into a network re-registration, so that the service of the UE does not have any impact due to the migration of the Anchor.

Step 2011: The user plane information and IP address received by the UE reconfigure its own IP layer related parameters, and return a response that receives the service layer address. The UE returns the response to the MME/UPE by using non-access stratum signaling.

Step 2012: The UE initiates a service request (Server Request) to the MME/UPE.

Step 2013: Before re-registering with the high-level service network, the UE may further perform a currently common authentication and authentication process for the UE with the MME/UPE, and even the MME/UPE and the HSS.

Step 2014: The UE applies the existing technology to the upper service network such as IMS to register using the received IP address.

If it is determined in step 2001 that all UEs in the old Anchor need to be migrated, the UE needs to be migrated in batches. Then you need to repeat steps 2002 ~ 2014. After the migration process of all UEs in the Anchor is completed, the smooth migration of the UE in the Anchor is implemented, and the old Anchor can be repaired or maintained. Embodiment 15: The MME and the UPE are separated into two logical entities, and the UPE and the Anchor are combined into one logical entity UPE/Anchor.

Referring to FIG. 21, FIG. 21 is a flowchart of mobility management according to Embodiment 15 of the present invention, where the process includes the following steps:

Step 2101: The MME determines by logic, or the old UPE/Anchor determines whether the UE in the idle state in the old UPE/Anchor needs to perform the Anchor migration by logically determining or receiving the relevant trigger command from the outside. The specific determination method is the same as step 2001. Step 2102: After the old UPE/Anchor determines the UE that needs to perform the Anchor migration, send an Anchor Relocation Request to the MME.

Step 2103: The MME returns an Anchor Relocation Response to the old UPE/Anchor. If it is determined by the MME and the Anchor migration process is initiated, steps 2102 and 2103 are omitted.

Step 2104: The MME sends a Create context request to the new UPE/Anchor to which the UE is to be migrated, and requests the new UPE/Anchor to allocate a new IP address to the UE.

Step 2105: The new UPE/Anchor establishes corresponding user plane information for the UE when receiving the Create context request from the MME, and allocates a new IP address to the UE. After that, the user plane information and the allocated IP address that are established for the UE are also The address is sent to the MME. Both the user plane information and the IP address can be carried in the Create context response and sent to the MME.

Step 2106: The MME sends a Delete PDP context request for the UE to the old UPE/Anchor.

Step 2107: The old UPE/Anchor deletes the stored UE Context when receiving the Delete PDP context request from the MME, and returns a Delete PDP context response to the MME.

Step 2108: The MME starts paging the UE in the paging area.

Step 2109: The UE returns a paging response.

Step 2110: The MME sends the UE to the new UPE/Anchor for the user plane information and the allocated service layer address established by the UE.

Step 2111: The UE reconfigures its own IP layer related parameters according to the received user plane information and the IP address, and returns a response of receiving the service layer address.

Step 2112: The UE initiates a Server Request. to the MME,

Step 2113: Before re-registering with the high-level service network, the UE may further perform the current common authentication with the MME and the MME further with the HSS for the UE. The authentication process.

Step 2114: The UE applies the existing technology to the upper service network registration such as IMS by using the received IP address.

If it is determined in step 2101 that all UEs in the old Anchor need to be migrated, the UE needs to be migrated in batches. Then, you need to repeat steps 2102 ~ 2114. Embodiment 16: The MME, UPE, and Anchor are separated into three logical entities, respectively.

Referring to FIG. 22, FIG. 22 is a flowchart of mobility management according to Embodiment 16 of the present invention, where the process includes the following steps:

Step 2201: The MME determines by logic, or the old anchor determines the UE in the idle state that needs to perform the anchor migration in the old anchor by logically determining or receiving the relevant trigger command from the outside. The specific determination method is the same as step 2001.

Step 2202: After the old anchor determines the UE that needs to perform the anchor migration, send an Anchor Relocation Request to the MME, and connect the Anchor Relocation Response returned by the MME. If the MME determines and initiates the Anchor migration process, this step 2202 is omitted.

Step 2203: The MME interacts with the new anchor to which the UE is to be migrated, and the new anchor establishes a new user plane for the UE and allocates a new IP address.

The specific operation is as follows: The MME sends a Create context request to the new Anchor, and requests the new Anchor to allocate a new IP address to the UE. The new Anchor establishes corresponding user plane information for the UE when receiving the Create context request from the MME, and allocates a new IP address for the UE. The address is also sent to the MME for the user plane information established by the UE and the assigned IP address. Both the user plane information and the IP address can be carried in the Create context response and sent to the MME.

Step 2204: The MME notifies the old Anchor to delete the UE Context. The specific deletion operation is usually: the MME sends a Delete PDP context request for the UE to the old Anchor; the old Anchor deletes the stored UE Context when receiving the Delete PDP context request from the MME, and returns a Delete PDP context response to the MME.

Steps 2206 to 2211 are the same as steps 2108 to 2114 shown in FIG. Similar to the foregoing FIG. 7 to FIG. 14, whether the MME and the UPE are combined into one logical entity, the saved UE UE Context may be deleted by the old MME and the old UPE in the process involving the new Anchor deleting the UE Context.

In addition, the MME interacts with the new anchor to enable the new anchor to establish a user plane and assign an IP address to the UE, usually through UPE.

It can be known from the mobility management brief flow shown in FIG. 6 and the embodiments of FIG. 20 to FIG. 22 that no matter whether at least two communication entities in the MME, UPE, and Anchor are combined into one logical entity, The mobility management method of the invention solves the problem that the single Anchor is overloaded when the load of the single network Anchor is too heavy, by performing an Anchor migration on the UE connected to the Anchor in an idle state without increasing the network equipment. The problem of load balancing is not well implemented. At the same time, when the Anchor is faulty or the Anchor is repaired according to the network management command, the Anchor is migrated by assigning the idle UE connected to the Anchor, thereby solving the network equipment operation without increasing the network equipment. After the issue is not suitable for online maintenance.

In order to implement the mobility management method under the evolved network architecture of the present invention, the present invention also provides a mobility management system under an evolved network architecture.

FIG. 23 is a schematic diagram showing the basic composition of a mobility management system according to an embodiment of the present invention. Referring to FIG. 23, the system includes a network server 2310 and an anchor point. The anchor point is specifically divided into a new anchor point 2320 to which the UE is to be migrated and an old anchor point 2330 serving the UE before the anchor point is migrated.

The network server 2310 notifies the UE when determining that the UE needs to perform anchor migration. The new anchor point 2320 to be migrated provides the UE with communication resources to support its subsequent communication; the communication resource is typically a user plane, a communication address for supporting subsequent communication of the UE.

Upon receiving the anchor migration notification from the network server 2310, the new anchor 2320 provides the UE with a user plane and communication address to support its subsequent communication.

The network server 2310 also notifies the UE that the old anchor point 2320 serving the UE before the Anchor migration deletes the user plane of the UE to be anchored.

After receiving the user plane deletion notification, the old anchor point 2320 deletes the user plane of the UE to be anchored for the anchor migration.

Specifically, the network server 2310 determines the UE to be migrated and the new anchor to be migrated by logical judgment. The executed logical judgment operation is performed after receiving the location area update initiated by the UE, or after receiving the anchor migration request sent by the old anchor point 2330, or according to the interaction with the old anchor point 2330. The information is determined to be performed after the anchor migration.

After determining the UE to be migrated and the new anchor to be migrated, the network server 2310 generates an anchor migration notification output to the determined new anchor 2320; and generates a user plane deletion notification output to the old anchor 2330.

The web server 2310 also sends the user plane and service layer address received from the new anchor 2320 to the UE. If the UE is in an idle state, the UE will be found by paging and then sent; if the UE is in an active state and a location area update request is initiated, the user plane and the service layer address may be carried in the location area update accept message. Give the UE.

The new anchor 2320 establishes a user plane and an assigned service layer address for the UE to be migrated according to the received anchor migration notification, and returns to the network server 2310. The new anchor 2320 interacts with the UPE to establish a user plane for the UE.

The old anchor point 2330 deletes the user plane corresponding to the UE to which the Anchor is to be migrated according to the received user plane deletion notification. The old anchor point 2330 further monitors its own load condition and, when it is determined that its own load is overweight, sends an anchor migration request to the network server 2310. Alternatively, the old anchor point 2330 sends an anchor migration request to the network server 2310 under external trigger. The external trigger may be a maintenance device command sent by the network management.

The network server 2310 described above is a network server that has been serving the UE all the time, or is a network server that is reselected for the UE due to the user location area update.

The network server 2310 is an MME/UPE in which the MME and the UPE are combined into one logical entity, and the new anchor point 2320 and the old anchor point 2330 are respectively separate network entities Anchor;

Alternatively, the network server 2310 is the MME, and the new anchor point 2320 and the old anchor point 2330 are respectively UPE/Anchor in which the UPE and the anchor are combined into one network entity;

Alternatively, the network server 2310 is the MME, and the new anchor point 2320 and the old anchor point 2330 are separate network entities Anchor.

It can be seen from the above that the mobility management method under the evolved network architecture provided by the present invention can significantly improve the communication quality of the UE, thereby significantly improving user satisfaction.

The above is only the preferred embodiment of the present invention, and is not intended to limit the present invention. Any modifications, equivalents, improvements, etc., which are made within the spirit and principles of the present invention, should be included in the present invention. Within the scope of protection.

Claims

Claim

A mobility management method under an evolved network architecture, characterized in that the method comprises:

Determining that the user equipment UE needs to perform anchor migration;

The anchor point to which the UE is to migrate provides communication resources for supporting subsequent communication by the UE.

The method according to claim 1, wherein the method for the anchor point to which the UE is to be migrated provides the communication resource as follows: an anchor point to which the UE is to be migrated is established to support subsequent communication of the UE. The user plane and the UE are assigned a communication address for supporting subsequent communication of the UE.

The method according to claim 2, wherein the anchor point to which the UE is to be migrated establishes the user plane as: an anchor point to which the UE is to be migrated directly with a user plane entity UPE currently serving the UE or Indirect interaction, establishing a user plane for supporting UE communication between the anchor point to be migrated and the UPE.

The method of claim 3, wherein the UPE is a UPE that is always serving the UE, or a UPE that is newly selected to provide services for the UE due to a UE location update.

The method according to claim 3, wherein the anchor point to which the UE is to be migrated interacts directly or indirectly with the user plane entity UPE currently serving the UE, and the anchor point to be migrated to the The user plane established between the UPEs to support UE communication is:

Sending an activation session context request to the UPE currently serving the UE; the UPE allocates a transmission channel resource to the UE according to the received activation session context request, and sends the necessary parameters in the transmission channel resource to the anchor point to be migrated to the UE. The anchor allocates an Internet Protocol IP address and allocates a data transmission channel resource for the bearer to be newly created according to the received necessary parameters.

6. The method of claim 5, wherein the necessary parameters are carried The anchor point to be sent to the UE to be migrated in the create session context request.

The method according to claim 6, wherein the interaction between the anchor to which the UE is to be migrated and the UPE is implemented by a mobility management entity MME that currently provides services for the UE.

The method according to claim 7, wherein the MME is an MME that always provides services for the UE, or an MME that is newly selected to provide services for the UE due to the location update of the UE.

The method according to claim 1 or 2, wherein the determining that the UE needs to perform a mis-point migration is:

Whether the UE needs to perform anchor migration is determined according to the anchor migration information preset in a static method and/or the anchor migration parameter acquired dynamically.

The method according to claim 9, wherein the method for determining whether the UE needs to perform anchor migration according to the anchor migration information is:

Presetting the route metric between the network server served by the UE and the connected anchor points, and determining whether the anchor point with the optimal route metric is an anchor point currently communicating with the UE, and if yes, determining that the UE does not need to perform an anchor point Migrate; otherwise, determine that the UE needs to perform anchor migration.

The method of claim 10, wherein the anchor point having the optimal routing metric is further determined as an anchor point to which the UE should migrate.

The method according to claim 9, wherein the method for determining whether the UE needs to perform anchor migration according to the anchor migration parameter is:

Obtaining a state parameter of each anchor point connected to the network server serving the UE, and comparing one or more of the acquired anchor state parameters to obtain an anchor point with the most dominant state parameter, and then determining the anchor point Whether it is the anchor point currently communicating with the UE, and determining that the UE needs to perform anchor point migration when the judgment result is no.

The method according to claim 12, wherein the anchor point having the most dominant state parameter is further determined as an anchor point to which the UE should migrate.

Obtaining the state parameters of each Anchor connected to the network server serving the UE, and the route metric between each Anchor and the network server, and determining whether the route metric between the Anchor and the network server with the most dominant state parameters is lower than the preset The route metric bottom limit further determines whether the Anchor is the Anchor currently communicating with the UE when the judgment result is no, and determines that the UE needs to perform anchor migration when the judgment result is no.

The method according to claim 14, wherein the anchor having the most dominant state parameter and the routing metric not lower than the routing metric limit is further determined as the Anchor to which the UE should migrate.

Obtaining the state parameters of each Anchor connected to the network server serving the UE, and the route metric between each Anchor and the network server, determining whether the state parameter of the Anchor Optimum route metric is better than the preset threshold state parameter, When the determination result is yes, it is further determined whether the Anchor is the Anchor currently communicating with the UE, and when the determination result is no, it is determined that the UE needs to perform anchor migration.

The method of claim 16, wherein the anchor with the best route metric and the state parameter superior to the bottom state parameter is further determined as the Anchor to which the UE should migrate.

The method according to claim 1 or 2, wherein the step of determining that the UE needs to perform anchor migration is performed under the trigger of the UE.

The method according to claim 18, wherein the UE triggers a process The location area update process initiated for the UE.

The method according to claim 1 or 2, wherein the method for determining that the UE needs to perform a wrong point migration is:

Determining, according to the load condition of the old anchor point served by the UE before the anchor point migration, the UE that needs to be anchored to the old anchor point;

Alternatively, according to the anchor migration request from the outside, the UE connected to the old anchor point and requiring anchor migration is determined.

The method according to claim 20, wherein the determining, according to the load condition of the old anchor point served by the UE before the anchor point migration, determining the UE connected to the old anchor point and requiring anchor point migration is Determined by the old anchor serving the UE; or determined by the network server serving the UE through information related to the old anchor load that interacted with the old anchor.

The method according to claim 20, wherein the anchor point migration information pre-set in a static manner and/or the anchor point migration parameter obtained in a dynamic manner is further determined to be the most favorable for communicating with the UE. The anchor point of the old anchor point is used as an anchor point to which the UE is to be migrated;

Alternatively, the anchor point indicated by the anchor migration request from the outside is used as an anchor point to which the UE is to be migrated.

The method according to claim 20, wherein the UE that needs to be migrated is a UE in an idle state.

The method according to claim 1 or 2, wherein, before providing the communication resource for subsequent communication of the UE, determining, according to the migration restriction information set in advance for the UE, whether to allow the UE to perform anchor migration Anchor migration, and/or whether the UE is allowed to migrate to the anchor point to be migrated to the UE; if so, the operation of providing the communication resource is performed; otherwise, the flow is exited.

The method according to claim 24, wherein said migration restriction information is set In the subscription data of the UE that needs to be the migration anchor point, or in the roaming protocol of the UE, or in the APN structure of the access point network, or the judgment letter in the PCC rule of the policy and charging control

The method according to claim 2, wherein the communication address assigned to the UE is further notified to the UE.

The method according to claim 26, wherein the UE that needs to be migrated is a UE that is in an idle state;

And notifying the UE of the communication address to be allocated to the UE as: paging the UE that needs anchor migration in the paging area, and notifying the UE of the assigned communication address.

28. The method of claim 26, wherein the UE further applies the IP address to an upper layer service network registration.

The method according to claim 28, further comprising: performing an authentication authentication process for the UE before registering with the upper layer service network.

The method according to claim 1 or 2, wherein the user plane saved by the old anchor point serving the UE before the anchor migration is performed is further deleted.

The method according to claim 1 or 2, wherein the UE further establishes a radio access bearer for supporting subsequent communication.

The method of claim 31, wherein the communication resource comprises an IP address as a communication address, and the IP address is further sent to the UE by using the radio bearer established for the UE.

33. A mobility management system in an evolved network architecture, the system comprising: a network server serving a UE and an anchor point to which a UE is to be migrated;

The system according to claim 33, wherein the network server is further configured to: determine, according to an anchor migration request of an old anchor that is served by the UE before the UE anchor migration, determine that the UE needs to perform an anchor point. Migration

Or determining, according to the information that interacts with the old anchor point, that the UE needs to perform anchor migration; or determining that the UE needs to perform anchor according to anchor migration information preset in a static method and/or dynamically obtained anchor migration parameters. Point migration.

The system according to claim 33, wherein the network server is further configured to notify the UE of the old anchor point serving the UE before the migration, and delete the user plane of the UE that is saved.

The system according to claim 33, wherein the network server is further configured to: after receiving the communication resource provided by the new anchor point, send the communication resource to the UE that performs the mis-point migration.

The system according to claim 33, wherein the network server is a network server that directly serves the UE or a network server that is reselected for the UE due to user location area update.

The system of claim 33 or 34, wherein the network server is an MME/UPE in which the MME and the UPE are combined into one logical entity, and the anchor point is a separate network entity anchor;

Alternatively, the network server is an MME, and the anchor point is a UPE/Anchor in which a UPE and an Anchor are combined into one network entity;

Alternatively, the network server is an MME, and the anchor point is a separate network entity Anchor.