Techniques for directing communication traffic of a user equipment (UE) in a wireless communication network

Abstract

Techniques for steering communication traffic of a user equipment (UE) in a wireless communication network, wherein the communication network comprises at least some network entities, in particular base stations, configured to each provide a radio access network (RAN) to the user equipment, wherein a network entity providing current access of the UE to the network is referred to as a serving network entity, and wherein each of the network entities is configured to communicate at least with its neighboring network entities, wherein an algorithm is implemented on a network unit performing the following steps: • estimating a time duration T 蜂窝小区 as a first input, the T 蜂窝小区 estimating a time duration in which the UE is within radio coverage area of the serving network entity; • estimating a time duration T LC as a second input, the T LC estimating a time duration needed by the network to determine adjusted load control settings for the UE; • comparing T 蜂窝小区 with T LC and if: T 蜂窝小区 > T LC applying a load control procedure within the communication network; adding load control information computed by the network to a radio resource control message; transmitting the radio resource control message with the load control information computed by the network to the UE; or if: T 蜂窝小区 < T LC transmitting the radio resource control message without the load control information computed by the network to the UE.

Description

[0001] This invention relates to a method for communicating with each other in a communication network, a communication network, a network entity, and user equipment. User equipment is frequently used when a user travels from one location to another. Base stations providing access to communication networks, particularly the Internet, for user equipment have limited radio coverage areas, commonly referred to as cells. If user equipment travels outside a cell, it will lose contact with the current base station, resulting in a radio link failure without applicable countermeasures. A typical countermeasure is a so-called handover process, in which the user equipment connects to another base station before a radio link failure occurs. This is possible because the radio coverage areas of different base stations have overlapping areas, where the user equipment can perform a smooth handover process in these overlapping areas. Specifically, this invention relates to a method, a communication network, a network entity, and user equipment configured to robustly guide the communication of the user equipment in a manner that prevents radio link failure during handover.

[0002] General information about the underlying system architecture in the technical field related to this invention can be found in TS 38.401Vg4.0 “NG-RAN Architecture Description (Release 16)”.

[0003] Mobile protocols using the so-called Uu and NG interfaces are divided into two structures:

[0004] User plane protocols: These are the protocols that implement the actual PDU session service, that is, to carry user data through the access layer.

[0005] Control plane protocols: These are protocols used to control PDU sessions and connections between the UE and the network from various aspects, including requesting services, controlling different transport resources, handover, etc. They may also include mechanisms for the transparent transmission of NAS messages.

[0006] User side: PDU session resource service is provided by the access layer from SAP to SAP. Figure 1 The protocol on the Uu and NG interfaces, which are linked together to provide PDU session resource services, is shown.

[0007] Control plane: Figure 2 The control plane (signaling) protocol stack on the NG and Uu interfaces is shown.

[0008] Figure 3The general architecture of NG-RAN is illustrated: NG-RAN (Next Generation Radio Access Network) comprises a set of gNBs (5G base stations) connected to the 5GC (5G Core Network) via NG interfaces. gNBs can interconnect via Xn interfaces. A gNB may include a gNB-CU and one or more gNB-DUs. The gNB-CU and gNB-DU are connected via F1 interfaces.

[0009] Figure 4 The overall architecture of NG-RAN and the 5G core network is shown: the gNB is responsible for all radio-related functions in one or more cells, such as radio resource management, admission control, connection establishment, routing of user plane data to UPF (User Plane Functions) (see TS 23.501 Vg0.2 “System Architecture for 5G System; Stage II (Release 16)”) and control plane information to AMF (Access Mobility Functions) (see TS 23.501 Vg0.2 “System Architecture for 5G System; Stage II (Release 16)”), and QoS (Quality of Service) flow management. (See TS 23.501 Vg0.2 “System Architecture for 5G System; Stage II (Release 16)”) Figure 4 As seen in the diagram, the gNB connects to the 5G core via the NG interface, more specifically, to the UPF via the NG user plane portion (NG-u), and to the AMF via the NG control plane portion (NG-c). For load sharing and redundancy purposes, a gNB can connect to multiple UPFs / AMFs. The Xn interface, which connects gNBs to each other, is primarily used to support active-mode mobility. This interface can also be used for multi-cell radio resource management (RRM) functions. The Xn interface is also used to support lossless mobility between adjacent base stations via packet forwarding.

[0010] Figure 5 This section explains the handover process of a User Equipment (UE) from its serving gNB (i.e., the current base station) to another gNB. Generally, the handover process is a procedure used for mobility guidance in the UE's connectivity mode. The principle of handover is as follows... Figure 5Explanation: In the first step, the network must perform measurements and apply the corresponding configuration. After Event 1 (typically, the radio quality measured in the UE is below the configured threshold) has occurred, the device sends a measurement report to the serving gNB. Now, the serving gNB must negotiate with neighboring gNBs to determine if the gNB is ready to serve the device ("Handover Request" and "Handover Request Acknowledgement" messages). After the neighboring gNB has accepted the device, the serving gNB sends an "RRC Reconfiguration Message" to the device. The "RRC Reconfiguration Message" contains the configuration to be applied by the neighboring gNB. In the next step, the device synchronizes with the neighboring B-node and sends the message "RRC Reconfiguration Complete" to notify it that the handover has been performed.

[0011] Conditional Handover (CHO). Mobility in connected mode—when the mobile terminal / user equipment is active—is controlled by the network unit, assisted by the mobile terminal, and typically facilitated by the handover procedure described above. If the communication link to the serving cell becomes degraded and / or the communication link to another neighboring cell becomes better than that of the serving cell, the mobile terminal transmits a measurement report. Based on these measurement reports, the network unit can switch the mobile terminal's connection from the serving cell to that neighboring cell, thus giving the mobile terminal better radio conditions and therefore a better user experience. However, it is possible that when the radio link becomes degraded and the mobile terminal needs to transmit a measurement report, the uplink also degrades and the report never reaches the network unit. Alternatively, even if the report reaches the network unit, the network attempts to respond with a handover command, which may never reach the mobile terminal (because the downlink degrades and / or the handover command is too large to be transmitted multiple times). The following... Figure 6 These two scenarios are described. If the radio link becomes unacceptably bad, a Radio Link Failure (RLF) is declared within the UE, and a reconstruction is initiated. RLF and reconstruction are specified in TS 38.331Vg2.0, “Radio Resource Control (RRC); Protocol Specification”.

[0012] These drawbacks can be addressed through the CHO procedure. Conditional handover features are standardized in 3GPP Rel-16 and essentially work as follows: the mobile terminal receives a handover command and stores it in its memory (an RRC reconfiguration message prepared by the target candidate), rather than applying it immediately as in legacy / normal handover procedures. Along with this command, the mobile terminal also receives associated conditions to be monitored. When the conditions are met, the mobile terminal applies the previously stored handover command as if the network had just sent it, instead of first sending a measurement report (which might fail to be transmitted) and then waiting to receive the command (which might fail to be received).

[0013] The criteria for defining the handover commands stored by the application are based on the quality of the serving cell and neighboring cells, somewhat similar to the conditions in previous versions that caused the mobile terminal to transmit a measurement report when certain conditions were met. For example, the network can configure the wireless terminal to transmit a measurement report when there is an "offset" in which a neighboring cell becomes better than the serving cell. Figure 5 Event 1 in this context, referred to as A3 in TS 38.331 Vg2.0 “Radio Resource Control (RRC); Protocol Specification”, serves as a way to indicate to the network that a handover may be necessary. In conditional handover, similar conditions can be configured in addition to the handover command stored in the mobile terminal application instead of transmitting measurement reports. Sending a handover command when radio conditions remain favorable reduces the risk of failure in transmitting measurement reports and / or receiving handover commands.

