Maintaining / Changing MR-DC at conditional handover (CHO)

Abstract

Techniques for conditional reconfiguration in multi-connectivity scenarios. In an example method, a first network node configured to function as a master node, MN, for multi-connectivity operation of a wireless device and a second network node configured to function as a secondary node, SN, for the wireless device determine (810) to configure the wireless device with conditional reconfiguration and send (820) a handover request message to a third network node, the handover request message including an indication that the handover request message is for a conditional handover. The first network node receives (830) an acknowledgement of the handover request message and, in response, delays (840) sending a release message to the second network node until the first network node receives an indication that the conditional handover was performed.

Description

Technical Field

[0001] This disclosure generally relates to wireless communication devices, and more specifically to condition reconfiguration in multi-connection operation scenarios. Background Technology

[0002] In new radio (NR) systems, some reconfiguration processes are particularly prone to failure, and NR radio links are more susceptible to rapid fading due to their higher operating frequencies. Conditional reconfiguration is a method to improve robustness against failure in this regard. In this method, the network sends a conditional reconfiguration message to the radio device, specifying the conditions that will trigger the device to perform the reconfiguration. The radio device waits to perform the reconfiguration until it detects that the condition has been met. Once the device detects the condition, it can autonomously perform the reconfiguration without receiving any further signaling, thus demonstrating the reconfiguration's robustness against link degradation.

[0003] The term "multi-connectivity" or "multi-connectivity operation" refers to a radio device (e.g., at the Radio Resource Control (RRC) layer) simultaneously connecting to multiple different radio network nodes, or connecting to multiple different cells provided by different radio network nodes. In radio networks developed by members of the 3rd Generation Partnership Project (3GPP), one type of multi-connectivity operation is called Multi-Radio Dual Connectivity (MR-DC). User equipment (UE) operating in MR-DC has a primary node (MN) connection and a secondary node (SN) connection. An example of an MR-DC configuration is EUTRAN-NR Dual Connectivity (EN-DC), where an LTE eNodeB acts as the MN and an NR gNodeB acts as the SN. Other configurations are also possible, for example, where both the MN and SN are NR gNodeBs.

[0004] Due to 3GPP specification version 15, for a UE operating in an MR-DC, the node acting as the MN can trigger a handover (synchronous reconfiguration) for the UE operating in the MR-DC. When this occurs, the target MN receiving the handover request can decide to release the MR-DC or continue MR-DC operation with the incoming UE.

[0005] While this conditional reconfiguration approach can improve robustness against failure, its use proves challenging in certain contexts. More specifically, known methods for conditional reconfiguration fail to adequately account for the diversity of radio network nodes or cells involving multiple connections. Summary of the Invention

[0006] In MR-DC, the expected time between sending the SN Add Request message for establishing an SN and receiving the message indicating SN reconfiguration completion is quite short. This is because in a CHO (Content on a UE's Memory Hazard) scenario, the UE may need more time to access the candidate target MN, or may not even attempt to access it, potentially leading to numerous unintended SN releases from the candidate target SN. This can create race conditions, for example, where the candidate target MN must repeatedly modify its CHO configuration against the source MN.

[0007] In addition to this issue, when the target MN candidate sends a handover request confirmation message in response to a CHO, the traditional procedure defines the source MN as releasing the SN in the event of deciding whether to keep or change the SN. However, this is not the desired behavior in the case of a CHO, because the equivalent change at the UE is only performed when the condition is met.

[0008] The various embodiments described herein address some or all of these problems.

[0009] According to a specific embodiment, the first example method includes a method performed by a first network node configured to serve as a primary network node for multi-connection operations of a wireless device. In some embodiments, the method includes: determining to configure the wireless device with conditional reconfiguration. The method may further include: sending a handover request message to a third network node, the handover request message including an indication that the procedure is for conditional handover. The method may further include: receiving an acknowledgment of the handover request message, and, in response, delaying the sending of a release message to a second network node, the second network node serving as a secondary network node for the wireless device.

[0010] According to other specific embodiments, the second example method includes a method performed by a network node configured to serve as a candidate target network node for multi-connection operations of a wireless device. The method includes: receiving (910) a handover request message for the wireless device from a source network node, the handover request message including an indication that the procedure is for conditional handover. The method further includes: sending a secondary node add request to a candidate target secondary network node, the secondary node add request including an indication that the request is for conditional handover. The method further includes: receiving an acknowledgment of the secondary node add request and sending an acknowledgment of the handover request to a first network node.

[0011] According to other specific embodiments, a third example method includes a method performed by a network node that can be configured to serve as a candidate target secondary node for a wireless device. The method includes: receiving a secondary node add request, the secondary node add request including an indication that the request is for conditional reconfiguration. The method further includes: sending an acknowledgment of the secondary node add request in response to the secondary node add request. In some embodiments, the method may include: starting a monitoring timer in response to receiving the secondary node add request; this may include: setting the monitoring timer to a value based on the request being an indication for conditional switching.

[0012] According to other specific embodiments, the fourth example method includes a method performed by a network node configured to act as a candidate target master node for multi-connection operations of a wireless device. The method includes: receiving an RRC reconfiguration complete message from the wireless device. The method further includes: determining that the wireless device has been configured for conditional reconfiguration and that the wireless device has associated multi-connection related configurations for the candidate target secondary node. The method further includes: sending a secondary node reconfiguration complete message to the candidate target secondary node and sending a message to the source master node of the wireless device.

[0013] According to other specific embodiments, the fifth example method includes a method performed by a network node configured to serve as a candidate target secondary node for a wireless device. The method includes, for example, receiving a secondary node reconfiguration completion message from a primary node candidate target for conditional switching of the wireless device. The method further includes stopping a monitoring timer associated with the conditional secondary node addition for the wireless device. The method also includes treating the context associated with the wireless device as active.

[0014] According to other specific embodiments, the sixth example method includes a method performed by a network node configured to act as a master network node for multi-connection operations of a wireless device. The method includes receiving a message from a candidate target master node to which the wireless device has performed a conditional handover. The method further includes sending a message to a candidate target master node for which a conditional handover of the wireless device has been configured but not yet executed, the message indicating that the conditional handover configuration for the wireless device will be released.

[0015] The seventh example method includes a method performed by a candidate target master node for a multi-connection conditional handover of a wireless device. The method includes: receiving from the source master node of the wireless device a message indicating that the conditional reconfiguration for the wireless device will be released; and determining that the conditional reconfiguration for the wireless device has associated target secondary node candidates for the conditional handover. The method may further include: sending a secondary node release request message to the target secondary node candidates.

[0016] The advantages of the disclosed embodiments are that they enable UEs operating in MR-DC to be configured for conditional reconfiguration (e.g., conditional handover - CHO), and they enable candidate target MNs to maintain SN or modify / change SN.

[0017] According to various embodiments, the target MN candidate can configure the SN candidate target to maintain or change the SN without the risk of the SN candidate target setting the supervision timer too short, as this is obvious for CHO. Since the time between sending the SN add request and receiving the SN reconfiguration completion is longer than conventional methods, and because in CHO, the UE may need a longer time to access the candidate target MN, or even be unable to access it, this method can be used to avoid undesirable SN releases from the candidate target SN. This avoids a considerable amount of contention, for example, where the candidate target MN must modify its CHO configuration against the source MN. In some embodiments, considering that the UE may connect after a longer time compared to conventional SN add or may not connect at all, the candidate target SN can also reserve resources for the UE, which will result in optimized resource allocation within the node.

[0018] Furthermore, in some embodiments, when the target MN candidate sends a switch request confirmation message in response to a CHO, if it has already decided to keep or change the SN, the method prevents the process of defining the source MN to release the SN by delaying the action until the CHO is executed.

[0019] The embodiments herein also include corresponding apparatus, computer programs, and carriers of such computer programs. Examples of the embodiments herein include various network nodes configured to perform any steps of any of the embodiments described above. Attached Figure Description

[0020] Figure 1 An example signaling flow for inter-MN handover is shown with or without an MN-initiated SN change.

[0021] Figure 2 This demonstrates the successful preparation operation for adding an NG-RAN node.

[0022] Figure 3 The successful completion of the S-NG-RAN node reconfiguration process is shown.

[0023] Figure 4 This is a signal flow diagram illustrating an example method including CHO preparation.

[0024] Figure 5 This is a signal flow diagram illustrating an example method performed by a CHO.

[0025] Figure 6This is a signal flow diagram illustrating an example method including CHO cancellation.

[0026] Figure 7 This illustrates aspects of currently disclosed technology related to wireless devices.

[0027] Figure 8 Example methods according to some embodiments are shown.

[0028] Figure 9 Example methods according to some embodiments are shown.

[0029] Figure 10 Example methods according to some embodiments are shown.

[0030] Figure 11 Example methods according to some embodiments are shown.

[0031] Figure 12 Example methods according to some embodiments are shown.

[0032] Figure 13 Example methods according to some embodiments are shown.

[0033] Figure 14 Example methods according to some embodiments are shown.

[0034] Figure 15 Example methods according to some embodiments are shown.

[0035] Figure 16 Example methods according to some embodiments are shown.

[0036] Figure 17 This is a block diagram showing an example network node.

[0037] Figure 18A and Figure 18B Example information elements are shown.

[0038] Figure 19A and Figure 19B The example SN adds a request message.

[0039] Figure 20A and Figure 20B A sample switch request message is shown together.

[0040] Figure 21 This shows an example definition of a handover success message from the 3GPP specification.

[0041] Figure 22A and Figure 22B Together, an example implementation of the 3GPP specification is shown, including the definition of the SN release request confirmation message.

[0042] Figure 23A and Figure 23B Together, an example implementation of the 3GPP specification is shown, including the definition of the Xn-U address indication message.

[0043] Figure 24 An example implementation of SN status transmission messages in the 3GPP specification is shown.

[0044] Figure 25 This is a signal flow diagram illustrating the switching between MNs with / without MN-initiated SN changes.

[0045] Figure 26 This is a signal flow diagram illustrating the switching between MNs with / without an SN change process initiated by an MN.

[0046] Figure 27 This is a block diagram of a wireless communication network according to some embodiments.

[0047] Figure 28 This is a block diagram of a user device according to some embodiments.

[0048] Figure 29 This is a block diagram of a virtualized environment according to some embodiments.

[0049] Figure 30 This is a block diagram of a communication network having a host computer according to some embodiments.

[0050] Figure 31 This is a block diagram of a host computer according to some embodiments.

[0051] Figure 32 This is a flowchart illustrating a method implemented in a communication system according to one embodiment.

[0052] Figure 33 This is a flowchart illustrating a method implemented in a communication system according to one embodiment.

[0053] Figure 34 This is a flowchart illustrating a method implemented in a communication system according to one embodiment.

[0054] Figure 35 This is a flowchart illustrating a method implemented in a communication system according to one embodiment. Detailed Implementation

[0055] In the following description, exemplary embodiments of the present disclosure will be described more fully with reference to the accompanying drawings, which illustrate examples of embodiments of the inventive concept. However, the inventive concept can be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the inventive concept to those skilled in the art. It should also be noted that these embodiments are not mutually exclusive. Components from one embodiment may be assumed to exist / be used in another embodiment. Any two or more embodiments described in this document can be combined with each other.

[0056] UEs operating in MR-DC maintain / change MR-DC during movement

[0057] In MR-DC (Multi-Radio Dual Connectivity), a UE has a primary node (MN) connection and a secondary node (SN) connection. An example of an MR-DC configuration is EUTRAN-NR Dual Connectivity (EN-DC), where the LTE eNodeB acts as the MN and the NRgNodeB acts as the SN. Other configurations are also possible, for example, where both the MN and SN are NR gNodeBs.

[0058] Due to 3GPP specification version 15, for a UE operating in an MR-DC, the node acting as the MN can trigger a handover (synchronous reconfiguration) for the UE operating in the MR-DC. When this occurs, the target MN receiving the handover request can decide to release the MR-DC or continue MR-DC operation with the incoming UE.

[0059] The entire process (or set of processes) involved in these situations is covered in 3GPP TS37.340, more specifically in Section 10.7 for the MR-DC situation (10.7.2). As discussed therein, inter-MN handovers with / without MN-initiated SN changes are used to transfer UE context data from the source MN to the target MN, while the UE context at the SN is maintained or moved to another SN. During the inter-master node handover, the target MN decides whether to maintain or change the SN, or release the SN.

[0060] Figure 1 An example signaling flow for inter-MN handover with or without MN-initiated SN changes is shown. The steps illustrated in the figure include the following:

[0061] 1. The source MN initiates a handover by sending a handover request to the target MN.

[0062] 2. If the target MN decides to maintain the source SN, the target MN sends an SN add request to the SN, which includes the SN UE XnAP ID as a reference to the UE context established by the source MN in the SN. If the target MN decides to change the SN, the target MN sends an SN add request to the target SN, which includes the UE context established by the source MN in the source MN.

[0063] 3. The (target) SN uses the SN to add a request confirmation in response. The (target) SN may include indications of the full or incremental RRC configuration.

[0064] 4. The target MN includes an MN RRC reconfiguration message to be sent to the UE for handover in the handover request confirmation message, and may also provide a forwarding address to the source MN. If PDU session splitting is performed on the target side during the handover process, more than one data forwarding address corresponding to each node is included in the handover request confirmation message. If the target MN and SN decide to maintain the UE context in the SN in steps 2 and 3, the target MN instructs the source MN to maintain the UE context in the SN.

[0065] 5a / 5b. The source MN sends an SN release request message to the (source) SN, which includes an indication of the reason for MCG mobility. The (source) SN acknowledges the release request. If the source MN receives an indication from the target MN, the source MN instructs the (source) SN to maintain the UE context in the SN. If an indication to maintain the UE context in the SN is included, the SN maintains the UE context.

[0066] 5c. The source MN sends an XN-U address indication message to the (source) SN to transmit data forwarding information. If the PDU session is split on the target side, more than one data forwarding address can be provided.

[0067] 6. The source MN triggers the UE to perform a handover and apply the new configuration by sending an RRC Connection Reconfiguration message.

[0068] 7 / 8. Random Access Procedure: The UE synchronizes with the target MN and replies with the MN RRC reconfiguration completion message.

[0069] 9. If the UE is configured with a bearer that requires SCG radio resources, the UE uses a random access procedure to synchronize with the (target) SN.

[0070] 10. If the RRC connection reconfiguration process is successful, the target MN will notify the (target) SN of the reconfiguration completion message via the SN.

[0071] 11a. The source SN sends a secondary RAT data usage report message to the source MN, including the amount of data transmitted to and received from the UE via NR / E-UTRA radio, as described in Section 10.11.2.

[0072] 11b. The source MN sends a secondary RAT report message to the AMF to provide information about the NR / E-UTRA resources used.

[0073] 12. For bearers using RLC AM, the source MN sends an SN state transmission to the target MN, which includes (if necessary) the SN state received from the source SN. If necessary, the target forwards the SN state to the target SN.

[0074] 13. If applicable, forward data from the source side. If the SN is maintained, data forwarding for bearers terminated by the SN or for QoS flows maintained in the SN can be omitted.

[0075] 14 to 17. The target MN initiates the path switching process. If the target MN includes multiple DL TEIDs for a PDU session in the path switching request message, then if there is a TEID update in the UPF, the multiple UL TEIDs for the UPF used for that PDU session should be included in the path switching confirmation message.

[0076] 18. The target MN initiates a UE context release process to the source MN.

[0077] 19. Upon receiving a UE context release message from the source MN, the (source) SN releases the C-plane related resources associated with the UE context to the source MN. Any ongoing data forwarding may continue. If the UE context retention indication is included in the SN release request message in step 5, the SN should not release the UE context associated with the target MN.

[0078] like Figure 1 As shown and discussed above, the target MN (i.e., T-Ng-eNB / gNB) receives a "Handover Request XnAP" message, which includes both the MCG and SCG configurations for the UE, indicating that the UE is operating in the MR-DC. If the target MN decides to maintain the source SN, it sends an SN Add Request to the SN, which includes the SN UE XnAP ID as a reference to the UE context established by the source MN in the SN. If the target MN decides to change the SN, it sends an SN Add Request to the target SN, which includes the UE context established by the source MN in the source SN.

[0079] The target SN (which can be the same as the source SN if the target MN decides to maintain the SN) sends an SN add request confirmation to the source MN. Afterward, the source MN triggers the SN release process, followed by the necessary steps to enable data forwarding, such as sending an Xn-U address indication to the source SN, receiving SN status transmissions from the source SN, and sending SN status transmissions to the target MN.

[0080] Similar principles also apply to the EN-DC case, as described in Section 10.7.1 of 3GPP TS 37.340.

[0081] Condition switching / condition reconfiguration

[0082] Two new work projects for mobility enhancements in LTE and NR have been launched in 3GPP Release 16. The primary objective of these work projects is to improve robustness during handover and reduce handover downtime. To this end, conditional handover (specified as a conditional reconfiguration in the RRC) has been specified. Conditional handover is described in Phase 2, 3GPP TS 38.300, v16.1.0, Section 9.2.3.4.

[0083] Conditional handover (CHO) is defined as a handover performed by the UE when one or more handover execution conditions are met. The UE begins evaluating the execution conditions upon receiving the CHO configuration and stops evaluating the execution conditions once they are met.

[0084] The following principles apply to CHOs:

[0085] The -CHO configuration contains the configuration of CHO candidate cells generated by the candidate gNB and the execution conditions generated by the source gNB.

[0086] - Execution conditions can consist of one or two trigger conditions (CHO events A3 / A5). Only a single RS type is supported, and the evaluation of CHO execution conditions for a single candidate cell can be configured with up to two different trigger quantities simultaneously (e.g., RSRP and RSRQ, RSRP and SINR, etc.).

[0087] - Prior to satisfying any CHO execution conditions, upon receiving an HO command (without CHO configuration), the UE executes the HO procedure described in Section 9.2.3.2 of 3GPP TS 38.300, regardless of any previously received CHO configuration.

[0088] - When executing CHO, that is, from the time when the UE starts synchronizing with the target cell, the UE does not monitor the source cell.

[0089] This version of the specification does not support CHOs for N2-based switching.

[0090] MR-DC and Condition Switching

[0091] In RAN2#109e, it has been agreed that “CHO (MCG)” can work with MR-DC, i.e., “CHO is received when MR-DC is configured, and SCG is received when CHO is configured.” Note that “MCG” and “SCG” refer to the primary cell group and secondary cell group, respectively; for the purposes of this disclosure, these terms may be considered interchangeable with MN and SN.

[0092] Therefore, according to the protocol, two scenarios will be supported:

[0093] -1. UEs operating in MR-DC can receive CHO configuration, which includes RRC reconfiguration for each candidate target MN;

[0094] -2. UEs configured with CHO (i.e., conditions for monitoring candidate targets) receive SCG additions.

[0095] Then, in RAN2#109e-bis, it has been agreed that the RRC Reconfiguration prepared by the MN candidate target can include the SCG configuration (i.e., keep it or modify it, if the UE is already in EN-DC) or release it. According to the current agreement: "We will not exclude the SCG configuration in the RRC reconfiguration by conditional reconfiguration. Limited to cases without RAN3 impact."

[0096] When a switch request to a CHO is sent from the source MN, the candidate target node may decide to adopt at least one of the following decisions:

[0097] - Case 1) Create a candidate target RRCReconfiguration to release the MR-DC configuration when the CHO is executed;

[0098] - Case 2) Create a candidate target RRCReconfiguration that maintains the MR-DC configuration (maintains SN) during CHO execution;

[0099] - Case 3) Create a candidate target RRCReconfiguration that changes the MR-DC configuration (changes the SN) when the CHO is executed;

[0100] For cases 2 and 3, the current process may cause problems, especially between candidate target MN and candidate target SN receiving the handover request message for CHO.

[0101] More specifically, if, upon receiving a handover request message for CHO from the source MN, the candidate target MN triggers a traditional SN add request to the candidate target SN (i.e., the candidate target MN only sends a traditional SN add request), then the candidate target SN can send an SN add request acknowledgment message and start its monitoring timer (TXn). DCprep The monitoring timer should continue running until the target SN candidate expects a reconfiguration completion message from the target MN candidate, which is an indication that the UE has accessed the target MN and successfully applied the configuration associated with the SN.

[0102] The relevant process includes an S-NG-RAN node addition preparation process, which requests the S-NG-RAN node to allocate resources for dual connectivity operations of a specific UE. This process is as follows: Figure 2 As shown, signaling associated with the UE is used.

[0103] An M-NG-RAN node initiates this process by sending an "S-NG-RAN Node Add Request" message to an S-NG-RAN node. When an M-NG-RAN node sends the "S-NG-RAN Node Add Request" message, it starts a timer TXn. DCprep Upon receiving the "S-Node Add Request Confirmation" message, the M-NG-RAN node stops its timer TXn. DCprep .

[0104] If the "S-Node Add Request" message contains an SN Add Trigger Indicator IE, then the S-NG-RAN node includes an RRC Configuration Indicator IE in the "S-Node Add Request Confirmation" message to notify the M-NG-RAN node whether the S-NG-RAN node has applied a full configuration or an incremental configuration.

