Event specific mobility change procedure

Abstract

A source Radio Access Network (RAN) node (120a) transmits, to a target RAN node (120b), a mobility change request that requests a change to a handover trigger point used by the target RAN node (120b) to trigger handover from the target RAN node (120b) The target RAN node receives the mobility change request from the source RAN node (120a) and changes the handover trigger point of the target RAN node (120b) based on the mobility change request. The source RAN node transmits, to the target RAN node (120b), a handover request triggered based on the handover trigger point.

Description

[0001] EVENT SPECIFIC MOBILITY CHANGE PROCEDURE

[0002] RELATED APPLICATIONS

[0003] This application claims the benefit of U.S. Provisional Application No. 63 / 595055, filed 1 November 2023, the entire disclosure of which being hereby incorporated by reference herein.

[0004] TECHNICAL FIELD

[0005] The present disclosure generally relates to the technical field of wireless communication and, more particularly, to enhancing how mobility changes are handled within a wireless communication network.

[0006] BACKGROUND

[0007] The Mobility Change Request procedure is traditionally used to indicate to a neighboring Radio Access Network (RAN) node (e.g., a Fifth Generation Node B (gNB)) that the thresholds used for mobility operations (e.g., Synchronization Signal Block (SSB) offsets) in one or more cells in the initiating RAN node (e.g., another gNB) is being reconfigured. The initiation of this procedure can be due to one or more reasons such as, handover optimization, dynamic cell shaping, interference management, load balancing, etc. As part of the procedure, the initiating RAN node may also suggest parameter settings for the cells at the neighboring RAN node. These suggestions may be evaluated by the neighboring RAN node to determine whether such a setting is permitted. The neighboring RAN node may communicate either an acknowledge or a failure message to the initiating RAN node to indicate the success or failure in configuring the suggested mobility parameters for cells in the neighboring RAN node.

[0008] While the mobility change request operates to set cell-level offsets, signaling for User Equipment (UE) handover is traditionally performed using the Handover Request procedure. In a traditional Handover Request procedure, information about the UE, its capabilities, active Packet Data Unit (PDU) sessions, estimation of bitrate, etc., are communicated from a source RAN node (e.g., a gNB) to a target RAN node (e.g., another gNB). In cases when a handover is accepted, signaling is traditionally done via the Handover Request Acknowledge message and in case of a failure the Handover Preparation Failure message is used.

[0009] SUMMARY

[0010] The present disclosure generally relates to enhancing how mobility changes are performed in a wireless communication network.

[0011] Embodiments of the present disclosure include a method implemented by a target RAN node. The method comprises receiving, from a source RAN node, a mobility change request that requests a change to a handover trigger point used by the target RAN node to trigger handover from the target RAN node. The method further comprises changing the handover trigger point of the target RAN node based on the mobility change request. In some embodiments, the method further comprises receiving a handover request from the source RAN node. Changing the handover trigger point of the target RAN node based on the mobility change request comprises changing the handover trigger point in response to detecting a correspondence between the handover request and the mobility change request. In some such embodiments, changing the handover trigger point in response to detecting the correspondence comprises changing the handover trigger point responsive to detecting that the handover request and the mobility change request comprise matching cause information. In other such embodiments the mobility change request further comprises an identifier associated with the requested change. The method further comprises transmitting, in response to the mobility change request, an acknowledgement comprising a further identifier associated with the requested change. The method further comprises changing the handover trigger point in response to detecting the correspondence comprises changing the handover trigger point responsive to detecting that the handover request comprises the identifier and the further identifier. In some of either of such embodiments, the method further comprises determining whether to accept or reject the handover request based on cause information comprised in the mobility change request.

[0012] In some embodiments, the mobility change request indicates that the handover trigger point relates to one or more specific mobility events. Changing the handover trigger point comprises changing the handover trigger point for the one or more specific mobility events without changing the handover trigger point for at least one other mobility event.

[0013] In some embodiments, the method further comprises the mobility change request comprises first cause information and second cause information that is more detailed than the first cause information. Changing the handover trigger point of the target RAN node based on the mobility change request comprises changing the handover trigger point based on the second cause information. In some such embodiments, changing the handover trigger point of the target RAN node based on the mobility change request further comprises changing the handover trigger point further based on the first cause information.

[0014] In some embodiments, the mobility change request indicates that a reason for changing the handover trigger point comprises network energy savings. In some such embodiments, the mobility change request further indicates an energy cost related to the reason for changing the handover trigger point.

[0015] In some embodiments, the mobility change request indicates that a reason for changing the handover trigger point comprises coverage and / or capacity optimization. In some such embodiments, the mobility change request further indicates a coverage state related to the reason for changing the handover trigger point.

[0016] In some embodiments, the mobility change request further indicates a time when the changing of the handover trigger point is expected or a time window within which the changing of the handover trigger point is expected. Other embodiments include a target RAN node configured to receive, from a source RAN node, a mobility change request that requests a change to a handover trigger point used by the target RAN node to trigger handover from the target RAN node. The target RAN node is further configured to change the handover trigger point of the target RAN node based on the mobility change request.