[0014] The principle of condition switching is... Figure 7 As shown, conditional handover is divided into two phases: the conditional handover preparation phase (phase 1) and the conditional handover execution phase (phase 2). In the first phase, after event 1 occurs, the device submits a measurement report to the network (serving gNB), which responds by reserving potential candidate cells for handover (neighbor gNB1 and neighbor gNB2). The latter is accomplished by messages 3 and 4. Once the candidate cells have been reserved, the serving gNB continues to notify the UE of the candidate cells (message 5), and the device confirms the configuration (message 6).

[0015] In Phase 2, after Event 2 occurs, the device synchronizes itself and sends HO completion messages to the selected neighbor gNB (messages 7 and 8). Within the network, messages 9 and 10 are used to release any remaining candidate gNBs that are not suitable for the handover process. In practice, different standardized events can be used for Event 2, such as A3 (the neighbor cell becomes better than the serving cell by an offset) or A5 (the serving cell is worse than threshold 1 and the neighbor cell is better than threshold 2), as specified in TS 38.331 Vg2.0 “RadioResource Control (RRC); Protocol Specification”.

[0016] Load balancing: The description of load balancing in this section is based on "LTE Self-Organizing Networks (SON)," S. Hämäläinen, H. Sanneck, C. Sartori (Wiley 2012). Load balancing optimizes network capacity and user experience through efficient utilization of the entire pool of available resources. The primary goal of load balancing is to direct traffic to the optimal tier within the covered cells by coordinating mobility configurations. However, it should not compromise robust and optimized mobility performance, for example, in terms of timely and perfect handover execution. Load balancing in connected modes (i.e., load balancing integrated into the handover procedures for overlapping cells) is the focus of this invention.

[0017] Typically, the serving gNB manages load balancing for all assigned (served) UEs. Therefore, the serving gNB collects load information from neighboring cells in the first step. This collection of load information is performed using "Global Xn Procedure Resource Status Report Initiation" and "Global Xn Procedure Resource Status Report," as described in TS 38.423 Vg3.0 "NG-RAN; XnApplication Protocol (XnAP)." Based on the collected load information, the serving base station / gNB can control mobility decision criteria, prioritizing less loaded cells as the next serving cell. In short: the serving gNB tells the UE which candidate gNB it will connect to next during handover. Since the reported radio channel measurements are used as the decision criteria to trigger the handover process, the serving gNB can negotiate with its more loaded neighboring node B (e.g., negative measurement offset) to favor less loaded neighboring node Bs with overlapping coverage during the handover procedure. This can be accomplished via "Global Xn Procedure Mobility Settings Change" as described in TS 38.423 Vg3.0 "NG-RAN; Xn Application Protocol (XnAP)". Load balancing can be integrated into both normal handover procedures and conditional handover procedures.

[0018] exist Figure 8 The document describes the principle of load balancing between two overlapping neighboring cells in connectivity mode, combined with a normal handover process. The "Measurement Configuration Message" can also contain the negative offset negotiated for neighboring gNB2 cells.

[0019] Requesting and retrieving Self-Organizing Network (SON) measurements: Some measurements used in the UE to implement this invention are referred to as SON measurements. These measurements are recorded within the UE and can be requested by the network in the message "UE Information Request" and subsequently reported to the network in the message "UE Information Response," as described in TS 38.331 Vg2.0 "Radio Resource Control (RRC); Protocol Specification." Figure 9 The corresponding information exchange between the network entity and the UE is shown.

[0020] Capability Retrieval: UE capabilities are used to describe what technical features are implemented in the UE. If a capability is signaled to the network as supported, the network understands that the relevant technical features are implemented in the UE and can use this knowledge in subsequent device configurations. The network requests UE capabilities via a "UE Capability Query Message," and the device sends the capability in the message "UE Capability Information," as described in TS 38.331 Vg2.0 "Radio Resource Control (RRC); Protocol Specification." Figure 10 The mechanism is illustrated in the figure.

[0021] In the current technical setup, the serving base station needs to communicate with its neighboring base stations—potential candidates for user equipment (UE) connection during conditional handover—to assess the load of each neighboring base station in order to perform appropriate load balancing assessments. Due to load balancing reasons (“global Xn procedure mobility setting change”), negotiating the measured offset of the candidate base station to which the UE should next connect can take a longer time than the time the UE is within the radio coverage of the serving base station. Therefore, it is impossible to provide the UE with appropriate load control information (e.g., RRC conditional configuration messages) before a radio link failure occurs. Such radio failures are undesirable for both users and network operators because they degrade the quality of service for the UE, requiring it to reconnect to the communication network. This reconnection requires more time and consumes more resources compared to a smooth handover process. Radio link failures can have interruption times on the order of up to 2000 ms.

[0022] In summary, the purpose of this invention is to provide a technique for robust handover procedures for user equipment in wireless communication networks. Specifically, the purpose of this invention is load control for conditional handover protocols.

[0023] This objective is achieved through the features of the independent claims.

[0024] Features or various embodiments of the invention described below can be combined with each other unless this is explicitly excluded or technically impossible.

[0025] In the context of this invention, the UE is a mobile terminal. In the context of this invention, load balancing of network entities, particularly base stations, is facilitated by generating load control information. In this context, the term load control information is preferred because it instructs the UE to be "controlled" by this information to select a network entity chosen for load balancing reasons during handover. In principle, the term load control information can also be renamed load balancing information.

[0026] According to a first aspect of the invention, a method is provided for guiding communication traffic of a user equipment (UE) in a wireless communication network. The communication network includes at least a number of network entities, particularly base stations, each configured to provide a radio access network (RAN) for the UE, wherein the network entity providing current access to the network for the UE is referred to as a serving network entity, and wherein each of these network entities is configured to communicate at least with its neighboring network entity, wherein an algorithm is implemented on a network unit performing the following steps:

[0027] Request and / or use the first time duration T 蜂窝小区 As the first input, this T 蜂窝小区 Estimate the duration of time the UE is within the radio coverage area of ​​the serving network entity;

[0028] Request and / or use the second time duration T LC As the second input, T LC Estimate the time required for the network to determine the adjusted load control settings for the UE, especially the time required for the "Global Xn Procedure Mobility Settings Change").

[0029] T 蜂窝小区 With T LC Compare, and if:

[0030] o T 蜂窝小区 > T LC :

[0031] Apply load control procedures within the communication network;

[0032] Load control information for network computing is added to radio resource control messages, particularly conditional configuration messages. Network entities calculate this load control information during load balancing. Serving network entities exchange load information with their neighboring network entities; based on this information exchange, the load control information for network computing can be determined.

[0033] In particular, the network entity transmits a Radio Resource Control (RRC) message containing load control information for network computation to the UE; the RRC message can be configured to enable the user equipment to perform a handover process from the serving network entity to a specific neighboring entity, wherein the specific neighboring entity can be selected based on load balancing reasons.

[0034] - If certain triggering conditions are met, specifically when the signal strength of a neighboring base station becomes one offset better than the signal strength of the serving base station, or when the signal strength of the serving base station becomes worse than a first threshold and the signal strength of the neighboring base station becomes better than a second threshold, the user equipment can initiate a conditional handover process before a radio link failure occurs. During the handover process, the user equipment can use network-computed control information to connect to specific neighboring network entities.

[0035] Radio Resource Control (RRC) messages: The Radio Resource Control (RRC) protocol is used for UMTS, LTE, and 5G over the air interface. It is a Layer 3 protocol used between the UE and the base station. This protocol is specified by 3GPP for new radios in UMTS, LTE, and 5G. RRC messages are transmitted via PDCP and underlying protocols. The main functions of the RRC protocol include connection establishment and release, system information broadcasting, radio bearer establishment, reconfiguration and release, RRC connection mobility procedures, paging notification and release, and outer loop power control. With the help of signaling functions, RRC configures the user and control plane according to network conditions and allows the implementation of radio resource management policies. Or if:

[0036] o T 蜂窝小区 < T LC :

[0037] In particular, radio resource control, which transmits load control information without network computing to the UE by network entities.

[0038] This provides the following advantages: ensuring a robust manner for redirecting user equipment communications from the serving network entity to the adjacent network entity during handover, while providing appropriate network computation load control information (if this information can be sent to the user equipment before a radio link failure occurs, this is T) 蜂窝小区 > T LC This is to provide load balancing within the communication network (in situations where T is in a certain condition). On the other hand, if T... 蜂窝小区 <= T LC In this case, the user equipment may leave the radio coverage of the serving network entity before the time required to generate load control information expires. Radio link failure is prevented by omitting the procedure for generating load control information within the network (“Global Xn Procedure Mobility Setting Change”) and instead sending a radio resource control condition configuration message to the UE that does not contain network-calculated load control information, allowing it to perform a handover procedure when the CHO trigger condition is met.

[0039] For example, with the aid of radio resource control (RRC) that lacks load control information for network computation, the UE can automatically and randomly connect to any neighboring network entity. In both scenarios, radio link failures are adequately prevented, and in the first scenario, load balancing mechanisms can even be applied to further improve the efficiency of the communication network. Therefore, load control is performed by the UE and / or the network. As will be seen later herein, in embodiments of the invention, load balancing mechanisms can even be applied in the second scenario by including so-called network mapping information in the RRC message.

[0040] Network entities can be defined by functional devices; that is, as entities configured to provide radio access networks. There are several such entities with this functionality, such as base stations, evolved B nodes, WLAN routers, or WLAN access points.

[0041] A network unit can be defined by a functional device, that is, a unit on which an algorithm is implemented and executed. Essentially, this network unit can be located anywhere within the communication network. It can be a server within the core network. Of course, in this case, it can be different from a network entity and therefore described using another term, namely, a unit. However, the algorithm can also be implemented on a network entity, for example, on a base station. Preferably, the network entity has processing units for performing its tasks so that the algorithm can also be implemented on network units, particularly on base stations. In this embodiment of the invention, the entity and the unit will be the same, but this is not the general case.

[0042] The term "each providing its own radio access network" describes that each network entity can provide a radio access network. These can be different RANs. Different radio access networks can be based on the technologies applied, such as LTE, 5G, or simply, different radio access networks can be provided by different telecommunications providers.

[0043] Therefore, this invention can be named "Conditional Distributed Load Control" because it is based on conditions (T). 蜂窝小区 With T LC The relationship between load control can be distributed between the UE and the network side (for T). 蜂窝小区 <= T LC ).

[0044] Conditional Distributed Load Control (CHO) enables the application of load control in conjunction with Conditional Handover (CHO) under all conditions (i.e., when channel conditions also change rapidly (the remaining time in the cell is less than or equal to the delay of the mobility setup procedure)). Even more advantageously, it allows for the implementation of legacy centralized load control whenever possible.

[0045] When several cells meet the Conditional Handover (CHO) trigger condition, Conditional Distributed Load Control eliminates the ambiguity in the decision-making process for a specific cell from the set of candidate neighboring cells. This ambiguity stems from the current specification's statement that the selection of a specific cell from several cells meeting the CHO trigger condition "Event 2" can be left to the UE.

[0046] Conditional Distributed Load Control provides the aforementioned benefits and only moderately increases UE and network complexity.

[0047] Conditional Distributed Load Control enables networks to use legacy solutions (centralized load control) as much as possible, thereby eliminating the risk of contention-based eavesdropping where load or capacity signaling is implemented as an extension of the RRC reconfiguration message.

[0048] Conditional distributed load balancing cannot be introduced to the entire group of endpoints simultaneously. Assuming this feature is first introduced on the network side, capability control is only allowed to use this feature once it has been fully integrated and tested on the endpoint side.

[0049] In one embodiment, at T 蜂窝小区 <= T LC In this scenario, the Radio Resource Control (RRC) message is provided with load control information for the network mapping of the UE. In this case, load control is actually performed by the UE. The network-mapped load control information has the effect that sending and receiving RRC messages appears substantially the same to the UE as if network-computed load control information were used. This allows the UE to perform the CHO procedure using an algorithm similar to that in the previous scenario. The network-mapped load control information within the RRC message (T...) 蜂窝小区 <= T LC ) and the network computed load control information (T) within the RRC message 蜂窝小区 > T LC The difference between the two is that there is essentially no time delay introduced by adding network mapping load control information to the RRC message. The network mapping load control information can be randomly generated within the serving network entity or simply retrieved from a lookup table storing typical load conditions. Alternatively, the standard RRC message may already include an information element with pre-specified network mapping load control information, further reducing time delay. Of course, in this scenario, it's possible for the UE to connect to a neighboring network entity based on non-network-based load control information, which is not the preferred network entity for load balancing reasons. However, since any time delay is avoided, this effectively prevents radio link failures.

[0050] In one embodiment, the algorithm is implemented on the serving network entity. Since the serving network entity is typically the serving base station that grants network access to the user equipment, this feature has the effect of further reducing the waiting time for determining load control information, because all network entities, along with the UE, are spatially as close as possible to each other.

[0051] In one embodiment, T is estimated based on the UE's state information. 蜂窝小区 This status information could be the time interval in which the UE typically spends within the cell, the UE's local coordinates, and / or the UE's measured speed. For example, the serving network entity has information about its radio coverage area. Therefore, if the UE's local coordinates along with the UE's actual measured speed are known, the time duration until the UE leaves the serving network entity's radio coverage area can be calculated, and this time duration is designated as time duration T. 蜂窝小区 .

[0052] In one embodiment, the serving network entity requests status information from the UE. Specifically, the serving network entity requests status information from the UE after the UE receives an RRC message from the serving network entity for future handover procedures. This has the advantage of efficiently reducing network traffic and computing resources, especially the UE's network traffic and computing resources, because the status information is only requested when actually needed.

[0053] In one embodiment, T is estimated based on the exchange of state information between the serving network entity and its neighboring network entities. LC Service network entities can use the available uplink and downlink capacity values ​​of their respective neighboring entities to estimate the time required to perform load balancing adjustments within the network. Essentially, the maximum time duration T... LC This is dominated by neighboring network entities with the lowest available uplink and downlink capacity values. The replacement method could be to record typical measured T values ​​in a lookup table. LC Duration, then select the most frequent T LC or greater than typical T LC The predetermined percentage of time duration for the value. For example, if T LC Selected as greater than typical T LC If the value is 95%, then this can prevent T LC It is underestimated.

[0054] In one embodiment, the serving network entity requests relevant status information from its neighboring network entities. This facilitates efficient use of communication network resources, as data traffic is only increased when the relevant information is actually needed.

[0055] In one embodiment, the load control information calculated by the network and / or the load control information mapped by the network is an offset value, capacity value, load value, or priority value characterizing each neighboring network entity. In the case of load control information mapped by the network, it is important to note that the offset value can also be obtained from a lookup table rather than being calculated in the network. In this way, it is possible to determine which cell the UE should preferentially connect to. This allows the UE to efficiently select neighboring network entities based on the load control information. Transmitting only the priority value has the added benefit that the actual load of the network entity can be encrypted, preventing hackers or competing network operators from obtaining information about the corresponding communication network when eavesdropping on RRC messages.