[0105] The S-NG-RAN node reconfiguration completion procedure provides the S-NG-RAN node with information regarding whether the requested configuration has been successfully applied by the UE. This procedure uses signaling associated with the UE, and as... Figure 3As shown. The M-NG-RAN node initiates this process by sending an "S-Node Reconfiguration Complete" message to the S-NG-RAN node. The "S-Node Reconfiguration Complete" message may contain information about the UE successfully applying the configuration requested by the S-NG-RAN node. In this case, the M-NG-RAN node may also provide the configuration information from the M-NG-RAN node to the S-NG-RAN node container IE. Alternatively, the "S-Node Reconfiguration Complete" message may indicate that the configuration requested by the S-NG-RAN node was rejected. In this case, the M-NG-RAN node will provide sufficiently precise information in the included reason IE so that the S-NG-RAN node can know the reason for the unsuccessful reconfiguration. The M-NG-RAN node may also provide the configuration information from the M-NG-RAN node to the S-NG-RAN node container IE.

[0106] Upon receiving the "S-Node reconfiguration complete" message, the S-NG-RAN node stops its timer TXn. DCoverall .

[0107] TXn DCoverall Specify the maximum time allowed in an S-NG-RAN node for the following: S-NG-RAN node modification process initiated by the S-NG-RAN node, or NG-RAN actions required to protect UE resources at the S-NG-RAN node addition point, or S-NG-RAN node modification initiated by the M-NG-RAN node.

[0108] Because the expected time between sending a request to add an SN and receiving the completion of SN reconfiguration is quite short, and because the UE may need more time to access the candidate target MN or even be unable to access it during the CHO, the current process can lead to many unwanted SN releases from the candidate target SN, which can create quite a lot of race conditions, such as the candidate target MN having to repeatedly modify its CHO configuration against the source MN.

[0109] In addition to this issue, when the target MN candidate sends a handover request confirmation message in response to a CHO, the traditional procedure defines the source MN as releasing the SN in the event of deciding whether to keep or change the SN. However, this is not the desired behavior in the case of a CHO, because the equivalent change at the UE is only performed when the condition is met.

[0110] Novel techniques for addressing these problems are described below. Although described and explained in the context of 3GPP MR-DC, it should be understood that the inventive concepts, techniques, and apparatus described herein include the use of the same and similar techniques in the context of EN-DC and more generally in the context of multi-connectivity. Therefore, the term "multi-connectivity" can be used in place of the term "MR-DC" in any of the following uses.

[0111] In the following discussion, the terms "first network node," "second network node," "third network node," and "fourth network node" are used to describe the technology. These labels should be understood as purely nominal and used for convenience, and should not be construed as indicating a specific order or priority. In the following description, the term "first network node" is used to refer to a network node, such as a gNB or eNB, that acts as the source MN in a multi-connection operation with the UE. "Second network node" is a network node, such as a gNB or eNB, that acts as the source SN in the same multi-connection operation. "Third network node" is a network node, such as a gNB or eNB, that acts as the target MN for conditional handover (CHO) according to the currently disclosed technology, while "fourth network node" is a network node, such as a gNB or eNB, that acts as the target SN for conditional handover.

[0112] More specifically, here are some possible corresponding examples:

[0113] - The first network node may correspond to (e.g., operate as) one of the following: a source master node (MN), an S-MN, a source gNodeB, a source eNodeB, a source NG-RAN node, an M-NG-RAN node indicating a gNodeB operating as an MN in the MR-DC (e.g., connected to the 5GC) and associated with the NG-RAN; an M-NG-RAN node indicating an ng-eNodeB operating as an MN in the MR-DC (e.g., connected to the 5GC) and associated with the NG-RAN; or an LTE eNodeB connected to an EPC operating as a MeNodeB or MeNB.

[0114] - The second network node can correspond to (for example, operate as) one of the following: source auxiliary node (SN), S-SN, source auxiliary gNodeB (SgNB), source auxiliary eNodeB (SeNB), auxiliary source NG-RAN node, etc.

[0115] - Third network node: can correspond to (for example, operate as) target candidate node, candidate target node, target node, target candidate gNodeB, target candidate eNodeB, target candidate NG-RAN node, candidate target gNodeB, candidate target eNodeB, candidate target NG-RAN node, target gNodeB, target eNodeB, target NG-RAN node.

[0116] - Fourth network node: can correspond to (for example, operate as) target candidate auxiliary node (SN), candidate target SN, target SN, target candidate S-gNodeB, target candidate S-eNodeB, target candidate S-NG-RAN node, candidate target S-gNodeB, candidate target S-eNodeB, candidate target S-NG-RAN node, target S-gNodeB, target S-eNodeB, target S-NG-RAN node.

[0117] The aspects of this invention correspond to methods specific to each of these network nodes, as described in detail below. Several embodiments relate to CHO preparation, which will be discussed shortly thereafter.

[0118] The first embodiment includes a method performed at a first network node used as the source MN, the method comprising:

[0119] - Determine to configure the UE with conditional reconfiguration (e.g., conditional switching -CHO), where the UE operates in MR-DC and the first network node acts as the master node (e.g., source MN (S-MN));

[0120] - Send a "Switch Request" message to a third network node (which is a candidate target node, such as target gNodeB), the "Switch Request" message including an indication that the process is for CHO;

[0121] - Receive a "Switch Request Confirmation" message from a third network node (which is a candidate target node, such as target gNodeB). This "Switch Request Confirmation" message may include information about maintaining the SN during CHO execution.

[0122] - Delay sending the "SN release request" message to the second network node used as the source secondary node SN (S-SN);

[0123] - Use CHO to configure the UE, including configurations provided by both the fourth network node (e.g., used as a candidate SN target) and the third network node.

[0124] Related embodiments include a method performed at a third network node used as a candidate target MN, the method comprising:

[0125] - Receive a "Switch Request" message from the first network node, which includes an indication that the procedure is for a CHO;

[0126] - Send an SN add request to a fourth network node (e.g., used as a candidate SN target), the SN add request including an indication that the request is for CHO;

[0127] - Receive confirmation of SN add request from the fourth network node (e.g., used as a candidate SN target);

[0128] - Send a "Handover Request Confirmation" message to the first network node (which is the source MN, such as the source gNodeB). This "Handover Request Confirmation" message may include information about the SN to be maintained during the CHO execution.

[0129] Another related embodiment includes a method performed at a fourth network node used as a candidate target SN, the method comprising:

[0130] - Receive an SN add request from a third network node that serves as a candidate target MN, the SN add request including an indication that the request is for CHO;

[0131] - Based on the fact that the request is an instruction for CHO, set the monitoring timer to a certain value;

[0132] In some embodiments, when it is determined that the SN add request is for a CHO candidate target MN, the third network node sets its supervisory timer to a value longer than the value it would set for a conventional HO and / or conventional SN add request.

[0133] - Send an SN add request confirmation to the third network node used as the candidate target MN;

[0134] - Start the monitoring timer when sending a message to a third network node.

[0135] In some embodiments, when it is determined that the SN add request is for a CHO candidate target MN, the third network node may reserve resources for the UE, taking into account that the UE may connect or may not connect at all after a longer period of time compared to a conventional SN add.

[0136] Figure 4An example of a method for the CHO preparation section is shown. As illustrated, the UE initially connects to the source MN and source SN. The source MN determines to configure the CHO and sends a handover request message to the target candidate master node (third network node), wherein the handover request message includes an indication that the request is for a CHO. The target candidate master node sends an "SN Add Request" message to the target candidate SN (fourth network node), wherein the SN Add Request message includes an indication that the request is for a CHO and an indication of whether the SN is being held. A monitoring timer is set by the target candidate SN, wherein the value is adjusted based on the handover in question being a CHO. The target candidate SN also sends an "SN Add Request Confirmation" message to the target candidate master node.

[0137] The target candidate master node then sends a "Switch Request Confirmation" message to the source master node. This message may include confirmation in response to a CHO and may include an indication of whether the SN is being maintained. The source master node delays sending the "SN Release Request," as described above, because the switch is conditional.

[0138] The source MN then sends an RRC reconfiguration to the UE, which includes an indication that it is for a CHO. This RRC reconfiguration may be included in the confirmation of the handover request, as provided by the target candidate MN. The UE responds with an RRC reconfiguration complete message to confirm the RRC reconfiguration, and then monitors relevant triggering / execution conditions to determine whether and when to execute the CHO.

[0139] Other embodiments involve CHO execution. An example embodiment is a method executed at a first network node used as the source MN, the method comprising:

[0140] - Receive the second message from the third node, which is the target MN (e.g., a candidate target gNodeB for which a CHO has been configured); and

[0141] - Send an "SN release request" message to the second network node used as the source SN (S-SN) (e.g., source secondary gNodeB (source SgNB)). This release request message may include an indication that the SN is being maintained; and

[0142] - Receive an "SN release request confirmation" message from the second network node that serves as the source SN (S-SN) (e.g., source auxiliary gNodeB (source SgNB)).

[0143] In some embodiments, the second message is a "handover successful" message. Some embodiments may also include: determining that delayed data forwarding will be performed. In these embodiments, if data forwarding is required, the first network node (e.g., the source MN) initiates an address indication procedure to the second network node; and receives an SN status transmission from the second network node, which serves as the source SN.

[0144] Sending SN status transmissions to a third network node (e.g., a candidate target node, target gNodeB); receiving forwarded data from a second network node used as the source SN; and forwarding data to a third network node (e.g., target gNodeB).

[0145] Another embodiment is a method performed at a second network node used as the source SN, the method comprising:

[0146] - Receive a "SN Release Request" message from the first network node acting as the source MN (S-MN), which may include an indication that the SN is being held; and

[0147] - Send a "SN release request confirmation" message to the first network node used as the source MN (S-MN).

[0148] Some embodiments may include any one or all of the following operations:

[0149] - Receive the Xn-U address indication from the first network node used as the source MN (S-MN);

[0150] - Determined data forwarding will be performed;

[0151] - Send SN status transmission to the first network node used as the source MN; and

[0152] - Forward data to the first network node (e.g., source gNodeB, source MN).

[0153] Another embodiment is a method performed at a third network node (used as a candidate target MN), the method comprising:

[0154] - Receive the RRC reconfiguration complete message from the UE;

[0155] This message can be included in another RRC reconfiguration complete message associated with the SCG reconfiguration;

[0156] - Determine that the incoming UE has been configured with CHO and has associated MR-DC related configuration for the fourth network node (used as a candidate SN target);

[0157] - Send an SN reconfiguration complete message to the fourth network node (used as a candidate SN target);

[0158] This message includes an RRC reconfiguration complete message associated with SCG reconfiguration and sent from the UE;

[0159] - Send a message to the first node that is the source MN (e.g., the source gNodeB that has been configured with CHO);

[0160] ○ In one embodiment, the message is a "switching successful" message.

[0161] - Receive forwarded data from the first node; and

[0162] - Transmit the data bearer that was forwarded by the SN to the fourth node.

[0163] Another embodiment is a method performed at a fourth network node (used as a candidate target SN), the method comprising:

[0164] - Receive the SN reconfiguration complete message from the third network node (as the MN candidate target);

[0165] This message includes an RRC reconfiguration complete message associated with SCG reconfiguration and sent from the UE;

[0166] - Stop the monitoring timer; treat the UE context as active; and

[0167] - Receive the forwarded bearer data from the third node after the SN is terminated.

[0168] Figure 5 The example execution process is summarized below. As shown in the attached figure, the UE determines that the conditions for handing over to the target candidate MN (third network node) are met. Based on its previously received RRC reconfiguration message, the UE then initiates a random access procedure to each of the target candidate MN and the target candidate SN (fourth network node). The UE then sends an RRC reconfiguration complete message to the target candidate MN.

[0169] The target candidate MN determines that the UE and the target candidate SN have MR-DC and sends an SN reconfiguration complete message to the target candidate SN. In response, the target candidate SN stops its surveillance timer. The target candidate MN also sends a "handover successful" message to the source MN. If the source SN is not being held, the source MN can initiate an SN release procedure. In this case, the source MN sends an "SN release request" message to the source SN, which responds with an "SN release request confirmation" message. The source MN then initiates an address indication procedure, sending an "XN-U address indication" message to the source SN, which responds with an "SN status transfer" message. The source MN forwards the "SN status transfer" message to the target candidate MN and forwards any delayed data it received from the source SN to the target candidate MN.

[0170] Other embodiments of the currently disclosed technology involve removing the CHO from targets that were not selected for use with the CHO. An example embodiment is a method performed in a source MN, the method comprising:

[0171] - Receive a message from the first candidate target MN regarding the UE's execution of the CHO;

[0172] In one embodiment, the message is a successful handover message; and

[0173] - Send a message to the second candidate target MN to which the UE has not yet executed the CHO, the message including an indication that the CHO configuration will be released.

[0174] Another embodiment is a method performed in a candidate target MN, the method comprising:

[0175] - Receive a message from the source MN that includes an indication that the CHO configuration will be released;

[0176] - Determine whether the CHO configuration used to associate the UE has an associated target SN candidate;

[0177] - Trigger the SN release process by sending an SN release request message to the candidate target SN; and

[0178] - Receive SN release request confirmation from candidate target SN.

[0179] Figure 6 Examples of these embodiments are provided. As seen in the accompanying drawings, the UE determines that the conditions for handover to the target candidate MN (third network node) are met. Based on its previously received RRC reconfiguration message, the UE then initiates a random access procedure to the target candidate MN. The UE then sends an RRC reconfiguration complete message to the target candidate MN. The target candidate MN determines that the UE has an MR-DC with the target candidate SN and sends an SN reconfiguration complete message to the target candidate SN. In response, the target candidate SN stops its surveillance timer. The target candidate MN also sends a "handover successful" message to the source MN.

[0180] The source MN then determines that it has previously configured another target candidate master node, namely target candidate MN-2, for the UE's CHO. The source MN sends a "handover cancellation" message to target candidate MN-2. Target candidate MN-2 then sends an "SN release request" to the target candidate SN that was not selected for CHO. The target candidate SN deletes the SN add configuration it previously received (see...). Figure 4 The system then responds with a "SN Release Request Confirmation" message. Target candidate MN-2 then releases the CHO configuration for the UE.

[0181] To provide a system-level context for the techniques described in this article, Figure 7A wireless device 12 configured for a wireless communication network according to some embodiments is illustrated. The wireless device 12 is configured for multi-connectivity operation. In this respect, multi-connectivity means that the wireless device 12 (e.g., at the Radio Resource Control (RRC) layer) simultaneously connects to multiple different radio network nodes, or connects to multiple different cells provided by different radio network nodes. The multiple different radio network nodes or cells may use the same radio access technology (e.g., both may use Evolved Universal Terrestrial Radio Access (E-UTRA) or both may use New Radio (NR)). Alternatively, the multiple different wireless network nodes or cells may use different radio access technologies; for example, one may use E-UTRA while another may use NR.

[0182] An example of multi-connectivity is dual connectivity (DC), in which wireless device 12 simultaneously connects to two different radio network nodes, or to two different cells served by two different radio network nodes. In this case, wireless device 12 can be configured with a so-called primary cell group (MCG) and secondary cell group (SCG), where the MCG comprises one or more cells served by a radio network node acting as the primary node (MN), and the SCG comprises one or more cells served by a radio network node acting as the secondary node (SN). A primary node can be considered a primary node in the sense that it controls the secondary nodes and / or provides control plane connectivity to the core network. For example, E-UTRA-NR(EN)DC means that the primary node uses E-UTRA and the secondary node uses NR, while NR-E-UTRA(NE) means that the primary node uses NR and the secondary node uses E-UTRA.

[0183] For example, in multi-connectivity operation, a wireless device 12 with multiple receivers (Rx) and / or transmitters (Tx) can utilize radio resources provided by multiple different schedulers via non-ideal backhaul connections in one or more radio access technologies (e.g., New Radio (NR) and / or E-UTRA). In this regard, Multi-Radio Dual-Connectivity (MR-DC) is a generalization of Intra-E-UTRA DC, where multiple Rx / Tx wireless devices can be configured to utilize resources provided by two different nodes via non-ideal backhaul connections, where one node provides NR access and the other provides E-UTRA or NR access. One node acts as the primary node (MN), and the other acts as the secondary node (SN). For example, E-UTRAN supports MR-DC via E-UTRA-NR Dual-Connectivity (EN-DC), where the wireless device is connected to an eNB acting as the MN and an en-gNB (SN) acting as the secondary node. In either case, in MR-DC, the wireless device 12 can have a single Radio Resource Control (RRC) state based on the MN RRC and a single control plane connection toward the core network.

[0184] In this context, Figure 7 A first network node 14 is also shown, which serves as the master network node (i.e., MN) for multi-connection operations of the wireless device 12. Figure 7 A second network node 16 is also shown, which serves as a secondary network node (i.e., SN) for the multi-connection operation of the wireless device 12. However, during the multi-connection operation, the first network node 14 decides to configure the wireless device 12 for handover relative to one or more candidate target nodes 18-1…18-N. As a result of the handover, the primary network node for the device's multi-connection operation changes from being the first network node 14 to being one of the candidate target network nodes 18-1…18-N.

[0185] Therefore, such as Figure 7 The first network node 14, as shown, sends a handover request message 20 to each of one or more candidate target nodes 18-1…18-N. The handover request message 20 requests resources prepared at the candidate target nodes for the handover of wireless device 12. Each candidate target node can return a response to the handover request message 20 to notify the first network node 14 whether resources are prepared for handover at that candidate target node. As shown in this example, each candidate target network node 18-1…18-N responds with a corresponding handover request acknowledgment (ACK) message 22, which informs the first network node 14 about the resources prepared for handover at the respective candidate target node. With the resources prepared for handover, the primary network node 14 can send a handover command 13, for example, in the form of an RRC reconfiguration, to wireless device 12.

[0186] However, it is worth noting that, according to some embodiments herein, the first network node 14 advantageously preserves the services of the wireless device from the second network node 16 in a multi-connection operation until the wireless device has performed a handover to a candidate target node. In this regard, the first network node 14 considers whether the handover is conditional. For example, if the wireless device 12 performs the handover unconditionally in response to the handover command 13, the first network node 14 can continue and request the release of resources for the wireless device 12 at the second network node 16 by sending a secondary node release request message 24 to the second network node 16 in response to receiving the handover request confirmation message 20. This is shown in Figure 7 In the lower left corner of the "Unconditional Handover Timeline". However, if the handover is a conditional handover, such that wireless device 12 will only perform the handover when the wireless device detects that the condition is met, then the first network node 14 can delay sending the secondary node release request message 24 to the second network node 16, for example, until the primary network node receives the message 26 indicating that the conditional handover has been performed. This is shown in Figure 7 In the lower right corner of the "Conditional Handover Timeline," message 26 could be, for example, a handover success message indicating that wireless device 12 has successfully accessed the candidate target node for handover. In any case, delaying the secondary node release request message 24 can advantageously prevent premature release of resources for wireless device 12 at the second network node 16, ensuring that these resources remain unchanged during the intermediate time between when wireless device 12 begins monitoring whether the conditions for performing a conditional handover are met and when wireless device 12 performs the conditional handover after the conditions are met. Some embodiments thereby allow wireless device 12 to achieve increased data rates through multi-connection operations while also enjoying improved reconfiguration (e.g., handover) robustness against failures.

[0187] In view of the above modifications and changes, Figure 8 A method implemented by a first network node according to a particular embodiment is described, the first network node being configured to serve as a primary network node for multi-connection operation of a wireless device. In some embodiments, the method includes: determining to configure the wireless device with conditional reconfiguration (block 810). The method may further include: sending a handover request message to a third network node, the handover request message including an indication that the procedure is for conditional handover (block 820). The method may further include: receiving an acknowledgment of the handover request message (block 830), and delaying the sending of a release message to a second network node serving as a secondary network node for the wireless device (block 840). The method may further include: configuring the wireless device with conditional handover information, the conditional handover information including configuration information provided from the third network node (block 850).

[0188] Figure 9A method performed by a third network node according to another specific embodiment is described, the third network node being configured as a target master node candidate for multi-connectivity operation of a wireless device. The method includes: receiving a handover request message from a first network node, the handover request message including an indication that the procedure is for conditional handover (box 910). The method further includes: sending a secondary node addition request to a fourth network node, the secondary node addition request including an indication that the request is for conditional handover (box 920). The method further includes: receiving an acknowledgment of the secondary node addition request (box 930) and sending an acknowledgment of the handover request to the first network node (box 940).

[0189] Figure 10 A method performed by a fourth network node, configured to serve as a candidate target secondary node for a wireless device, is described according to another specific embodiment. The method includes: receiving a secondary node addition request from a third network node, the secondary node addition request including an indication that the request is for conditional switching (box 1010). The method further includes: setting a monitoring timer to a value based on the indication that the request is for conditional switching (box 1020). The method further includes: sending an acknowledgment of the secondary node addition request to the third network node (box 1030) and starting the monitoring timer (box 1040).