[0017] In some embodiments, the target RAN node comprises interface circuitry and processing circuitry communicatively connected to the interface circuitry. The processing circuitry is configured to receive, from the source RAN node via the interface circuitry, the mobility change request that requests a change to a handover trigger point used by the target RAN node to trigger handover from the target RAN node. The processing circuitry is further configured to change the handover trigger point of the target RAN node based on the mobility change request.

[0018] In some embodiments, the target RAN node is further configured (e.g., by operation of the processing circuitry) to perform any one of the target RAN node methods described above.

[0019] Other embodiments include a computer program comprising instructions which, when executed on processing circuitry of a target RAN node, cause the processing circuitry to carry out any one of the target RAN node methods described above.

[0020] Yet other embodiments include a carrier containing said computer program. The carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

[0021] Embodiments of the present disclosure also include a method implemented by a source RAN node. The method comprises transmitting, to a target RAN node, a mobility change request that requests a change to a handover trigger point used by the target RAN node to trigger handover from the target RAN node. The method further comprises transmitting, to the target RAN node, a handover request triggered based on the handover trigger point.

[0022] In some embodiments, the handover request and the mobility change request comprise matching cause information.

[0023] In some embodiments, the mobility change request further comprises an identifier associated with the requested change. The method further comprises receiving, in response to the mobility change request, an acknowledgement comprising a further identifier associated with the requested change. The method further comprises transmitting the handover request comprises including the identifier and the further identifier in the handover request.

[0024] In some embodiments, the mobility change request indicates that the change requested relates to one or more specific mobility events. Transmitting the handover request is responsive to one or more of the specific mobility events occurring.

[0025] In some embodiments, the mobility change request comprises first cause information and second cause information that is more detailed than the first cause information. The handover request is responsive to a handover being triggered due to a cause consistent with the first cause information and the second cause information in the mobility change request. In some embodiments, the mobility change request indicates that a reason for changing the handover trigger point comprises network energy savings. In some such embodiments, the mobility change request further indicates an energy cost related to the reason for changing the handover trigger point.

[0026] In some embodiments, the mobility change request indicates that a reason for changing the handover trigger point comprises coverage and / or capacity optimization. In some such embodiments, the mobility change request further indicates a coverage state related to the reason for changing the handover trigger point.

[0027] In some embodiments, the mobility change request further indicates a time when the changing of the handover trigger point is expected or a time window within which the changing of the handover trigger point is expected.

[0028] Other embodiments include a source RAN node configured to transmit, to a target RAN node, a mobility change request that requests a change to a handover trigger point used by the target RAN node to trigger handover from the target RAN node. The source RAN node is further configured to transmit, to the target RAN node, a handover request triggered based on the handover trigger point.

[0029] In some embodiments, the source RAN node comprises interface circuitry and processing circuitry communicatively connected to the interface circuitry. The processing circuitry is configured to transmit, to the target RAN node via the interface circuitry, the mobility change request that requests a change to a handover trigger point used by the target RAN node to trigger handover from the target RAN node. The processing circuitry is further configured to transmit, to the target RAN node via the interface circuitry, the handover request triggered based on the handover trigger point.

[0030] In some embodiments, the source RAN node is further configured (e.g., by operation of the processing circuitry) to perform any one of the source RAN node methods described above.

[0031] Other embodiments include a computer program comprising instructions which, when executed on processing circuitry of a source RAN node, cause the processing circuitry to carry out any one of the source RAN node methods described above.

[0032] Yet other embodiments include a carrier containing said computer program. The carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

[0033] BRIEF DESCRIPTION OF THE DRAWINGS

[0034] Aspects of the present disclosure are illustrated by way of example and are not limited by the accompanying figures with like references indicating like elements.

[0035] FIG. 1 is a schematic block diagram illustrating an example network, according to one or more embodiments of the present disclosure.

[0036] FIG. 2 is a table illustrating an example mobility change request message, according to one or more embodiments of the present disclosure. FIG. 3 is a table illustrating an example handover request message, according to one or more embodiments of the present disclosure.

[0037] FIG. 4 is a table illustrating an example handover preparation failure message, according to one or more embodiments of the present disclosure.

[0038] FIG. 5 is a table illustrating example cause values, according to one or more embodiments of the present disclosure.

[0039] FIGS. 6A, 6B, and 6C are tables illustrating an example complementary cause information IE, according to one or more embodiments of the present disclosure.

[0040] FIG. 7 is a signaling diagram illustrating an example message exchange between RAN nodes, according to one or more embodiments of the present disclosure.

[0041] FIG. 8 is a flow diagram illustrating an example method implemented by a target RAN node, according to one or more embodiments of the present disclosure.

[0042] FIG. 9 is a flow diagram illustrating an example method implemented by a source RAN node, according to one or more embodiments of the present disclosure.

[0043] FIG. 10 is a schematic block diagram illustrating an example RAN node, according to one or more embodiments of the present disclosure.

[0044] DETAILED DESCRIPTION

[0045] In the examples provided herein, examples may be given that are commonly associated with a particular generation of Third Generation Partnership Project (3GPP) networks. For example, the term gNB (a term that was first used in connection with 5G networks) may be used to refer to a RAN node of a 5G RAN. These specific examples are given solely for purposes of illustration and should not be interpreted to exclude other network elements, whether presently known or to be developed in the future. Indeed, the embodiments described herein may be applied to any generation of 3GPP network unless otherwise specified.