[0056] In one embodiment, by using T # LC Instead of T LC To perform the comparison, where T # LC = T LC + T 安全 T 安全 It is to ensure T LC Not too close to T 蜂窝小区 The safe time interval. If T LC Approaching T 蜂窝小区 Then the safe time interval T 安全 Effectively prevents radio link failures. Because of T LC and T 蜂窝小区 The determination of T is merely an estimate, so even if the estimate yields T... LC < T 蜂窝小区 The actual value may differ to some extent, which could lead to radio link failure.

[0057] In one embodiment, T is dynamically adapted based on the previous success rate. 安全 Of course, if T 安全 If T is chosen to be sufficiently large, this has the advantage of effectively preventing radio link failures, but also the disadvantage of not performing network-based load balancing. Therefore, if T 安全 By dynamically adapting to a value that matches a predetermined success rate, network operators can optimize procedures according to their needs. For example, a network operator might define a desired actual success rate of 90% (i.e., preventing radio link failures). If T 安全 If a certain value achieves a 95% success rate, then T can be dynamically reduced. 安全 This continues until a 90% optimal success rate is achieved. This results in more network-based load balancing being performed, as in T... 安全 The same applies when the value is large.

[0058] In one embodiment, if the UE detects a CHO condition, the UE initiates a Conditional Handover (CHO) procedure to connect to another network entity based on a Radio Resource Control (RRC) message. This has the effect that the RRC message is only used when the UE releases the cell of the serving network entity, and effectively prevents radio link failures in that case.

[0059] In one embodiment, the load control information for network computing depends on the current application running on the UE. Network entities can be designed in a 5G environment to adapt to specific slices of the 5G network. Those specific slices are designed to be tailored to the specific needs of the user equipment or the applications running on the user equipment. Therefore, load balancing can also consider which neighboring network entity provides the 5G slice that best meets the needs of the user equipment and / or the applications running on the user equipment.

[0060] According to a second aspect of the present invention, a wireless communication system is disclosed, wherein the wireless communication system comprises:

[0061] Wireless communication networks;

[0062] User equipment, configured to connect to and exchange data with the wireless communication network;

[0063] At least some network entities, particularly base stations, are configured to each provide a radio access network (RAN) to the user equipment. The network entity that provides the UE with current access to the network is called the serving network entity.

[0064] The wireless and / or wired communication links between the service network entity and its neighboring entities;

[0065] A processor unit implemented in the service network entity, wherein the processor is configured to perform the above-described method to direct communication traffic of the user equipment (UE) in the wireless communication network.

[0066] The advantage of this communication system is that it is configured to implement "conditional distributed load control".

[0067] According to a third aspect of the present invention, a network entity, particularly a base station, is disclosed, wherein the network entity comprises:

[0068] Used to provide the first communication interface for the radio access network (RAN) for user equipment;

[0069] A second communication interface for communicating with other network entities in a wired or wireless manner;

[0070] A processor unit implemented in the service network entity, wherein the processor is configured to perform the above-described method to direct communication traffic of the user equipment (UE) in the wireless communication network.

[0071] The advantage of this network entity is that it is configured to implement "conditional distributed load control".

[0072] According to a fourth aspect of the present invention, a user equipment is disclosed, wherein the user equipment comprises:

[0073] The first communication interface is configured to communicate with a network entity as described above, wherein the network entity provides the UE with access to the communication network;

[0074] A processor unit implemented in the UE, wherein the processor is configured to transmit UE status information upon receiving a request from a network entity, and wherein the processor is configured to perform a handover procedure according to the method described above.

[0075] The advantage of this user equipment is that it is configured to implement "conditional distributed load control".

[0076] In the following explanation, preferred embodiments of the invention are described with reference to the accompanying drawings:

[0077] Figure 1 The user plane protocols on the Uu and NG interfaces in a mobile network scenario are shown.

[0078] Figure 2 The control plane (signaling) protocol stack on the Uu and NG interfaces is shown.

[0079] Figure 3 The general architecture of NG-RAN is shown.

[0080] Figure 4 The overall architecture of NG-RAN and 5G core network is shown.

[0081] Figure 5 The process of switching user equipment was explained.

[0082] Figure 6 The potential technical problems that can occur and prevent a successful switching process are illustrated.

[0083] Figure 7 The basic principles of the Conditional Switching (CHO) procedure are shown.

[0084] Figure 8 An example of load control in connectivity mode is shown.

[0085] Figure 9 This illustrates the information exchange between a network entity and a UE based on a UE information request message.

[0086] Figure 10 The UE capability transfer procedure is shown.

[0087] Figure 11 The load control algorithm implemented in the service network entity is shown.

[0088] Figure 12 The content of the "Xn message resource status update" message is shown.

[0089] Figure 13 Showing from Figure 12 The content of the "TNL Capacity Indicator" information element (IE).

[0090] Figure 14 Showing from Figure 12 Details of the composite available capacity group.

[0091] Figure 15 It shows Figure 14 Further details.

[0092] Figure 16 A flowchart of the method according to the present invention is shown.

[0093] Figure 17 It is shown in T LC < T 蜂窝小区 In this context, the participating entities in the network and their corresponding data flows.

[0094] Figure 18 It is shown in T LC > T 蜂窝小区 In this context, the participating entities in the network and their corresponding data flows.

[0095] Figure 19 A flowchart of the UE's decision-making process is shown.

[0096] Figure 20 An example is shown in which the network entity only requests reduced information from the UE.

[0097] Figure 21 A further embodiment is shown in which the network entity only requests reduced information from the UE.

[0098] Figure 22 It shows according to Figure 21 The flowchart.

[0099] The numerous features of the invention are explained in detail below with reference to preferred embodiments. This disclosure is not limited to specifically named combinations of features. Rather, the features mentioned herein can be combined arbitrarily in the embodiments of the invention, unless this is expressly excluded below.

[0100] The above describes centralized load control performed by changing the cell-specific offset used for handover measurements. In the description, a legacy handover procedure (which differs from conditional handover (CHO)) is assumed.

[0101] In describing the invention (see...) Figure 11 This assumes that centralized load control can be combined with conditional handover within the network. In addition to considering only radio conditions, load conditions also play a role in the handover process. This makes resource utilization in the system more equitable.

[0102] In the following text, we will consider the case where several overlapping adjacent cells simultaneously meet the triggering condition "Event 2" for configuring possible CHO adjacent cells.

[0103] like Figure 11As shown, load reporting on the "Xn interface" is configured by exchanging "Resource Status Request" and "Resource Status Response" messages between the serving network entity 100 and one or more neighboring network entities 105, 110. In the specification, network entities 100, 105, and 110 are base stations configured to provide access to 5G and LTE communication networks. In a further specification, serving network entities 100, 105, and 110 are gNBs 100, 105, and 110 used to provide access to 5G networks. A typical implementation of load reporting via the "Xn interface" will result in the periodic sending of a "Resource Status Update" message containing load information from neighboring gNBs 105, 110 to the serving gNB 100. (These messages for load control are described in detail in TS 38.423 Vg3.0 “NG-RAN; XnApplication Protocol (XnAP)”.) Preferably, if multiple configured gNBs 105, 110 meet the criteria for triggering CHO “Event 2” 130, the load control mechanism needs to select among those gNBs 105, 110. This can be accomplished by prioritizing certain cells or the corresponding gNBs 105, 110. The current Radio Resource Control (RRC) specification does not specify the standard-varying means of prioritizing cells during CHO, leaving it to the UE implementation (see TS 38.331 Vg2.0 “Radio Resource Control (RRC); Protocol Specification” for details).