[0190] Figure 11 A method performed by a first network node according to another specific embodiment is described, the first network node being configured to act as a master network node for multi-connection operations of a wireless device. The method includes: receiving a message from a third network node, the third network node acting as a candidate target master node for a conditional handover configured for the wireless device (box 1110). The method further includes: sending a secondary node release request to a second network node acting as a source secondary node for the wireless device (box 1120). The method further includes: receiving acknowledgment of the secondary node release request from the second network node (box 1130).

[0191] Figure 12 A method performed by a second network node, according to another specific embodiment, is described, the second network node acting as a source-secondary node of a wireless device operating in multiple connections. The method includes: receiving a secondary node release request message from a first network node acting as a source-master node of the wireless device (box 1210). The method further includes: sending an acknowledgment of the secondary node release request to the first network node (box 1220).

[0192] Figure 13A method performed by a third network node, configured as a target master node candidate for multi-connectivity operations of a wireless device, is described according to another specific embodiment. The method includes: receiving an RRC reconfiguration complete message from the wireless device (box 1310). The method further includes: determining that the wireless device has been configured for conditional handover and has associated multi-connectivity-related configurations for a fourth network node serving as a secondary node candidate target (box 1320); the method further includes: sending a secondary node reconfiguration complete message to the fourth network node (box 1330), and sending a message to a first network node serving as the source master node of the wireless device (box 1340).

[0193] Figure 14 A method performed by a fourth network node, configured to serve as a candidate target secondary node for a wireless device, is described according to another specific embodiment. The method includes: receiving a secondary node reconfiguration complete message from a third network node serving as a primary node candidate target for conditional handover of the wireless device (box 1410). The method further includes: stopping a monitoring timer associated with the conditional handover of the wireless device (box 1420). The method further includes: treating the context associated with the wireless device as active (box 1430).

[0194] Figure 15 A method performed by a network node according to another specific embodiment is described, the network node being configured as a candidate target master node for a multi-connection conditional handover of a wireless device. The method includes: receiving from a source master node of the wireless device a message indicating that a conditional handover configuration for the wireless device will be released (box 1510). The method further includes: determining that the conditional handover configuration for the wireless device has associated target secondary node candidates for the conditional handover (box 1520). The method further includes: sending a secondary node release request message to the target secondary node candidates (box 1530).

[0195] Figure 16 A method performed by a first network node according to another specific embodiment is described, the first network node being configured to act as a master network node for multi-connection operations of a wireless device. The method includes: receiving a message from a candidate target master node to which the wireless device has performed a conditional handover (box 1610). The method further includes: sending a message to a candidate target master node for which a conditional handover of the wireless device has been configured but not yet performed, the message indicating that the conditional handover configuration for the wireless device will be released (box 1620).

[0196] The embodiments described herein also include corresponding devices. Examples of the embodiments described herein include, for instance, network nodes (e.g., a first network node, a second network node, a third network node, or a fourth network node) configured to perform any steps of any of the embodiments described herein. Note that any network node devices described herein may be configured such that they can act as any one of the first, second, third, or fourth network nodes described herein for different wireless devices at different times or even at the same time.

[0197] The embodiments also include: network nodes (e.g., a first network node, a second network node, a third network node, or a fourth network node) including processing circuitry and power supply circuitry. The processing circuitry is configured to perform any step of any embodiment described herein. The power supply circuitry is configured to supply power to the network nodes.

[0198] The embodiments also include: a network node (e.g., a first network node, a second network node, a third network node, or a fourth network node) including processing circuitry. The processing circuitry is configured to perform any step of any embodiment described herein. In some embodiments, the network node also includes communication circuitry.

[0199] The embodiments also include: network nodes (e.g., a first network node, a second network node, a third network node, or a fourth network node) comprising processing circuitry and memory. The memory contains instructions executable by the processing circuitry, thereby configuring the network node to perform any steps of any embodiment described herein.

[0200] More specifically, the above-described apparatus can perform the methods and any other processing described herein by implementing any functional means, modules, units, or circuits. For example, in one embodiment, the apparatus includes various circuits or circuit systems configured to perform the steps shown in the method diagrams. In this regard, the circuits or circuit systems may include circuitry dedicated to performing certain functional processing and / or one or more microprocessors combined with memory. For example, the circuitry may include one or more microprocessors or microcontrollers and other digital hardware, which may include digital signal processors (DSPs), application-specific digital logic, etc. The processing circuitry may be configured to execute program code stored in memory, which may include one or more types of memory, such as read-only memory (ROM), random access memory, cache memory, flash memory devices, optical storage devices, etc. In several embodiments, the program code stored in the memory may include program instructions for executing one or more telecommunications and / or data communication protocols and instructions for executing one or more techniques described herein. In embodiments employing memory, the memory stores program code that, when executed by one or more processors, performs the techniques described herein.

[0201] For example, Figure 17 A network node 1700 implemented according to one or more embodiments is shown. As shown, the network node 1700 includes processing circuitry 1710 and communication circuitry 1720. The communication circuitry 1720 (e.g., a radio circuit) is configured to send information to and / or receive information from one or more other nodes, for example, via any communication technology. Such communication may be performed via one or more antennas, either internal or external to the network node 1700. The processing circuitry 1710 is configured to perform the above-described processing, for example, by executing instructions stored in memory 1730. In this respect, the processing circuitry 1710 may implement certain functional means, units, or modules.

[0202] Those skilled in the art will also understand that the embodiments herein also include corresponding computer programs.

[0203] The computer program includes instructions that, when executed on at least one processor of the device, cause the device to perform any of the corresponding processes described above. In this respect, the computer program may include one or more code modules corresponding to the aforementioned device or unit.

[0204] The embodiments also include a carrier containing such a computer program. The carrier may include one of electrical signals, optical signals, radio signals, or computer-readable storage media.

[0205] In this regard, embodiments herein also include a computer program product stored on a non-transitory computer-readable (storage or recording) medium, the computer program product including instructions that, when executed by a processor of the device, cause the device to perform as described above.

[0206] The embodiments also include a computer program product comprising a program code portion that, when executed by a computing device, performs the steps of any of the embodiments herein. The computer program product may be stored on a computer-readable recording medium.

[0207] Additional details and variations of the above embodiments are provided below. For illustrative purposes, at least some of these embodiments may be described as applicable to certain contexts and / or wireless network types, but these embodiments are similarly applicable to other contexts and / or wireless network types not explicitly described.

[0208] The solutions described in detail below address scenarios where a UE is configured with Multi-Radio Dual Connectivity (MR-DC) when it receives a Conditional Handover (CHO) configuration. The embodiments described herein focus on NR-DC (i.e., when both the primary and secondary nodes are NRgNBs), but these solutions are equally applicable to other DC scenarios (e.g., NE-DC, (NG)EN-DC, and LTE DC).

[0209] In this document, the term Conditional Switching (CHO) is used repeatedly. Other terms (e.g., Conditional Reconfiguration or Conditional Configuration) can be considered synonyms (since the message stored and applied when the condition is met is RRCReconfiguration or RRCConnectionReconfiguration). CHO can also be interpreted in a broader sense regarding terminology.

[0210] The principle of configuration is the same as configuring the trigger / execution conditions and the reconfiguration message to be applied when the trigger conditions are met.

[0211] CHO preparation techniques

[0212] The embodiment includes a method performed at a first network node used as the source MN, the method comprising:

[0213] - Determine to configure the UE with conditional reconfiguration (e.g., conditional switching -CHO), where the UE operates in MR-DC and the first network node acts as the master node (e.g., source MN (S-MN));

[0214] ○ This determination may be based on a measurement report received from the UE at the source MN, which includes measurements of cells associated with neighboring nodes (e.g., neighboring gNodeB), which may be candidate target nodes for CHO;

[0215] - Send a "Switch Request" message to a third network node (which is a candidate target node, such as target gNodeB), the "Switch Request" message including an indication that the process is for CHO;

[0216] ○ In one embodiment, the MN sends a "switch request" message to a single candidate target, the "switch request" message including an indication that the process is for CHO;

[0217] ■ For example, a candidate target may have a target cell candidate associated with it.

[0218] ○ In one embodiment, the MN sends a handover request message to a single candidate target, the handover request message including an indication that the process is for CHO;

[0219] ■ For example, a candidate target may have multiple target cell candidates associated with it. In that case, a "handover request" message can be sent for each target cell candidate.

[0220] ○ In one embodiment, the MN sends a "switch request" message to multiple candidate targets, the "switch request" message including an indication that the process is for CHO;

[0221] For example, a candidate target may have multiple target cell candidates associated with it. In that case, a "handover request" message can be sent for each target cell candidate. Furthermore, multiple candidate cells may exist within different candidate target nodes.

[0222] ○ In one embodiment, the source MN sends a "handover request" message for each UE and each candidate target cell, the "handover request" message including an indication that the procedure is for CHO;

[0223] ■ The determination of the cell for which the source MN requests a CHO can be based on measurements reported by the UE. For example, if the UE reports that neighboring cells A, B, and C are the best in terms of RSRP and / or RSRQ and / or SINR, then these cells can be the cells for which the source MN requests a candidate target MN to configure a CHO. Furthermore, for each of these candidate cells, the source MN sends a "HO Request" message with an indication that this is for a CHO.

[0224] In one embodiment, the source MN sends a "handover request" message for each UE and each candidate target cell. This "handover request" message includes MCG and SCG configurations. The source MN includes the source SN, UE XnAP ID (or an equivalent interface protocol identifier for the UE), SN ID (a node identifier for the SN), and the UE context in the source SN in the handover request message. This includes indicating SN-related information to the candidate target MN, which can determine whether to maintain, release, or change the SN during CHO execution.

[0225] - Receive a "Switch Request Confirmation" message from a third network node (which is a candidate target node, such as target gNodeB). This "Switch Request Confirmation" message may include information about maintaining the SN during CHO execution.

[0226] ○ In one embodiment, MN receives a "handover request confirmation" from a single candidate target;

[0227] ■ For example, a candidate target may have a target cell candidate associated with it.

[0228] ○ In one embodiment, the MN receives a "handover request confirmation" message from a single candidate target node;

[0229] ■ For example, a candidate target may have multiple target cell candidates associated with it. In that case, a "handover request confirmation" message can be received for each target cell candidate.

[0230] ○ In one embodiment, MN receives a "handover request confirmation" message from multiple candidate targets;

[0231] For example, a candidate target may have multiple target cell candidates associated with it. In that case, a "handover request confirmation" message can be received for each target cell candidate. Furthermore, multiple candidate cells may exist within different candidate target nodes.

[0232] ○ In one embodiment, the source MN receives a "handover request confirmation" message that includes an indication to maintain the SN;

[0233] ■ Unlike traditional handover scenarios, in this CHO scenario, the instruction is used to indicate that the SN should be maintained while the CHO is being executed; and the actions of the source Mn will be executed only when the CHO is being executed, rather than when a message is received.

[0234] - Delay sending the "SN release request" message to the second network node used as the source secondary node SN (S-SN);

[0235] ○ In one embodiment, the method includes, for example, delaying (i.e., delaying initiation, delaying start) the SN release process upon receiving a handover request confirmation.

[0236] ■ For example, (for a UE operating in EN-DC) when MN is an LTE node and SN is an NR node, the SN release procedure can correspond to the MeNB-initiated SgNB release procedure as defined in subsection 8.7.9 of TS 36.423.

[0237] ■ For example, (for a UE operating in NR-DC) when MN is an NR node and SN is an NR node, the SN release procedure may correspond to the S-NG-RAN node release procedure initiated by the M-NG-RAN node as defined in subsection 8.3.6 of TS 38.423.

[0238] ○ In one embodiment, a delay (or suppression) action is performed when it is determined that a "handover request confirmation" has been received in response to a "handover request" for condition reconfiguration (e.g., condition switching);

[0239] ○ The “SN Release Request” message can be at least one of the following:

[0240] ■ For example, (for a UE operating in EN-DC) when MN is an LTE node and SN is an NR node, the “SN release request” message can correspond to the “SgNB release request” message as defined in TS 36.423.

[0241] ■ For example, (for a UE operating in NR-DC) in the case where MN is an NR node and SN is an NR node, the “SN release request” message can correspond to the “S node release request” message as defined in TS 38.423.

[0242] ○ In one embodiment:

[0243] ■ If a "Handover Request Confirmation" has been received in response to a "Handover Request" used for traditional reconfiguration (e.g., handover).

[0244] ● (If the UE is operating in MR-DC) Initiate the SN release procedure; otherwise...

[0245] ■ If a "Switch Request Confirmation" has been received in response to a "Switch Request" used for conditional reconfiguration (e.g., conditional switching).

[0246] ● (If the UE is operating in MR-DC) Delay / suppress the initiation of the SN release procedure; otherwise...

[0247] In one embodiment, the reception of a first message from one of the candidate targets is monitored; upon receiving the first message, (if the UE is operating in MR-DC) an SN release procedure is initiated.

[0248] ■ The reason for adding "If the UE is operating in the MR-DC" is that the UE may have been reconfigured after the CHO configuration, that is, the UE may no longer be operating in the MR-DC when the CHO is executed.

[0249] In one embodiment, if instructed in a “HO request confirmation” message, the source MN action is delayed for cases where the SN needs to be maintained.

[0250] ■ This includes sending an SN release request to the source SN, which includes an indication that the UE wants to retain the SN;

[0251] ■ The delayed actions at the source MN are as follows: The source MN sends an SN release request to the (source) SN, which includes a reason indicating the MCG's mobility (or possibly a CHO indication). The (source) SN acknowledges the release request. If the source MN receives an indication from the target MN, the source MN instructs the (source) SN to maintain the UE context in the SN. If an indication to maintain the UE context in the SN is included, the SN maintains the UE context.

[0252] ■ For example, when a handover success message (or equivalent indication) is received from a candidate target MN that has already been accessed by the UE, these actions will be delayed until a known CHO will be executed.

[0253] - Use CHO to configure the UE, including configurations provided from the fourth network node (e.g., as a candidate SN target) and the third network node.

[0254] In one embodiment, the method includes configuring a first network node (e.g., source MN, S-MN, which may be an LTE eNodeB serving as the MN) of the UE with conditional reconfiguration (e.g., conditional switching (CHO)). In other words, the first network node sends an RRC reconfiguration message to the UE containing the CHO configuration (e.g., the conditionalReconfiguration field of IE ConditionalReconfiguration as defined in 3GPP TS 38.331).

[0255] Another embodiment is a method performed at a third network node used as a candidate target MN, the method comprising:

[0256] - Receive a "Switch Request" message from the first network node, which includes an indication that the procedure is for a CHO;

[0257] In one embodiment, the candidate target MN receives a "handover request" message for a single candidate target cell, the "handover request" message including an indication that the process is for CHO; for example, the candidate target may have a target cell candidate associated with it.

[0258] ○ In one embodiment, the candidate target MN receives a "switch request" message that may come from multiple source MNs, the "switch request" message including an indication that the process is for CHO;

[0259] ○ In one embodiment, the source MN receives a "handover request" message from multiple candidate targets, the "handover request" message including an indication that the process is for CHO;

[0260] For example, a candidate target may have multiple target cell candidates associated with it. In that case, a "handover request" message can be sent for each target cell candidate. Furthermore, multiple candidate cells may exist within different candidate target nodes.

[0261] ○ In one embodiment, the source MN receives a "handover request" message for each UE and each candidate target cell, the "handover request" message including an indication that the procedure is for CHO;

[0262] In one embodiment, the candidate target MN is determined to contain a “HO request” message that includes a CHO indication for a given UE, and also includes an indication that the UE is operating in the MR-DC (e.g., including MCG and SCG configuration, SN terminated bearer, etc.).

[0263] ■ In one embodiment, determining that a UE for which a CHO is to be configured is operating in an MR-DC is performed by determining that the "Handover Request" message includes both MCG configuration and SCG configuration. Furthermore, this message also includes the source SN UE XnAP ID (or an equivalent interface protocol identifier for the UE), the SN ID (a node identifier for the SN), and the UE context from the source SN in the handover request message. This includes indicating SN-related information to a candidate target MN, which can determine whether to retain, release, or change the SN during CHO execution.

[0264] ■ In this determination step, it is determined that the following configurations are performed for a UE operating in MR-DC and configured with a CHO, wherein this action will be delayed until the CHO is executed:

[0265] ●Release SN;

[0266] ● Maintain SN;

[0267] In one embodiment, the candidate target MN decides to maintain the SN; furthermore, the candidate target MN decides to maintain the same SpCell (PSCell) for the SCG. This is likely if the candidate target MN knows that the current PSCell has overlapping coverage with the MCG configured in the RRCReconfiguration for the CHO. In other words, the candidate target MN knows that if the UE performs a CHO on the configured MCG, it is very likely to be within the coverage of the currently configured PSCell.

[0268] In one embodiment, the candidate target MN decides to maintain the SN; however, it decides to change the current SpCell (PSCell) of the SCG to another cell associated with the same SN. This is possible if the candidate target MN knows that the current PSCell has no overlapping coverage for the MCG configured for the CHO in the RRCReconfiguration, but knows that another cell associated with the SN has overlapping coverage with the MCG configured for the CHO. In other words, the candidate target MN knows that if the UE performs a CHO for the configured MCG, it is very likely that it will be within the coverage area of ​​the new PSCell and also associated with the SN.

[0269] In one embodiment, the determination step of maintaining the SN (and additionally configuring the same PSCell or changing it to another PSCell in the same SN) is based, for example, on measurement information included in the "HO request" message, wherein such measurement information is measurement values ​​reported by the user.

[0270] ●Change SN;

[0271] In one embodiment, the candidate target MN decides to change the SN; furthermore, the candidate target MN determines a new candidate target SpCell (PSCell) for the SCG. This is likely if the candidate target MN knows that the new candidate target PSCell has overlapping coverage with the MCG configured in RRCReconfiguration for the CHO. In other words, the candidate target MN knows that if the UE performs a CHO on the configured MCG, it is likely to be associated with the new SN that the UE will change to when the CHO is performed, within the coverage of the newly configured PSCell.

[0272] ○ In one embodiment, the candidate target MN is determined to contain a “HO request” message that includes a CHO indication for a given UE, but does not contain an indication that the UE is operating in the MR-DC (e.g., including MCG and SCG configuration, SN termination bearer, etc.).

[0273] ■ In one embodiment, determining that a UE for which a CHO is to be configured is not operating in an MR-DC is done by determining that the "Handover Request" message does not contain an SCG configuration and / or that the message does not contain the source SN UE XnAP ID (or the equivalent interface protocol identifier for the UE), SN ID (the node identifier for the SN), or the UE context in the source SN in the handover request message.

[0274] ■ In this determination step, it is determined that the following configurations are performed for a UE operating in MR-DC and configured with a CHO, wherein this action will be delayed until the CHO is executed:

[0275] ●Add SN;

[0276] In one embodiment, the candidate target MN determines the added SN; furthermore, the candidate target MN determines the candidate target SpCell (PSCell) of the SCG. This is likely if the candidate target MN knows that the candidate target PSCell has overlapping coverage with the MCG configured in RRCReconfiguration for the CHO. In other words, the candidate target MN knows that if the UE performs a CHO on the configured MCG, it is likely to be associated with the new SN that the UE will change to when the CHO is performed, within the coverage of the newly configured PSCell.

[0277] - Send an SN add request to a fourth network node (e.g., used as a candidate SN target), the SN add request including an indication that the request is for CHO;

[0278] ○ In one embodiment, the SN add request process in this step is initiated when it is determined that the SN will be maintained or changed for a UE that is operating in MR-DC and will be configured with CHO;

[0279] ■ In one embodiment, if the candidate target MN determines to release SN during CHO execution, this step is not performed.