[0046] FIG. 1 is a schematic block diagram illustrating an example of a UE 110 connected to a wireless communication network 100. The network comprises a core network 160 and a RAN represented in this example by a first RAN node 120a and a second RAN node 120b. Each of the RAN nodes 120a, 120b serves a respective cell 130a, 130b through which the UE 110 may access the core network 160. The core network 160 comprises one or more core network nodes 140 that support the UE 110 in accessing core network services and / or resources provided by an external data network 170.

[0047] The UE 110 is connected to the network 100 via cell 130a served by RAN node 120a. The UE 110 is also within a coverage area provided by cell 130b. Under certain circumstances, it may (or may not) be advantageous for the RAN nodes 120a, 120b to perform a handover procedure so that UE 110 is handed over from cell 130a to cell 130b. Should the RAN nodes 120a, 120b perform a handover procedure for the UE 110, RAN node 120a may be considered a source RAN node and RAN node 120b may be considered a target RAN node. If the handover procedure is a conditional handover, RAN node 120b may be more specifically considered to be a candidate target RAN node 130b. Although further examples herein will not make a distinction between conditional and unconditional handovers nor between target RAN nodes and candidate target RAN nodes, it should be understood that the embodiments described herein may include handovers of any kind and, correspondingly, target RAN nodes or candidate target RAN nodes, as appropriate.

[0048] A mobility change, such as by performing a handover, may result in a Mobility Change Request being exchanged between the RAN nodes 120a, 120b. A traditional Mobility Change Request message comprises a Cause Information Element (IE) that can be used to indicate a reason for triggering the adaptation of mobility parameters. However, the amount of detail that traditional networks are able to communicate using such a mechanism is limited. Traditional networks are unable to provide significant insight regarding the underlying reason that triggered the change and how this impacts the neighbor node. This, in turn, limits the ability of the node receiving the request to decide the most appropriate course of action.

[0049] That is, in a traditional Mobility Setting Change procedure, the reason why the handover trigger point needs to be changed both at the source RAN node 120a and at the target RAN node 120b is not detailed enough. According to traditional techniques, it is not possible for the source and target nodes to determine the importance of changing the handover trigger point. Accordingly, there is inadequate information available to decide whether to accept or reject such reconfiguration.

[0050] Further, traditional networks lack a mechanism by which the handover trigger point change requested via the Mobility Setting Change procedure is adopted only for certain specific mobility procedures and not adopted for other mobility procedures.

[0051] Embodiments of the present disclosure solve one or more of the problems described above by adding information to a mobility change request. This additional information may, for example, comprise one or more additional cause elements. These additional cause elements may include, for example, one or more further cause values and / or details regarding the cause of the change. Such detail may, in some embodiments, be associated with one or more cause values that will be communicated to the receiving RAN node.

[0052] In general, either RAN node 120a, 120b may send a mobility change request to the other RAN node 120a, 120b. That said, for purposes of clarity of explanation and brevity, in many examples provided herein, RAN node 120a sends a mobility change request to RAN node 120b. Accordingly, RAN node 120a may be considered to be a sending RAN node and RAN node 120b may be considered to be a receiving RAN node. Notwithstanding, it should be understood that the features of RAN node 120a may be attributed to RAN node 120b, and vice versa. That is, in other embodiments, RAN node 120b may be the sending RAN node and RAN node 120a may be the receiving RAN node even though such scenarios may not be explicitly described. Upon receiving the change in mobility parameters of the sending RAN node 120a, and suggested parameters for the receiving RAN node 120b, the receiving RAN node 120b may evaluate the suggested parameters in the light of the communicated additional cause information in order to judge whether the mobility change should be accepted. In some embodiments, this evaluation may consider the priority or urgency of such a change.

[0053] Details regarding potential mobility procedure signaling (such as in the handover preparation for an handover or for a conditional handover), similar complementary information for the purpose of enabling the target RAN node 120b to understand what handover trigger point was adopted to trigger a specific handover, and / or what handover trigger point was adopted to trigger a specific type of handover (e.g., normal handover compared to a conditional handover) will be provided below.

[0054] As an example, if the Mobility Change Request signaled from a first RAN node 120a to a second RAN node 120b indicates that the cause of a handover trigger point change relates to saving energy, and if a Handover Request message is signaled from the first RAN node 120a to the second RAN node 120b that indicates that the handover cause relates to saving energy, then the target RAN node 120b can deduce that the handover has been triggered at the handover trigger point negotiated via the Mobility Setting Change procedure with an energy saving cause.

[0055] Accordingly, particular embodiments of the present disclosure will include an indication (e.g., in an extension to a traditional mobility message) of the reason for the mobility change. This indication may, for example, take the form of a cause value and / or what will be described in greater detail below as “complementary information.” The change may, for example, include a change to a handover trigger point, among other things.

[0056] The cause value may be one of a plurality of predefined values that indicate respective causes. The plurality of predefined values may correspond to an expanded list of causes relative to those available in traditional networks.