[0104] exist Figure 11 In the serving gNB 100, a load control algorithm is implemented. This algorithm is configured to detect whether neighboring gNB2 110 has a worse load condition than neighboring gNB1 105. This detection is based on information provided in the "Resource Status Update" message. Therefore, it is desirable to apply centralized load control and configure a negative measurement offset for cells belonging to neighboring gNB2, so that the device can preferentially hand over to one of the cells belonging to neighboring gNB1. (This negative offset can be transmitted to the UE in the RRC reconfiguration message.)

[0105] For this purpose, the “Global Xn Procedure Mobility Setting Change” described in TS 38.331 Vg2.0 “Radio Resource Control (RRC); Protocol Specification” can be applied (the relevant messages are “Mobility Change Request”, “Mobility Change Failure”, and “Mobility Change Acceptance”). Signaling associated with this procedure is exchanged on the “Xn Interface” between the serving gNB 100 and adjacent gNBs 105 and 110, resulting in an additional waiting time before sending an “RRC reconfiguration” message to the user equipment (UE) 120 regarding the configuration of the cell (which is a candidate cell for performing conditional handover). The exact content of the RRC reconfiguration message regarding the configuration of the candidate CHO cell is given in IE ConditionalReconfiguration-r16 of TS 38.331 Vg2.0 “Radio Resource Control (RRC); Protocol Specification”.

[0106] However, it is possible that during the time period corresponding to the waiting time determined by the processing time of the serving gNB 100 and the neighboring gNB2 110, and the Xn interface waiting time, the signal quality of the serving cell associated with gNB 100 deteriorates rapidly, and it becomes impossible to send a conditional handover reconfiguration message due to radio link failure 140. Therefore, the radio link needs to be rebuilt, and the robustness intended to be introduced by conditional handover is lost because the handover cannot be performed. As described in TS38.331 Vg2.0 “Radio Resource Control (RRC); Protocol Specification”, recovery from radio link failures is primarily determined by an interruption time on the order of “T310” 150 (up to 2000 ms).

[0107] and Figure 11 The relevant technical setup assumes that RRC connection reconstruction will be performed toward the neighboring gNB1 105 by broadcasting corresponding cell selection parameters with offsets for load control to UE 120.

[0108] Omitting "Global Xn Procedure Mobility Setting Change" can lead to timely transmission and execution of conditional handover, but there is no corresponding configuration for load control to define a specific measurement offset for each gNB before sending the RRC reconfiguration message. According to the current state of the specification, candidate CHO neighboring cells that meet trigger condition "Event 1" 160 must be prioritized according to the UE 120 implementation-specific solution. However, network providers typically cannot influence the choices made by a particular UE 120 implementation.

[0109] Sending an RRC reconfiguration message without load control information may result in a handover to the neighboring gNB2 110—even if gNB1 105 would be the preferred choice for the network operator due to load balancing issues. In this scenario, load control cannot be applied immediately but must be performed later, for example, by redirecting UE 120 to the neighboring gNB1 105. However, this may result in increased signaling load and new outages. Nevertheless, this remains the preferred option compared to a complete RL failure when UE 120 is out of communication range of its serving gNB 100.

[0110] Therefore, network 90, especially the serving gNB 100, must make a choice as soon as possible regarding whether there is sufficient time to send an RRC reconfiguration message with load control information or whether to send an RRC reconfiguration message without load control information, in order to avoid RL failure 140.

[0111] The solution to this problem will be proposed below, in which load control is always implemented in at least some gNBs.

[0112] Conditional Distributed Load Control

[0113] Network-side solutions:

[0114] To apply load control, the network provides UE 120 with additional information (e.g., in the form of load indications or neighbor cell priorities, thresholds, and / or offsets associated with these information slices) so that load control can be performed partly by the network and partly by the terminal. However, if the collection of this information is less than the time elapsed before the occurrence of RL fault 140, the network 90 will only send this information to perform conditional handover.

[0115] To achieve this, an additional load control algorithm can be implemented on UE 120. UE 120 uses the information provided within this additional load control algorithm to prioritize neighboring cells / neighboring gNBs and perform conditional handover. When additional information is provided to UE 120, the network needs to perform a first estimate regarding whether the execution of the "Global Xn Procedure Mobility Setting Change" will simultaneously lead to unacceptable deterioration of radio conditions and subsequent radio link failures, T310 expiration with increased outage time, and RRC connection re-establishment.

[0116] Estimate the remaining time in the cell

[0117] In order to perform time duration T for the UE within the radio coverage area of ​​serving gNB 100 蜂窝小区 The first estimate by the serving gNB 100 uses information obtained from the mobility history SON report (IE VisitedCellInfoList) and the recorded measurement SON report (IE LocationInfo-r16), along with collected load information and channel measurements, to estimate whether a “Global Xn Procedure Mobility Setting Change” will cause a radio link failure before an RRC reconfiguration message can be sent. The abbreviation IE stands for Information Element.

[0118] According to TS 38.331 Vg2.0 “Radio Resource Control (RRC); Protocol Specification”, the list of IE-surveyed cell information in the mobility history report is as follows:

[0119] -- ASN1START

[0120] --TAG-VISITEDCELLINFOLIST-START

[0121] VisitedCellInfoList-r16 ::= SEQUENCE (SIZE (1..maxCellHistory-r16))OF VisitedCellInfo-r16