[0280] In one embodiment, the SN add request includes an indication that the request is associated with a CHO procedure (i.e., the requesting node is a candidate target MN). In other words, the indication tells the candidate target SN that the UE may not perform a handover (and therefore not apply the SCG configuration and not perform a reconfiguration synchronized with the SCG's SpCell), or will perform it at a later point in time (i.e., when the CHO conditions to be configured for the UE will be met).

[0281] ■In one embodiment, with Figure 18A Information elements similar to the one shown (IE) can be introduced into the "S-NG-RAN Add Request" message.

[0282] ■ In one embodiment, at least one new value associated with the CHO is introduced into the SN Add Trigger Indication to be included in the S-NG-RAN Add Request message. Further distinctions may exist for cases where the CHO is an intra-MN CHO (if the candidate target MCG used for the CHO is associated with an MN that shares the same SpCell as the current MCG) or an inter-MN CHO (if the candidate target MCG used for the CHO is associated with an MN that shares the same SpCell as the current MCG), as shown below. Adding this value to the SN Add Trigger Indication is as follows: Figure 18B As shown.

[0283] ○ In one embodiment, if the candidate target MN (e.g., based on measurements included in a "switch request" message from the source MN) decides to maintain the SN but change the SpCell of the SCG; or

[0284] In one embodiment, if the candidate target MN (e.g., based on a measurement included in a "Switch Request" message from the source MN, which is forwarded to the candidate target SN in a "SN Add Request") decides to maintain the SN, but the decision to maintain or change the SpCell of the SCG is made by the candidate target SN; the following operations are performed:

[0285] ■ If the candidate target MN (when CHO is executed) decides to maintain the source SN, the candidate target MN sends an SN add request to the candidate target SN, which includes the SNUE XnAP ID as a reference to the UE context established by the source MN in the candidate target SN.

[0286] ■ In this case, in one example, at least Figure 19A The information elements shown in the example message will be included in the S-NG-RAN node (SN) "Add Request" message.

[0287] ■ In this case, in another example, at least Figure 19B The information elements shown in the example message will be included in the S-NG-RAN node (SN) "Add Request" message. In one embodiment, if a candidate target MN (e.g., based on measurements included in a "Switch Request" message from the source MN) decides to change the SN;

[0288] ■ If the candidate target MN decides to change the SN (i.e., a different candidate target SN compared to the source SN), the candidate target MN sends an SN addition request to the candidate target SN, which includes the UE context established by the source MN in the source SN.

[0289] In one embodiment, the SN addition request includes an indication that the request is associated with a conditional SN addition procedure (i.e., the UE receiving the configuration applies it not upon reception, but upon fulfillment of a condition). Furthermore, the message may contain at least another indication enabling the candidate target SN to distinguish between a mobility scenario (i.e., the requesting node is the target MN) and an SN addition scenario (where the UE is not operating in the MR-DC and the requesting node is the source MN associated with the serving cell (e.g., the SpCell of the MCG).

[0290] - Receive confirmation of SN add request from the fourth network node (e.g., used as a candidate SN target);

[0291] In one embodiment, the candidate target MN receives an SN add request confirmation from the candidate target SN, which may include an indication of full or incremental RRC configuration.

[0292] ○ If the message contains an indication of the complete RRC configuration, CHO modifications from the source MN to the candidate target MN will not trigger modifications to the candidate target SN.

[0293] ○ If the message contains an indication of incremental RRC configuration, then the CHO modification from the source MN to the candidate target MN triggers a modification of the candidate target SN.

[0294] - Send a "Handover Request Confirmation" message to the first network node (which is the source MN, such as the source gNodeB). This "Handover Request Confirmation" message may include information about the SN to be maintained during the CHO execution.

[0295] In one embodiment, the candidate target MN includes an MN RRC reconfiguration message to be sent to the UE to perform conditional handover configuration within the handover request confirmation message, and may also provide a forwarding address to the source MN. If PDU session splitting is to be performed on the candidate target side during the conditional handover execution process, more than one data forwarding address corresponding to each node is included in the handover request confirmation message. If the candidate target MN and the candidate target SN decide to maintain the UE context in the SN, the candidate target MN instructs the source MN to maintain the UE context in the SN.

[0296] Figure 20A and Figure 20B An example of the "Switch Request" message mentioned above is shown together, which contains the information described in this section.

[0297] Another embodiment is a method performed at a fourth network node used as a candidate target SN, the method comprising:

[0298] - Receive an SN add request from a third network node that serves as a candidate target MN, the SN add request including an indication that the request is for CHO;

[0299] When it is determined that the SN add request is for a CHO candidate target MN, the third network node is able to set its supervisory timer to a value that is longer than the value it would set for a traditional HO and / or traditional SN add request.

[0300] ○ When it is determined that the SN add request is for the CHO candidate target MN, the third network node may accept another SN add request for the same UE;

[0301] In one embodiment, the SN add request includes an indication that the request is associated with a CHO procedure (i.e., the requesting node is a candidate target MN). Based on this indication, the candidate target SN determines that the UE may not perform a handover (therefore not applying the SCG configuration and not performing a reconfiguration synchronized with the SCG's SpCell), or will perform it at a later point in time (i.e., when the CHO conditions to be configured for the UE will be met).

[0302] In one embodiment, the received SN Add Request message includes the SN UE XnAP ID as a reference to the UE context established by the source MN in the candidate target SN; upon receiving this message, the candidate target SN determines that the candidate target MN is requesting the SN to retain the UE context in the SN after the CHO is executed. The SN then anticipates that the source MN (at the time of CHO execution) will trigger an SN Release, since in this case, the candidate target SN is the same as the source SN.

[0303] In one embodiment, if the candidate target MN decides to change the SN (i.e., a different candidate target SN compared to the source SN), the received SN Add Request message includes the UE context established by the source MN in the source SN. Then, when the UE executes a CHO, the candidate target SN waits for a reconfiguration completion indication from the candidate target MN and sends an RRC reconfiguration completion to the candidate target MN when the CHO is executed.

[0304] In one embodiment, the received SN addition request includes an indication that the request is associated with a conditional SN addition process (i.e., the UE receiving the configuration applies it not upon reception, but when conditions are met). Furthermore, the message may contain at least another indication enabling the candidate target SN to distinguish between mobility scenarios (i.e., the requesting node is the target MN) and SN addition scenarios (where the UE is not operating in the MR-DC and the requesting node is the source MN associated with the serving cell (e.g., the SpCell of the MCG).

[0305] - Send an SN add request confirmation to the third network node used as the candidate target MN.

[0306] ○ When it is determined that the message is sent in response to a request to add an SN to a CHO candidate target MN, a monitoring timer is started when the message is sent to the third network node.

[0307] ■ In one embodiment, the supervisory timer is the TXn DC total timer, as specified in TS 38.423.

[0308] In one embodiment, the candidate target SN prepares SN-related configurations for the UE, such as the SCG configuration in the RRC reconfiguration message.

[0309] In one embodiment, the candidate target SN sends an SN add request confirmation to the candidate target MN, which may include an indication of full or incremental RRC configuration.

[0310] If the candidate target SN does not wish to support SCG modification when CHO is modified, the SN prepares an RRC reconfiguration associated with the SN. This RRC reconfiguration is a full configuration for the UE (i.e., non-incremental) and includes an indication of the full RRC configuration.

[0311] If the candidate target SN supports SCG modification when CHO is modified, the SN prepares an RRC reconfiguration associated with the SN. This RRC reconfiguration is an incremental configuration for the UE and includes an indication of the incremental RRC configuration.

[0312] CHO execution technology

[0313] An example embodiment is a method performed at a first network node used as the source MN, the method comprising:

[0314] - Receive a second message from a third node, which is a candidate target node (e.g., a candidate target gNodeB for which a CHO has been configured); and

[0315] ○ In one embodiment, the second message is a "switching successful" message.

[0316] ■ A “Handover Success” message is received as part of the handover success process and is used during conditional handover or DAPS handover to enable the target NG-RAN node to notify the source NG-RAN node that the UE has successfully accessed the target NG-RAN node. In other words, receiving a “Handover Success” message from a specific target NG-RAN (i.e., one of the candidate target MNs) indicates that the UE has successfully accessed that specific target NG-RAN node.

[0317] ■ If delayed data forwarding is configured, the source NG-RAN node should use the tunnel information associated with the global target cell ID provided in the "Handover Success" message to initiate data forwarding. In this specific case, where the UE is in the MR-DC when the CHO is executed and notified via the "Handover Success" message, data forwarding may involve the source SN node (e.g., "state transfer", data forwarding from the source SN to the source MN, etc.). Details are provided in later embodiments.

[0318] ■ When the source NG-RAN node receives the “Switch Successful” message, it should assume that all other CHO preparations accepted for the UE in the target NG-RAN node have been cancelled, and (if any) can initiate a handover cancellation procedure for the UE to other candidate target NG-RAN nodes, and if the UE is configured with dual connectivity, can initiate an S-NG-RAN node release procedure initiated by the M-NG-RAN node, as described in TS 37.340[8].

[0319] ○ In one embodiment, the second message may be one of the following messages:

[0320] ■ "UE Context Release"

[0321] ■ "Request to retrieve UE context"

[0322] ○ In one embodiment, the second message is not a "switch request confirmation" message;

[0323] ○ In one embodiment, the second message is any message indicating to the source MN that a conditional switch has been performed;

[0324] ■This message can be received by the UE;

[0325] ■This message can be received from the candidate target node;

[0326] ○ In one embodiment, the second message is any message indicating to the source MN that the conditional switch has been successfully executed;

[0327] ■This message can be received by the UE;

[0328] ■This message can be received from the candidate target node;

[0329] In one embodiment, the second message may include one of the following indications:

[0330] ■The UE has been given an instruction that includes the configuration of MR-DC (i.e., when CHO is executed, the UE either starts operating in MR-DC or continues operating in MR-DC);

[0331] ■The UE has been configured to include MR-DC and is instructed to maintain the SN context during CHO execution.

[0332] - Send an "SN release request" message to the second network node used as the source SN (S-SN) (e.g., source auxiliary gNodeB (source SgNB));

[0333] ○ In one embodiment, the method includes, for example, initiating an SN release procedure to the source SN upon receiving a second message (e.g., a switch success message) from a candidate target MN.

[0334] ○ The receiving instruction for the second message is executed by the CHO in the candidate target MN, which sends the second message to the first network node.

[0335] In one embodiment, upon receiving a "handover successful" message, the source MN initiates a release of resources from the source SN, including a reason indicating MCG mobility. The SN acknowledges the release request. If data forwarding is required, the MN provides a data forwarding address to the source SN. Receipt of the "SN release request" message triggers the source SN to stop providing user data to the UE and, if applicable, to begin data forwarding.

[0336] In one embodiment, a first network node (e.g., S-MN) indicates a cause value for a "SN release request" to a second network node (e.g., source SN, S-SN), indicating that the release was triggered due to a condition switch. The cause value can be at least one of the following:

[0337] ■MN mobility;

[0338] ● This can be used as a cause value when S-SN does not require any distinction between CHO and traditional HO (e.g., when sending "SN release request confirmation").

[0339] ■Conditional MN mobility;

[0340] ● This can be used as a cause value when the S-SN needs to differentiate between CHO and traditional HO (e.g., when sending an "SN release request confirmation" that includes specific information);

[0341] ■MCG mobility;

[0342] ● This can be used as a cause value when S-SN does not require any distinction between CHO and traditional HO (e.g., when sending "SN release request confirmation").

[0343] ■Conditional MCG mobility;

[0344] ● This can be used as a cause value when the S-SN needs to differentiate between CHO and traditional HO (e.g., when sending an "SN release request confirmation" that includes specific information);

[0345] In one embodiment, the source MN indicates to the (source) SN to retain the UE context in the SN if the source MN has already received this indication from the candidate target MN during the CHO preparation phase. This means that the information is stored in the UE context during the preparation phase and is therefore used during the CHO execution phase. If the indication to retain the UE context in the SN is included, the SN retains the UE context.

[0346] - Receive an "SN release request confirmation" message from the second network node used as the source SN (S-SN) (e.g., source auxiliary gNodeB (source SgNB));

[0347] ○ Receiving a “SN release request confirmation” confirms from the S-SN that the resource has been released;

[0348] The S-NG-RAN node release procedure initiated by the M-NG-RAN node is triggered by the M-NG-RAN node to release resources used for a specific UE. This procedure uses signaling associated with the UE.

[0349] In one embodiment, if the S-NG-RAN node provides data forwarding related information for a QoS flow in the "S-Node Release Request Confirmation" message (which it receives in the first network node S-MN), and the QoS flow is mapped to a DRB configured with the SN termination bearer option in the PDU Session Release List - SN Termination IE, the M-NG-RAN node may decide to provide a data forwarding address to the S-NG-RAN node and trigger the Xn-U address indication procedure, as specified for CHO in 3GPP TS 37.340.

[0350] Figure 21 An example is shown below of how the "handover successful" message discussed above might be defined in 3GPP TS 38.423.

[0351] Figure 22A and Figure 22B The example shown illustrates how the SN release request acknowledgment message discussed above can be defined in the 3GPP specification.

[0352] In some embodiments of the technology just described, if data forwarding is required, the first network node (e.g., the source MN):

[0353] - Initiate the address indication process to the second network node;

[0354] ○ In one embodiment, the address indication procedure is the XN-U address indication procedure as defined in TS 38.423 (e.g., in subsection 8.2.6).

[0355] ○ In one embodiment, the first network node corresponds to an M-NG-RAN node.

[0356] ○ In one embodiment, the first network node indicates its own one (or more) forwarding addresses to the source SN during the address indication process;

[0357] ○ In one embodiment, the first network node (e.g., an M-NG-RAN node) sends an "XN-U address indication" message;

[0358] In one embodiment, if the first network node receives an indication to retain the SN during CHO preparation (in a handover request confirmation message), the source MN includes a UE context retention indicator IE set to "True" in the "SN release request" (e.g., "S node release request").

[0359] In one embodiment, if the UE context retention indicator IE is set to “True” and the DRB transmitted to the MNIE is included in the “S-Node Release Request” message, the S-NG-RAN node should provide uplink / downlink PDCP SN and HFN status for the listed DRB, as specified in TS 37.340[8].

[0360] For MR-DCs with 5GC, the Xn-U address indication procedure is used to provide forwarding address and Xn-U bearer address information to complete the establishment of the SN termination bearer from the M-NG-RAN node to the S-NG-RAN node, as specified in TS 37.340. Figure 23A and Figure 23B The image shows an example of how this message is defined in the 3GPP specification.

[0361] In some embodiments, the above method may further include determining that delayed data forwarding (LDF) will be performed.

[0362] In one embodiment, this is determined based on, for example, a configuration provided from an Operation and Maintenance (OAM) system.

[0363] - Receive SN status transmission from the second network node used as the source SN;

[0364] For each corresponding DRB of the S-SN DRB configuration that applies PDCP SN and HFN state preservation, the source MN receives the uplink PDCP SN and HFN receiver states and the downlink PDCP SN and HFN transmitter states from the S-SN.

[0365] The source MN receives the SN "state transmission" message from the S-SN at the point in time when it believes the transmitter / receiver state is frozen.

[0366] In the case of MR-DC, if the S-MN performs a PDCP SN length change or RLC mode change for the DRB as specified in TS 37.340[8], it should ignore the information received for the DRB in the message.

[0367] For each DRB for which the S-SN has accepted a request for uplink forwarding from the S-MN, the S-MN may receive the lost and received uplink SDUs in the Receive State of the UL PDCP SDUs IE in the SN State Transmission message.

[0368] For each DRB constrained by the State Transfer List (IE), the S-MN should not transmit any uplink packets with a PDCP-SN that is lower than the value contained in the UL count value within the IE.

[0369] For each DRB constrained by the State Transfer List (IE), the S-MN shall use the PDCP SN value contained in the DL count value IE for the first downlink packet for which a PDCP-SN has not yet been assigned.

[0370] For at least one DRB, if the reception status of the UL PDCP SDUs IE is included in the “SN Status Transmission” message, the S-MN node can use it in the status report message sent to the UE via the radio interface.

[0371] If the “SN State Transfer” message contains the old QoS flow list - UL end marker expected IE in the DRB constrained by the State Transfer List IE, then the S-MN should be prepared to receive the SDAP end marker for the QoS flow via the corresponding DRB, as specified in TS38.300[8].

[0372] - Send SN status transmission to a third network node (e.g., candidate target node, target gNodeB).

[0373] - Forward data to a third network node (e.g., target gNodeB).

[0374] - Receive forwarded data from the second network node used as the source SN;

[0375] In one embodiment, if delayed data forwarding is applied, the first network node (e.g., the source MN) initiates data forwarding once it knows which target MN the UE has successfully accessed. In this case, the behavior of conditional handover data forwarding follows the same behavior defined in 9.2.3.2.3 for intra-system handover data forwarding, except for the behavior of the DRB configured with DAPS handover.

[0376] In another embodiment, the source MN only begins forwarding data to the target MN after receiving the "SN status transmission" from the S-SN (after receiving "successful handover").

[0377] Another example embodiment is a method performed at a second network node used as the source SN, the method including (e.g., performed by a CHO):

[0378] - Receive the "SN Release Request" message from the first network node used as the source MN (S-MN);

[0379] ○ In one embodiment, the method includes, for example, initiating an SN release procedure to the source SN upon receiving a second message (e.g., a handover success message) from a candidate target.

[0380] ○ The CHO in the candidate target for receiving the second message is executed, and the candidate target sends the second message to the first network node.

[0381] In one embodiment, upon receiving a "handover successful" message, the MN initiates a release of resources from the source SN, including a reason indicating the mobility of the MCG. The SN acknowledges the release request. If data forwarding is required, the MN provides a data forwarding address to the source SN. Receipt of the "SN release request" message triggers the source SN to stop providing user data to the UE and, if applicable, to begin data forwarding.

[0382] In one embodiment, a first network node (e.g., S-MN) indicates a cause value for a "SN release request" to a second network node (e.g., source SN, S-SN), indicating that the release was triggered due to a condition switch. The cause value can be at least one of the following:

[0383] ■MN mobility;

[0384] ● This can be used as a cause value when S-SN does not require any distinction between CHO and traditional HO (e.g., when sending "SN release request confirmation").

[0385] ■Conditional MN mobility;

[0386] ● This can be used as a cause value when the S-SN needs to differentiate between CHO and traditional HO (e.g., when sending an "SN release request confirmation" that includes specific information);

[0387] ■MCG mobility;

[0388] ● This can be used as a cause value when S-SN does not require any distinction between CHO and traditional HO (e.g., when sending "SN release request confirmation").

[0389] ■Conditional MCG mobility;

[0390] ● This can be used as a cause value when the S-SN needs to differentiate between CHO and traditional HO (e.g., when sending an "SN release request confirmation" that includes specific information);

[0391] In one embodiment, the source SN that receives the “SN release request” message stops providing user data to the UE and (if applicable) begins data forwarding.

[0392] In one embodiment, upon receiving a “SN release request” (e.g., “S node release request”) message containing a UE context hold indicator IE set to “true”, the S-NG-RAN node should (if supported) initiate the release of resources only for the UE-associated signaling connection between the M-NG-RAN node and the S-NG-RAN node.

[0393] In one embodiment, if an S-NG-RAN node confirms a request to release S-NG-RAN node resources, it should send an "S-Node Release Request Confirmation" message to the M-NG-RAN node.

[0394] In one embodiment, if the UE context retention indicator IE is set to “True” and the DRB transmitted to the MNIE is included in the “S-Node Release Request” message, the S-NG-RAN node should provide uplink / downlink PDCP SN and HFN status for the listed DRB, as specified in TS 37.340[8].

[0395] - Send a "SN release request confirmation" message to the first network node used as the source MN (S-MN);

[0396] ○ Confirmation of "SN Release Request" sent confirming that the SN resource has been released;

[0397] In one embodiment, the second network node (e.g., the S-NG-RAN node) provides data forwarding related information for a QoS flow in an S-Node Release Request Confirmation message (which it receives in the first network node S-MN), the QoS flow being mapped to a DRB configured with the SN Termination Bearer option in the PDU Session Release List - SN Termination IE, and the S-NG-RAN node may decide to provide a data forwarding address to the S-NG-RAN node and trigger the Xn-U address indication process, as specified for CHO in TS 37.340[8].

[0398] ■ In one embodiment, the sub-step including data forwarding information is executed only when delayed data forwarding of the SN is configured (e.g., requested in an SN release request, etc.).

[0399] In some embodiments, the method may further include receiving an Xn-U address indication from a first network node acting as the source MN (S-MN):

[0400] In this message, the source MN provides the data forwarding address to the source SN.

[0401] Upon receiving the “XN-U address indication” message, in the case of data forwarding, the second network node (e.g., an S-NG-RAN node) should initiate data forwarding by forwarding the pending DL user data to the indicated TNL address;

[0402] ○ Upon completion of the Xn-U bearer establishment for the SN termination bearer, the S-NG-RAN node may begin transmitting user data to the indicated TNL address. If the XN-U address indication message includes the DRB ID IE used, the S-NG-RAN node shall (if applicable) operate as specified in TS 37.340[8].

[0403] - Some of these embodiments may also include determining that data forwarding is required;

[0404] Some of these embodiments may also include determining that delayed data forwarding will be performed.

[0405] - Some of these embodiments may also include sending SN status transmissions to a first network node used as the source MN;

[0406] For each corresponding DRB§ of the S-SN DRB configuration that applies PDCP SN and HFN state preservation, the S-SN transmits the uplink PDCP SN and HFN receiver states and the downlink PDCP SN and HFN transmitter states from the S-SN to the S-MN.

[0407] ○The S-SN initiates the process at the point when it considers the transmitter / receiver state to be frozen by: ceasing to allocate PDCP SN to the downlink SDU, ceasing to transmit UL SDU to the 5GC, and sending SN status transmission messages to the S-MN node.

[0408] In the case of MR-DC, if the S-MN performs a PDCP SN length change or RLC mode change for the DRB as specified in TS 37.340[8], it should ignore the information received for the DRB in the message.

[0409] For each DRB that uses PDCP-SN and HFN state storage, the S-SN node should include the DRB ID IE, UL count value IE, and DL count value IE in the DRB constrained by the state transfer list IE in the "SN State Transfer" message.

[0410] For each DRB for which the S-SN has accepted a request for uplink forwarding from the S-MN, the S-SN may also include the lost and received uplink SDUs in the UL PDCP SDUs IE receive status in the SN status transmission message.

[0411] For each DRB constrained by the State Transmission List (IE), the S-MN node should not transmit any uplink packets with a PDCP-SN lower than the value contained in the UL count value within the IE.

[0412] For each DRB constrained by the State Transfer List (IE), the S-MN shall use the PDCP SN value contained in the DL count value IE for the first downlink packet to which a PDCP-SN has not yet been assigned.

[0413] For at least one DRB, if the reception status of the UL PDCP SDUs IE is included in the “SN Status Transmission” message, then the S-MN can be used in the status report message sent to the UE via the radio interface.

[0414] ○ If the “SN State Transfer” message contains an old QoS flow list - UL end marker expected IE in a DRB constrained by a state transfer list IE, then the S-MN should be prepared to receive the SDAP end marker for the QoS flow via the corresponding DRB, as specified in TS38.300. An example definition of this message is provided in... Figure 24 As shown in the image.

[0415] Some of these embodiments may also include forwarding data to a first network node (e.g., source gNodeB, source MN).

[0416] ○ This data may be DL data that the S-SN is still receiving from the UPF or DL ​​data that the S-SN is still receiving from the UE.

[0417] Some of these embodiments may also include notifying the S-SN that a CHO is being configured at the UE; the S-SN receives a message (e.g., an "SN Request Release" message) from the S-MN, which indicates that the message is being triggered because a CHO has already been configured at the UE. In that case, the source SN does not release the SN resource upon receipt, but it is prepared to release it (e.g., upon receiving another "SN Request Release" message) and sends an "SN Request Release Confirmation" to the source MN;

[0418] Another example embodiment includes a method performed at a third network node (used as a candidate target MN), the method comprising:

[0419] - Receive the RRC reconfiguration complete message from the UE;

[0420] This message can be included in the second RRC reconfiguration complete message associated with the SCG reconfiguration; the UE has also applied the CHO execution.

[0421] ○ In one embodiment, the RRC reconfiguration complete message is the RRCReconfigurationComplete message;

[0422] In another embodiment, the RRC reconfiguration complete message is the RRCConnectionReconfigurationComplete message;

[0423] ○ In one embodiment, the second RRC reconfiguration complete message is an RRCReconfigurationComplete message;

[0424] In another embodiment, the second RRC reconfiguration complete message is an RRCConnectionReconfigurationComplete message;

[0425] - Determine that the incoming UE has been configured with CHO and has associated MR-DC related configuration for the fourth network node (used as a candidate SN target);

[0426] This can be accomplished by identifying the C-RNTI that the incoming UE has already used, which is the same as the C-RNTI assigned to a possible incoming UE configured with CHO.

[0427] - Send an SN reconfiguration complete message to the fourth network node (used as a candidate SN target);

[0428] This message includes an RRC reconfiguration complete message associated with SCG reconfiguration and sent from the UE;

[0429] This is a way to confirm to the candidate target SN that the RRC connection reconfiguration process has been successful.

[0430] - Send a message to the first node that is the source MN (e.g., the source gNodeB that has been configured with CHO);

[0431] In one embodiment, the message is a switchover success message.

[0432] By including a second RRC reconfiguration complete (which can be either nr-SCG-Response (also an RRCReconfigurationComplete message) or eutra-SCG-Response) related to the SCG applied to the CHO in the scg-Response field, the RRCReconfigurationComplete message specified in the 3GPP standard can be modified to support the techniques described herein. This might look like this, for example:

[0433]

[0434] Another example embodiment is a method performed at a fourth network node (used as a candidate target SN), the method comprising:

[0435] - Receive the SN reconfiguration complete message from the third network node (as the MN candidate target);

[0436] This message includes an RRC reconfiguration complete message associated with SCG reconfiguration and sent from the UE;

[0437] - Stop monitoring the timer; treat the UE context as active.

[0438] Figure 5 The above-described execution process is summarized in the text.

[0439] CHO cancellation technique (e.g., in another candidate MN)

[0440] Another example embodiment is a method performed in a source MN, the method comprising:

[0441] - Receive a message from the first candidate target MN regarding the UE's execution of the CHO;

[0442] ○ In one embodiment, the message is a successful switchover message;

[0443] - Send a message to the second candidate target MN to which the UE has not yet executed the CHO, the message including an indication that the CHO configuration will be released;

[0444] Another example embodiment is a method performed in a candidate target MN, the method comprising:

[0445] - Receive a message from the source MN that includes an indication that the CHO configuration will be released;

[0446] - Determine whether the CHO configuration used to associate the UE has an associated target SN candidate;

[0447] - Trigger the SN release process by sending an SN release request message to the candidate target SN;

[0448] - Receive confirmation of SN release request from candidate target SN;

[0449] Figure 6 The document provides examples as discussed above.

[0450] The advantages of the disclosed embodiments are that they enable UEs operating in MR-DC to be configured for conditional reconfiguration (e.g., conditional handover - CHO), and specifically, they enable candidate target MNs to maintain SN or modify / change SN.

[0451] According to various embodiments, the target MN candidate can configure the SN candidate target to maintain or change the SN without the risk of the SN candidate target setting the supervision timer too short, as this is obvious for CHO. Since the time between sending the SN add request and receiving the SN reconfiguration completion is longer than conventional methods, and because in CHO, the UE may need a longer time to access the candidate target MN, or even be unable to access it, this method can be used to avoid undesirable SN releases from the candidate target SN. This avoids a considerable amount of contention, for example, where the candidate target MN must modify its CHO configuration against the source MN. In some embodiments, considering that the UE may connect after a longer time compared to conventional SN add or may not connect at all, the candidate target SN can also reserve resources for the UE, which will result in optimized resource allocation within the node.

[0452] Furthermore, in some embodiments, when the target MN candidate sends a switch request confirmation message in response to a CHO, if it has already decided to keep or change the SN, the method prevents the process of defining the source MN to release the SN by delaying the action until the CHO is executed.

[0453] As an example of a possible implementation of a 3GPP specification, the implementation of the technology described herein may require modifications to the 3GPP TS37.340 specification. Examples of modifications to this 3GPP specification to implement certain parts of the currently disclosed technology are provided below.

[0454] ********************Start of Example 3GPP Specification*******************

[0455] 10.7 Switching between primary nodes with / without secondary node changes

[0456] 10.7.1 EN-DC

[0457] A master node handover with or without a secondary node change initiated by an MN is used to transfer context data from the source MN to the target MN, while the context at the SN is either retained or moved to another SN. During the master node handover, the target MN decides whether to retain or change the SN (or release the SN, as described in Section 10.8).

[0458] Note 1: This version of the protocol does not support master node switching between systems with / without SN changes (e.g., it does not support conversion from EN-DC to NGEN-DC or NR-DC).

[0459] [Image omitted - see attached] Figure 25 ]

[0460] [ Figure 25 This illustrates an example signaling flow for master node handover with or without MN-initiated secondary node changes:

[0461] Note 2: For switching between primary nodes that do not have changes in secondary nodes. Figure 10 The source SN and target SN shown in .7.1-1 are the same node.

[0462] 1. The source MN initiates the handover process by launching an X2 handover preparation procedure that includes MCG and SCG configurations. The source MN includes the source SN, UE X2AP ID, SN ID, and UE context in the (source) SN in the handover request message.

[0463] Note 3: The source MN can trigger the SN modification process initiated by the MN (to the source SN) before step 1 to retrieve the current SCG configuration.

[0464] 2. If the target MN decides to maintain the SN, it sends an SN Add Request to the SN, which includes the SN UE X2AP ID as a reference to the UE context established by the source MN in the SN. If the target MN decides to change the SN, it sends an SgNB Add Request to the target SN, which includes the UE context established by the source MN in the source SN. The target MN may also instruct the SN Add Request to be associated with conditional handover.

[0465] 3. The (target) SN uses the SN to add a request confirmation in response. The (target) SN may include indications of the full or incremental RRC configuration.

[0466] 4. The target MN includes a transparent container in the handover request confirmation message to be sent to the UE as an RRC message to perform the handover, and may also provide a forwarding address to the source MN. If the target MN and SN decide to preserve the UE context in the SN in steps 2 and 3, the target MN instructs the source MN to preserve the UE context in the SN.

[0467] 5. The source MN sends an SN release request to the (source) SN, which includes an indication of the reason for MCG mobility. The (source) SN acknowledges the release request. The source MN instructs the (source) SN to maintain the UE context in the SN, if the source MN receives this instruction from the target MN. If the instruction to maintain the UE context in the SN is included, the SN maintains the UE context.

[0468] Note 2: In the case of a conditional handover, as described in TS 36.300[2], step 5 is performed after the source MN receives an indication that the UE has successfully accessed one of the candidate target eNBs (i.e., after step 9).

[0469] 6. The source MN triggers a new configuration for the UE application.

[0470] 7 / 8. The UE synchronizes with the target MN and replies with an RRCConnectionReconfiguration-Complete message.

[0471] 9. If the UE is configured with a bearer that requires SCG radio resources, the UE synchronizes with the (target) SN.

[0472] 10. If the RRC connection reconfiguration process is successful, the target MN will notify the (target) SN of the reconfiguration completion message via the SgNB.

[0473] 11a.SN sends a secondary RAT data usage report message to the source MN, including the amount of data transmitted to and received from the UE via NR radio for the relevant E-RAB.

[0474] Note 4: The order in which the source SN sends secondary RAT data using report messages and performs data forwarding with the MN / target SN is undefined. The SgNB may send a report when transmission of the associated bearer is stopped.

[0475] 11b. The source MN sends a secondary RAT report message to the MME to provide information about the NR resources used.

[0476] 12. For bearers using RLC AM, the source MN sends an SN state transmission to the target MN, which includes, if necessary, the SN state received from the source SN. If necessary, the target forwards the SN state to the target SN.

[0477] 13. If applicable, forward data from the source side. If the SN is maintained, data forwarding can be omitted for bearers whose SNs are terminated and maintained within the SN.

[0478] 14 to 17. The target MN initiates the S1 path switching process.

[0479] Note 5: If a new UL TEID is included in the S-GW, the target MN performs the MN-initiated SN modification process to provide them to the SN.

[0480] 18. The target MN initiates a UE context release process to the source MN.

[0481] 19. Upon receiving a UE context release message, the (source) SN releases the C-plane related resources associated with the UE context to the source MN. Any ongoing data forwarding may continue. If the UE context retention indication is included in the SgNB release request message in step 5, the SN should not release the UE context associated with the target MN.

[0482] 10.7.2 MR-DC with 5GC

[0483] Inter-MN handover with / without MN-initiated SN change is used to transfer UE context data from the source MN to the target MN, while the UE context at the SN is maintained or moved to another SN. During the inter-master node handover, the target MN decides whether to maintain or change the SN (or release the SN, as described in Section 10.8). Only intra-RAT inter-master node handovers with / without SN change are supported (e.g., transitions from NGEN-DC to NR-DC are not supported).

[0484] [Image omitted - see attached] Figure 26 ]

[0485] [ Figure 26 The example signaling flow for inter-MN handover with or without MN-initiated SN changes is shown.

[0486] Note 1: For switching between primary nodes that do not have changes in secondary nodes. Figure 10 The source SN and target SN shown in .7.2-1 are the same node.

[0487] 1. The source MN initiates the handover process by launching an Xn handover preparation procedure that includes MCG and SCG configurations. The source MN includes the source SN, UE XnAP ID, SN ID, and UE context in the source SN in the handover request message.

[0488] Note 2: The source MN can trigger the SN modification process initiated by the MN (to the source SN) before step 1 to retrieve the current SCG configuration and allow the provision of data forwarding related information.

[0489] 2. If the target MN decides to maintain the source SN, the target MN sends an SN add request to the SN, which includes the SN UE XnAP ID as a reference to the UE context established by the source MN in the SN. If the target MN decides to change the SN, the target MN sends an SN add request to the target SN, which includes the UE context established by the source MN in the source SN. The target MN may also instruct the SN add request to be associated with conditional handover.

[0490] Note: If the switch is a conditional switch, then the candidate target MN in step 2 includes the CHO indication in the SN add request.

[0491] 3. The (target) SN uses the SN to add a request confirmation in response. The (target) SN may include indications of the full or incremental RRC configuration.

[0492] 4. The target MN includes an MN RRC reconfiguration message to be sent to the UE for handover in the handover request confirmation message, and may also provide a forwarding address to the source MN. If PDU session splitting is to be performed on the target side during the handover process, more than one data forwarding address corresponding to each node is included in the handover request confirmation message. If the target MN and SN decide to maintain the UE context in the SN in steps 2 and 3, the target MN instructs the source MN to maintain the UE context in the SN.

[0493] 5a / 5b. The source MN sends an SN release request message to the (source) SN, which includes an indication of the reason for MCG mobility. The (source) SN acknowledges the release request. The source MN instructs the (source) SN to maintain the UE context in the SN, if the source MN receives this instruction from the target MN. If the instruction to maintain the UE context in the SN is included, the SN maintains the UE context.

[0494] Note 2: In the case of a conditional handover, as described in TS 38.300[3], step 3 is performed after the source MN receives an indication that the UE has successfully accessed one of the potential target ng-eNB / gNB (i.e., after step 9).

[0495] 5c. The source MN sends an XN-U address indication message to the (source) SN to transmit data forwarding information. If the PDU session is split on the target side, more than one data forwarding address can be provided.

[0496] 6. The source MN triggers the UE to perform a handover and apply the new configuration.

[0497] 7 / 8. The UE synchronizes with the target MN and replies with the MN RRC reconfiguration completion message.

[0498] 9. If the UE is configured with a bearer that requires SCG radio resources, the UE synchronizes with the (target) SN.

[0499] 10. If the RRC connection reconfiguration process is successful, the target MN will notify the (target) SN of the reconfiguration completion message via the SN.

[0500] 11a. The source SN sends a secondary RAT data usage report message to the source MN, including the amount of data transmitted to and received from the UE via NR / E-UTRA radio, as described in Section 10.11.2.

[0501] Note 2a: The order in which the source SN sends secondary RAT data using report messages and performs data forwarding with the MN / target SN is undefined. An SN may send a report when transmissions with a relevant QoS are stopped.

[0502] 11b. The source MN sends a secondary RAT report message to the AMF to provide information about the NR / E-UTRA resources used.

[0503] *******************End of Example 3GPP Specification********************

[0504] Some of the foregoing embodiments are described in scenarios where a UE is configured with multiple radio dual connectivity (MR-DC) when it receives a conditional handover (CHO) configuration. The embodiments described herein focus on NR-DC (i.e., when both the primary and secondary nodes are NRgNBs), but these embodiments are equally applicable to other DC scenarios (e.g., NE-DC, (NG)EN-DC, and LTE DC).

[0505] The embodiments described herein have been used for most of the time by the term Conditional Switching (CHO). Other terms (e.g., Conditional Reconfiguration or Conditional Configuration) may be considered synonyms (since the message stored and applied when the condition is met is RRCReconfiguration or RRCConnectionReconfiguration).

[0506] The principle of configuration is the same as configuring the trigger / execution conditions and the reconfiguration message to be applied when the trigger conditions are met.

[0507] While the subjects described herein can be implemented using any suitable components in any suitable type of system, the embodiments disclosed herein pertain to wireless networks (e.g., Figure 27 The example wireless network shown is described below. For simplicity, Figure 27The wireless network depicted only includes network 2706, network nodes 2760 and 2760b, and WD 2710, 2710b, and 2710c. In practice, the wireless network may also include any additional elements suitable for supporting communication between wireless devices or between a wireless device and another communication device (such as a landline telephone, service provider, or any other network node or terminal device). Among the components shown, network node 2760 and wireless device (WD) 2710 are depicted with additional details. The wireless network can provide communication and other types of services to one or more wireless devices to facilitate access to and / or use of services provided by or via the wireless network.

[0508] Wireless networks can include any type of communications, telecommunications, data, cellular and / or radio networks or other similar systems, and / or interface with any type of communications, telecommunications, data, cellular and / or radio networks or other similar systems. In some embodiments, a wireless network can be configured to operate according to a specific standard or other type of predefined rules or procedures. Thus, specific embodiments of a wireless network can implement communication standards such as Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), Narrowband Internet of Things (NB-IoT), and / or other suitable 2G, 3G, 4G, or 5G standards; Wireless Local Area Network (WLAN) standards, such as the IEEE 802.11 standard; and / or any other suitable wireless communication standards, such as Global Microwave Access Interoperability (WiMax), Bluetooth, Z-Wave, and / or ZigBee standards.

[0509] Network 2706 may include one or more backhaul networks, core networks, IP networks, public switched telephone networks (PSTN), packet data networks, optical networks, wide area networks (WAN), local area networks (LAN), wireless local area networks (WLAN), wired networks, wireless networks, metropolitan area networks, and other networks to enable communication between devices.

[0510] Network node 2760 and WD 2710 include various components described in more detail below. These components work together to provide network node and / or wireless device functionality, such as providing wireless connectivity in a wireless network. In different embodiments, the wireless network may include any number of wired or wireless networks, network nodes, base stations, controllers, wireless devices, relay stations, and / or any other components that can facilitate or participate in the communication of data and / or signals (whether via wired or wireless connections).

[0511] As used herein, a network node refers to a device capable of, configured, positioned, and / or operatively communicating directly or indirectly with wireless devices and / or with other network nodes or devices in a wireless network to enable and / or provide wireless access to the wireless devices and / or perform other functions (e.g., management) in the wireless network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points) and base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs), and NR Node Bs (gNBs)). Base stations can be classified based on the coverage they provide (or, in other words, the transmit power level of the base station), and thus can also be referred to as femtobases, picobases, microbases, or macrobases. A base station can be a relay node or a relay donor node controlling a relay. A network node can also include one or more (or all) portions of a distributed radio base station, such as a centralized digital unit and / or a remote radio unit (RRU), sometimes referred to as a remote radio headend (RRH). These remote radio units may be integrated with an antenna to form an antenna-integrated radio, or may not be integrated with an antenna to form an antenna-integrated radio. A portion of a distributed radio base station can also be referred to as a node in a distributed antenna system (DAS). Further examples of network nodes include multi-standard radio (MSR) equipment (e.g., MSR BS), network controllers (e.g., Radio Network Controller (RNC) or Base Station Controller (BSC)), base transceiver stations (BTS), transmitting points, transmitting nodes, multi-cell / multicast coordination entities (MCE), core network nodes (e.g., MSC, MME), O&M nodes, OSS nodes, SON nodes, location nodes (e.g., E-SMLC), and / or MDTs. As another example, a network node can be a virtual network node, as described in more detail below. However, more generally, a network node can represent any suitable device (or group of devices) that is capable of, configured, arranged, and / or operable to enable and / or provide access to a wireless communication network for wireless devices, or to provide some service to wireless devices already connected to the wireless network.

[0512] exist Figure 27 In this network node 2760, processing circuitry 2770, device-readable medium 2780, interface 2790, auxiliary equipment 2784, power supply 2786, power supply circuitry 2787, and antenna 2762 are included. Although Figure 27The network node 2760 shown in the exemplary wireless network may represent a device including a combination of the hardware components shown, but other embodiments may include network nodes with different combinations of components. It should be understood that a network node includes any suitable combination of hardware and / or software required to perform the tasks, features, functions, and methods disclosed herein. Furthermore, while the components of network node 2760 are depicted as a single box within a larger box, or nested within multiple boxes, in practice, a network node may include multiple different physical components constituting a single illustrated component (e.g., device-readable medium 2780 may include multiple separate hard disk drives and multiple RAM modules).

[0513] Similarly, network node 2760 may consist of multiple physically separate components (e.g., Node B components and RNC components, or BTS components and BSC components, etc.), each with its own corresponding components. In some scenarios where network node 2760 includes multiple separate components (e.g., BTS and BSC components), one or more separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such scenarios, each unique NodeB and RNC pair may be considered a single, separate network node in some cases. In some embodiments, network node 2760 may be configured to support multiple Radio Access Technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate device-readable media 2780 for different RATs), and some components may be reused (e.g., the same antenna 2762 may be shared by the RATs). Network node 2760 may also include multiple sets of various illustrated components for integrating different wireless technologies (e.g., GSM, WCDMA, LTE, NR, WiFi, or Bluetooth wireless technologies) into network node 2760. These wireless technologies can be integrated into the same or different chips or chipsets and other components within network node 2760.