[0057] As discussed herein, the indication of cause may relate to a change that needs to be performed for fewer than all mobility events (e.g., for one or more particular mobility events and / or for one or more types of mobility events). For example, the handover trigger point may need to be changed for handovers triggered by coverage, handovers triggered in order to save energy, for conditional handovers, for non-conditional handovers, and so on.

[0058] The indication may be included in a message of a Mobility Change Request procedure that corresponds to the reason for which the handover trigger point needs to be changed. The additional information about the cause of the change request may, e.g., enable the receiving RAN node 120b to interpret the requested change in settings and / or policies at the originating RAN node 120a and decide whether to adjust its own settings accordingly.

[0059] The indication may additionally or alternatively be included within a Handover Request message. The additional information about the cause of the Handover Request message may, e.g., enable the target RAN node 120b to understand the handover trigger point used for triggering the mobility procedure. In some embodiments, the additional information in the Handover Request enables the target RAN node 120b to retrieve the handover trigger point configuration used by the source RAN node 120a for a specific mobility cause. In some such embodiments, the retrieved handover trigger point configuration is further used for the specific mobility cause with respect to a certain type of handover, which may be further indicated. Such configuration may be communicated from the source RAN node 120a to the target RAN node 120b by means of the Mobility Setting Change procedure.

[0060] Advantageously, a RAN node 120b receiving the enhanced cause information described herein may evaluate the communicated change in mobility settings with added context. As described before, the additional information can be used to evaluate differentiated behavior when accepting or rejecting a Mobility Change Request and may even lead to an additional change in parameter settings at the receiving RAN node 120b that may then be communicated via additional mobility change requests from the receiving RAN node 120b.

[0061] By adding similar information in the handover request message, the target RAN node 120b may determine that the handover was triggered at a handover trigger point that was negotiated via the Mobility Setting Change procedure carrying the same further cause information as that included in the Handover Request message (e.g., “complimentary” cause information). With this, the target RAN node 120b can determine whether to commit to a handover trigger point towards the source RAN node 120a that matches the handover trigger point adopted by the source or suggest different handover trigger point towards the source RAN node 120a for the mobility procedure to which the complementary information received by the source RAN node 120a refers to. This may avoid ping pong effects.

[0062] In some embodiments, the proposed additional cause information (e.g., extended cause values, additional “complementary information”) provided with a mobility settings change message and / or handover request message enables the receiving RAN node 120b to interpret actions and / or procedures of the sending RAN node 120a and / or consequences of such actions that may be valid for a certain future time horizon (e.g., for a certain reference prediction time in the future, or for a certain reference prediction time interval in the future, such as a Requested Prediction Time that is either agreed before or configured by an Operations and Maintenance (OAM) node).

[0063] As discussed herein, an enhanced cause value may be provided in the traditional cause IE or in an additional cause IE. For example, the traditional cause IE may support one or more additional predefined values. Alternatively, the traditional cause IE may be unmodified from current standards and an additional cause IE may be included in the Mobility Setting Change procedure and / or Handover Request message as discussed above.

[0064] FIGS. 2-4 are tables, each describing a respective message that has been extended according to embodiments of the present disclosure. FIG. 2 describes an example mobility change request message. FIG. 3 describes an example handover request message. FIG. 4 describes an example handover preparation failure message. Each of the messages of FIGS. 2-4 comprises a cause IE that supports one or more enhanced cause values as shown in the table of FIG. 5. In the example of FIG. 5, values that are traditionally supported by the cause IE are omitted for brevity and clarity of explanation. Each message may also include a complementary cause information IE in which further cause information may be provided. FIGS. 6A, 6B, and 6C illustrate an example of values that may be supported by such a complementary cause information IE.

[0065] The enhanced cause value (e.g., one of the values enumerated in FIG. 5) may relate to a change that is requested for one, some, or all mobility procedures and / or events (e.g., to particular events or event types). An enhanced cause value may indicate any one or more of the following as a cause:

[0066] • Network energy savings (e.g., the change is intended to achieve improvement in energy saving and / or the change relates to mobility procedures triggered due to energy savings);

[0067] • Dynamic cell shaping (e.g., the change is intended to adapt to dynamic cell shaping events);

[0068] • Coverage and capacity optimization (e.g., the change is intended to adapt to coverage and capacity optimization events and / or the change is for mobility procedures triggered due to coverage and / or capacity optimization);

[0069] • Energy efficiency (e.g., the change is intended to achieve improvement in energy efficiency and / or the change is for mobility procedures triggered for energy efficiency reasons);

[0070] • Critical service (e.g. the change is intended to achieve improved handling of critical services and / or the change is for mobility procedures triggered for UEs using critical services);

[0071] • Throughput critical service (e.g., the change is intended to achieve improved handling of throughput critical services and / or the change is for mobility procedures triggered for UEs using throughput critical services);

[0072] • Delay critical service (e.g., the change is intended to achieve improved handling of delay critical services and / or the change is for mobility procedures triggered for UEs using delay critical service);

[0073] • Ultra reliable service (e.g., the change is intended to achieve improved handling of ultra reliable services and / or the change is for mobility procedures triggered for UEs using ultra reliable services);