[0122] VisitedCellInfo-r16 ::= SEQUENCE {

[0123] visitedCellId-r16 CHOICE {

[0124] nr-CellId-r16 CHOICE {

[0125] cgi-Info CGI-Info-Logging-r16,

[0126] pci-arfcn-r16 SEQUENCE {

[0127] physCellId-r16 PhysCellId,

[0128] carrierFreq-r16 ARFCN-ValueNR

[0129] }

[0130] },

[0131] eutra-CellId-r16 CHOICE {

[0132] cellGlobalId-r16 CGI-InfoEUTRA,

[0133] pci-arfcn-r16 SEQUENCE {

[0134] physCellId-r16 EUTRA-PhysCellId,

[0135] carrierFreq-r16 ARFCN-ValueEUTRA

[0136] }

[0137] }

[0138] OPTIONAL

[0139] timeSpent-r16 INTEGER (0..4095), ...

[0141] }

[0142] --TAG-VISITEDCELLINFOLIST-STOP

[0143] -- ASN1STOP

[0144] The relevant IE is timeSpent-r16, which indicates the duration of stay in a cellular or any cell-selected state and / or the duration of stay in any NR or E-UTRA cell state (approximately to the nearest second). This information can be used to estimate the terminal's speed, especially in conjunction with the velocityEstimate-r16 parameter from another IE.

[0145] According to TS 38.331 Vg2.0 “Radio Resource Control (RRC); Protocol Specification”, the IELocationInfo-r16 content in the recorded measurement report is as follows:

[0146] -- ASN1START

[0147] -- TAG-LOCATIONINFO-START

[0148] LocationInfo-r16 ::= SEQUENCE {

[0149] commonLocationInfo-r16 CommonLocationInfo-r16 OPTIONAL,

[0150] bt-LocationInfo-r16 LogMeasResultListBT-r16 OPTIONAL,

[0151] wlan-LocationInfo-r16 LogMeasResultListWLAN-r16 OPTIONAL,

[0152] sensor-LocationInfo-r16 Sensor-LocationInfo-r16 OPTIONAL, ...

[0154] }

[0155] -- TAG-LOCATIONINFO-STOP

[0156] -- ASN1STOP

[0157] -- ASN1START

[0158] --TAG-COMMONLOCATIONINFO-START

[0159] CommonLocationInfo-r16 ::= SEQUENCE {

[0160] gnss-TOD-msec-r16 OCTET STRING OPTIONAL,

[0161] locationTimestamp-r16 OCTET STRING OPTIONAL,

[0162] locationCoordinate-r16 OCTET STRING OPTIONAL,

[0163] locationError-r16 OCTET STRING OPTIONAL,

[0164] locationSource-r16 OCTET STRING OPTIONAL,

[0165] velocityEstimate-r16 OCTET STRING OPTIONAL

[0166] }

[0167] --TAG-COMMONLOCATIONINFO-STOP

[0168] -- ASN1STOP

[0169] CommonLocationInfo field description:

[0170] locationTimeStamp: The parameter type DisplacementTimeStamp is defined in TS 37.355. The first / leftmost bit of the first octet contains the most significant bit.

[0171] locationCoordinate: The parameter type LocationCoordinate is defined in TS 37.355. The first / leftmost bit of the first octet contains the most significant bit.

[0172] locationError: The LocationError parameter is defined in TS 37.355. The first / leftmost bit of the first octet contains the most significant bit.

[0173] locationSource: The parameter LocationSource is defined in TS 37.355

[49] . The first / leftmost bit of the first octet contains the most significant bit.

[0174] velocityEstimate: The parameter type Velocity is defined in TS 37.355

[49] . The first / leftmost bit of the first octet contains the most significant bit.

[0175] The relevant IE is locationCoordinate-r16, which indicates the terminal's location within the cell. The estimated speed and location can be used to estimate the minimum remaining time a mobile terminal can spend within the cell without experiencing unacceptable degradation in radio quality.

[0176] The network can obtain these reports by retrieving mobility history SON reports and recorded measurement SON reports from UE 120 using UE information request / response messages.

[0177] Estimate the delay for the global Xn procedure "Mobility Settings Change":

[0178] To determine the time delay T of the global Xn procedure "Mobility Settings Change". LC As a second estimate, it is necessary to examine the content of the "Xn Message Resource Status Update" for each possible candidate gNB 105 and 110. According to the specifications in TS 38.423 Vg3.0 "NG-RAN; Xn Application Protocol (XnAP)", the message content is... Figure 12 As shown in the image.

[0179] IE (Information Elements) "TNL Capacity Indicator" as follows Figure 13 The same specification (i.e., TS 38.423Vg3.0 “NG-RAN; Xn Application Protocol (XnAP)”) is further described as shown.

[0180] The serving gNB 100 can use "TNL capacity indicator" information, which specifies the provided and available capacity in the DL (download) and UL (upload) directions for each gNB 105, 110, to estimate the transmission delay of messages on the corresponding "Xn" interface. Based on previous reports of the "TNL capacity indicator," a lookup table including capacity values ​​and corresponding measured delays can be stored in the serving gNB 100 for each of the adjacent gNBs 105, 110. The time delay T of the "global Xn protocol mobility setting change" can then be obtained by simple linear interpolation or extrapolation of the delay against the capacity values. LC .

[0181] As previously mentioned, in order to implement load control in UE 120, the network expands the content of the RRC reconfiguration message with various information such as load information, thresholds, and priority information. In the simplest case, the network transmits the IE capacity value or (100 – capacity value) as the load information for each neighboring cell.

[0182] Composite available capacity group IE also Figure 12 It is shown in, and indicates in Figure 14 The figure shows the overall available resource levels for each cell and each SSB area within a cell in the downlink and uplink directions.

[0183] like Figure 15 The composite available capacity (IE) shown indicates the overall available resource level in a cell on the downlink or uplink.

[0184] The extended RRC reconfiguration message may include the following data i) to iii):

[0185] i)

[0186] Cell ID_1 Capacity value 1

[0187] Cell ID_2 Capacity value 2

[0188] …

[0189] Cell ID_N, capacity value N;

[0190] Where N is the total number of cells reported to serving gNB 100 in the "Measurement Report" message, and cell ID_i corresponds to the identifier of cell i, and capacity value i corresponds to the capacity value reported to serving gNB 100 in the "Resource Status Update" message for cell i. Remember that those values ​​for cell i are related to the corresponding neighboring gNBs 105 and 110. Therefore, in all cases from i) to iii), cell ID_i can be replaced by gNB_i.

[0191] As mentioned above, the capacity values ​​of the downlink and uplink can be weighted according to their respective traffic distributions and combined into a single capacity value.

[0192] ii)

[0193] Cell ID_1 Load value 1

[0194] Cell ID_1 Load value 2

[0195] …

[0196] Cell ID_N and load value N;

[0197] Where N is the total number of cells reported to service gNB 100 in the message “Measurement Report”, and cell ID_i corresponds to the identifier of cell i, and load value i is calculated as 100 minus capacity value i, where capacity value i corresponds to the capacity value reported to service gNB 100 in the message resource status update for cell i.

[0198] iii)

[0199] Cell ID_1 Priority value 1

[0200] Cell ID_1 Priority value 2

[0201] …

[0202] Cell ID_N and priority value N;

[0203] Where N is the total number of cells reported to service gNB 100 in the message “Measurement Report”, cell ID_i corresponds to the identifier of cell i, and priority value i is a value indicating which cell i will be prioritized in the load balancing procedure.

[0204] In many situations, network operators prefer not to signal the actual capacity or load values ​​of their gNBs to neighboring networks, as this information could be effective against hackers planning to attack the network or other competitors in the area who could use this information to plan their own networks accordingly. In such cases, it is beneficial to send only an "abstract" priority value per cell ID_i, as shown in the table above. In other words, the priority value encrypts the actual capacity or load value. The priority value i corresponds to a comparison between the capacity value i / load value i and an internally set threshold. For example, if threshold i < load value i < threshold i+1, then priority value i is assigned to cell ID i. Besides preventing the network from directly signaling capacity or load values, the described priority signaling has another advantage: the priority of signaling notifications can guide network traffic very efficiently. In practice, if the corresponding capacity or load values ​​are too close, it is clear which gNB the UE 120 will choose. The priority value i is a possible means of "separating" very similar values ​​into two distinct priority categories that can influence the UE 120's decision.

[0205] Based on T LC and T 蜂窝小区 Based on estimates, network entities, particularly the serving gNB 100, can decide whether to transmit a standard legacy RRC reconfiguration message or to use distributed load control (i.e., to instead send some additional information to the endpoint in the RRC reconfiguration message) to prevent RL failure 140 from occurring. If T LC < T 蜂窝小区 The estimated remaining time for the mobile device within the radio coverage area of ​​the serving gNB100 cell is significantly larger than the delay estimate for "Global Xn Procedure Mobility Setting Change," and the legacy RRC reconfiguration message can be used. If T LC >= T 蜂窝小区 The estimated remaining time for the mobile device within the radio coverage area of ​​the serving gNB 100 cell is significantly smaller than the delay estimate for a "global Xn procedure mobility setting change," and some additional information will be transmitted to the terminal in the RRC reconfiguration message. The algorithm implemented on UE 120 can distinguish between these two scenarios based on the content of the "RRC reconfiguration" message from the serving gNB 100: if per-cell ID signaling of capacity, load, or priority values, the network has decided to use distributed load control, and UE 120 acts accordingly.

[0206] The flowchart of the method of the present invention is as follows Figure 16 As shown.

[0207] In step 200, the network entity configures the recorded measurements. In step 205, the network entity retrieves the recorded measurement reports and mobility history reports. In step 210, the network entity estimates the remaining time the mobile device can spend in the cell serving gNB 100, and the time delay in the event of executing a "mobility setting change procedure". Subsequently, the algorithm proceeds to a decision in step 215, where it assesses whether the remaining time the mobile device has in the cell is greater than the delay caused by the "mobility setting change procedure".