[0514] Processing circuitry 2770 is configured to perform any determination, calculation, or similar operation (e.g., certain acquisition operations) described herein as being provided by a network node. These operations performed by processing circuitry 2770 may include information acquired by processing circuitry 2770 through processes such as: converting the acquired information into other information, comparing the acquired or converted information with information stored in the network node, and / or performing one or more operations based on the acquired or converted information, and making a determination based on the result of said processing.

[0515] Processor circuitry 2770 may include a combination of one or more of the following: a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field-programmable gate array, or any other suitable computing device, resource, or combination of hardware, software, and / or coding logic, operable to provide network node 2760 functionality, either alone or together with other network node 2760 components (e.g., device-readable medium 2780). For example, processing circuitry 2770 may execute instructions stored in device-readable medium 2780 or in memory within processing circuitry 2770. Such functionality may include providing any of the various wireless features, functions, or benefits discussed herein. In some embodiments, processing circuitry 2770 may include a system-on-a-chip (SoC).

[0516] In some embodiments, the processing circuitry 2770 may include one or more of a radio frequency (RF) transceiver circuitry 2772 and a baseband processing circuitry 2774. In some embodiments, the RF transceiver circuitry 2772 and the baseband processing circuitry 2774 may be on separate chips (or chipsets), boards, or units (e.g., radio units and digital units). In alternative embodiments, some or all of the RF transceiver circuitry 2772 and the baseband processing circuitry 2774 may be on the same chip or chipset, board, or unit group.

