WO2008000182A1 - Procédé et système de gestion des déplacements dans une architecture de réseau évoluée - Google Patents

Procédé et système de gestion des déplacements dans une architecture de réseau évoluée Download PDF

Info

Publication number
WO2008000182A1
WO2008000182A1 PCT/CN2007/070143 CN2007070143W WO2008000182A1 WO 2008000182 A1 WO2008000182 A1 WO 2008000182A1 CN 2007070143 W CN2007070143 W CN 2007070143W WO 2008000182 A1 WO2008000182 A1 WO 2008000182A1
Authority
WO
WIPO (PCT)
Prior art keywords
anchor
migration
mme
new
upe
Prior art date
Application number
PCT/CN2007/070143
Other languages
English (en)
Chinese (zh)
Inventor
Jian Zhang
Xiaolong Guo
Zhiming Zhu
Weihua Hu
Original Assignee
Huawei Technologies Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from CN2006100865401A external-priority patent/CN101094096B/zh
Priority claimed from CN2006100933930A external-priority patent/CN101094509B/zh
Application filed by Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Publication of WO2008000182A1 publication Critical patent/WO2008000182A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W60/00—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/04—Wireless resource allocation

Definitions

  • 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
  • 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.
  • MME Mobility Management Entity
  • LTE-RAN Long Term Evolution-Radio Access Network
  • a UPE (User Plane Entity) 104 and communicates with an anchor 109 connected to the UPE 104.
  • 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.
  • 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.
  • 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.
  • FIG. 2 is a schematic diagram of an MME/UPE reselection process for non-real-time services in the prior art.
  • 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.
  • 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.
  • 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 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. .
  • FIG. 3 is a schematic diagram of an MME/UPE reselection process for real-time services in the prior art.
  • 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.
  • 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.
  • Anchor 304 may no longer be the Anchor that is most beneficial to UE 301 communication.
  • 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.
  • the UE 301 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.
  • 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.
  • a single Anchor is overloaded, which can also cause network devices to be unbalanced.
  • 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:
  • 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;
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 1 is a structural diagram of an evolution network of the prior art.
  • FIG. 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 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.
  • the Anchor migration process is described.
  • 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.
  • 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.
  • 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.
  • 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;
  • P-TMSI Packet-Temporary Mobile Subscriber Identity
  • TAI Track Area Identifier
  • TLI Temporary Retrieval Link Identifier
  • new Network Server 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 1 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.
  • the new Network Server when it 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.
  • 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.
  • the new network server 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.
  • 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.
  • 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.
  • APN access point network
  • PCC Policy and Charging Control
  • 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.
  • HSS Home Subscriber Server
  • 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.
  • the new network server sends a user plane allocation request including the UE Context to the new Anchor.
  • 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.
  • DNS Domain Name Server
  • 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.
  • 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.
  • 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.
  • TAI New Location Area Identifier
  • 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.
  • step 405 and step 406 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the Network Server 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • step 504 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.
  • step 505 step 504 and step 505 can also be performed simultaneously.
  • the Network Server can determine whether the UE needs to perform the Anchor migration and should be migrated.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the judgment rule can also be set according to other Anchor parameters.
  • 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.
  • 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.
  • 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.
  • Anchor 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.
  • 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.
  • 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.
  • the service layer address is usually an IP address.
  • 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.
  • CGI/SAI Cell Global Identification/ Service Area Identification
  • RAT type Radio Access Technic Type
  • the new anchor 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.
  • 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.
  • Network Server passes the non-access stratum (NAS, 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.
  • the current authentication authentication process may be further performed between the UE, the Network Server, and even the HSS.
  • step 607 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.
  • 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.
  • 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.
  • the administrator can migrate the UE on the anchor to another anchor in batches, thereby implementing smooth migration of the UE in the anchor.
  • the Anchor that requires maintenance can be repaired or maintained.
  • 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.
  • FIG. 4 and FIG. 5 are only a general outline of the mobility management method of the present invention.
  • 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.
  • 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;
  • 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.
  • TAU Request location area update request
  • 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.
  • 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 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.
  • step 706 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.
  • 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.
  • IMSI International Mobile Subscriber Identity
  • 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.
  • TA update Complete location update completion
  • 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;
  • 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.
  • 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;
  • 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.
  • step 906 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 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.
  • 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.
  • 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;
  • 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.
  • 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;
  • 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 1106 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 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.
  • 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 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.
  • 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.
  • 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.
  • 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.
  • 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 7 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;
  • 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 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.
  • step 1306 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.
  • 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.
  • 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.
  • 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 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.
  • 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.
  • 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.
  • Embodiment 8 MME, UPE, and Anchor are separated into three logical entities respectively; the MME is not reselected and UPE migration occurs;
  • 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.
  • 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 7 After receiving the IP address from the MME, the UE returns a TA update to the MME.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • TEID tunnel end identifier
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the UE 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.
  • the UE may further apply the existing technology to perform in an upper layer service network such as IMS. Registration process.
  • 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.
  • the establishment or release of an IP bearer can also be completed by interacting between the UPE and the anchor as in Embodiment 10.
  • 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.
  • 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 0 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.
  • the new anchor also allocates a new IP address for subsequent communication to the UE, and notifies the MME of the IP address.
  • 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.
  • the UE 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.
  • the UE may further apply the existing technology to perform in an upper layer service network such as IMS. Registration process.
  • 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.
  • 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.
  • 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.
  • Step 1713 The MME sends a TA Update to the UE that includes at least the newly assigned IP address.
  • 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.
  • the UE 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.
  • 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.
  • 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.
  • 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 is
  • 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.
  • 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.
  • the UE 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.
  • 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;
  • 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.
  • 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 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.
  • 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.
  • the UE 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.
  • the UE can further apply the prior art to perform a registration process in an upper layer service network such as IMS.
  • the MME may also perform a location update procedure for the UE and HSS application prior art.
  • 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.
  • 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.
  • the IP address allocated to the UE may be sent to the UE through the established radio access bearer.
  • the mobility management method of the present invention can select the Anchor that is most beneficial for communication for the UE;
  • 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.
  • the operation of the Anchor that is most advantageous for communication is triggered by the location area update operation initiated by the UE.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Embodiment 16 The MME, UPE, and Anchor are separated into three logical entities, respectively.
  • 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 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the new anchor 2320 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.
  • the old anchor point 2320 deletes the user plane of the UE to be anchored for the anchor migration.
  • 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.
  • the network server 2310 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.
  • 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;
  • 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;
  • the network server 2310 is the MME, and the new anchor point 2320 and the old anchor point 2330 are separate network entities Anchor.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

La présente invention concerne procédé de gestion des déplacements dans une architecture de réseau évoluée, procédé par lequel on confirme la nécessité qu'un équipement utilisateur soit transféré entre des ancrages, l'ancrage de destination fournissant des ressources de communication à l'équipement utilisateur pour une communication ultérieure. L'invention concerne également un système de gestion des déplacements dans une architecture de réseau évoluée, lequel système comprend un serveur de réseau qui fournit des services à un équipement utilisateur, lequel équipement demande des ressources de communication en provenance de l'ancrage de destination, au profit d'une communication ultérieure de l'équipement utilisateur quand on confirme que l'équipement utilisateur doit être transféré entre les ancrages. L'ancrage de destination auquel l'équipement utilisateur est transféré fournit à l'équipement utilisateur les ressources de communication. Le projet de gestion des déplacements dans l'architecture de réseau évoluée peut renforcer la qualité de communication de l'équipement utilisateur et améliorer énormément la satisfaction de l'utilisateur.
PCT/CN2007/070143 2006-06-20 2007-06-20 Procédé et système de gestion des déplacements dans une architecture de réseau évoluée WO2008000182A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
CN200610093393.0 2006-06-20
CN200610086540.1 2006-06-20
CN2006100865401A CN101094096B (zh) 2006-06-20 2006-06-20 一种演进网络架构下的移动性管理方法
CN2006100933930A CN101094509B (zh) 2006-06-20 2006-06-20 演进网络及用户设备锚点迁移的方法

Publications (1)

Publication Number Publication Date
WO2008000182A1 true WO2008000182A1 (fr) 2008-01-03

Family

ID=38845134

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2007/070143 WO2008000182A1 (fr) 2006-06-20 2007-06-20 Procédé et système de gestion des déplacements dans une architecture de réseau évoluée

Country Status (1)

Country Link
WO (1) WO2008000182A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1415177A (zh) * 1999-11-03 2003-04-30 高通股份有限公司 在网络中提供移动性的方法和装置
US20030207688A1 (en) * 2002-05-03 2003-11-06 Vincent Nikkelen Service-based inter-system handover
WO2005112499A1 (fr) * 2004-05-17 2005-11-24 Ipwireless, Inc Systeme et procede de reattribution de reseau de radiocommunication

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1415177A (zh) * 1999-11-03 2003-04-30 高通股份有限公司 在网络中提供移动性的方法和装置
US20030207688A1 (en) * 2002-05-03 2003-11-06 Vincent Nikkelen Service-based inter-system handover
WO2005112499A1 (fr) * 2004-05-17 2005-11-24 Ipwireless, Inc Systeme et procede de reattribution de reseau de radiocommunication

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
FAN C., CHANG Y., YANG D.: "Fast Access Network Architecture for 3GPP Long Term Evolution", TELECOM ENGINEERING TECHNICS AND STANDARDIZATION, no. 5, 15 May 2006 (2006-05-15) *

Similar Documents

Publication Publication Date Title
US11678240B2 (en) Method and system for transferring user equipment in mobile communication system
CA3132854C (fr) Radiomessagerie de dispositif sans fil par le biais d'un reseau sans fil
US8687592B2 (en) Method for switching session of user equipment in wireless communication system and system employing the same
KR20190052060A (ko) 세션 관리를 위한 시스템 및 방법
US20230379830A1 (en) Base station handling of transitioning wireless device to inactive state
US20110235605A1 (en) Radio resource allocation method and device of henb in evolved packet system
US8976717B2 (en) Method for data forwarding
US20100309881A1 (en) Mobile communication system and tunnel management method thereof
KR20130014398A (ko) 핸드오버 지원 장치 및 방법
WO2011026392A1 (fr) Procédé et système d'acquisition de stratégies d’itinéraire
WO2011140888A1 (fr) Système et procédé de communication pour continuité d'appel vocal radio unique améliorée
WO2011026407A1 (fr) Procédé et système de prise en charge de mobilité de connexion d'accès par protocole internet local
EP4154566A1 (fr) Authentification et autorisation spécifiques à une tranche de réseau
US20220248370A1 (en) Signaling Delivery in a Wireless Network
WO2008154783A1 (fr) Procédé pour établir un tunnel à partir de sgsn vers la passerelle de service
WO2008000182A1 (fr) Procédé et système de gestion des déplacements dans une architecture de réseau évoluée
WO2012167460A1 (fr) Procédé et appareil permettant la réalisation de mobilité de connexion d'accès ip local ou de délestage de trafic ip sélectionné

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07721762

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

NENP Non-entry into the national phase

Ref country code: RU

122 Ep: pct application non-entry in european phase

Ref document number: 07721762

Country of ref document: EP

Kind code of ref document: A1