[0208] If T LC >= T 蜂窝小区 (Step 220) The algorithm then proceeds to step 225, and the network entity sends an RRC reconfiguration message to user equipment 120. This RRC reconfiguration message may include additional information (such as load values ​​and priority values), which have been stored internally by the network entity to minimize the time delay in retrieving this information. In step 230, UE 120 may randomly connect to either candidate GNB 105 or 110, or UE 120 may apply load control based on the additional information, where the load control procedure within UE 120 determines which candidate GNB 105 or 110 UE 120 should first attempt to connect to. Finally, in step 235, conditional handover (CHO) is executed.

[0209] If T LC < T 蜂窝小区 (Step 240) The algorithm then proceeds to step 245. In step 245, the network entity applies a "Mobility Settings Change Procedure" between the serving gNB 100 and neighboring gNBs 105 and 110. In step 250, the network entity sends an appropriate RRC configuration message to the UE 120, which is expanded with information obtained from the "Mobility Settings Change Procedure". In this case, load control is applied by the network entity. Or in other words, the network entity instructs the UE 120 which neighboring gNBs 105 and 110 it will connect to next. Finally, the algorithm also enters a second path in step 235 where a Conditional Handover (CHO) is applied.

[0210] Figure 17 It is shown in T LC < T 蜂窝小区 In this case, the participating entities in the network and the corresponding signaling flow. Figure 17 Step 210 is illustrated, in which the network entity estimates the remaining time UE 120 has within the cellular radio coverage area of ​​the serving gNB 100 and the delay of the "Mobility Change Procedure". Figure 17 Show T LC < T 蜂窝小区In this scenario, a "Mobility Change Request Procedure" 300 is triggered within the network, causing load control to be applied in network 305. After the "Mobility Change Request Procedure" 300 is completed, the resulting "RRC Configuration Message" with a measured offset is sent to UE 120, which instructs UE 120 which adjacent gNB 105, 110 it will connect to next during a Conditional Handover (CHO) process.

[0211] Figure 18 It is shown in T LC >= T 蜂窝小区 In this context, the participating entities in the network and their corresponding data flows. Figure 18 Step 210 is illustrated, in which the network entity estimates the remaining time UE 120 has within the cellular radio coverage area of ​​the serving gNB 100 and the delay of the "Mobility Change Procedure". Figure 18 Show T LC > T 蜂窝小区 In this scenario, the network entity, particularly the serving gNB 100, promptly sends an RRC configuration message 315 containing priority, load, or capacity information to the UE 120. Following "Event 2" 130, load control 320 is applied by the UE 120.

[0212] according to Figures 16 to 18 Possible implementations of the procedure within UE 120:

[0213] In an ideal scenario, UE 120 selects the same neighboring gNBs 105 and 110 as in the case where the network entity applies load control.

[0214] If load control is fully implemented on the network side (non-distributed), the network entity can prioritize cells by applying corresponding measurement offsets to measurements of specific cells. The offset essentially prevents cells from simultaneously reaching triggering criteria and lowers the priority of cells with the largest negative offset or the smallest positive offset. The offset should be set so that cells with lower loads reach the radio triggering criteria for CHO before cells with higher loads. A radio triggering criterion for CHO (Event 2) implies the implementation of triggering events A3 or A5 (as defined in TS38.331 Vg2.0 “Radio Resource Control (RRC); Protocol Specification)”).

[0215] If load control is distributed, there is no configured offset to prevent cells from simultaneously meeting the radio triggering criteria for CHO, because the "Global Xn Procedure Mobility Setting Change" cannot be applied between the serving gNB 100 and its corresponding neighboring gNBs 105 and 110. Therefore, UE 120 can simultaneously request candidate cells for the radio portion that meet the triggering criteria based on a decrease in the signaled capacity value (if these values ​​are signaled in RRC reconfiguration) or an increase in the signaled load value (if these values ​​are signaled in RRC reconfiguration), and perform a handover to the first cell in the cell list listed in this manner. Alternatively, the terminal can simultaneously request cells for the radio portion that meet the triggering criteria based on an increase in priority value (if these priority values ​​are signaled), and perform a handover to the first cell in the cell list ordered in this manner.

[0216] Figure 19 A flowchart of the decision-making process of UE 120 is shown.

[0217] In step 400, UE 120 receives an "RRC reconfiguration message" for CHO.

[0218] The algorithm then enters decision loop 410, where UE 120 frequently checks whether the CHO radio trigger condition is met. Step 415 shows that if the answer is "no," the entire process of checking the radio trigger condition is repeated. Step 420 shows that if the radio trigger condition is met, the algorithm enters decision 425, where it checks whether the capacity value was signaled in the RRC reconfiguration message. If yes, the algorithm enters step 430, where UE 120 requests communication establishment with cells that meet the radio trigger condition in descending order of capacity value. Finally, the algorithm enters step 435, where the CHO procedure is performed for the first cell in the list.

[0219] If the answer to decision 425 is no, the algorithm proceeds to another decision 440, where it checks whether the load value was signaled in the RRC reconfiguration message. If yes, the algorithm proceeds to step 445, where UE 120 requests communication establishment with cells that meet the radio triggering conditions in ascending order of load value. Subsequently, the algorithm finally proceeds to step 435, where a CHO procedure is performed for the first cell in the list.

[0220] If the answer to decision 440 is no, the algorithm proceeds to another decision 450, where it checks whether a priority value was signaled in the RRC reconfiguration message. If yes, the algorithm proceeds to step 445, where UE 120 requests communication establishment with cells that meet the radio triggering conditions in ascending order of priority value. Subsequently, the algorithm finally proceeds to step 435, where a CHO procedure is performed for the first cell in the list.

[0221] If the answer to decision 450 is no, the algorithm will finally execute the CHO procedure in step 460 for all or any selected cells / gNBs 105, 110 that meet the CHO radio triggering conditions.

[0222] Solution variant: Transmission of SON information in measurement reports:

[0223] As previously explained, network entities can obtain mobility history SON reports or recorded measurement SON reports by using the UE Information Request / Response procedure. According to the current specification, the information obtained using this procedure contains a large number of information elements that are not actually needed for network estimation. To recognize that network estimation does not require a large number of IEs, the current decoding of the "UE Information Request" and "Information Response" messages according to TS 38.331 Vg2.0 "Radio Resource Control (RRC); Protocol Specification" is given below.

[0224] -- ASN1START

[0225] -- TAG-UEINFORMATIONREQUEST-START

[0226] UEInformationRequest-r16 ::= SEQUENCE {

[0227] rrc-TransactionIdentifier RRC-TransactionIdentifier,

[0228] criticalExtensions CHOICE {

[0229] ueInformationRequest-r16 UEInformationRequest-r16-IEs,

[0230] criticalExtensionsFuture SEQUENCE {}

[0231] }

[0232] }

[0233] UEInformationRequest-r16-IEs ::= SEQUENCE {

[0234] idleModeMeasurementReq-r16 ENUMERATED{true} OPTIONAL, -- Need N

[0235] logMeasReportReq-r16 ENUMERATED {true} OPTIONAL, -- Need N

[0236] connEstFailReportReq-r16 ENUMERATED {true} OPTIONAL, -- Need N

[0237] ra-ReportReq-r16 ENUMERATED {true} OPTIONAL, -- Need N

[0238] rlf-ReportReq-r16 ENUMERATED {true} OPTIONAL, -- Need N

[0239] mobilityHistoryReportReq-r16 ENUMERATED {true} OPTIONAL, -- Need N

[0240] lateNonCriticalExtension OCTET STRING OPTIONAL,

[0241] nonCriticalExtension SEQUENCE {} OPTIONAL

[0242] }

[0243] -- TAG-UEINFORMATIONREQUEST-STOP

[0244] -- ASN1STOP

[0245] -- ASN1START