[0517] In some embodiments, some or all of the functions described herein as being provided by a network node, base station, eNB, or other such network device may be performed by processing circuitry 2770, which executes instructions stored on device-readable medium 2780 or memory within processing circuitry 2770. In alternative embodiments, some or all of the functions may be provided by processing circuitry 2770, for example, in a hard-wired manner, without executing instructions stored on separate or discrete device-readable media. In any of these embodiments, processing circuitry 2770 may be configured to perform the described functions regardless of whether instructions stored on device-readable storage media are executed. The benefits provided by such functions are not limited to processing circuitry 2770 or other components of network node 2760, but are enjoyed as a whole by network node 2760 and / or generally by end users and wireless networks.

[0518] Device-readable medium 2780 may include any form of volatile or non-volatile computer-readable storage, including but not limited to permanent storage devices, solid-state storage, remotely mounted storage, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (e.g., hard disk), removable storage media (e.g., flash drives, optical discs (CDs), or digital video discs (DVDs)) and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable storage device that stores information, data, and / or instructions that can be used by processing circuitry 2770. Device-readable medium 2780 may store any suitable instructions, data, or information, including computer programs, software, applications including one or more of logic, rules, codes, tables, etc., and / or other instructions that can be executed by processing circuitry 2770 and used by network node 2760. Device-readable medium 2780 may be used to store any calculations performed by processing circuitry 2770 and / or any data received via interface 2790. In some embodiments, the processing circuitry 2770 and the device-readable medium 2780 may be considered as integrated.

[0519] Interface 2790 is used for wired or wireless communication of signaling and / or data between network node 2760, network 2706, and / or WD 2710. As shown, interface 2790 includes a port / terminal 2794 for transmitting and receiving data to and from network 2706, for example, via a wired connection. Interface 2790 also includes a radio front-end circuit 2792, which may be coupled to antenna 2762, or in some embodiments, is part of antenna 2762. Radio front-end circuit 2792 includes filter 2798 and amplifier 2796. Radio front-end circuit 2792 may be connected to antenna 2762 and processing circuitry 2770. Radio front-end circuitry can be configured to modulate the signals communicating between antenna 2762 and processing circuitry 2770. Radio front-end circuitry 2792 can receive digital data that will be transmitted wirelessly to other network nodes or WD. The radio front-end circuit 2792 can use a combination of filter 2798 and / or amplifier 2796 to convert digital data into radio signals with suitable channel and bandwidth parameters. The radio signals can then be transmitted via antenna 2762. Similarly, when receiving data, antenna 2762 can collect radio signals, which are then converted into digital data by the radio front-end circuit 2792. The digital data can be passed to processing circuitry 2770. In other embodiments, the interface may include different components and / or different combinations of components.

[0520] In some alternative embodiments, network node 2760 may not include a separate radio front-end circuitry 2792. Instead, processing circuitry 2770 may include radio front-end circuitry and may be connected to antenna 2762 without requiring a separate radio front-end circuitry 2792. Similarly, in some embodiments, all or some of the RF transceiver circuitry 2772 may be considered part of interface 2790. In other embodiments, interface 2790 may include one or more ports or terminals 2794, radio front-end circuitry 2792, and RF transceiver circuitry 2772 as part of a radio unit (not shown), and interface 2790 may communicate with baseband processing circuitry 2774, which is part of a digital unit (not shown).

[0521] Antenna 2762 may include one or more antennas or antenna arrays configured to transmit and / or receive wireless signals. Antenna 2762 may be coupled to radio front-end circuitry 2790 and may be any type of antenna capable of wirelessly transmitting and receiving data and / or signals. In some embodiments, antenna 2762 may include one or more omnidirectional, sector, or planar antennas operably transmitting / receiving radio signals between, for example, 2 GHz and 66 GHz. Omnidirectional antennas can be used to transmit / receive radio signals in any direction, sector antennas can be used to transmit / receive radio signals relative to a device within a specific area, and planar antennas can be line-of-sight antennas used to transmit / receive radio signals in a relatively straight line. In some cases, the use of more than one antenna may be referred to as MIMO. In some embodiments, antenna 2762 may be separate from network node 2760 and may be connected to network node 2760 via an interface or port.

[0522] Antenna 2762, interface 2790, and / or processing circuitry 2770 can be configured to perform any receive operation and / or certain acquire operation described herein as being performed by a network node. Any information, data, and / or signals can be received from a wireless device, another network node, and / or any other network device. Similarly, antenna 2762, interface 2790, and / or processing circuitry 2770 can be configured to perform any transmit operation described herein as being performed by a network node. Any information, data, and / or signals can be transmitted to a wireless device, another network node, and / or any other network device.

[0523] Power supply circuit 2787 may include or be coupled to power management circuitry and is configured to provide power to the components of network node 2760 for performing the functions described herein. Power supply circuit 2787 may receive power from power source 2786. Power source 2786 and / or power supply circuit 2787 may be configured to provide power to various components of network node 2760 in a manner suitable for the respective components (e.g., at the voltage and current levels required by each respective component). Power source 2786 may be included in or external to power supply circuit 2787 and / or network node 2760. For example, network node 2760 may be connected to an external power source (e.g., a power outlet) via input circuitry or an interface such as a cable, thereby supplying power to power supply circuit 2787. As another example, power source 2786 may include a power source in the form of a battery or battery pack, which is connected to or integrated into power supply circuit 2787. The battery can provide backup power if the external power source fails. Other types of power sources, such as photovoltaic devices, may also be used.

[0524] Alternative embodiments of network node 2760 may include more than Figure 27 Additional components of the components shown may be responsible for providing certain aspects of the functionality of the network node (including any of the functionalities described herein and / or any functionality required to support the subject matter described herein). For example, network node 2760 may include a user interface device to allow information to be input into and output from network node 2760. This can allow users to perform diagnostic, maintenance, repair, and other management functions on network node 2760.

[0525] As used herein, a wireless device (WD) means a device capable of, configured, positioned, and / or operable for wireless communication with network nodes and / or other wireless devices. Unless otherwise stated, the term WD is used interchangeably with User Equipment (UE) herein. Wireless communication may include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for transmitting information through the air. In some embodiments, a WD may be configured to transmit and / or receive information without direct human interaction. For example, a WD may be designed to send information to a network in a predetermined schedule when triggered by an internal or external event or in response to a request from the network. Examples of WDs include, but are not limited to, smartphones, mobile phones, cellular phones, Voice over IP (VoIP) phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, game consoles or devices, music storage devices, playback devices, wearable terminal devices, wireless endpoints, mobile stations, tablet computers, laptop computers, laptop embedded devices (LEEs), laptop-mounted devices (LMEs), smart devices, wireless client devices (CPEs), in-vehicle wireless terminal devices, etc. A UE can, for example, support device-to-device (D2D) communication, vehicle-to-vehicle (V2V) communication, vehicle-to-infrastructure (V2I) communication, and vehicle-to-anything (V2X) communication by implementing 3GPP standards for sidelink communication, and in this case, it can be referred to as a D2D communication device. As yet another specific example, in the Internet of Things (IoT) scenario, a UE can represent a machine or other device that performs monitoring and / or measurement and sends the results of such monitoring and / or measurement to another UE and / or network node. In this case, the WD can be a machine-to-machine (M2M) device, which can be referred to as an MTC device in the 3GPP context. As a specific example, a WD can be a UE that implements the 3GPP Narrowband Internet of Things (NB-IoT) standard. Specific examples of such machines or devices are sensors, metering devices (e.g., power meters), industrial machines, or household or personal appliances (e.g., refrigerators, televisions, etc.), personal wearable devices (e.g., watches, fitness trackers, etc.). In other scenarios, a UE can represent a vehicle or other device capable of monitoring and / or reporting its operational status or other functions associated with its operation. As mentioned above, WD can represent a wireless connection endpoint, in which case the device can be referred to as a wireless terminal. Furthermore, as mentioned above, UE can be mobile, in which case it can also be referred to as a mobile device or mobile terminal.

[0526] As shown in the figure, the wireless device 2710 includes an antenna 2711, an interface 2714, processing circuitry 2720, a device-readable medium 2730, a user interface device 2732, auxiliary devices 2734, a power supply 2736, and a power supply circuit 2737. The WD 2710 may include one or more of the components shown for various wireless technologies supported by the WD 2710, such as GSM, WCDMA, LTE, NR, WiFi, WiMAX, NB-IoT, or Bluetooth wireless technologies, to name just a few. These wireless technologies may be integrated into chips or chipsets that are the same as or different from other components within the WD 2710.

[0527] Antenna 2711 may include one or more antennas or antenna arrays configured to transmit and / or receive wireless signals and connected to interface 2714. In some alternative embodiments, antenna 2711 may be separate from WD 2710 and may be connected to WD 2710 via an interface or port. Antenna 2711, interface 2714, and / or processing circuitry 2720 may be configured to perform any receive or transmit operations described herein as performed by a WD. Any information, data, and / or signals may be received from a network node and / or another WD. In some embodiments, radio front-end circuitry and / or antenna 2711 may be considered as an interface.

[0528] As shown in the figure, interface 2714 includes radio front-end circuitry 2712 and antenna 2711. Radio front-end circuitry 2712 includes one or more filters 2718 and amplifiers 2716. Radio front-end circuitry 2714 is connected to antenna 2711 and processing circuitry 2720 and is configured to modulate signals communicating between antenna 2711 and processing circuitry 2720. Radio front-end circuitry 2712 may be coupled to antenna 2711 or be a portion thereof. In some embodiments, WD 2710 may not include separate radio front-end circuitry 2712; instead, processing circuitry 2720 may include radio front-end circuitry and may be connected to antenna 2711. Similarly, in some embodiments, some or all of RF transceiver circuitry 2722 may be considered part of interface 2714. Radio front-end circuitry 2712 can receive digital data that will be transmitted wirelessly to other network nodes or WD. The radio front-end circuit 2712 can use a combination of filter 2718 and / or amplifier 2716 to convert digital data into radio signals with suitable channel and bandwidth parameters. The radio signals can then be transmitted via antenna 2711. Similarly, when receiving data, antenna 2711 can collect radio signals, which are then converted into digital data by the radio front-end circuit 2712. The digital data can be passed to processing circuitry 2720. In other embodiments, the interface may include different components and / or different combinations of components.

[0529] Processor circuitry 2720 may include a combination of one or more of the following: a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field-programmable gate array, or any other suitable computing device, resource, or combination of hardware, software, and / or coding logic, operable to provide WD 2710 functionality, either alone or together with other WD2710 components (e.g., device-readable medium 2730). Such functionality may include providing any of the various wireless features or benefits discussed herein. For example, processing circuitry 2720 may execute instructions stored in device-readable medium 2730 or in memory within processing circuitry 2720 to provide the functionality disclosed herein.

[0530] As shown in the figure, the processing circuit 2720 includes one or more of an RF transceiver circuit 2722, a baseband processing circuit 2724, and an application processing circuit 2726. In other embodiments, the processing circuit may include different components and / or different combinations of components. In some embodiments, the processing circuit 2720 of the WD 2710 may include a System-on-a-Chip (SOC). In some embodiments, the RF transceiver circuit 2722, the baseband processing circuit 2724, and the application processing circuit 2726 may be on a separate chip or chipset. In alternative embodiments, a portion or all of the baseband processing circuit 2724 and the application processing circuit 2726 may be combined into a single chip or chipset, and the RF transceiver circuit 2722 may be on a separate chip or chipset. In further alternative embodiments, a portion or all of the RF transceiver circuit 2722 and the baseband processing circuit 2724 may be on the same chip or chipset, and the application processing circuit 2726 may be on a separate chip or chipset. In other alternative embodiments, some or all of the RF transceiver circuitry 2722, baseband processing circuitry 2724, and application processing circuitry 2726 may be combined in the same chip or chipset. In some embodiments, the RF transceiver circuitry 2722 may be part of interface 2714. The RF transceiver circuitry 2722 may modulate the RF signal used for processing circuitry 2720.

[0531] In some embodiments, some or all of the functions described herein as being performed by WD may be provided by processing circuitry 2720 that executes instructions stored on device-readable medium 2730, which may be a computer-readable storage medium. In alternative embodiments, some or all of the functions may be provided by processing circuitry 2720, for example, in a hard-wired manner, without executing instructions stored on separate or discrete device-readable storage media. In any of those particular embodiments, processing circuitry 2720 may be configured to perform the described functions regardless of whether instructions stored on device-readable storage media are executed. The benefits provided by such functions are not limited to processing circuitry 2720 or other components of WD 2710, but are enjoyed as a whole by WD 2710 and / or generally by end users and wireless networks.

[0532] Processing circuitry 2720 can be configured to perform any determination, calculation, or similar operation (e.g., certain acquisition operations) described herein as being performed by WD. These operations performed by processing circuitry 2720 may include information acquired by processing circuitry 2720 through processes such as: converting the acquired information into other information, comparing the acquired or converted information with information stored by WD 2710, and / or performing one or more operations based on the acquired or converted information, and making a determination based on the result of said processing.

[0533] Device-readable medium 2730 operatively stores computer programs, software, applications including one or more of logic, rules, code, tables, etc., and / or other instructions executable by processing circuitry 2720. Device-readable medium 2730 may include computer memory (e.g., random access memory (RAM) or read-only memory (ROM)), mass storage media (e.g., hard disk), removable storage media (e.g., CD or DVD), and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory device that stores information, data, and / or instructions usable by processing circuitry 2720. In some embodiments, processing circuitry 2720 and device-readable medium 2730 may be considered integrated.

[0534] User interface device 2732 can provide components that allow a human user to interact with WD 2710. This interaction can take many forms, such as visual, auditory, tactile, etc. User interface device 2732 is operable to produce output to the user and allow the user to provide input to WD 2710. The type of interaction can vary depending on the type of user interface device 2732 installed in WD 2710. For example, if WD 2710 is a smartphone, interaction can be made via a touchscreen; if WD 2710 is a smart meter, interaction can be made via a screen providing a purpose (e.g., the number of gallons used) or a speaker providing an audible alarm (e.g., if smoke is detected). User interface device 2732 can include input interfaces, devices, and circuitry, as well as output interfaces, devices, and circuitry. User interface device 2732 is configured to allow information to be input into WD 2710 and is connected to processing circuitry 2720 to allow processing circuitry 2720 to process the input information. User interface device 2732 can include, for example, a microphone, proximity or other sensors, buttons / buttons, a touch display, one or more cameras, a USB port, or other input circuitry. User interface device 2732 is also configured to allow information output from WD 2710 and to allow processing circuitry 2720 to output information from WD 2710. User interface device 2732 may include, for example, a speaker, display, vibration circuitry, USB port, headphone jack, or other output circuitry. By using one or more input and output interfaces, devices, and circuitry of user interface device 2732, WD 2710 can communicate with end users and / or wireless networks, allowing them to benefit from the functionality described herein.

[0535] The auxiliary device 2734 is operable to provide more specific functions that may not typically be performed by the WD. This may include dedicated sensors for measuring for various purposes, and interfaces for additional types of communication such as wired communication. The contents and types of components of the auxiliary device 2734 may vary depending on the embodiment and / or scenario.

[0536] In some embodiments, power supply 2736 may be in the form of a battery or battery pack. Other types of power sources may also be used, such as an external power source (e.g., a power outlet), a photovoltaic device, or a battery cell. WD 2710 may also include power circuitry 2737 for supplying power from power supply 2736 to various parts of WD 2710 that require power from power supply 2736 to perform any functions described or indicated herein. In some embodiments, power circuitry 2737 may include power management circuitry. Power circuitry 2737 may additionally or alternatively be operable to receive power from an external power source; in this case, WD 2710 may be connected to an external power source (e.g., a power outlet) via input circuitry or an interface such as a power cable. In some embodiments, power circuitry 2737 may also be operable to supply power from an external power source to power supply 2736. This may be used, for example, for charging power supply 2736. Power circuitry 2737 may perform any formatting, conversion, or other modifications on the power from power supply 2736 to suit the power supply for the various components of WD 2710 that are powered thereto.

[0537] Figure 28 An embodiment of a UE according to the various aspects described herein is illustrated. As used herein, "User Equipment" or "UE" may not necessarily have the meaning of a "user" in the sense of a human user who owns and / or operates the associated equipment. Alternatively, a UE may refer to a device intended to be sold to or operated by a human user but may not or initially be associated with a particular human user (e.g., a smart sprinkler controller). Alternatively, a UE may refer to a device not intended to be sold to or operated by an end user but may be associated with or operated for the benefit of a user (e.g., a smart power meter). UE 2800 can be any UE identified by the 3rd Generation Partnership Project (3GPP), including NB-IoT UEs, Machine Type Communication (MTC) UEs, and / or Enhanced MTC (eMTC) UEs. Figure 28 As shown, UE 2800 is an example of a WD configured for communication according to one or more communication standards (such as 3GPP's GSM, UMTS, LTE, and / or 5G standards) published by the 3rd Generation Partnership Project (3GPP). As previously stated, the terms WD and UE are used interchangeably. Therefore, although... Figure 28 This is for UE, but the components discussed in this article also apply to WD, and vice versa.

[0538] exist Figure 28In this embodiment, UE 2800 includes processing circuitry 2801 operatively coupled to an input / output interface 2805, a radio frequency (RF) interface 2809, a network connectivity interface 2811, a memory 2815 including random access memory (RAM) 2817, read-only memory (ROM) 2819, and storage medium 2821, a communication subsystem 2831, a power supply 2833, and / or any other component, or any combination thereof. Storage medium 2821 includes an operating system 2823, application programs 2825, and data 2827. In other embodiments, storage medium 2821 may include other similar types of information. Some UEs may use... Figure 28 All components are shown, or only a subset of components are used. The level of integration between components can vary from one UE to another. Furthermore, some UEs may contain multiple instances of components, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0539] exist Figure 28 In this embodiment, processing circuitry 2801 can be configured to process computer instructions and data. Processor 2801 can be configured to execute any sequential state machine containing machine instructions stored in memory as a machine-readable computer program, such as one or more hardware-implemented state machines (e.g., in discrete logic, FPGA, ASIC, etc.); programmable logic and suitable firmware; one or more stored programs, a general-purpose processor (e.g., a microprocessor or digital signal processor (DSP)) and suitable software; or any combination thereof. For example, processing circuitry 2801 may include two central processing units (CPUs). Data may be information in a form suitable for use by a computer.

[0540] In the depicted embodiments, the input / output interface 2805 can be configured to provide a communication interface to an input device, an output device, or both input and output devices. The UE 2800 can be configured to use an output device via the input / output interface 2805. The output device can use an interface port of the same type as the input device. For example, a USB port can be used to provide input to and output from the UE 2800. The output device can be a speaker, sound card, video card, display, monitor, printer, actuator, transmitter, smart card, another output device, or any combination thereof. The UE 2800 can be configured to use an input device via the input / output interface 2805 to allow a user to capture information into the UE 2800. The input device can include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, digital camcorder, webcam, etc.), a microphone, a sensor, a mouse, a trackball, a directional keyboard, a touchpad, a scroll wheel, a smart card, etc. A presence-sensitive display can include a capacitive or resistive touch sensor to sense input from the user. Sensors can be, for example, accelerometers, gyroscopes, tilt sensors, force sensors, magnetometers, optical sensors, proximity sensors, another type of sensor, or any combination thereof. For example, input devices can be accelerometers, magnetometers, digital cameras, microphones, and optical sensors.

[0541] exist Figure 28 In this configuration, RF interface 2809 can be configured to provide a communication interface to RF components such as transmitters, receivers, and antennas. Network interface 2811 can be configured to provide a communication interface to network 2843a. Network 2843a may include wired and / or wireless networks, such as local area networks (LANs), wide area networks (WANs), computer networks, wireless networks, telecommunications networks, another similar network, or any combination thereof. For example, network 2843a may include a Wi-Fi network. Network interface 2811 can be configured to include receiver and transmitter interfaces for communicating with one or more other devices over the communication network according to one or more communication protocols (e.g., Ethernet, TCP / IP, SONET, ATM, etc.). Network interface 2811 can implement receiver and transmitter functions suitable for the communication network link (e.g., optical, electrical, etc.). The transmitter and receiver functions may share circuit components or software, or alternatively, may be implemented separately.