[0074] • and / or Ultra Reliable Low Latency Service (e.g., the change is intended to achieve improved handling of ultra reliable low latency services and / or the change is for mobility procedures triggered for UEs using ultra reliable low latency services); • Services with bounded latency requirements (e.g., the change is intended to achieve improved handling of services with bounded latency requirements and / or the change is for mobility procedures triggered for UEs using services with bounded latency requirements);

[0075] • Time Sensitive Communication (TSC) (e.g., the change is intended to achieve improved handling of TSC and / or the change is for mobility procedures triggered for TSC (or for UEs using TSC))

[0076] • Time Sensitive Networking (TSN) (e.g., the change is intended to achieve improved handling of TSN and / or the change is for mobility procedures triggered for TSN (or for UEs using TSN))

[0077] • Emergency service (e.g., the change is intended to achieve improved handling of emergency services and / or the change is for mobility procedures triggered for UEs using emergency services);

[0078] • Private network access (e.g., the change is intended to achieve improvement in private network access and / or the change is for mobility procedures triggered for private network access reasons);

[0079] • Non-terrestrial network access and / or mobility (e.g., the change is intended to achieve improvement in non-terrestrial network access and / or mobility and / or the change is for mobility procedures triggered for non-terrestrial network access and / or mobility reasons);

[0080] • Performance optimization (e.g., the change is intended to achieve improved performance and / or the change is for mobility procedures triggered for performance reasons);

[0081] • Conditional handover priority (e.g., the change is intended to achieve a prioritization of different conditional handover candidate cells or different conditional handover configurations, such as for load balancing purposes).

[0082] Additionally or alternatively, “complementary cause information” may be included in any of the messages described above. As discussed herein, complementary cause information may be provided in the traditional cause IE or in a different IE (e.g., in an IE as shown in FIGS. 6A- 6C). The complementary cause information may comprise its own cause value (such as the enhanced cause value discussed above) and / or may provide further information, insights, and / or details regarding one or more reasons for a node to initiate a change in a mobility trigger or handover initiation. The complementary cause information may, in some embodiments, comprise different parameters depending on the complementary cause information. Examples of parameters that may be included in an IE for complementary cause information include an indication of:

[0083] • A characteristic of a cell and / or node in relation to the cause that triggered the mobility change request, such as: o An energy cost; o An energy savings state; o One or more cell shaping actions (currently active and / or soon to be taken); o One or more cell coverage (currently active and / or about to occur); o Load balancing actions (occurring and / or soon to start);

[0084] • One or more times of an expected action (e.g., expressed as an absolute time or as a time in relation to another time or event). For example, one or more mobility triggers are valid between times T 1 and T2 and between times T3 and T4. Examples time indications may include: o a time in the future when an action is expected; o a time interval in the future within which an action is expected; o a periodicity of an action; o an expected duration or periodicity of the suggested mobility settings change in the receiving RAN node 120b;

[0085] • one or more objectives of the RAN node 120 sending the complimentary information. The information about the objective(s) may be useful to the RAN node 120 receiving the information in evaluating future handovers toward the sending RAN node 120a (e.g., such information may be evaluated against periodic status updates exchanged between neighboring RAN nodes 120, e.g., using Resource Status Update messages or Data Collection Update messages). Example objectives may include: o a Physical Resource Block (PRB) utilization target; o an energy savings target; o an energy cost target; o composite available capacity targets.

[0086] • A Quality of Service (QoS) profile for QoS Flows and / or Data Radio Bearers (DRBs) that will be handed over according to the indicated handover trigger point. This may include, e.g., throughput, packet delay budget, target packet error rate, 5G QoS Identifier (5QI), Allocation and Retention Priority (ARP), scheduling priority, and the like;

[0087] • Priority order associated with the corresponding conditional handover action. By using this indicator, the source RAN node 120a may, e.g., use different handover trigger points to prioritize different conditional handover actions. For example, a priority 1 for a conditional handover configuration related to energy savings and a priority 2 for a conditional handover configuration related to load balancing.

[0088] In view of the above, a RAN node 120b may accept, reject, or modify one or more settings suggested in a mobility change request based on the additional cause information provided. Similarly, the above information may facilitate evaluation of future handover decisions towards the RAN node 120a providing the information, thereby minimizing the likelihood of a rejected handover request.

[0089] For example, when the source RAN node 120a signals to the target RAN node 120b a Mobility Change Request with the additional information above included, the target RAN node 120b understands that the source RAN node 120a wants to change its handover trigger point from certain cells (e.g., cell 130a) of the source RAN node 120a to certain cells (e.g., cell 130b) of the target RAN node 120b for the reason specified by the additional information included.

[0090] Alternatively, the source RAN node 120a may want to change its handover trigger point from certain cells 130a of the source RAN node 120a to certain cells 130b of the target RAN node 120b only for specific mobility events, which will be marked by adding the same additional information in the handover request message. In one embodiment, the source RAN node 120a includes in the Mobility Change Request a specific flag that indicates to the target RAN node 120b whether the handover trigger point is changed for all mobility events or only for the mobility events triggered for the reasons described in the additional information. Such flag may be called, for example, Event Based Change IE and may support values “true” or “false”.