[0246] -- TAG-UEINFORMATIONRESPONSE-START

[0247] UEInformationResponse-r16 ::= SEQUENCE {

[0248] rrc-TransactionIdentifier RRC-TransactionIdentifier,

[0249] criticalExtensions CHOICE {

[0250] ueInformationResponse-r16 UEInformationResponse-r16-IEs,

[0251] criticalExtensionsFuture SEQUENCE {}

[0252] }

[0253] }

[0254] UEInformationResponse-r16-IEs ::= SEQUENCE {

[0255] measResultIdleEUTRA-r16 MeasResultIdleEUTRA-r16 OPTIONAL,

[0256] measResultIdleNR-r16 MeasResultIdleNR-r16 OPTIONAL,

[0257] logMeasReport-r16 LogMeasReport-r16 OPTIONAL,

[0258] connEstFailReport-r16 ConnEstFailReport-r16 OPTIONAL,

[0259] ra-ReportList-r16 RA-ReportList-r16 OPTIONAL,

[0260] rlf-Report-r16 RLF-Report-r16 OPTIONAL,

[0261] mobilityHistoryReport-r16 MobilityHistoryReport-r16 OPTIONAL,

[0262] lateNonCriticalExtension OCTET STRING OPTIONAL,

[0263] nonCriticalExtension SEQUENCE {} OPTIONAL

[0264] }

[0265] LogMeasReport-r16 ::= SEQUENCE {

[0266] absoluteTimeStamp-r16 AbsoluteTimeInfo-r16,

[0267] traceReference-r16 TraceReference-r16,

[0268] traceRecordingSessionRef-r16 OCTET STRING (SIZE (2)),

[0269] tce-Id-r16 OCTET STRING (SIZE (1)),

[0270] logMeasInfoList-r16 LogMeasInfoList-r16,

[0271] logMeasAvailable-r16 ENUMERATED {true} OPTIONAL,

[0272] logMeasAvailableBT-r16 ENUMERATED {true} OPTIONAL,

[0273] logMeasAvailableWLAN-r16 ENUMERATED {true} OPTIONAL, ...

[0275] }

[0276] LogMeasInfoList-r16 ::= SEQUENCE (SIZE (1..maxLogMeasReport-r16)) OFLogMeasInfo-r16

[0277] LogMeasInfo-r16 ::= SEQUENCE {

[0278] locationInfo-r16 LocationInfo-r16 OPTIONAL,

[0279] relativeTimeStamp-r16 INTEGER (0..7200),

[0280] servCellIdentity-r16 CGI-Info-Logging-r16 OPTIONAL,

[0281] measResultServingCell-r16 MeasResultServingCell-r16 OPTIONAL,

[0282] measResultNeighCells-r16 SEQUENCE {

[0283] measResultNeighCellListNR MeasResultListLogging2NR-r16 OPTIONAL,

[0284] measResultNeighCellListEUTRA MeasResultList2EUTRA-r16 OPTIONAL

[0285] },

[0286] anyCellSelectionDetected-r16 ENUMERATED {true} OPTIONAL

[0287] }

[0288] To reduce uplink signaling load and avoid invoking the UE Information Request / Response (CHO) procedure every time, the network entity can decide to implement load control on the CHO. Specifically, a flag can be introduced in the Measurement Configuration message to request only the transmission of the information elements timeSpent, locationCoordinate, and velocityEstimate. In this context, Figure 20 This illustrates a scenario where the estimated remaining time a mobile device can spend in a cellular space is much greater than the delay estimate for a "global Xn procedure mobility setting change". Figure 21 This illustrates a scenario where the estimated remaining time a mobile device can spend in a cellular space is much greater than the delay estimate for a "global Xn procedure mobility setting change". Figure 22A flowchart of network operations in this scenario is shown.

[0289] UE capabilities for distributed load control:

[0290] As a result, the network will not be specifically populated with UE 120s that are capable of distributed load control from the outset. Most likely, a significant portion of UE 120s will not support distributed load control, preventing the network from applying the described solution on such terminals. To avoid potential conflicts between network signaling and the actual capabilities of the UEs, it is recommended that the terminal signal its distributed load control capabilities to the network. The network typically retrieves terminal capabilities during the initial connection establishment, thus knowing in advance whether the described solution can be applied to a specific situation.

Claims

1. A method for guiding communication traffic of a user equipment (UE) in a wireless communication network. The wireless communication network mentioned above includes: At least some network entities are configured to each provide a radio access network (RAN) to the user equipment, wherein the network entity providing the UE with current access to the wireless communication network is referred to as a serving network entity, and Each of the network entities is configured to communicate with at least its neighboring network entities. The algorithm is implemented on the service network entity that performs the following steps: Use the first time duration T 蜂窝小区 As the first input, where T 蜂窝小区 Estimate the time duration of the UE within the radio coverage area of ​​the serving network entity; Use the second time duration T LC As the second input, where T LC Estimate the time duration required for the wireless communication network to determine the adjusted load control settings for the UE; T 蜂窝小区 With T LC Compare, and if: T 蜂窝小区 > T LC : Apply load control procedures within the wireless communication network; Add the load control information calculated by the wireless communication network to the radio resource control message; The radio resource control message containing load control information calculated by the wireless communication network is transmitted to the UE; Or if: T 蜂窝小区 < T LC : A radio resource control message that does not contain load control information calculated by the wireless communication network is transmitted to the UE.

2. The method of claim 1, wherein if T 蜂窝小区 < T LC Then, the radio resource control message is provided with load control information based on wireless communication network mapping for the UE.

3. The method of claim 1, wherein T 蜂窝小区 It is estimated based on the state information of the UE.

4. The method of claim 3, wherein the serving network entity requests the status information from the UE.

5. The method of claim 1, wherein T LC It is estimated based on the state information exchange between the service network entity and its neighboring network entities.

6. The method of claim 5, wherein the service network entity requests the corresponding status information of its neighboring network entities.

7. The method of claim 2, wherein the load control information calculated by the wireless communication network and / or the load control information mapped by the wireless communication network is selected as an offset value, capacity value, load value, or priority value characterizing each adjacent network entity.

8. The method of claim 1, wherein the comparison is performed using T # LC Instead of T LC To execute, where T # LC =T LC + T 安全 T 安全 It is to ensure T LC Not too close to T 蜂窝小区 The safe time interval.

9. The method of claim 8, wherein T 安全 It is dynamically adapted based on previous success rates.

10. The method of claim 1, wherein if the UE detects a Conditional Handover (CHO) condition, the UE initiates a CHO procedure to connect to another network entity based on the radio resource control message.

11. The method of claim 2, wherein the load control information calculated by the wireless communication network and / or the load control information mapped by the wireless communication network depends on the current application running on the UE.

12. A wireless communication system, comprising: Wireless communication networks; User equipment, the user equipment being configured to connect to the wireless communication network and exchange data with the wireless communication network; At least some network entities are configured to each provide a radio access network (RAN) to the user equipment, wherein the network entity providing the UE with current access to the wireless communication network is referred to as a serving network entity. The wireless and / or wired communication links between the service network entity and its neighboring entities; A processor unit implemented in the service network entity, wherein the processor unit is configured to perform the method as described in any one of claims 1-9 and 11 to direct communication traffic of the user equipment (UE) in the wireless communication network.

13. A network entity, wherein the network entity comprises: Used to provide the first communication interface for the radio access network (RAN) for user equipment; A second communication interface for communicating with other network entities in a wired or wireless manner; A processor unit implemented in the network entity, wherein the processor unit is configured to perform the method as described in any one of claims 1-9 and 11 to direct communication traffic of the user equipment (UE) in the wireless communication network.

Images