[0542] RAM 2817 can be configured to interface with processing circuitry 2801 via bus 2802 to provide storage or cache of data or computer instructions during the execution of software programs such as operating systems, applications, and device drivers. ROM 2819 can be configured to provide computer instructions or data to processing circuitry 2801. For example, ROM 2819 can be configured to store invariant low-level system code or data for basic system functions such as basic input and output (I / O), startup, or reception of keystrokes from a keyboard, stored in non-volatile memory. Storage medium 2821 can be configured to include memory such as RAM, ROM, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), disk, optical disk, floppy disk, hard disk, removable magnetic tape, or flash drive. In one example, storage medium 2821 can be configured to include operating system 2823, application 2825 such as a web browser application, widget or utility engine or another application, and data file 2827. Storage medium 2821 can store any one or a combination of various operating systems for use by UE 2800.

[0543] Storage medium 2821 can be configured to include multiple physical drive units, such as a redundant array of independent disks (RAID), a floppy disk drive, flash memory, a USB flash drive, an external hard disk drive, a thumb drive, a pen drive, a key drive, a high-density digital versatile optical disc (HD-DVD) drive, an internal hard disk drive, a Blu-ray disc drive, a holographic digital data storage (HDDS) disc drive, an external mini dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro DIMM SDRAM, smart card memory such as a user identification module or a removable user identity (SIM / RUIM) module, other memory, or any combination thereof. Storage medium 2821 can allow UE 2800 to access computer-executable instructions, applications, etc., stored on a transient or non-transient storage medium to unload or upload data. Articles such as those utilizing a communication system can be tangibly embodied in storage medium 2821, which may include a device-readable medium.

[0544] exist Figure 28In this configuration, processing circuitry 2801 can be configured to communicate with network 2843b using communication subsystem 2831. Networks 2843a and 2843b can be one or more of the same networks or one or more different networks. Communication subsystem 2831 can be configured to include one or more transceivers for communicating with network 2843b. For example, communication subsystem 2831 can be configured to include one or more remote transceivers for communicating with another device (e.g., another WD, UE) or a base station of a radio access network (RAN) capable of wireless communication according to one or more communication protocols (e.g., IEEE 802.28, CDMA, WCDMA, GSM, LTE, UTRAN, WiMax, etc.). Each transceiver can include transmitter 2833 and / or receiver 2835 to implement transmitter or receiver functions suitable for the RAN link (e.g., frequency allocation, etc.). Furthermore, transmitter 2833 and receiver 2835 of each transceiver can share circuit components, software, or firmware, or they can be implemented separately.

[0545] In the illustrated embodiment, the communication functions of the communication subsystem 2831 may include data communication, voice communication, multimedia communication, short-range communication such as Bluetooth, near-field communication, location-based communication (such as the use of a Global Positioning System (GPS) for determining location), another type of communication function, or any combination thereof. For example, the communication subsystem 2831 may include cellular communication, Wi-Fi communication, Bluetooth communication, and GPS communication. The network 2843b may include wired and / or wireless networks, such as a local area network (LAN), a wide area network (WAN), a computer network, a wireless network, a telecommunications network, another similar network, or any combination thereof. For example, the network 2843b may be a cellular network, a Wi-Fi network, and / or a near-field network. The power supply 2813 may be configured to provide alternating current (AC) or direct current (DC) power to the components of the UE 2800.

[0546] The features, benefits, and / or functions described herein may be implemented in one of the components of UE 2800 or partitioned among multiple components of UE 2800. Furthermore, the features, benefits, and / or functions described herein may be implemented in any combination of hardware, software, or firmware. In one example, the communication subsystem 2831 may be configured to include any of the components described herein. Additionally, the processing circuitry 2801 may be configured to communicate with any such component via bus 2802. In another example, any such component may be represented by program instructions stored in memory, which, when executed by the processing circuitry 2801, perform the corresponding functions described herein. In another example, the functionality of any such component may be partitioned between the processing circuitry 2801 and the communication subsystem 2831. In yet another example, the non-computationally intensive functions of any such component may be implemented in software or firmware, and the computationally intensive functions may be implemented in hardware.

[0547] Figure 29 This is a schematic block diagram illustrating a virtualization environment 2900, in which functionality implemented by some embodiments can be virtualized. In this context, virtualization means creating a virtual version of an apparatus or device that may include a virtualized hardware platform, storage devices, and network resources. As used herein, virtualization can be applied to nodes (e.g., virtualized base stations or virtualized radio access nodes) or devices (e.g., UEs, wireless devices, or any other type of communication device) or components thereof, and relates to an implementation in which at least a portion of functionality is implemented as one or more virtual components (e.g., through one or more applications, components, functions, virtual machines, or containers executing on one or more physical processing nodes in one or more networks).

[0548] In some embodiments, some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines implemented in one or more virtual environments 2900 hosted on one or more hardware nodes 2930. Furthermore, in embodiments where the virtual node is not a radio access node or does not require radio connectivity (e.g., a core network node), the network node may then be fully virtualized.

[0549] These functionalities can be implemented by one or more applications 2920 (which may alternatively be referred to as software instances, virtual devices, network functions, virtual nodes, virtual network functions, etc.), operable to implement some of the features, functions, and / or benefits of some embodiments disclosed herein. Application 2920 runs in a virtualization environment 2900, which provides hardware 2930 including processing circuitry 2960 and memory 2990. Memory 2990 contains instructions 2995 executable by processing circuitry 2960, thereby enabling application 2920 to operate to provide one or more of the features, benefits, and / or functions disclosed herein.

[0550] The virtualization environment 2900 includes general-purpose or special-purpose network hardware devices 2930, which include one or more processors or processing circuitry 2960, which may be commercial off-the-shelf (COTS) processors, application-specific integrated circuits (ASICs), or any other type of processing circuitry including digital or analog hardware components or special-purpose processors. Each hardware device may include memory 2990-1, which may be non-permanent memory for temporarily storing instructions 2995 or software executed by the processing circuitry 2960. Each hardware device may include one or more network interface controllers (NICs) 2970, also referred to as network interface cards, which include physical network interfaces 2980. Each hardware device may also include non-transitory, permanent machine-readable storage media 2990-2 in which the software 2995 and / or instructions executable by the processing circuitry 2960 are stored. The software 2995 may include any type of software, including software for instantiating one or more virtualization layers 2950 (also referred to as supervisors), software for executing virtual machines 2940, and software that allows them to perform the functions, features, and / or benefits described in relation to some embodiments described herein.

[0551] Virtual machine 2940 includes virtual processing, virtual memory, virtual networking or interface, and virtual storage, and can be run by a corresponding virtualization layer 2950 or supervisor. Different embodiments of instances of virtual device 2920 can be implemented on one or more of virtual machines 2940, and the implementation can be made in different ways.

[0552] During operation, the processing circuitry 2960 executes software 2995 to instantiate the hypervisor or virtualization layer 2950, ​​which may sometimes be referred to as a virtual machine monitor (VMM). The virtualization layer 2950 can present a virtual operating platform that appears as networked hardware of the virtual machine 2940.

[0553] like Figure 29 As shown, hardware 2930 can be a standalone network node with general or specific components. Hardware 2930 may include antenna 29225 and may implement some functions through virtualization. Alternatively, hardware 2930 may be part of a larger hardware cluster (e.g., in a data center or customer premises equipment (CPE)) where many hardware nodes work together and are managed by management and coordination (MANO) 29100, which in particular oversees the lifecycle management of application 2920.

[0554] In some contexts, hardware virtualization is referred to as Network Functions Virtualization (NFV). NFV can be used to unify numerous network device types onto industry-standard high-capacity server hardware, physical switches, and physical storage that can reside in data centers and customer premises equipment (CPE).

[0555] In the context of NFV, virtual machine 2940 can be a software implementation of a physical machine, and its running programs are executed as if they were on a physical, non-virtualized machine. Each virtual machine 2940, along with the portion of hardware 2930 that executes that virtual machine (whether it is hardware dedicated to that virtual machine and / or hardware shared by that virtual machine and other virtual machines in virtual machine 2940), forms a separate virtual network element (VNE).

[0556] Still within the context of NFV, Virtual Network Functions (VNFs) are responsible for handling one or more virtual machines 2940 running on top of the hardware network infrastructure 2930 and corresponding to Figure 29 The specific network functions of application 2920.

[0557] In some embodiments, each of the one or more radio units 29200, including one or more transmitters 29220 and one or more receivers 29210, may be coupled to one or more antennas 29225. The radio unit 29200 may communicate directly with the hardware node 2930 via one or more suitable network interfaces and may be used in conjunction with virtual components to provide radio capabilities to the virtual node, such as a radio access node or base station.

[0558] In some embodiments, the control system 29230 may be used to implement some signaling, and the control system 29230 may alternatively be used for communication between the hardware node 2930 and the radio unit 29200.

[0559] Figure 30 A telecommunications network connected to a host computer via an intermediate network, according to some embodiments, is illustrated. Specifically, refer to... Figure 30According to an embodiment, the communication system includes: a telecommunications network 3010, such as a 3GPP-type cellular network, which includes an access network 3011 (such as a radio access network) and a core network 3014. The access network 3011 includes multiple base stations 3012a, 3012b, and 3012c, such as NB, eNB, gNB, or other types of radio access points, each base station defining a corresponding coverage area 3013a, 3013b, or 3013c. Each base station 3012a, 3012b, or 3012c can be connected to the core network 3014 via a wired or wireless connection 3015. A first UE 3091 located in coverage area 3013c is configured to wirelessly connect to or be paged by the corresponding base station 3012c. A second UE 3092 located in coverage area 3013a can wirelessly connect to the corresponding base station 3012a. Although multiple UEs 3091 and 3092 are shown in this example, the disclosed embodiments are equally applicable to situations where a single UE is located in the coverage area or a single UE is connected to the corresponding base station 3012.

[0560] Telecommunications network 3010 is connected to host computer 3030, which may be embodied in the hardware and / or software of a standalone server, a cloud-implemented server, a distributed server, or as processing resources in a server cluster. Host computer 3030 may be owned by or under the control of a service provider, or may be operated by or on behalf of a service provider. Connections 3021 and 3022 between telecommunications network 3010 and host computer 3030 may extend directly from core network 3014 to host computer 3030, or may pass through optional intermediate network 3020. Intermediate network 3020 may be one or more of a public, private, or hosted network; intermediate network 3020 (if any) may be a backbone network or the Internet; specifically, intermediate network 3020 may include two or more subnetworks (not shown).

[0561] Figure 30The communication system as a whole enables connectivity between connected UEs 3091 and 3092 and host computer 3030. This connection can be described as an over-the-top (OTT) connection 3050. Host computer 3030 and connected UEs 3091 and 3092 are configured to transmit data and / or signaling via OTT connection 3050 using access network 3011, core network 3014, any intermediate network 3020, and possibly other intermediate infrastructure (not shown). The participating communication devices through which OTT connection 3050 passes are unaware of the routes of uplink and downlink communications; in this sense, OTT connection 3050 can be transparent. For example, base station 3012 may not be informed or need not be informed of the past routes of incoming downlink communications containing data originating from host computer 3030 and to be forwarded (e.g., handed over) to connected UE 3091. Similarly, base station 3012 does not need to know the future routes of uplink communications originating from UE 3091 and outputting toward host computer 3030.

[0562] Now refer to Figure 31 The example implementations of the UE, base station, and host computer according to the embodiments discussed in the preceding paragraphs are described. Figure 31 A host computer is illustrated that communicates with a user equipment via a base station through a partially wireless connection according to some embodiments. In the communication system 3100, the host computer 3110 includes hardware 3115, which includes a communication interface 3116 configured to establish and maintain wired or wireless connections with interfaces of different communication devices of the communication system 3100. The host computer 3110 also includes processing circuitry 3118, which may have storage and / or processing capabilities. In particular, the processing circuitry 3118 may include one or more programmable processors, application-specific integrated circuits, field-programmable gate arrays, or combinations of such devices (not shown) adapted to execute instructions. The host computer 3110 also includes software 3111, which is stored in or accessible by the host computer 3110 and can be executed by the processing circuitry 3118. The software 3111 includes a host application 3112. Host application 3112 can be operated to provide services to remote users, such as UE 3130 connected via OTT connection 3150, which terminates between UE 3130 and host computer 3110. When providing services to remote users, host application 3112 can provide user data sent using OTT connection 3150.

[0563] The communication system 3100 also includes a base station 3120 installed in the telecommunications system. The base station 3120 includes hardware 3125 enabling it to communicate with the host computer 3110 and the UE 3130. Hardware 3125 may include: a communication interface 3126 for establishing and maintaining wired or wireless connections with interfaces of different communication devices of the communication system 3100; and a radio interface 3127 for establishing and maintaining connections with the coverage area served by the base station 3120. Figure 31 At least one wireless connection 3170 of UE 3130 (not shown in the image). Communication interface 3126 can be configured to facilitate connection 3160 to host computer 3110. Connection 3160 can be a direct connection, or alternatively, the connection can be via the core network of a telecommunications network (…). Figure 31 (Not shown) and / or via one or more intermediate networks outside the telecommunications network. In the illustrated embodiment, the hardware 3125 of the base station 3120 also includes processing circuitry 3128, which may include one or more programmable processors, application-specific integrated circuits, field-programmable gate arrays, or combinations thereof (not shown) adapted to execute instructions. The base station 3120 also has software 3121 stored internally or accessible via an external connection.

[0564] The communication system 3100 also includes the previously mentioned UE 3130. The hardware 3135 of UE 3130 may include a radio interface 3137 configured to establish and maintain a wireless connection 3170 with a base station serving the coverage area currently occupied by UE 3130. The hardware 3135 of UE 3130 also includes processing circuitry 3138, which may include one or more programmable processors, application-specific integrated circuits, field-programmable gate arrays, or combinations of such devices (not shown) suitable for executing instructions. UE 3130 also includes software 3131, which is stored in or accessible by UE 3130 and can be executed by processing circuitry 3138. Software 3131 includes a client application 3132. Client application 3132 can be operated to provide services to human or non-human users via UE 3130, supported by host computer 3110. In host computer 3110, the executing host application 3112 can communicate with the executing client application 3132 via OTT connection 3150, which terminates between UE 3130 and host computer 3110. When providing services to a user, client application 3132 can receive request data from host application 3112 and provide user data in response to the request data. OTT connection 3150 can transmit both request data and user data. Client application 3132 can interact with the user to generate the user data it provides.

[0565] It should be noted that Figure 31The host computer 3110, base station 3120, and UE 3130 shown can be respectively connected to... Figure 30 The host computer 3030, one of the base stations 3012a, 3012b, and 3012c, and one of the UEs 3091 and 3092 are similar to or equivalent to each other. That is, the internal workings of these entities can be as follows: Figure 31 As shown, and independently, the surrounding network topology can be Figure 30 The network topology.

[0566] exist Figure 31 The OTT connection 3150 is abstractly depicted to illustrate communication between host computer 3110 and UE 3130 via base station 3120, but no intermediate devices or the exact routing messages via these devices are explicitly mentioned. The network infrastructure can determine the routing, which can be configured to be hidden from UE 3130 or the service provider operating host computer 3110, or both. When OTT connection 3150 is active, the network infrastructure can also make dynamic decisions to change the routing (e.g., based on load balancing considerations or network reconfiguration).

[0567] The wireless connection 3170 between UE 3130 and base station 3120 is consistent with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of the OTT services provided to UE 3130 using OTT connection 3150, in which wireless connection 3170 forms the final part.

[0568] Measurement procedures may be provided for monitoring data rates, latency, and other factors that are the subject of improvement in one or more embodiments. Optional network functionality may also be present for reconfiguring the OTT connection 3150 between the host computer 3110 and the UE 3130 in response to changes in measurement results. The measurement procedures and / or network functionality for reconfiguring the OTT connection 3150 may be implemented in the software 3111 and hardware 3115 of the host computer 3110, or in the software 3131 and hardware 3135 of the UE 3130, or both. In embodiments, sensors (not shown) may be deployed in or associated with communication devices through which the OTT connection 3150 traverses; the sensors may participate in the measurement process by providing values ​​of the monitored quantities illustrated above, or by providing values ​​of other physical quantities from which the software 3111, 3131 can calculate or estimate the monitored quantities. Reconfiguration of the OTT connection 3150 may include message formatting, retransmission settings, preferred routing, etc.; reconfiguration does not need to affect the base station 3120 and may be unknown or imperceptible to the base station 3120. Such processes and functions may be known and practiced in the art. In some embodiments, measurements may involve proprietary UE signaling, which facilitates the host computer 3110 in measuring throughput, propagation time, latency, etc. Measurements may be achieved by software 3111 and 3131 using the OTT connection 3150 to send messages (particularly empty messages or "virtual" messages) while simultaneously monitoring propagation time, errors, etc.

[0569] Figure 32 This is a flowchart illustrating a method implemented in a communication system according to one embodiment. The communication system includes: a host computer, a base station, and a UE, which may be referenced... Figure 30 and Figure 31 The host computers, base stations, and UEs described herein. For the sake of simplicity, this section will only include... Figure 32 Reference numerals are used in the accompanying drawings. In step 3210, the host computer provides user data. In sub-step 3211 of step 3210 (which may be optional), the host computer provides user data by executing a host application. In the second step 3220, the host computer initiates a transmission to the UE carrying user data. In the third step 3230 (which may be optional), in accordance with the teachings of the embodiments described throughout this disclosure, the base station sends the user data carried in the host computer-initiated transmission to the UE. In step 3240 (which may also be optional), the UE executes a client application associated with the host application executed by the host computer.

[0570] Figure 33This is a flowchart illustrating a method implemented in a communication system according to one embodiment. The communication system includes: a host computer, a base station, and a UE, which may be referenced... Figure 30 and Figure 31 The host computers, base stations, and UEs described herein. For the sake of simplicity, this section will only include... Figure 33 Reference numerals are used in the accompanying drawings. In step 3310 of the method, the host computer provides user data. In an optional sub-step (not shown), the host computer provides user data by executing a host application. In a second step 3320, the host computer initiates a transmission to the UE, which carries user data. According to the teachings of the embodiments described throughout this disclosure, the transmission can be carried out via a base station. In step 3330 (which may be optional), the UE receives the user data carried in the transmission.

[0571] Figure 34 This is a flowchart illustrating a method implemented in a communication system according to one embodiment. The communication system includes: a host computer, a base station, and a UE, which may be referenced... Figure 30 and Figure 31 The host computers, base stations, and UEs described herein. For the sake of simplicity, this section includes only descriptions of... Figure 34 References. In step 3410 (which may be optional), the UE receives input data provided by the host computer. Additionally or alternatively, in a second step 3420, the UE provides user data. In a sub-step 3421 of step 3420 (which may be optional), the UE provides user data by executing a client application. In a sub-step 3411 of step 3410 (which may be optional), the UE executes a client application that provides user data in response to the received input data provided by the host computer. When providing user data, the executed client application may also consider user input received from the user. Regardless of the specific manner in which user data is provided, the UE initiates the transmission of user data to the host computer in a third sub-step 3430 (which may be optional). In step 3440 of the method, the host computer receives user data sent from the UE, in accordance with the teachings of the embodiments described throughout this disclosure.

[0572] Figure 35 This is a flowchart illustrating a method implemented in a communication system according to one embodiment. The communication system includes: a host computer, a base station, and a UE, which may be referenced... Figure 30 and Figure 31 The host computers, base stations, and UEs described herein. For the sake of simplicity, this section will only include... Figure 35Reference numerals are used in the accompanying drawings. In step 3510 (which may be optional), the base station receives user data from the UE according to the teachings of the embodiments described throughout this disclosure. In step 3520 (which may be optional), the base station initiates a transmission of the received user data to the host computer. In a third step 3530 (which may be optional), the host computer receives the user data carried in the transmission initiated by the base station.

[0573] Any suitable steps, methods, features, functions, or benefits disclosed herein can be performed by one or more functional units or modules of one or more virtual devices. Each virtual device may include multiple such functional units. These functional units may be implemented by processing circuitry, which may include one or more microprocessors or microcontrollers and other digital hardware (including digital signal processors (DSPs), application-specific digital logic, etc.). The processing circuitry may be configured to execute program code stored in memory, which may include one or more types of memory, such as read-only memory (ROM), random access memory (RAM), cache memory, flash memory devices, optical storage devices, etc. The program code stored in the memory includes program instructions for executing one or more telecommunications and / or data communication protocols and instructions for executing one or more techniques described herein. In some implementations, the processing circuitry may be used to cause corresponding functional units to perform corresponding functions according to one or an embodiment of this disclosure.