[0091] In another embodiment, the source RAN node 120a may include an identifier in the Mobility Change Request. The identifier may identify the Mobility Setting Change procedure. The target RAN node 120b may also generate an identifier for the Mobility Setting Change procedure and signal the identifier in a Mobility Change Acknowledge message. This set of identifiers identify the changes in the handover trigger point agreed between source and target RAN nodes 120a, 120b for handover events characterized by the additional characteristics indicated in the Mobility Change Request message. Upon the occurrence of a handover preparation procedure for a handover that falls within the characterization indicated by the additional characteristics indicated in the Mobility Change Request message, the source RAN node 120a may include in an Xn: Handover Request message (or similar message to initiate the handover preparation) the set of identifiers exchanged between source RAN node 120a and target RAN node 120b in the Mobility Change Request / Acknowledge messages. With the reception of the set of identifiers in the Handover Request message, the target RAN node 120b understands that the handover was triggered by the source RAN node 120a at the handover trigger point negotiated via the Mobility Setting Change carrying the same set of identifiers. This enables the target RAN node 120b to adopt matching handover trigger points for the same UE 110, thereby avoiding ping pong and late handover conditions.

[0092] When the target RAN node 120b receives the Mobility Change Request with the additional information described above, it may decide to accept the request and adapt its handover trigger point from those of cell(s) 130b at the target RAN node 120b to cell(s) 130a at the source RAN node 120a in a way that matches the configuration adopted at the source RAN node 120a. Alternatively, the target RAN node 120b may decide to reject the change request. It should be noted that if the Mobility Change Request implies a change of the handover trigger point only for specific mobility events, a successful reply by the target RAN node 120b implies that a matching handover trigger point will be used by the target RAN node 120b for the same mobility events of UEs 110 going from cell(s) 130b of the target RAN node 120b to cell(s) 130a at the source RAN node 120a.

[0093] The embodiments above can be used in conjunction with Artificial Intelligence (Al) I Machine Learning (ML) based techniques that take action on UE mobility to optimize different aspects of network performance such as load balancing, energy efficiency and UE performance. In such case, the handover trigger point suggested by the source RAN node 120a to the target RAN node 120b for specific mobility events or for all mobility events may be the result of AI / ML inference by which it is predicted that such handover trigger point improves network performance for some or all of the mobility events and / or UEs 110 in the network 100.

[0094] FIG. 7 is a signaling diagram illustrating an example process in which one or more handover trigger points are changed for one or more specific mobility events. At step 210, the source RAN node 120a sends a mobility change request to the target RAN node 120b. The mobility change request may indicate a cause (e.g., energy saving), complementary cause information, whether the change is an event based change (e.g., which may be true or false), and one or more handover trigger points between source cell 130a and target cell 130b (e.g., sent in a Mobility Parameters IE for the source RAN node 120a).

[0095] At step 220, the target RAN node 120b sends an mobility change acknowledgement to the source RAN node 120a. At step 230, the source RAN node 120a sends a handover request to the target RAN node 120b. The handover request may indicate a cause of the handover request that matches the cause indicated in the mobility change request (e.g., energy saving).

[0096] At step 240, the target RAN node 120b determines (e.g., from the cause information) that the handover trigger point used by the source RAN node 120a for this handover is the handover trigger point sent by the source RAN node 120a in step 210. Accordingly, the target RAN node 120b uses a matching handover trigger point for this UE 110 toward cell(s) 130a of the source RAN node 120a, thereby avoiding ping pong effects or late handovers. At step 250, the target RAN node 120b transmits a handover response to the source RAN node 120a.

[0097] Thus, in the example of FIG. 7, the source RAN node 120a and the target RAN node 120b adopt handover trigger points specific to a UE 110 and specific to a cause (energy savings) for which the UE was initially handed over from source to target. Other UEs not handed over for the same cause may not be subject to the same handover trigger points.

[0098] As noted above, the RAN nodes 120a, 120b may exchange identifiers during the change procedure. For example, in step 210 the source RAN node 120a may include a first mobility settings identifier in the mobility change request and, in step 220, the target RAN node 120b may include a second mobility settings identifier in the mobility change acknowledgement. In step 230, the source RAN node 120a may include both the first and the second mobility identifiers in the handover request. By checking the mobility settings identifiers in the handover request, the target RAN node 120b may determine that the handover trigger point for the UE 110 being handed over is the handover trigger point included in the mobility change request of step 210. Accordingly, as noted above, the target RAN node 120b may use a matching handover trigger point for this UE 110 toward cell(s) 130a of the source RAN node 120a, thereby avoiding ping pong effects or late handovers.

[0099] In view of the above, FIG. 8 is a flow diagram illustrating an example method 300 implemented by a target RAN node 120b according to one or more embodiments of the present disclosure. The method 300 comprises receiving, from a source RAN node 120a, a mobility change request that requests a change to a handover trigger point used by the target RAN node 120b to trigger handover from the target RAN node 120b (block 310). The method 300 further comprises changing the handover trigger point of the target RAN node 120b based on the mobility change request (block 330). In some embodiments, the method 300 further comprises receiving a handover request from the source RAN node 120a (block 320). In some such embodiments, changing the handover trigger point of the target RAN node 120b based on the mobility change request comprises changing the handover trigger point in response to detecting a correspondence between the handover request and the mobility change request.