[0574] Therefore, in light of the foregoing, embodiments described herein typically include a communication system comprising a host computer. The host computer may include processing circuitry configured to provide user data. The host computer may also include a communication interface configured to forward user data to a cellular network for transmission to a user equipment (UE). The cellular network may include a base station having a radio interface and processing circuitry configured to perform any of the steps described above for any embodiment of the base station.

[0575] In some embodiments, the communication system further includes a base station.

[0576] In some embodiments, the communication system further includes a UE, wherein the UE is configured to communicate with a base station.

[0577] In some embodiments, the host computer's processing circuitry is configured to execute a host application to provide user data. In this case, the UE includes processing circuitry configured to execute a client application associated with the host application.

[0578] Embodiments herein also include methods implemented in a communication system comprising a host computer, a base station, and a user equipment (UE). The method includes providing user data at the host computer. The method may also include initiating a transmission carrying user data from the host computer to the UE via a cellular network including the base station. The base station performs any steps of any of the embodiments described above with respect to the base station.

[0579] In some embodiments, the method further includes transmitting user data at the base station.

[0580] In some embodiments, user data is provided at a host computer by executing a host application. In this case, the method also includes executing a client application associated with the host application at the UE.

[0581] The embodiments described herein also include user equipment (UE) configured to communicate with a base station. The UE includes a radio interface and processing circuitry configured to perform any of the embodiments described above for the UE.

[0582] The embodiments described herein also include a communication system comprising a host computer. The host computer includes processing circuitry configured to provide user data and a communication interface configured to forward the user data to a cellular network for transmission to a user equipment (UE). The UE includes a radio interface and processing circuitry. Components of the UE are configured to perform any of the steps described above for any embodiment of the UE.

[0583] In some embodiments, the cellular network further includes a base station configured to communicate with the UE.

[0584] In some embodiments, the processing circuitry of the host computer is configured to execute a host application to provide user data. The processing circuitry of the UE is configured to execute a client application associated with the host application.

[0585] The embodiments also include a method implemented in a communication system including a host computer, a base station, and a user equipment (UE). The method includes: providing user data at the host computer and initiating a transmission carrying the user data to the UE via a cellular network including the base station. The UE performs any of the steps of any of the embodiments described above for the UE.

[0586] In some embodiments, the method further includes receiving user data from a base station at the UE.

[0587] The embodiments described herein also include a communication system comprising a host computer. The host computer includes a communication interface configured to receive user data originating from transmissions from a user equipment (UE) to a base station. The UE includes a radio interface and processing circuitry. The processing circuitry of the UE is configured to perform any steps of any of the embodiments described above for the UE.

[0588] In some embodiments, the communication system further includes a UE.

[0589] In some embodiments, the communication system further includes a base station. In this case, the base station includes a radio interface configured to communicate with the UE, and a communication interface configured to forward user data carried by transmissions from the UE to the base station to a host computer.

[0590] In some embodiments, the processing circuitry of the host computer is configured to execute a host application. The processing circuitry of the UE is configured to execute a client application associated with the host application, thereby providing user data.

[0591] In some embodiments, the host computer's processing circuitry is configured to execute a host application to provide requested data. The UE's processing circuitry is also configured to execute a client application associated with the host application to provide user data in response to the requested data.

[0592] The embodiments described herein also include methods implemented in a communication system comprising a host computer, a base station, and a user equipment (UE). The method includes receiving user data transmitted from the UE to the base station at the host computer. The UE performs any of the steps described above for any of the embodiments for the UE.

[0593] In some embodiments, the method further includes providing user data at the UE to the base station.

[0594] In some embodiments, the method further includes executing a client application at the UE to provide user data to be sent. The method may also include executing a host application associated with the client application at a host computer.

[0595] In some embodiments, the method further includes: executing a client application at the UE, and receiving input data at the client application at the UE. The input data is provided at a host computer by executing a host application associated with the client application. The user data to be sent is provided by the client application in response to the input data.

[0596] The embodiments also include a communication system comprising a host computer. The host computer includes a communication interface configured to receive user data originating from transmissions from a user equipment (UE) to a base station. The base station includes a radio interface and processing circuitry. The processing circuitry of the base station is configured to perform any steps of any of the embodiments described above with respect to the base station.

[0597] In some embodiments, the communication system further includes a base station.

[0598] In some embodiments, the communication system further includes a UE. The UE is configured to communicate with a base station.

[0599] In some embodiments, the host computer's processing circuitry is configured to execute a host application. The UE is also configured to execute a client application associated with the host application, thereby providing user data to be received by the host computer.

[0600] The embodiments also include a method implemented in a communication system comprising a host computer, a base station, and a user equipment (UE). The method includes: receiving, at the host computer, user data from a base station originating from transmissions already received by the base station from the UE. The UE performs any of the steps of any of the embodiments described above for the UE.

[0601] In some embodiments, the method further includes receiving user data from the UE at the base station.

[0602] In some embodiments, the method further includes: at the base station, initiating the transmission of the received user data to the host computer.

[0603] Example Implementation

[0604] Embodiments of the technologies, apparatuses, and systems described herein include, but are not limited to, the examples listed below.

[0605] Group B Implementation Examples

[0606] B1. A method performed by a first network node, the network node being configured to act as a master network node for multi-connection operations of a wireless device, the method comprising:

[0607] Determine whether to reconfigure the wireless device using conditional reconfiguration;

[0608] A handover request message is sent to a third network node. The handover request message includes the following indication: This procedure is used for conditional handover.

[0609] Receive confirmation of the handover request message;

[0610] Delaying the sending of a release message to the second network node, which is used as a secondary network node for the wireless device; and

[0611] Configure the wireless device using conditional switching information, which includes configuration information provided from a third network node.

[0612] B2. The method according to example embodiment B1, wherein the confirmation indication will maintain the auxiliary node during the execution condition switch.

[0613] B3. The method according to example embodiment B1 or B2, wherein the condition switching information includes information from a fourth network node, which acts as a target auxiliary node candidate for condition switching.

[0614] B4. A method performed by a third network node configured as a target master node candidate for multi-connection operations of a wireless device, the method comprising:

[0615] Receive a handover request message from the first network node. The handover request message includes the following indication: This procedure is for conditional handover.

[0616] Send a secondary node addition request to the fourth network node. The secondary node addition request includes the following indication: the request is for condition switching.

[0617] Receive confirmation of the request to add a secondary node; and

[0618] Send an acknowledgment of the handover request to the first network node.

[0619] B5. The method according to Example Implementation B4, wherein the confirmation of the switching request includes the following indication: the secondary node will be maintained when performing conditional switching.

[0620] B6. A method performed by a fourth network node, the fourth network node being configured to act as a target candidate secondary node for a wireless device, the method comprising:

[0621] Receive a secondary node addition request from a third network node. The secondary node addition request includes the following indication: the request is for condition switching.

[0622] Based on the fact that the request is an indication for condition switching, set the monitoring timer to a certain value;

[0623] Send an acknowledgment to the third network node regarding the request to add the secondary node; and

[0624] Start the monitoring timer.

[0625] B7. The method according to Example Implementation B6, wherein setting the supervisory timer includes: setting the supervisory timer to a value longer than the value at which the fourth network node will set the supervisory timer for unconditional handover and / or addition of a traditional secondary node.

[0626] B8. The method according to example embodiment B6 or B7, wherein the method includes: starting a monitoring timer when sending an acknowledgment to a third network node for a request to add a secondary node.

[0627] B9. The method according to any one of the example embodiments B6 to B8 further includes: reserving resources for the wireless device, taking into account that the request is for condition switching.

[0628] B10. A method performed by a first network node, the first network node being configured to act as a master network node for multi-connection operations of a wireless device, the method comprising:

[0629] Messages are received from a third network node, which serves as a target candidate master node for conditional switching configured for the wireless device;

[0630] Send a secondary node release request to the second network node that is used as the source secondary node for the wireless device;

[0631] Receive confirmation from the second network node of the request to release the secondary node.

[0632] B11. The method according to example embodiment B10, wherein the secondary node release request indicates that the wireless device retains the secondary node.

[0633] B12. The method according to example embodiment B10 or B11, wherein the message is a switch success message.

[0634] B13. A method performed by a second network node, the second network node acting as a source-secondary node for a wireless device operating in a multi-connectivity manner, the method comprising:

[0635] Receives a secondary node release request message from the first network node, which is used as the source master node for wireless devices;

[0636] Send an acknowledgment to the first network node regarding the release request for the secondary node.

[0637] B14. The method according to Example Implementation B13, wherein the secondary node release request indicates that the wireless device retains the secondary node.

[0638] B15. A method performed by a third network node, the third network node being configured as a target master node candidate for multi-connection operations of a wireless device, the method comprising:

[0639] Receive the RRC reconfiguration complete message from the wireless device;

[0640] It is determined that the wireless device has been configured for conditional handover and has associated multi-connection related configurations for a fourth network node to be used as a candidate for a secondary node target;

[0641] Send a message to the fourth network node indicating that the secondary node reconfiguration is complete;

[0642] Send a message to the first network node that serves as the source master node for the wireless device.

[0643] B16. The method according to Example Embodiment B15 further includes:

[0644] Receive forwarded data from the first node; and

[0645] Transmit the data carried by the auxiliary node for the wireless device to the fourth node.

[0646] B17. The method according to example embodiment B15 or B16, wherein the secondary node reconfiguration completion message includes an RRC reconfiguration completion message received from the wireless device.

[0647] B18. A method performed by a fourth network node, the fourth network node being configured to act as a target candidate secondary node for a wireless device, the method comprising:

[0648] Receives a secondary node reconfiguration completion message from a third network node used as a primary node target candidate for conditional switching of wireless devices; and

[0649] Stop the monitoring timer associated with conditional switching of the wireless device; and

[0650] The context associated with the wireless device is considered active.

[0651] B19. The method according to Example Embodiment B18 further includes:

[0652] Receive forwarded data from the third network node for the bearer to be terminated by the secondary node of the wireless device.

[0653] B20. A method performed by a first network node, the first network node being configured to act as a master network node for multi-connection operations of a wireless device, the method comprising:

[0654] The wireless device has received a message from the target candidate master node to which it is performing a conditional switch.

[0655] Send a message to the target candidate master node for which conditional handover of the wireless device has been configured but has not yet been executed, indicating that the conditional handover configuration for the wireless device will be released.

[0656] B21. The method according to example embodiment B21, wherein the received message is a handover success message.

[0657] B22. A method performed by a network node configured as a target candidate master node for multi-connectivity conditional handover of a wireless device, the method comprising:

[0658] Receive a message from the source master node for the wireless device indicating that the conditional switching configuration for the wireless device will be released.

[0659] The conditional handover configuration for the wireless device is determined to have associated target secondary node candidates for conditional handover; and

[0660] Send a secondary node release request message to the target secondary node candidate.

[0661] B23. The method according to Example Implementation B22 further includes: receiving confirmation of the release request message for the secondary node from the target secondary node candidate.

[0662] B24. The method according to any of the foregoing embodiments further includes:

[0663] Obtaining user data; and

[0664] Forward user data to the host computer or wireless device.

[0665] Group C Implementation Examples

[0666] C1. A network node configured to perform any step of any of the Group B embodiments.

[0667] C2. A network node including processing circuitry configured to perform any step of any of the Group B embodiments.

[0668] C3. A network node, comprising:

[0669] Communication circuits; and

[0670] The processing circuitry is configured to perform any step of any embodiment in the Group B embodiments;

[0671] C4. A network node, comprising:

[0672] The processing circuitry is configured to perform any step of any embodiment in the Group B embodiments;

[0673] The power supply circuit is configured to supply power to the network nodes.

[0674] C5. A network node, comprising:

[0675] The processing circuitry and memory contain instructions executable by the processing circuitry, thereby configuring the network node to perform any step of any Group B embodiment.

[0676] C6. The network node according to any one of embodiments C1 to C5, wherein the network node is a base station.

[0677] C7. A computer program including instructions that, when executed by at least one processor of a radio network node, cause the radio network node to perform the steps of any of the Group B embodiments.

[0678] C8. The computer program according to embodiment C7, wherein the network node is a base station.

[0679] C9. A carrier comprising a computer program according to any one of embodiments C7 or C8, wherein the carrier is one of an electrical signal, an optical signal, a radio signal, or a computer-readable storage medium.

[0680] Group D Implementation Examples

[0681] D1. A communication system including a host computer, the host computer comprising:

[0682] Processing circuitry is configured to provide user data; and

[0683] The communication interface is configured to forward user data to the cellular network for transmission to the user equipment (UE).

[0684] The cellular network includes a base station with a radio interface and processing circuitry, the processing circuitry of which is configured to perform any step of any embodiment in the Group B embodiments.

[0685] D2. The communication system according to the foregoing embodiments further includes a base station.

[0686] D3. The communication system according to the two embodiments described above also includes a UE, wherein the UE is configured to communicate with a base station.

[0687] D4. The communication system according to the foregoing three embodiments, wherein:

[0688] The host computer's processing circuitry is configured to execute host applications, thereby providing user data; and

[0689] The UE includes processing circuitry configured to execute client applications associated with the host application.

[0690] D5. A method implemented in a communication system including a host computer, a base station, and a user equipment (UE), the method comprising:

[0691] At the host computer, user data is provided; and

[0692] At the host computer, a transmission carrying user data is initiated to the UE via a cellular network including a base station, wherein the base station performs any step of any embodiment in the Group B embodiments.

[0693] D6. The method according to the foregoing embodiments further includes: transmitting user data at the base station.

[0694] D7. The method according to the two embodiments above, wherein user data is provided at the host computer by executing a host application, the method further includes executing a client application associated with the host application at the UE.

[0695] D8. A user equipment (UE) configured to communicate with a base station, the UE including a radio interface and processing circuitry, configured to perform any of the steps described in any of the preceding three embodiments.

[0696] D9. A communication system comprising a host computer including a communication interface configured to receive user data originating from a user equipment (UE) transmitted to a base station, wherein the base station includes a radio interface and processing circuitry configured to perform any step of any embodiment in the Group B embodiments.

[0697] D10. The communication system according to the foregoing embodiments further includes a base station.

[0698] D11. The communication system according to the two embodiments described above further includes a UE, wherein the UE is configured to communicate with a base station.

[0699] D12. The communication system according to the foregoing three embodiments, wherein:

[0700] The host computer's processing circuitry is configured to execute host applications;

[0701] The UE is configured to execute a client application associated with a host application, thereby providing user data to be received by the host computer.

[0702] Generally, unless explicitly stated and / or implied from the context, all terms used herein shall be interpreted according to their common meaning in the relevant art. Unless otherwise expressly stated, all references to “an element, device, component, apparatus, step, etc.” shall be openly interpreted as referring to at least one instance of an element, device, component, apparatus, step, etc. Unless it must be explicitly described that a step is after or before another step and / or implicitly implied that a step must be after or before another step, the steps of any method disclosed herein need not be performed in the exact order disclosed. Where appropriate, any feature of any embodiment disclosed herein may be applied to any other embodiment. Similarly, any advantage of any embodiment may be applied to any other embodiment, and vice versa. Further objects, features, and advantages of the appended embodiments will become apparent from the description.

[0703] The term "unit" may have a conventional meaning in the field of electronic, electrical and / or electronic equipment, and may include, for example, electrical and / or electronic circuits, devices, modules, processors, memories, logic solid-state and / or discrete devices, computer programs or instructions for performing various tasks, processes, calculations, outputs and / or display functions, such as those described herein.

[0704] The accompanying drawings illustrate some embodiments contemplated herein more fully. However, other embodiments are included within the scope of the subject matter disclosed herein. The disclosed subject matter should not be construed as being limited to the embodiments set forth herein; rather, these embodiments are provided by way of example only to convey the scope of the subject matter to those skilled in the art.

Claims

1. A method executed by a first network node, wherein, The first network node is configured to act as a master node MN, and the master node MN, together with a second network node acting as a secondary node SN for the wireless device, is used for the multi-connection operation of the wireless device. The method includes: Determine (810) to configure the wireless device using conditional reconfiguration; Send a (820) handover request message to a third network node, the handover request message including an indication that the handover request message is for conditional handover; Receive (830) an acknowledgment of the handover request message, the acknowledgment indicating that the secondary node will be maintained during the conditional handover; and In response to the confirmation of the handover request message, a release message is delayed (840) and sent to the second network node until the first network node receives an indication that the conditional handover has been performed.

2. The method according to claim 1, wherein, The third network node is a candidate target network node for the conditional handover, and the indication for the conditional handover to be performed is a handover success message received from the third network node.

3. The method according to any one of claims 1 to 2, wherein, The method includes: configuring (850) the wireless device with conditional switching information, the conditional switching information including information from a third network node used for the conditional switching.

4. The method according to any one of claims 1 to 2, wherein, The method further includes: Receive message (1610) from the third network node to which the wireless device has performed a condition switch; Send a (1620) message to a third network node that has configured conditional switching for the wireless device but has not yet executed it, the message indicating that the conditional switching configuration for the wireless device will be released.

5. The method according to claim 4, wherein, The received message is a handover success message.

6. A method performed by a network node, the network node being configured to serve as a candidate target network node for multi-connection operations of a wireless device, the method comprising: Receive (910) a handover request message for the wireless device from the source network node, the handover request message including an indication that the handover request message is for conditional handover; In response to receiving the switching request message, a (920) secondary node add request is sent to the candidate target secondary node, wherein the secondary node add request includes an indication that the secondary node add request is for condition reconfiguration; Receive (930) confirmation of the request to add the secondary node; and Send (940) confirmation of the handover request to the source network node.

7. The method according to claim 6, wherein, The candidate target secondary node is the source secondary node for the wireless device, and the confirmation of the handover request includes an instruction to retain the source secondary node during the execution of the conditional process.

8. The method according to any one of claims 6 to 7, wherein, The method further includes: Receive a message from the wireless device indicating that the reconfiguration of the candidate target auxiliary node has been completed; and Send a secondary node reconfiguration complete message to the candidate target secondary node.

9. The method according to claim 8, wherein, The secondary node reconfiguration completion message includes a received message indicating that the reconfiguration of the candidate target secondary node has been completed.

10. The method of claim 8, further comprising: Send a message indicating a successful handover to the source network node.

11. The method according to any one of claims 6 to 7, wherein, The method further includes: Receive (1310) Radio Resource Control (RRC) reconfiguration complete message from the second wireless device; It is determined (1320) that the second wireless device has been configured for conditional reconfiguration and that the second wireless device has associated multi-connection related configuration for candidate target auxiliary nodes; Send a (1330) secondary node reconfiguration complete message to the candidate target secondary node; Send a message (1340) to the source master node for the second wireless device indicating that the condition reconfiguration has been completed.

12. The method according to claim 11, wherein, The condition reconfiguration is a condition switch.

13. The method according to any one of claims 6 to 7, wherein, The method further includes: Receive message (1510) from the source master node for the wireless device, the message indicating that the conditional switching configuration for the wireless device will be released; Determine (1520) that the conditional switching configuration for the wireless device has associated target secondary node candidates for the conditional switching; and Send a (1530) auxiliary node release request message to the target auxiliary node candidate.

14. The method of claim 13, further comprising: Receive confirmation of the release request message for the secondary node from the target secondary node candidate.

15. A method performed by a network node, the network node being configured to act as a candidate target auxiliary node for multi-connection operations of a wireless device, the method comprising: Receive a secondary node add request (1010) from a candidate target network node, the secondary node add request including an indication that the secondary node add request is for condition reconfiguration; In response to the secondary node addition request, send (1030) an acknowledgment of the secondary node addition request.

16. The method of claim 15, further comprising: In response to receiving the secondary node addition request, start (1040) a monitoring timer for adding the secondary node.

17. The method according to claim 16, wherein, The method includes setting the supervisory timer (1020) to a value based on the indication that the request is for condition reconfiguration.

18. The method according to claim 17, wherein, Setting (1020) the supervisory timer includes setting the supervisory timer to a value longer than the value that the network node would set for adding an unconditional secondary node.

19. The method according to any one of claims 15 to 18, wherein, The method includes: starting a (1040) monitoring timer when sending an acknowledgment of the request to add the auxiliary node.

20. The method according to any one of claims 15 to 18, further comprising: Then receive the message that the secondary node has completed reconfiguration; as well as In response to receiving the message that the secondary node has been reconfigured, the monitoring timer is stopped.

21. The method according to any one of claims 15 to 18, further comprising: Considering that the secondary node addition request is for conditional reconfiguration, resources are reserved for the wireless device.

22. A network node (1700) adapted to perform the method according to any one of claims 1 to 21.

23. A network node (1700), comprising: The communication circuit (1720) is configured to communicate with one or more wireless devices and one or more other network nodes; as well as The processing circuit (1710) is operatively coupled to the communication circuit and configured to perform the method according to any one of claims 1 to 21.

24. A computer program product comprising computer program instructions configured to be executed by processing circuitry in a network node and configured to cause the network node to perform the method according to any one of claims 1 to 21.

25. A computer-readable medium having stored thereon a computer program product according to claim 24.

Images