[0100] Correspondingly, FIG. 9 is a flow diagram illustrating an example method 400 implemented by a source RAN node 120a according to one or more embodiments of the present disclosure. The method 400 comprises transmitting, to a target RAN node 120b, a mobility change request that requests a change to a handover trigger point used by the target RAN node 120b to trigger handover from the target RAN node 120b (block 410). The method 400 further comprises transmitting, to the target RAN node 120b, a handover request triggered based on the handover trigger point (block 420).

[0101] A RAN node 120 may be implemented as schematically illustrated in the example of FIG. 10. The RAN node 120 of FIG. 10 comprises processing circuitry 710, memory circuitry 720, and interface circuitry 730. The processing circuitry 710 is communicatively coupled to the memory circuitry 720 and the interface circuitry 730, e.g., via a bus 704. The processing circuitry 710 may comprise one or more microprocessors, microcontrollers, hardware circuits, discrete logic circuits, hardware registers, digital signal processors (DSPs), field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), or a combination thereof. For example, the processing circuitry 710 may be programmable hardware capable of executing software instructions stored, e.g., as a machine-readable computer program 740 in the memory circuitry 720. The memory circuitry 720 of the various embodiments may comprise any non- transitory machine-readable media known in the art or that may be developed, whether volatile or non-volatile, including but not limited to solid state media (e.g., SRAM, DRAM, DDRAM, ROM, PROM, EPROM, flash memory, solid state drive, etc.), removable storage devices (e.g., Secure Digital (SD) card, miniSD card, microSD card, memory stick, thumb-drive, USB flash drive, ROM cartridge, Universal Media Disc), fixed drive (e.g., magnetic hard disk drive), or the like, wholly or in any combination.

[0102] The interface circuitry 730 may be a controller hub configured to control the input and output (I / O) data paths of the RAN node 120. Such I / O data paths may include data paths for exchanging signals over a network. The interface circuitry 730 may be implemented as a unitary physical component, or as a plurality of physical components that are contiguously or separately arranged, any of which may be communicatively coupled to any other or may communicate with any other via the processing circuitry 710. For example, the interface circuitry 730 may comprise a transmitter 732 configured to send wireless communication signals and a receiver 734 configured to receive wireless communication signals.

[0103] The RAN node 120 may be configured (e.g., by the processing circuitry 710) to perform the method 300 and / or the method 400 described above. For example, the RAN node 120 may be configured to act as a target RAN node 120b and perform the method 300 to handle a mobility change request from a source RAN node 120a. Additionally or alternatively, the RAN node 120 may be configured to act as a source RAN node 120a to request that a target RAN node 120b change its handover trigger point. It will be understood that each RAN node 120 of a network 100 may interact dynamically with other RAN nodes 120 in the network 100 to implement one or more improvements described herein, e.g., to effectuate mobility changes in the network that improve network performance, avoid handover ping pong effects and / or other improvements.

[0104] Still other embodiments include a control program 740 comprising instructions that, when executed on processing circuitry 710 of a RAN node 120, cause the RAN node 120 to carry out the method 300 and / or method 400 described above.

[0105] Yet other embodiments include a carrier containing the control program 740. The carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

[0106] Although the various communication devices described herein may include the illustrated combination of hardware components, other embodiments may comprise computing and / or communication hardware with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and / or software needed to perform the tasks, features, functions, and methods disclosed herein. Further, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, the devices described herein may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components.

Claims

CLAIMSWhat is claimed is:

1. A method (300), implemented by a target Radio Access Network, RAN, node (120b), the method comprising: receiving (310), from a source RAN node (120a), a mobility change request that requests a change to a handover trigger point used by the target RAN node (120b) to trigger handover from the target RAN node (120b); and changing (330) the handover trigger point of the target RAN node (120b) based on the mobility change request.

2. The method of claim 1 , further comprising receiving (320) a handover request from the source RAN node (120a), wherein changing the handover trigger point of the target RAN node (120b) based on the mobility change request comprises changing the handover trigger point in response to detecting a correspondence between the handover request and the mobility change request.

3. The method of claim 2, wherein changing the handover trigger point in response to detecting the correspondence comprises changing the handover trigger point responsive to detecting that the handover request and the mobility change request comprise matching cause information.

4. The method of claim 2, wherein: the mobility change request further comprises an identifier associated with the requested change; the method further comprises transmitting, in response to the mobility change request, an acknowledgement comprising a further identifier associated with the requested change; and changing the handover trigger point in response to detecting the correspondence comprises changing the handover trigger point responsive to detecting that the handover request comprises the identifier and the further identifier.

5. The method of any one of claims 2-4, further comprising determining whether to accept or reject the handover request based on cause information comprised in the mobility change request.

6. The method of any one of claims 1-5, wherein: the mobility change request indicates that the handover trigger point relates to one or more specific mobility events; andchanging the handover trigger point comprises changing the handover trigger point for the one or more specific mobility events without changing the handover trigger point for at least one other mobility event.

7. The method of any one of claims 1-6, wherein: the mobility change request comprises first cause information and second cause information that is more detailed than the first cause information; and changing the handover trigger point of the target RAN node (120b) based on the mobility change request comprises changing the handover trigger point based on the second cause information.

8. The method of claim 7, wherein changing the handover trigger point of the target RAN node (120b) based on the mobility change request further comprises changing the handover trigger point further based on the first cause information.

9. The method of any one of claims 1-8, wherein the mobility change request indicates that a reason for changing the handover trigger point comprises network energy savings.

10. The method of claim 9, wherein the mobility change request further indicates an energy cost related to the reason for changing the handover trigger point.

11. The method of any one of claims 1-10, wherein the mobility change request indicates that a reason for changing the handover trigger point comprises coverage and / or capacity optimization.

12. The method of claim 11 , wherein the mobility change request further indicates a coverage state related to the reason for changing the handover trigger point.

13. The method of any one of claims 9-12, wherein the mobility change request further indicates: a time when the changing of the handover trigger point is expected; or a time window within which the changing of the handover trigger point is expected.

14. A target Radio Access Network, RAN, node (110b), configured to: receive, from a source RAN node (120a), a mobility change request that requests a change to a handover trigger point used by the target RAN node (120b) to trigger handover from the target RAN node (120b); andchange the handover trigger point of the target RAN node (120b) based on the mobility change request.

15. The target RAN node of the preceding claim, further configured to perform the method of any one of claims 2-13.

16. A target Radio Access Network, RAN, node (120b), comprising: interface circuitry (730) and processing circuitry (710) communicatively connected to the interface circuitry (730), wherein the processing circuitry (710) is configured to: receive, from a source RAN node (120a) via the interface circuitry (730), a mobility change request that requests a change to a handover trigger point used by the target RAN node (120b) to trigger handover from the target RAN node (120b); and change the handover trigger point of the target RAN node (120b) based on the mobility change request.

17. The target RAN node of the preceding claim, wherein the processing circuitry (710) is further configured to perform the method of any one of claims 2-13.

18. A computer program, comprising instructions which, when executed on processing circuitry (710) of a target Radio Access Network, RAN, node (120b), cause the processing circuitry (710) to carry out the method according to any one of claims 1-13.

19. A carrier containing the computer program of the preceding claim, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

20. A method (400), implemented by a source Radio Access Network, RAN, node (120a), the method comprising: transmitting (410), to a target RAN node (120b), a mobility change request that requests a change to a handover trigger point used by the target RAN node (120b) to trigger handover from the target RAN node (120b); and transmitting (420), to the target RAN node (120b), a handover request triggered based on the handover trigger point.

21. The method of claim 20, wherein the handover request and the mobility change request comprise matching cause information.

22. The method of any one of claims 20-21 , wherein: the mobility change request further comprises an identifier associated with the requested change; the method further comprises receiving, in response to the mobility change request, an acknowledgement comprising a further identifier associated with the requested change; and transmitting the handover request comprises including the identifier and the further identifier in the handover request.

23. The method of any one of claims 20-22, wherein: the mobility change request indicates that the change requested relates to one or more specific mobility events; and transmitting the handover request is responsive to one or more of the specific mobility events occurring.

24. The method of any one of claims 20-23, wherein: the mobility change request comprises first cause information and second cause information that is more detailed than the first cause information; and the handover request is responsive to a handover being triggered due to a cause consistent with the first cause information and the second cause information in the mobility change request.

25. The method of any one of claims 20-24, wherein the mobility change request indicates that a reason for changing the handover trigger point comprises network energy savings.

26. The method of claim 25, wherein the mobility change request further indicates an energy cost related to the reason for changing the handover trigger point.

27. The method of any one of claims 20-26, wherein the mobility change request indicates that a reason for changing the handover trigger point comprises coverage and / or capacity optimization.

28. The method of claim 27, wherein the mobility change request further indicates a coverage state related to the reason for changing the handover trigger point.

29. The method of any one of claims 25-28, wherein the mobility change request further indicates: a time when the changing of the handover trigger point is expected; or a time window within which the changing of the handover trigger point is expected.

30. A source Radio Access Network, RAN, node (110a), configured to: transmit, to a target RAN node (120b), a mobility change request that requests a change to a handover trigger point used by the target RAN node (120b) to trigger handover from the target RAN node (120b); and transmit, to the target RAN node (120b), a handover request triggered based on the handover trigger point.

31. The source RAN node of the preceding claim, further configured to perform the method of any one of claims 21-29.

32. A source Radio Access Network, RAN, node (120a), comprising: interface circuitry (730) and processing circuitry (710) communicatively connected to the interface circuitry (730), wherein the processing circuitry (710) is configured to: transmit, to a target RAN node (120b) via the interface circuitry (730), a mobility change request that requests a change to a handover trigger point used by the target RAN node (120b) to trigger handover from the target RAN node (120b); and transmit, to the target RAN node (120b) via the interface circuitry (730), a handover request triggered based on the handover trigger point.

33. The source RAN node of the preceding claim, wherein the processing circuitry (710) is further configured to perform the method of any one of claims 21-29.

34. A computer program, comprising instructions which, when executed on processing circuitry (710) of a source Radio Access Network, RAN, node (120a), cause the processing circuitry (710) to carry out the method according to any one of claims 20-29.

35. A carrier containing the computer program of the preceding claim, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

Images