Handling measurement settings when performing conditional mobility

Abstract

To provide devices, methods, and computer-readable media that improve mobility operations of wireless devices or user equipment (UEs) in a wireless network.SOLUTION: Provided are methods for conditional mobility in a radio access network (RAN), performed by a user equipment. Such methods include: receiving, from one or more RAN nodes, one or more mobility-related messages that include a) a first indication of a mobility operation, b) a second indication of a triggering condition for the mobility operation, c) a second measurement configuration related to the triggering condition, and d) a third measurement configuration related to one or more target cells; based on the second measurement configuration, detecting fulfillment of the triggering condition with respect to a particular one of the target cells; executing the mobility operation towards the particular target cell; and subsequently performing and reporting third measurements in the particular target cell based on the third measurement configuration.SELECTED DRAWING: Figure 13

Description

[Technical field]

[0001] The present application relates generally to the field of wireless communications, and more particularly, to devices, methods, and computer-readable media that improve mobility operations of wireless devices or user equipment (UE) in wireless networks. [Background technology]

[0002] Generally, all terms used herein should be interpreted according to the ordinary meaning of those terms in the relevant technical field, unless a different meaning is clearly given and / or implied from the context in which the term is used. All references to a / an / the element, apparatus, component, means, step, etc. should be openly interpreted as referring to at least one instance of that element, apparatus, component, means, step, etc., unless expressly stated otherwise. The steps of any method and / or procedure disclosed herein need not be performed in the exact order disclosed, unless a step is expressly described as following or preceding another step, and / or if it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may be applied to any other embodiment, and vice versa. Other objects, features and advantages of the enclosed embodiments will become apparent from the following description.

[0003] Long-Term Evolution (LTE), also known as Evolved UTRAN (E-UTRAN), is an umbrella term for the so-called fourth-generation (4G) radio access technologies developed within the 3rd Generation Partnership Project (3GPP) and initially standardized in Releases 8 and 9. LTE targets various licensed frequency bands and is accompanied by improvements to non-radio aspects, commonly referred to as System Architecture Evolution (SAE), including the Evolved Packet Core (EPC) network. LTE continues to evolve through subsequent releases developed according to a standards-setting process by 3GPP and its Working Groups (WGs), including the Radio Access Network (RAN) WG and its sub-working groups (e.g., RAN1, RAN2, etc.).

[0004] LTE Release 10 (Rel-10) supports bandwidths larger than 20 MHz. One important requirement for Rel-10 is to ensure backward compatibility with LTE Release 8. This should also include spectrum compatibility. So, a wideband LTE Rel-10 carrier (e.g., wider than 20 MHz) should appear as several carriers to LTE Rel-8 ("legacy") terminals. Each such carrier can be called a component carrier (CC). And for efficient use of wide carriers for legacy terminals, the legacy terminals can be scheduled within all parts of the wideband LTE Rel-10 carrier. One exemplary way to achieve this is by carrier aggregation (CA), whereby a Rel-10 terminal can receive multiple CCs, preferably with each CC having the same structure as a Rel-8 carrier. One of the enhancements in LTE Rel-11 is the enhanced physical downlink control channel (ePDCCH), which has the goals of increasing the capacity of control channel resources, improving spatial reuse, improving inter-cell interference coordination (ICIC), and supporting antenna beamforming and / or transmit diversity for the control channel. Additionally, LTE Rel-12 introduced dual connectivity (DC), which allows a UE to connect to two network nodes simultaneously, thereby improving connection robustness and / or capacity.

[0005] An example overall architecture of a network comprising LTE and SAE is shown in Figure 1. E-UTRAN 100 comprises one or more evolved node Bs (eNBs), such as eNBs 105, 110, and 115, and one or more user equipments (UEs), such as UE 120. As used within 3GPP standards, as third generation ("3G") and second generation ("2G") 3GPP radio access networks are commonly known, "user equipment" or "UE" refers to any wireless communication device (e.g., a smartphone or computing device) capable of communicating with 3GPP standards-compliant network equipment, including E-UTRAN as well as UTRAN and / or GERAN.

[0006] As specified by 3GPP, the E-UTRAN 100 is responsible for all radio-related functions in the network, including radio bearer control, radio admission control, radio mobility control, scheduling, and dynamic allocation of resources to UEs in the uplink and downlink, as well as security of communications with the UEs. These functions reside in eNBs, such as eNBs 105, 110, and 115. The eNBs in the E-UTRAN communicate with each other via an X2 interface, as shown in FIG. 1. The eNBs are also responsible for the E-UTRAN interface to the EPC 130, and in particular the S1 interface to the Mobility Management Entity (MME) and Serving Gateway (SGW), shown collectively in FIG. 1 as MME / S-GW 134 and 138. Generally speaking, the MME / S-GW handles both the overall control of the UE and the data flow between the UE and the rest of the EPC. More specifically, the MME handles the signaling (e.g., control plane) protocols between the UE and the EPC, known as the Non-Access Stratum (NAS) protocols. The S-GW handles all Internet Protocol (IP) data packets (e.g., data or user plane) between the UE and the EPC and acts as a local mobility anchor for data bearers when the UE moves between eNBs, such as eNBs 105, 110, and 115.

[0007] The EPC 130 may also include a Home Subscriber Server (HSS) 131 that manages user-related and subscriber-related information. The HSS 131 may also provide support functions in mobility management, call and session setup, user authentication and access authorization. The functions of the HSS 131 may be related to the functions of a traditional Home Location Register (HLR) as well as the functions or operations of an Authentication Center (AuC).

[0008] In some embodiments, the HSS 131 can communicate with a User Data Repository (UDR), labeled EPC-UDR 135 in FIG. 1, via a Ud interface. The EPC-UDR 135 can store user credentials after they are encrypted by AuC algorithms. Because these algorithms are not standardized (i.e., vendor-specific), the encrypted credentials stored in the EPC-UDR 135 often cannot be accessed by any other vendor than the vendor of the HSS 131.

[0009] FIG. 2A illustrates a high-level block diagram of an exemplary LTE architecture for the entities that make up the LTE architecture, namely, UE, E-UTRAN, and EPC, and the high-level functional division into Access Stratum (AS) and Non-Access Stratum (NAS). FIG. 2A also illustrates two specific interface points, namely, Uu (UE / E-UTRAN radio interface) and S1 (E-UTRAN / EPC interface), each of which uses a unique set of protocols, namely, radio protocols and S1 protocols. Although not illustrated in FIG. 2A, each set of protocols can be further segmented into user plane and control plane protocol functions. The user and control planes are also referred to as U-plane and C-plane, respectively. At the Uu interface, the U-plane carries user information (e.g., data packets) and the C-plane carries control information between the UE and the E-UTRAN.

[0010] FIG. 2B shows a block diagram of an exemplary C-plane protocol stack between a UE, an eNB, and an MME. The exemplary protocol stack includes physical (PHY), medium access control (MAC), radio link control (RLC), packet data convergence protocol (PDCP), and radio resource control (RRC) layers between the UE and the eNB. The PHY layer is concerned with how and which characteristics are used to transfer data on transport channels on the LTE air interface. The MAC layer provides data transfer services on logical channels, maps logical channels to PHY transport channels, and reallocates PHY resources to support these services. The RLC layer provides error detection and / or error correction, concatenation, segmentation, reassembly, and reordering of data transferred to and from higher layers. The PHY, MAC, and RLC layers perform identical functions for both the U-plane and the C-plane. The PDCP layer provides encryption / decryption and integrity protection for both the U-plane and the C-plane, as well as other functions for the U-plane, such as header compression. The exemplary protocol stack also includes Non-Access Stratum (NAS) signaling between the UE and the MME.

[0011] FIG. 2C illustrates a block diagram of an exemplary LTE air interface protocol architecture from the perspective of the PHY layer. An interface between the various layers is provided by a service access point (SAP), depicted by an oval in FIG. 2C. The PHY layer interfaces with the MAC and RRC protocol layers, described above. In the figure, PHY, MAC, and RRC are also referred to as layers 1-3, respectively. While the MAC provides the RLC protocol layer (also described above) with different logical channels, characterized by the type of information transferred, the PHY provides the MAC with transport channels, characterized by how information is transferred over the air interface. In providing this transport service, the PHY performs various functions, including error detection and correction, rate matching and mapping of coded transport channels onto physical channels, power weighting, modulation, and demodulation of physical channels, transmit diversity, and beamforming multiple-input multiple-output (MIMO) antenna processing. The PHY layer also receives control information (e.g., commands) from the RRC and provides various information, e.g., radio measurements, to the RRC.

[0012] The downlink (i.e., from the network node to the UE) physical channels provided by the LTE PHY include the Physical Downlink Shared Channel (PDSCH), the Physical Multicast Channel (PMCH), the Physical Downlink Control Channel (PDCCH), the Relay Physical Downlink Control Channel (R-PDCCH), the Physical Broadcast Channel (PBCH), the Physical Control Format Indicator Channel (PCFICH), and the Physical Hybrid ARQ Indicator Channel (PHICH). In addition, the LTE PHY downlink includes various reference, synchronization, and discovery signals.

[0013] The uplink (i.e., from the UE to the network node) physical channels provided by the LTE PHY include the Physical Uplink Shared Channel (PUSCH), the Physical Uplink Control Channel (PUCCH), and the Physical Random Access Channel (PRACH). In addition, the LTE PHY uplink includes various reference signals, including Demodulation Reference Signals (DM-RS) transmitted to assist the network node in receiving an associated PUCCH or PUSCH, and Sounding Reference Signals (SRS) that are not associated with any uplink channel.

[0014] The multiple access scheme for the LTE PHY is based on Orthogonal Frequency Division Multiplexing (OFDM) with Cyclic Prefix (CP) in the downlink and Single Carrier Frequency Division Multiple Access (SC-FDMA) with Cyclic Prefix in the uplink. To support transmission in paired and unpaired spectrum, the LTE PHY supports both Frequency Division Duplexing (FDD) (including both full-duplex and half-duplex operation) and Time Division Duplexing (TDD). The LTE FDD downlink (DL) radio frame has a fixed duration of 10 ms and is composed of 20 slots, labeled 0 through 19, each with a fixed duration of 0.5 ms. A 1 ms subframe comprises two consecutive slots, where subframe i is composed of slot 2i and slot 2i+1. Each exemplary FDD DL slot has N DL symb It consists of N OFDM symbols. DL symb Each of the OFDM symbols is sc It consists of N OFDM subcarriers. DL symb An example value of N may be 7 (for normal CP) or 6 (for extended length CP) for a subcarrier bandwidth of 15 kHz. sc The value of can be set based on the available channel bandwidth. Those skilled in the art are familiar with the principles of OFDM, so further details are omitted here.

[0015] Furthermore, a particular combination of subcarriers within a particular symbol is known as a Resource Element (RE). Each RE is used to transmit a particular number of bits depending on the type of modulation and / or bit mapping constellation used for that RE. For example, some REs may carry 2 bits using QPSK modulation, while other REs may carry 4 or 6 bits using 16QAM or 64QAM, respectively. Radio resources in LTE PHY are also defined in terms of Physical Resource Blocks (PRBs). A PRB is a block that is divided into 16 bits and 6 bits, and is a number of bits that are divided into 16 bits and 6 bits, respectively. DL symb symbols) over N RB sc N subcarriers, RB sc is typically either 12 (for a 15 kHz subcarrier bandwidth) or 24 (for a 7.5 kHz bandwidth). DL symb symbols) between the same N RB sc A PRB that spans N subcarriers is known as a PRB pair. Therefore, the available resources in a LTE PHY DL subframe are N DL RB PRB pairs, N DL RB Each of the PRB pairs is DL symb N RB sc For normal CP and 15 KHz subcarrier bandwidth, a PRB pair comprises 168 REs.

[0016] The LTE FDD uplink (UL) radio frame is configured in a similar manner to the exemplary FDD DL radio frame described above. Using terminology consistent with the DL description above, each UL slot is UL symb It consists of N OFDM symbols. UL symbEach of the OFDM symbols is sc It consists of OFDM subcarriers.

[0017] As described above, the LTE PHY maps various DL and UL physical channels to PHY resources. For example, the PHICH carries HARQ feedback (e.g., ACK / NAK) for UL transmissions by the UE. Similarly, the PDCCH carries scheduling assignments, channel quality feedback (e.g., CSI) for UL channels, and other control information. Similarly, the PUCCH carries uplink control information such as scheduling requests, CSI for downlink channels, HARQ feedback for network node DL transmissions, and other control information. Both the PDCCH and the PUCCH can be transmitted on an aggregation of one or several consecutive control channel elements (CCEs), where the CCEs are mapped to physical resources based on resource element groups (REGs), each of which consists of multiple REs. For example, a CCE can comprise 9 REGs, and each of the REGs can comprise 4 REs.

[0018] Since LTE Release 8, three signaling radio bearers (SRBs), namely SRB0, SRB1, and SRB2, have been available for transporting RRC messages and Non-Access Stratum (NAS) messages between the UE and the network node. A new SRB, known as SRB1bis, was also introduced in rel-13 to support Data over NAS (DoNAS) in NB-IoT. SRB0 is for RRC messages that use the CCCH logical channel, and SRB0 is used to handle RRC connection setup, RRC connection resumption, and RRC connection re-establishment. Once the UE is connected to the network node (i.e., RRC connection setup or RRC connection re-establishment / resumption is successful), SRB1 is used to handle RRC messages (which may include piggybacked NAS messages) as well as NAS messages prior to the establishment of SRB2, all of which use the DCCH logical channel. Meanwhile, SRB2 is used for RRC messages including logged measurement information as well as NAS messages, all of which use the DCCH logical channel. SRB2 has a lower priority than SRB1 because logged measurement information and NAS messages may be redundant and may cause blocking of more urgent and smaller SRB1 messages. SRB2 is always configured by E-UTRAN after security activation.

[0019] As briefly mentioned above, the LTE RRC layer (shown in Figures 2B-2C) controls the communication between the UE and the eNB in ​​the radio interface as well as the movement of the UE between cells in the E-UTRAN. The normal mobility procedure for a UE in RRC_CONNECTED state (e.g., with an active connection) is the inter-cell handover (HO). More specifically, the UE is handed over from a source or serving cell served by a source node to a target cell served by a target node. Generally, for LTE, the handover source and target nodes are different eNBs, although intra-node handover between different cells served by a single eNB is also possible.

[0020] The concept of "delta signaling" was introduced in 3GPP standards to reduce the amount of RRC signaling between the network and the UE. At handover, for example, the source node can provide the target node with the UE's current RRC configuration. Given this information, when the target node prepares the RRC configuration to be used by the UE in the target cell after handover, it only has to signal the "delta" or "difference" between the current UE configuration and the new configuration to be used in the target cell. Such delta signaling is usually implemented with several protocol features such as "required codes", AddMod lists, and UE variables in which the received configuration is stored.

[0021] However, handovers can have various problems related to robustness. For example, HO commands (e.g., RRCConnectionReconfiguration with mobilityControlInfo or RRCReconfiguration with reconfigurationWithSync) are usually sent when radio conditions for the UE are already quite bad. Therefore, the HO command may need to be segmented (e.g., to allow redundancy to protect against errors) and / or retransmitted one or more times (e.g., using HARQ) before reaching the UE. In such cases, the HO command may not reach the UE in time (or at all) before a degraded connection with the source node (e.g., the node hosting the UE's current serving cell) is interrupted.

[0022] To address these and other challenges in handover and other mobility procedures, several "conditional mobility" techniques have been proposed. Nevertheless, these proposed techniques suffer from various deficiencies, particularly related to the use of delta signaling, that render the techniques unsuitable in various use cases, scenarios, and / or conditions. Summary of the Invention

[0023] Thus, example embodiments of the present disclosure address these and other mobility-related problems in wireless communication networks by providing improvements in mobility operations, e.g., handovers (including conditional handovers) between a source node (or cell) and a target node (or cell).

[0024] Exemplary embodiments of the present disclosure include methods (e.g., procedures) for conditional mobility in a Radio Access Network (RAN). The exemplary methods and / or procedures may be performed by a user equipment (UE, e.g., a radio device, an MTC device, an NB-IoT device, a modem, etc., or components thereof) in communication with a network node (e.g., a base station, an eNB, a gNB, etc., or components thereof) serving a cell in the RAN (e.g., E-UTRAN, NG-RAN).

[0025] In some embodiments, these example methods may include receiving a first measurement configuration from a source RAN node serving a source cell of the UE, storing the received first measurement configuration, and performing and reporting a first measurement at the source cell of the UE based on the first measurement configuration.

[0026] These example methods may also include receiving, from the RAN, one or more mobility-related messages including: a first indication of a mobility operation, a second indication of a trigger condition for the mobility operation, a second measurement configuration for the source cell, and a third measurement configuration for the one or more target cells. In some embodiments, the one or more mobility-related messages may include a conditional mobility command received from the source node including the first and second indications and the second and third measurement configurations. In addition, the second and third measurement configurations may include a respective measurement configuration for each target cell that is a candidate for the indicated mobility operation.

[0027] In other embodiments, the one or more mobility related messages may include a conditional mobility command received from the source node including the first and second instructions and the second measurement configuration, and a reconfiguration message received from the target node including the third measurement configuration.

[0028] The example methods may also include detecting achievement of a trigger condition for a particular one of the target cells based on the second measurement configuration, and performing a mobility operation toward the particular target.

[0029] In some embodiments, detecting achievement of the trigger condition can include performing a second measurement at the source cell based on the second measurement configuration. In some embodiments, performing the mobility operation can include one or more of the following operations: stopping performing the second measurement based on the second measurement configuration, deleting or releasing at least a portion of the stored second measurement configuration, and storing a third measurement configuration.

[0030] In some embodiments, the third measurement configuration may be received as a complete measurement configuration, in which performing the mobility operation may include replacing the stored first measurement configuration with the third measurement configuration.

[0031] In other embodiments, the third measurement configuration may be received as a delta with respect to the first measurement configuration and / or the second measurement configuration. In such embodiments, performing the mobility operation may include determining a measurement configuration for the third measurement based on the third measurement configuration and one or more of the first measurement configuration and the second measurement configuration.

[0032] In some embodiments, for example, when the one or more mobility-related messages include a conditional mobility command and a reconfiguration message, performing a mobility operation may include performing and reporting a third measurement at a particular target cell based on a second measurement configuration (e.g., received in the conditional mobility command) and subsequently receiving (e.g., in the reconfiguration message) a reconfiguration message including the third measurement configuration.

[0033] The example methods may also include performing and reporting a third measurement on the particular target cell based on a third measurement configuration.

[0034] Other example embodiments of the present disclosure include additional methods (e.g., procedures) for conditional mobility of a user equipment (UE) in a radio access network (RAN). These example methods may be performed by a source RAN node (e.g., a base station, eNB, gNB, etc., or a component thereof) serving one or more user equipment (UE, e.g., a radio device, an MTC device, an NB-IoT device, a modem, etc., or a component thereof) in a cell of the RAN (e.g., E-UTRAN, NG-RAN).

[0035] In some embodiments, these example methods may include transmitting a first measurement configuration for the UE serviced by the source RAN node to the UE, the first measurement configuration relating to a source cell; receiving a first measurement made by the UE at the source cell based on the first measurement configuration; and determining that a mobility action is required for the UE based on the first measurement.

[0036] These example methods may also include transmitting a request to the target node to accept a mobility operation (e.g., as determined above) for the UE. In some embodiments, the request may include a first measurement configuration for the UE. These example methods may also include receiving a confirmation of the mobility operation from the target RAN node, the confirmation including a third measurement configuration for one or more target cells served by the target RAN node. These example methods may also include determining a second measurement configuration related to a trigger condition for the mobility operation. For example, the second measurement configuration may be usable to detect achievement of the trigger condition at a source cell of the UE. In some embodiments, determining the second measurement configuration may also include transmitting the second measurement configuration to the target RAN node.

[0037] In some embodiments, at least one of the following conditions applies: the second measurement configuration is determined as a delta with respect to the first measurement configuration, the third measurement configuration is received as a delta with respect to the first measurement configuration, and the third measurement configuration is received as a delta with respect to the first and second measurement configurations.

[0038] These example methods may also include transmitting, to the UE, a mobility-related message that includes: a first indication of a mobility operation, a second indication of a trigger condition, and a second measurement configuration. In some embodiments, the conditional mobility command may also include a third measurement configuration, where the second and third measurement configurations may include respective measurement configurations for each target cell that is a candidate for the indicated mobility operation.

[0039] In some embodiments, the example methods may also include receiving a third indication from the target RAN node that the mobility operation is complete, and deleting or releasing at least a portion of the stored first and second measurement configurations in response to the third indication.

[0040] Other example embodiments of the present disclosure include additional methods (e.g., procedures) for conditional mobility of a user equipment (UE) in a radio access network (RAN). These example methods may be performed by a target RAN node (e.g., a base station, eNB, gNB, etc., or a component thereof) serving a cell of the RAN (e.g., E-UTRAN, NG-RAN).

[0041] These example methods can include receiving a request from a source RAN node to accept a mobility operation for the UE. The request can include a first measurement configuration for the UE. These example methods can also include determining a third measurement configuration for the UE with respect to one or more target cells served by the target RAN node. The third measurement configuration can be based on (e.g., a delta with respect to) the first measurement configuration.

[0042] These example methods may include transmitting a confirmation of the mobility operation to the source RAN node, the confirmation including the third measurement configuration. In various embodiments, the third measurement configuration may be transmitted as a complete measurement configuration or as a delta with respect to the first measurement configuration and / or the second measurement configuration. These example methods may also include receiving, from the UE, measurements made at a particular one of the target cells based on the third measurement configuration.

[0043] In some embodiments, these example methods may also include receiving measurements made by the UE with respect to the particular target cell based on the second measurement configuration, and then transmitting a reconfiguration message to the UE that includes a third measurement configuration.

[0044] In these embodiments, these example methods may also include receiving, from the source RAN node, a second measurement configuration for the UE. The second measurement configuration may be received as a delta with respect to the first measurement configuration. In such embodiments, the third measurement configuration included in the reconfiguration message may be the second measurement configuration and a delta with respect to the first measurement configuration.

[0045] In some embodiments, these example methods may also include sending an indication to the source RAN node that the mobility operation is complete.

[0046] Other exemplary embodiments include user equipment (UE, e.g., a wireless device, an MTC device, an NB-IoT device, a modem, etc., or components thereof) and a network node (e.g., a base station, a gNB, an eNB, etc., or components thereof) configured to perform operations corresponding to any of the exemplary methods described herein. Other exemplary embodiments include a non-transitory computer-readable medium storing computer-executable instructions that, when executed by processing circuitry of the UE or network node, configure such UE or network node to perform operations corresponding to any of the exemplary methods described herein.

[0047] These and other objects, features, and advantages of the exemplary embodiments of the present disclosure will become apparent from a reading of the following detailed description in light of the drawings briefly described below. [Brief description of the drawings]

[0048] [Figure 1]FIG. 1 is a high-level block diagram of an example architecture of a Long-Term Evolution (LTE) Evolved UTRAN (E-UTRAN) and Evolved Packet Core (EPC) network as standardized by 3GPP. [Figure 2A] FIG. 1 is a high-level block diagram of an example E-UTRAN architecture with respect to the components, protocols, and interfaces that make up the E-UTRAN architecture. [Figure 2B] FIG. 2 is a block diagram of example protocol layers of the control plane portion of the radio (Uu) interface between a user equipment (UE) and an E-UTRAN. [Figure 2C] FIG. 1 is a block diagram of an example LTE air interface protocol architecture from a PHY layer perspective. [Diagram 3] A high-level diagram of a 5G network architecture, including a split central unit (CU)-distributed unit (DU) split architecture for gNBs. [Figure 4] FIG. 1 illustrates NR RRC states and procedures by which a UE transitions between NR RRC states. [Diagram 5] A diagram, divided into Figures 5A and 5B, showing a signaling flow between a UE, a source node (e.g., a source gNB), and a target node (e.g., a target gNB) during a handover procedure in an NR network. [Figure 6] A diagram, comprising Figures 6A-6C, showing three exemplary ASN.1 data structures used to transfer and store a UE's measurement configuration. [Figure 7] 7A and 7B, which illustrate two example robustness issues that may arise during UE mobility operations, e.g., handover. [Figure 8] FIG. 2 illustrates a signaling flow between a UE, a source node, and a target node of a CHO according to an exemplary embodiment of the present disclosure. [Figure 9]9A-9C, which include FIGS. 9A-9C, illustrate three different techniques for configuring a UE with a conditional mobility (eg, CHO) trigger condition. [Figure 10] 1 illustrates a signaling flow of an example technique that uses delta signaling to provide a UE with measurement configurations to be used during and after conditional mobility (e.g., CHO) operation. [Figure 11] FIG. 1 illustrates a signaling flow of an improved technique for providing a UE with measurement configurations to be used during the monitoring and execution phases of conditional mobility (e.g., CHO) operation, in accordance with various example embodiments of the present disclosure. [Figure 12] FIG. 13 illustrates a signaling flow of another improved technique for providing a UE with measurement configurations to be used during the monitoring and execution phases of conditional mobility (e.g., CHO) operation, in accordance with various example embodiments of the present disclosure. [Figure 13] FIG. 1 illustrates example methods and / or procedures performed by a user equipment (UE) for conditional mobility in a radio access network (RAN), in accordance with various example embodiments of the present disclosure. [Figure 14] FIG. 1 illustrates example methods and / or procedures performed by a source node in a radio access network (RAN) for conditional mobility of a UE, in accordance with various example embodiments of the present disclosure. [Figure 15] FIG. 1 illustrates example methods and / or procedures performed by a target node in a radio access network (RAN) for conditional mobility of a UE, in accordance with various example embodiments of the present disclosure. [Figure 16] FIG. 1 illustrates an example embodiment of a wireless network in accordance with various aspects described herein. [Figure 17] FIG. 1 illustrates an example embodiment of a UE in accordance with various aspects described herein. [Figure 18]FIG. 1 is a block diagram illustrating an example virtualization environment usable for implementation of various embodiments of the network nodes described herein. [Figure 19] 1A-1C are block diagrams of various example communication systems and / or networks in accordance with various aspects described herein. [Figure 20] 1A-1C are block diagrams of various example communication systems and / or networks in accordance with various aspects described herein. [Figure 21] FIG. 19 is a flow diagram of an example method and / or procedure for transmitting and / or receiving user data that may be implemented in, for example, the example communication system and / or network shown in FIGS. 17-18. [Figure 22] FIG. 19 is a flow diagram of an example method and / or procedure for transmitting and / or receiving user data that may be implemented in, for example, the example communication system and / or network shown in FIGS. 17-18. [Diagram 23] FIG. 19 is a flow diagram of an example method and / or procedure for transmitting and / or receiving user data that may be implemented in, for example, the example communication system and / or network shown in FIGS. 17-18. [Figure 24] FIG. 19 is a flow diagram of an example method and / or procedure for transmitting and / or receiving user data that may be implemented in, for example, the example communication system and / or network shown in FIGS. 17-18. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0049] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. However, other embodiments are included within the scope of the subject matter disclosed herein, and the subject matter disclosed should not be construed as being limited to only the embodiments described herein, but rather, these embodiments are provided as examples to convey the scope of the subject matter to those skilled in the art. Additionally, the following terms are used throughout the description given below: ● Wireless node: As used herein, a "wireless node" may be either a "wireless access node" or a "wireless device." ● Radio Access Node: As used herein, a "radio access node" (or "radio network node") may be any node in a radio access network (RAN) of a cellular communications network that operates to transmit and / or receive signals wirelessly. Some examples of radio access nodes include, but are not limited to, base stations (e.g., a new radio (NR) base station (gNB) in a 3GPP fifth generation (5G) NR network, or an enhanced or evolved Node B (network node) in a 3GPP LTE network), high power or macro base stations, low power base stations (e.g., micro base stations, pico base stations, home eNBs, etc.), integrated access backhaul (IAB) nodes, and relay nodes. Core network node: As used herein, a "core network node" is any type of node in a core network. Some examples of core network nodes include, for example, a mobility management entity (MME), a packet data network gateway (P-GW), a service capability exposure function (SCEF), etc. ● Wireless Device: As used herein, a "wireless device" (or "WD" for short) is any type of device that has access to (i.e., is served by) a cellular communications network by communicating wirelessly with network nodes and / or other wireless devices. Unless otherwise noted, the term "wireless device" is used interchangeably herein with "user equipment" (or "UE" for short). Some examples of wireless devices include, but are not limited to, UEs in 3GPP networks and machine type communications (MTC) devices. Communicating wirelessly can involve transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information over the air. ● Network Node: As used herein, a "network node" is any node that is part of either the radio access network or the core network of a cellular communications network. Functionally, a network node is equipment that is capable of, set up, configured, and / or operable to communicate, directly or indirectly, with wireless devices and / or with other network nodes or equipment in the cellular communications network to enable and / or provide wireless access to the wireless devices and / or to perform other functions (e.g., administration) in the cellular communications network.

[0050] It should be noted that the description provided herein focuses on 3GPP cellular communication systems, and therefore 3GPP terminology or terminology similar to 3GPP terminology is often used. However, the concepts disclosed herein are not limited to 3GPP systems. Other wireless systems, including but not limited to Wideband Code Division Multiple Access (WCDMA), Worldwide Interoperability for Microwave Access (WiMAX), Ultra Mobile Broadband (UMB), and Global System for Mobile Communications (GSM), can also benefit from the concepts, principles, and / or embodiments described herein.

[0051] In addition, functions and / or operations described herein as being performed by a wireless device or network node may be distributed across multiple wireless devices and / or network nodes. Further, although the term "cell" is used herein, it should be understood that a beam may be used in place of a cell (particularly with respect to 5G NR), and thus the concepts described herein apply equally to both cells and beams.

[0052] As explained above, the current handover (HO) process in 3GPP networks has various problems with robustness. For example, the HO command (e.g., RRCConnectionReconfiguration with mobility ControlInfo or RRCReconfiguration with reconfigurationWithSync) is usually sent when the radio conditions of the UE are already quite bad. Therefore, the HO command may need to be segmented (e.g., to allow redundancy to protect against errors) and / or retransmitted (e.g., using HARQ) one or more times before it reaches the UE. In such cases, the HO command may not reach the UE on time (or at all) before the degraded connection with the target node is interrupted.

[0053] One solution to improve mobility robustness is called "Conditional Handover" (abbreviated "CHO") or "Early Handover Command". To avoid dependency on serving radio link conditions when the UE should perform handover, RRC signaling for handover may be provided to the UE earlier while the condition of the radio link is better. Such CHO RRC signaling may be based on delta signaling, described above, which provides similar advantages with respect to conventional (i.e., non-conditional) handover. Nevertheless, the use of delta signaling may create various problems, inconsistencies, and / or issues during CHO operation, especially when used to configure UE measurements. These problems and specific improvements realized by exemplary embodiments of the present disclosure are described in more detail below.

[0054] Prior to Rel-13, there were two RRC states defined for a UE. More specifically, after a UE is powered on, it is in RRC_IDLE state until an RRC connection is established, at which point the UE transitions to an RRC_CONNECTED state (where, e.g., data transfer may occur). After the connection is released, the UE returns to RRC_IDLE. In RRC_IDLE state, the UE's radio is active on a discontinuous reception (DRX) schedule set by higher layers. During the DRX active period, a UE in RRC_IDLE receives system information (SI) broadcasted by the serving cell, performs measurements on neighboring cells to support cell reselection, and monitors the paging channel on the PDCCH for pages from the EPC via the eNB. A UE in RRC_IDLE is known in the EPC and has an assigned IP address, but is unknown to the serving eNB (e.g., no stored context exists).

[0055] In LTE Rel-13, a mechanism was introduced for the UE to be suspended by the network into a SUSPENDED state, which is similar to RRC_IDLE but with some important differences. First, the SUSPENDED state is not a third RRC "state" together with RRC_IDLE and RRC_CONNECTED, rather the SUSPENDED state can be seen as a "sub-state" of RRC_IDLE. Second, both the UE and the serving eNB store the AS (e.g., S1-AP) context and RRC context of the UE after suspension. When a suspended UE needs to resume a connection (e.g., to transmit UL data), instead of going through the traditional service request procedure, the suspended UE only needs to send an RRCConnectionResumeRequest message to the eNB. The eNB resumes the S1AP context and responds with an RRCConnectionResume message. There is no complex exchange of security context between the MME and the eNB, and no setup of AS security context. The saved AS context and RRC context are just resumed from where they were previously suspended. Reducing signaling can result in reduced UE latency (e.g., for smartphones accessing the Internet) and reduced UE signaling, which can lead to reduced UE energy consumption, especially for machine type communication (MTC) devices that transmit very little data (i.e., signaling is the primary energy consumer).

[0056] To support mobility between cells and / or beams (e.g., handover or reselection), the UE may perform periodic cell search and measurement of signal power and quality (e.g., Reference Signal Received Power (RSRP) and Reference Signal Received Quality (RSRQ)) in both RRC_CONNECTED and RRC_IDLE modes. The UE is responsible for detecting new neighboring cells, as well as tracking and monitoring already detected cells. The detected cells and related measurements are reported to the network. An LTE UE may perform such measurements for various downlink reference signals (RS), including, for example, cell-specific reference signals (CRS), MBSFN RS, UE-specific demodulation RS (DM-RS) associated with PDSCH, DM-RS associated with EPDCCH or M / NPDCCH, positioning RS (PRS), and channel state information RS (CSI-RS).

[0057] UE measurement reporting to the network can be configured to be periodic or aperiodic based on certain events. For example, the network can configure the UE to perform measurements for different carrier frequencies and different radio access technologies (RATs) corresponding to neighboring cells, and for different purposes including, for example, mobility and / or positioning. The configuration for each of these measurements is called a "measurement object." Furthermore, the UE can be configured to perform measurements according to a "measurement gap pattern" (or "gap pattern" for short), which can include a measurement gap repetition period (MGRP, i.e., how often a repetition gap is available for measurement) and a measurement gap length (MGL, i.e., the length of each repetition gap).

[0058] In LTE, the concept of Time-To-Trigger (TTT) is used to ensure that an event trigger criterion for a long enough duration is met before a measurement report is sent by the UE. The trigger criterion and the TTT are configured in the reportConfig message (or an information element, IE, of the message) sent by the network to the UE. The value of TTT provided in the reportConfig is applicable to all neighboring cells of the UE that may trigger a measurement report based on the specified trigger criterion.

[0059] It is recalled that while LTE was designed primarily for user-to-user communication, 5G cellular networks (also called "NR") will support both high single-user data rates (e.g., 1 Gb / s) and large-scale machine-to-machine communication with short bursts of transmission from many different devices sharing the frequency band. 5G wireless standards (also called "New Radio" or "NR") currently cover a wide range of data services, including eMBB (enhanced Mobile Broadband) and URLLC (Ultra-Reliable Low Latency Communications). These services may have different requirements and objectives. For example, URLLC has very strict error and latency requirements, e.g., 10 -5 The eMBB standard is intended to provide data services with an error probability of 1 ms or less and an end-to-end latency of 1 ms or less. For eMBB, the requirements on latency and error probability may be less stringent, but the required supported peak rates and / or spectral efficiency may be higher.

[0060] Similar to LTE, the NR PHY uses CP-OFDM (cyclic prefix orthogonal frequency division multiplexing) in the DL and both CP-OFDM and DFT-extended OFDM (DFT-S-OFDM) in the UL. In the time domain, NR DL and UL physical resources are organized into equal-sized 1 ms subframes. Each subframe contains one or more slots, and each slot contains 14 (with normal cyclic prefix) or 12 (with extended cyclic prefix) time-domain symbols.

[0061] FIG. 3 illustrates a high-level diagram of a 5G network architecture including a Next Generation RAN (NG-RAN) 399 and a 5G Core Network (5GC) 398. The NG-RAN 399 may include one or more g Node Bs (gNBs) connected to the 5GC via one or more NG interfaces, such as gNBs 300, 350 connected via interfaces 302, 352, respectively. More specifically, the gNBs 300, 350 may connect to one or more Access and Mobility Management Functions (AMFs) in the 5GC 398 via respective NG-C interfaces. Similarly, the gNBs 300, 350 may connect to one or more User Plane Functions (UPFs) in the 5GC 398 via respective NG-U interfaces. The NG-C and NG-U are the control plane and user plane portions, respectively, of the NG interfaces 302 and 352 shown in FIG. 3.

[0062] Although not shown, in some deployments, the 5GC 398 may be replaced by an evolved packet core (EPC) that is traditionally used with E-UTRAN in LTE. In such deployments, the gNBs 300, 350 may connect to one or more mobility management entities (MMEs) in the EPC via their respective S1-C interfaces. Similarly, the gNBs 300, 350 may connect to one or more serving gateways (SGWs) in the EPC via their respective NG-U interfaces.

[0063] In addition, the gNBs may be connected to each other via one or more Xn interfaces, such as Xn interface 340 between gNBs 300 and 350. The radio technology for NG-RAN is often referred to as "New Radio" (NR). For the NR interface to the UE, each of the gNBs may support Frequency Division Duplex (FDD), Time Division Duplex (TDD), or a combination thereof.

[0064] NG-RAN 399 can be divided into Radio Network Layer (RNL) and Transport Network Layer (TNL). The NG-RAN architecture, i.e. NG-RAN logical nodes and interfaces between the nodes, are specified as part of the RNL. For each NG-RAN interface (NG, Xn, F1), the protocols and functions of the involved TNL are specified. The TNL provides services for user plane transport and signaling transport. In some example configurations, each gNB is connected to all 5GC nodes in the "AMF region" specified in 3GPP TS 23.501 (v15.4.0). If security protection for CP and UP data on the TNL of the NG-RAN interface is supported, NDS / IP (specified in 3GPP TS 33.401 v15.6.0) should be applied.

[0065] The NG-RAN logical node shown in FIG. 3 (and described in 3GPP TS38.401 v15.4.0 and 3GPP TR38.801 v14.0.0) includes a central unit (CU or gNB-CU) and one or more distributed units (DU or gNB-DU). For example, the gNB 300 includes a gNB-CU 310 and a gNB-DU 320 and 330. The CU (e.g., gNB-CU 310) is a logical node that hosts higher layer protocols and performs various gNB functions such as controlling the operation of the DU. The DU (e.g., gNB-DU 320, 330) is a distributed logical node that hosts lower layer protocols and can include various subsets of gNB functions depending on the function partitioning option. Thus, each of the CU and DU can include various circuits required to perform their respective functions, including processing circuits, transceiver circuits (e.g., for communication), and power supply circuits. Moreover, the terms "central unit" and "centralized unit" are used interchangeably herein with the terms "distributed unit" and "distributed unit."

[0066] The gNB-CU connects to one or more gNB-DUs via respective F1 logical interfaces, such as interfaces 322 and 332 shown in FIG. 3. However, a gNB-DU can only connect to a single gNB-CU. The gNB-CU and the connected gNB-DU appear simply as a gNB to other gNBs and 5GC. In other words, the F1 interface is not visible beyond the gNB-CU. Furthermore, the F1 interface between the gNB-CU and the gNB-DU is specified by and / or based on the following general principles: ●F1 is an open interface. • F1 supports the exchange of signaling information between each of the endpoints as well as the transmission of data to each of the endpoints. From a logical point of view, F1 is a point-to-point interface between the endpoints (even though there is no direct physical connection between them). ●F1 supports separation of the control plane (CP) and user plane (UP), so that the gNB-CU may be separated in the CP and UP. ●F1 separates the Radio Network Layer (RNL) and the Transport Network Layer (TNL). • F1 enables the exchange of User Equipment (UE) related and non-UE related information. • F1 will be defined to remain current with new requirements, services and capabilities. The gNB terminates the X2, Xn, NG, and S1-U interfaces, and for the F1 interface between the DU and CU, it utilizes the F1 Application Part protocol (F1-AP) specified in 3GPP TS38.473.

[0067] Further, the CU can host protocols such as RRC and PDCP, and the DU can host protocols such as RLC, MAC, and PHY. However, there can be other variations of protocol distribution between the CU and the DU, such as hosting RRC, PDCP, and parts of the RLC protocol in the CU (e.g., automatic repeat request (ARQ) functionality) while hosting the rest of the RLC protocol in the DU, along with MAC and PHY. In some exemplary embodiments, the CU can host RRC and PDCP, and PDCP is assumed to handle both UP and CP traffic. Nevertheless, other exemplary embodiments can utilize other protocol splits by hosting some protocols in the CU and some other protocols in the DU. Exemplary embodiments can also place the centralized control plane protocols (e.g., PDCP-C and RRC) in a different CU relative to the centralized UP protocols (e.g., PDCP-U).

[0068] In addition to the RRC_IDLE and RRC_CONNECTED states described above, NR UEs also support an RRC_INACTIVE state, which has similar characteristics to the suspend condition in LTE Rel-13. However, the RRC_INACTIVE state has the slightly different characteristics of being a separate RRC state and not part of RRC_IDLE as in LTE. Additionally, the CN / RAN connection (NG or N2 interface) remains active during RRC_INACTIVE, whereas it was suspended in LTE.

[0069] Figure 4 illustrates the NR RRC states and the procedures by which a UE transitions between the NR RRC states. The characteristics of the states illustrated in Figure 4 are summarized as follows: ●RRC_IDLE: UE-specific discontinuous reception (DRX) operation can be configured by higher layers. -UE controlled mobility based on network configuration (e.g. cell reselection). -UE, ○5G-S-TMSI is used to monitor the paging channel for CN paging. ○Perform neighbouring cell measurements and cell (re)selection. ○Get system information. ●RRC_INACTIVE: UE-specific DRX operation may be configured by higher layers or RRC. -UE controlled mobility based on network configuration. - The UE stores the AS context. -UE, ○5G-S-TMSI is used to monitor the paging channel for CN paging, and I-RNTI is used to monitor the paging channel for RAN paging. ○Perform neighbouring cell measurements and cell (re)selection. Perform RAN based notification area updates periodically and when moving outside the RAN based notification area. ○Get system information. ●RRC_CONNECTED: - The UE stores the AS context. -Transfer of unicast data to / from the UE via a shared data channel (e.g., PDSCH and / or PUSCH). At lower layers, the UE may be configured with UE-specific DRX. For UEs supporting CA, use of one or more SCells aggregated in an SpCell for increased bandwidth. For UEs supporting DC, use of one SCG aggregated with an MCG for increased bandwidth. -Network controlled mobility, i.e. handovers within NR and to / from E-UTRAN. -UE, ○ Monitor the paging channel. o Monitor a control channel associated with the shared Data channel to determine if data is scheduled on the shared Data channel. o Provides channel quality and feedback information. ○ Perform neighbor cell measurements and measurement reporting. ○Get system information.

[0070] As shown in Figure 4, the transition between the RRC_INACTIVE and RRC_CONNECTED states is achieved by two new procedures: "Suspend" (also called RRC Connection Release with SuspendConfig) and "Resume". The gNB can suspend the connection and move the UE from RRC_CONNECTED to RRC_INACTIVE by sending an RRCRelease message with a suspend indication (or configuration) to the UE. This can happen, for example, after the UE has been inactive for a period of time that causes a gNB internal inactivity timer to expire. Upon moving to RRC_INACTIVE, both the UE and the gNB store the UE's Access Stratum (AS) context and the associated identifier (called I-RNTI).

[0071] Similarly, a UE can attempt to resume a connection towards a particular gNB (e.g., the same or a different cell than the one where the connection was suspended) by sending a RRCResumeRequest message to the gNB, which includes the I-RNTI, a security token (called resumeMAC-I) used to identify and verify the UE upon RRC connection resumption, and an indication of the resumption cause (e.g., mobile originated data). The gNB serving the cell where the UE attempts to resume is often referred to as the "target gNB," and the gNB serving the cell where the UE was suspended is often referred to as the "source gNB." To resume the connection, the target gNB identifies the source gNB (e.g., from a portion of the I-RNTI) and requests that gNB to send the UE's context. In this request, the target gNB provides, among other things, the target cell ID, the UE ID, and the security token received from the UE. The NR resume procedure is similar in some ways to the corresponding resume procedures in LTE (e.g., E-UTRAN and EPC) and eLTE (e.g., E-UTRAN and 5GC).

[0072] As mentioned above, an RRC_CONNECTED UE may be configured by the network to perform measurements, and upon triggering a measurement report, the network may send a handover command to the UE. In LTE, this command is an RRConnection-Reconfiguration message with a Mobility ControlInfo field. In NR, this command is an RRCReconfiguration message with a reconfigurationWithSync field.

[0073] These reconfigurations are prepared by the handover target mode upon request from the source node, exchanged over the X2 or S1 interface in LTE (see, for example, FIG. 1) or the NG interface in the case of NR (see, for example, FIG. 3). These reconfigurations take into account the existing RRC configuration between the UE and the source cell, which is usually provided in the node-to-node request. In LTE, for example, this existing UE configuration is provided in the HandoverPreparationInformation of the request from the source node to the target node. In response, the target node provides reconfiguration parameters, including all information the UE needs to access the target cell, e.g., random access configuration, a new C-RNTI assigned by the target cell, security parameters that allow the UE to calculate new security keys related to the target cell, etc. The new security keys allow the UE to send a handover complete message on SRB1, encrypted and integrity protected, when it has accessed the target cell.

[0074] FIG. 5, divided into FIG. 5A and FIG. 5B, illustrates the signaling flow between a UE, a source node (e.g., source gNB), and a target node (e.g., target gNB) during a handover procedure in an NR network. FIG. 5 also illustrates the roles of 5GC functions, including an Access Management Function (AMF) and a User-Plane Function (UPF). Nevertheless, the following description addresses various principles related to HO (or more generally, UE mobility while in RRC_CONNECTED mode) in both NR and LTE networks.

[0075] First, UE mobility in RRC_CONNECTED is network-based, since the network has the latest and / or most accurate information about the current situation, such as load conditions, resources in different nodes, available frequencies, etc. The network can also take into account the situation of many UEs in the network in terms of resource allocation.

[0076] As shown in Figure 5, there are three phases in the handover procedure: handover preparation, handover execution, and handover completion. Before handover preparation, the UE may be transmitting and / or receiving user data to the UPF in 5GC via the source gNB. During the handover preparation phase, the network prepares the target cell before the UE accesses that cell. The AMF provides mobility control information to the source gNB (operation 0). In addition, the source node receives measurement reports from the UE (operation 1), makes a handover decision based on these reports (e.g., operation 2), and negotiates the handover of the UE with the target node (e.g., operations 3-5).

[0077] During handover execution, the source node provides various information to the UE to trigger handover to the target cell served by the target node (operation 6) and provides the target node with the current status of the UE at the source node (operation 7). For example, the source node (e.g., in operation 6) provides the UE with the RRC configuration to be used in the target cell, including the SRB1 configuration (e.g., parameters from which to derive keys for encryption / integrity protection) to send a HO complete message (e.g., RRCConnectionReconfigurationComplete). The source node provides the UE with the target C-RNTI, so that the target node can identify the UE from the random access msg3 on the MAC level for the HO complete message. This information is received from the target node during the handover preparation phase. Therefore, there is no need for the target node to perform a UE context fetch unless a failure occurs.

[0078] Furthermore, to accelerate HO, the source node provides the UE with the necessary information on how to access the target (e.g., RACH configuration), so that the UE does not need to acquire the target node's system information (SI, e.g., from broadcast) prior to handover. Both full and delta reconfiguration are supported, so that HO commands can be minimized. The UE may be provided with Contention Free Random Access (CFRA) resources, in which case the target node can identify the UE from the RACH preamble (also called msg1). More generally, the normal HO procedure can always be optimized with dedicated resources such as CFRA resources.

[0079] Also during the handover execution phase, the UE disassociates from the old cell (e.g., served by the source node) and synchronizes to the new cell served by the target node (e.g., operation 8). Concurrent with these operations, the source node delivers buffered user data for the UE to the target node, which can then communicate this user data to the UE after the UE completes the handover.

[0080] During the handover completion phase, the target node and the source node in the NG-RAN communicate with the 5GC (e.g., AMF) to update routing information related to the UE (e.g., operations 9 and 11). In addition, nodes or functions in the 5GC (e.g., AMF and UPF) may communicate to update the UE routing based on the handover (e.g., operation 10). Finally, the target node may inform the source node that the source node may release the context of the UE (e.g., operation 12).

[0081] As mentioned above, "delta signaling" is used to reduce the amount of RRC signaling between the network and the UE. As also mentioned above, delta signaling is typically implemented with protocol features such as "required codes", AddMod lists, and UE variables in which received settings are stored.

[0082] In NR, a measurement configuration may be provided to the UE in an RRCResume or RRCReconfiguration message. For example, such a measurement configuration may be provided as a delta with respect to one or more measurement configurations (e.g., a complete measurement configuration) previously provided to the UE. For example, FIG. 6A shows an ASN.1 data structure that defines an example RRCResume message that includes a complete measurement configuration information element (measConfig IE) for the UE.

[0083] The measConfig IE in FIG. 6A is labeled "Required M" and specifies measurements to be performed by the UE, including intra-frequency, inter-frequency and inter-RAT mobility and configuration of measurement gaps. The "Required M" code means that this field needs to be stored by the UE. In addition, the measConfig IE in FIG. 6A points to a MeasConfig data structure, which may be defined by the exemplary ASN.1 data structure shown in FIG. 6B. Note that some of the fields in FIG. 6B are also labeled "Required M". Table 1 below provides further definitions of certain fields shown in the figure. TIFF0007638339000001.tif105170

[0084] When the measConfig IE is provided to the UE in the RRCResume message, the UE stores the above based on their associated "required M" codes. In particular, the UE stores the information received in measConfig in the UE variable VarMeasConfig, which contains the cumulative configuration of measurements to be performed by the UE, including intra-frequency, inter-frequency, and inter-RAT mobility related measurements. Figure 6C shows an ASN.1 data structure defining an exemplary VarMeasConfig used by the UE in this manner.

[0085] Assume that the UE receives an RRCReconfiguration with reconfigurationWithSync indicating that it should perform a handover to the target cell. Upon receiving the message, the UE applies the contents of the message to its configuration. If the measConfig IE is present, the UE updates its stored configuration with any new values ​​or subfields included in the IE. Due to delta signaling, the network includes only new or changed values ​​or subfields. If no configuration change is required, the network does not include the measConfig IE and the UE continues to use its currently stored measConfig. For the specific case of handover, if the target node notices that the UE's stored measurement configuration is the UE's desired configuration to use in the target cell, the target node simply does not signal anything. Alternatively, if certain fields are to be changed, the target node simply includes them in the measConfig IE sent to the UE.

[0086] For example, assume that the UE has stored the measConfig received in the RRCResume, and now the UE receives an RRCReconfiguration with a MeasConfig IE containing measConfig'. As shown in Figure 6B, the fields s-MeasureConfig, quantityConfig, measGapConfig, and measGapSharingConfig in this IE are labeled as "Required". This means that if any of these fields are missing in the received IE, the UE should continue to use the corresponding stored parameters from measConfig.

[0087] For example, if in RRCResume the UE receives quantityConfig, measGapConfig, s-MeasureConfig and measGapSharingConfig, and in RRCReconfiguration the UE receives measConfig' with only quantityConfig', the UE will replace quantityConfig with quantityConfig' and continue to use the other stored values ​​received in measConfig. So after this delta signaling the UE's stored configurations will be quantityConfig', measGapConfig, s-MeasureConfig and measGapSharingConfig.

[0088] For the MeasConfig field with the code "required N", a list structure is used, but the principle is similar. "required N" stands for "no action", indicating a field that is not stored and whose presence causes one action by the UE. When the "required N" field is absent, the UE performs no action. Such a list structure is important to configure the UE with the measurement objects to be measured (e.g. carrier frequency, cell, cell quality derived parameters in NR, frequency specific thresholds, etc.), reporting settings (e.g. event triggered measurement reporting settings), measurement identifiers, etc. It is also used to remove these.

[0089] Despite the fact that such fields are labelled "required", their reception triggers the UE to store the contained information. For example, if the network wants to add a measurement object to the UE when it sends the first measConfig in the previous example, this will trigger the UE to perform the following one-time procedure (assuming the object does not exist): 1> If the received measConfig contains measObjectToAddModList: 2> The UE should: 1> For each measObjectId contained in the received measObjectToAddModList: 2>If an entry with a matching measObjectId exists in the measObjectList in VarMeasConfig, then for this entry: …. 2>If not: 3>Add a new entry for the received measObject to the measObjectList in VarMeasConfig.

[0090] The UE stores this list information, so delta signaling is performed by sending pointers or identifiers to specific configurations known to be stored in the UE. If any of these lists are provided in a subsequent message with measConfig, the UE will keep what it has stored in VarMeasConfig and continue performing measurements accordingly. If the network wants to explicitly add a measurement object, reporting configuration, and / or measurement identifier, it simply includes the fields and adds the new one. It will be added to the list stored by the UE in VarMeasConfig. Similarly, if the network wants to remove or modify an existing measurement object or reporting configuration, either is referenced by an identifier provided in the AddMod list.

[0091] One of the primary objectives of NR is to provide greater capacity for operators to serve ever-increasing traffic demands and various applications. For this reason, NR should be able to operate at higher frequencies (above 6 GHz and below 100 GHz) where more spectrum will be available. Compared to the current frequency bands allocated to LTE, some of the new bands will have much more difficult propagation characteristics, such as lower diffraction and higher outdoor / indoor penetration loss. As a result, signals have a lower ability to propagate around corners and penetrate walls. In addition, atmospheric / rain attenuation and higher body losses make the coverage of NR signals in the high frequency bands even more spotty. Fortunately, operation at higher frequencies allows the use of smaller antenna elements, which allows antenna arrays with a large number of antenna elements. Such antenna arrays facilitate beamforming, where multiple antenna elements are used to form narrow beams and thereby compensate for the difficult propagation characteristics.

[0092] Despite the link budget gains realized by beamforming solutions, reliability of systems relying purely on beamforming and operating at higher frequencies may be challenging, since coverage may be more susceptible to both time / frequency and spatial variations. As a result, the SINR of such narrow links may fall much faster than in the case of LTE. Even in the case of LTE, it has been observed that the serving cell may not be able to deliver HO commands in a timely manner. Lowering the enabled Time-To-Trigger (TTT) and measurement hysteresis may reduce handover failure rates, but may increase the ping-pong probability (e.g., of bouncing between cells). These effects may be further pronounced when operating in the higher frequency bands of NR.

[0093] FIG. 7, including FIGS. 7A and 7B, illustrates various exemplary robustness problems that may occur during UE mobility operations, e.g., during handover. In the scenario illustrated in FIG. 7A, based on neighbor cell measurements, the UE triggers an "A3 event" in which the neighbor cell is better than the UE's primary cell (PCell). In response, the UE attempts to send a measurement report regarding this condition to the source (e.g., serving) node. However, due to rapidly deteriorating uplink radio conditions, the source node does not receive the measurement report from the UE. Conditions continue to deteriorate in the UE's source cell, eventually prompting the UE to declare a radio link failure (RLF) and to attempt to re-establish (which may or may not be successful) a connection with the source node. In FIG. 7B, the source node correctly receives the UE's measurement report, but due to deteriorating downlink radio conditions, the UE does not receive a HO command from the source node. Ultimately, the same result occurs in both cases illustrated in FIG. 7.

[0094] Therefore, there is a need to improve mobility robustness in NR systems, and a work item for mobility extensions in LTE and NR was started in 3GPP Rel-16. The main objective of the work item is to improve robustness in handover and reduce interruption time in handover. Different solutions to improve mobility robustness in LTE and NR have been discussed in the past. One solution is based on Dual Connectivity (DC), introduced in LTE Rel-12. In DC, the UE is connected to two network nodes at the same time. This improves mobility robustness by serving control plane traffic (e.g., used for measurement reports and handover commands) by a robust macro layer in the lower frequency and achieving increased capacity with the higher frequency. This feature is often called "UP / CP split". Alternatively, DC can be configured such that control plane signaling is exchanged via both connected nodes. This is called "RRC diversity" and can improve robustness due to diversity in the time and space domains.

[0095] As briefly mentioned above, another solution is called "Conditional Handover" (or "CHO" for short) or "Early Handover Command". To avoid dependency on serving radio link conditions on the time when the UE should perform handover, the RRC signaling for handover can be provided to the UE earlier while the conditions of the radio link are better. To achieve this, the HO command can be associated with a condition (e.g., radio conditions similar to those associated with the A3 event).

[0096] For example, an exemplary execution condition may be that the quality of the target cell or beam is X dB stronger than the serving cell. The previous measurement report event may use a threshold Y selected to be lower than that in the handover execution condition. This allows the serving cell to prepare the handover upon receiving an early measurement report and to provide an RRCConnectionReconfiguration with mobility ControlInfo (for LTE) or an RRCReconfiguration with either reconfigurationWithSync or cellGroupConfig (for NR) at a time when the radio link between the source cell and the UE is still relatively stable. The handover execution is performed at a subsequent time (and threshold) that is optimal and / or preferred for handover execution.

[0097] 8 illustrates an example signal flow between a user equipment (UE) 810, a source node 820, and a target node 830 for a conditional handover (HO) in accordance with an example embodiment of the present disclosure. For example, the source and target nodes may be a gNB and / or components of a gNB, e.g., a CU and / or a DU.

[0098] This procedure requires two different measurement thresholds: a low threshold and a high threshold. The two thresholds can be expressed as different levels of a particular metric, e.g., signal strength, signal quality, etc. For example, the high threshold can be that the quality of the mobility RS (MRS) of the target cell or beam is X dB stronger than the MRS of the UE's serving cell (e.g., provided by the source node), and the low threshold is less than the high threshold (i.e., the target exceeds the source by a low amount). As used within this context, MRS refers to a reference signal used for any mobility-related purpose. For example, in NR, the MRS can be either the SSB (SS / PBCH block) or the CSI-RS. As a further example, for NR operating in an unlicensed spectrum (referred to as NR-U), the MRS can be a discovery reference signal (DRS) in addition to any of the signals mentioned above.

[0099] The UE may be provided with a measurement configuration including a low threshold (not shown). Upon performing measurements that satisfy the low threshold, the UE may send a measurement report to the serving node (operation 1). The UE continues to operate within its current RRC configuration while performing measurements and evaluating the low threshold. In operation 2, based on this report, the source node may decide to request an early handover of the UE to the target node (e.g., to a cell indicated in the measurement report). For example, this early handover request may include a HandoverPreparationInformation IE as described above.

[0100] The target node performs admission control of the UE, similar to the basic handover shown in Figure 5, and responds with a handover acknowledgement that includes the RRC configuration (operation 3). In operation 4, the source node then sends a "conditional HO command" to the UE, which may include a high threshold. Upon receiving this command, the UE continues performing measurements, and whenever the high threshold condition is met, the UE can move to the target node and perform the handover (e.g., operations 5-7). The UE can still remain in the serving cell (i.e., served by the source node) for an extended time if the high threshold condition is not met.

[0101] This allows the serving cell to prepare for handover upon receiving an early measurement report and to provide a conditional HO command (e.g., RRCConnectionReconfiguration with mobilityControlInfo in case of LTE, or RRCReconfiguration with reconfigurationWithSync or cellGroupConfig in case of NR) at a time when the radio link between the source cell and the UE is still relatively stable. The UE performs the handover at an optimal and / or preferred subsequent time point (and threshold).

[0102] While Figure 8 shows an example conditional handover with a single serving cell and a single target cell, other scenarios may involve multiple cells or beams that the UE has reported as possible candidates based on its Radio Resource Management (RRM) measurements. The network should have the freedom to issue a conditional handover command for any of those candidates. The conditional HO commands for each of those candidates may differ in terms of the HO execution conditions (e.g., reference signals (RS) to measure, thresholds to exceed, etc.) and / or in terms of the RA preamble to be transmitted when the conditions are met.

[0103] Each RRCConnectionReconfiguration / RRCReconfiguration message is typically a "delta" with respect to the UE's current configuration. LTE UEs apply RRCConnectionReconfiguration messages in the order they are received. When the UE receives a "conditional HO command", it should interpret the corresponding RRC signaling as a delta to its current configuration (unless it is a full configuration message). It can in principle determine the target configuration immediately upon receiving the command, but it should apply / execute it only if the relevant conditions are met. While the UE evaluates the status, it should continue to operate according to its current RRC configuration without applying the conditional HO command. When the UE determines that the conditions are met, it disconnects from the serving cell, applies the conditional HO command and connects to the target cell.

[0104] In other words, the UE is configured with at least one measurement-related condition associated with a mobility command or action (e.g., an RRCReconfiguration or RRCConnectionReconfiguration message), and the UE will apply the mobility command and perform the specified action when it triggers the condition. However, there are some problems with this configuration process.

[0105] First, there may be a conflict between measurements that the UE has already been configured to perform (e.g., when receiving an earlier message containing measConfig) and measurements related to the conditions of the conditional mobility command. In other words, it is unclear whether measurements that need to be performed to monitor the relevant conditions are properly configured. For example, certain parameters may be missing.

[0106] Second, the conditional mobility command may need to include a large amount of configuration information for the UE that may need to be transmitted in poor radio conditions. The combination of large messages and poor radio conditions increases the likelihood that the command will be delayed, resulting in RLF for the UE.

[0107] FIG. 9, including FIGS. 9A-9C, illustrates three different techniques for configuring a UE with conditional mobility (e.g., CHO) trigger conditions that at least partially address some of these issues. FIG. 9A illustrates signaling for a technique in which the UE receives a conditional mobility configuration (e.g., RRCConditionalReconfiguration) from the network (e.g., gNB) that includes at least one trigger condition for a mobility procedure (e.g., handover). The trigger condition may include at least one reference, or identifier, of a measurement configuration (e.g., “identifier X” in FIG. 9A). * After receiving the trigger condition including the identifiers, the UE determines whether measurements related to the identifiers need to be initiated or whether they have already been performed by the UE.

[0108] FIG. 9B shows a variation of the technique shown in FIG. 9A. In this variation, the provided identifier X * refers to measurement configurations already stored in the UE, possibly received in messages processed before the message containing the conditional mobility configuration. Therefore, the conditional mobility configuration message does not need to contain the detailed measurement configuration, only an identifier to the earlier received configuration. After receiving the identifier, the UE can match it with the stored configuration and start measurements based on the matching configuration.

[0109] 9C shows another variation of the technique shown in FIG. 9A. In this variation, the provided identifier refers to a measurement configuration that is also provided in the conditional mobility configuration. In other words, the message contains the measurement configuration (labeled measConfig) and the identifier X *In this variant, the measurement configuration may be explicitly provided for the purpose of conditional mobility (e.g., conditional resumption / re-establishment / handover). After receiving the message, the UE may also store the provided configuration and start measurements based on it.

[0110] While the techniques illustrated by Figure 9 address measurements to detect pre-mobility trigger conditions, they do not address measurements that must result in the execution of the mobility procedure itself (e.g., in handover) after the trigger condition is detected. For example, for each target cell candidate for handover after the trigger condition is met, the CHO configuration may include the following information: ● Trigger condition settings (including measurement settings) and ● RRCReconfiguration with reconfigurationWithSync (or equivalent parameters / fields / IEs as specified for these messages used for handover / reconfiguration).

[0111] Figure 10 shows three different UE measurement configurations - measConfig, measConfig', and measConfig * 1 illustrates a signaling flow of an example conditional mobility (e.g., CHO) technique with - Each RRCReconfiguration may indicate its own measurement configuration (e.g., measConfig ) that may be indicated by delta signaling relative to the current UE measurement configuration, e.g., measConfig used by the UE 1010 (hereinafter referred to as "UE") before the conditional mobility operation is configured. * In other words, the measConfig generated by each target node in RRCReconfiguration may include * is what the target node expects the UE to use in the target cell after performing the mobility operation.

[0112] As shown in FIG. 10, initially, the UE operates in RRC_CONNECTED state with a stored measurement configuration, measConfig. A source node 1020 (e.g., gNB, hereafter referred to as “source node”) serving the UE’s current source cell is also aware of the measConfig. The source node then decides to configure the UE’s CHO to a particular target cell served by a target node 1030 (e.g., gNB, hereafter referred to as “target node”). For example, this decision may be based on a measurement report from the UE. Similar to the configuration shown in FIG. 8, the source node and the target node exchange messages, and the target node determines the measConfig to be used by the UE in the target cell after CHO is performed. * to provide.

[0113] On the other hand, as explained above, the source node may need to reconfigure the current UE measurement configuration measConfig for detection of a trigger condition prior to the mobility operation. This also applies to the measConfig * This can be done by delta signaling of measConfig′, which can be different from measConfig and measConfig * may include new events, new thresholds, new carriers, etc. that are different from both the original and new thresholds.

[0114] Once configured in this manner, the UE starts monitoring the CHO trigger conditions using measConfig'. If the CHO conditions are met, the UE will use the measConfig' prepared by the target cell where the UE is performing the procedure. * In the case of delta signaling, since the UE most recently used measConfig' to detect the CHO trigger condition, the UE uses the delta signaled measConfig *However, the target node will apply measConfig' based on the UE's initial measConfig before receiving the CHO command. * was previously determined. In practice, the target node * When preparing, I am not aware of measConfig'.

[0115] It creates a state mismatch where the UE and the network assume different configurations for determining what type of measurements the UE should perform in the target cell, which can lead to various problems, e.g., the UE performing unnecessary measurements (which consumes the UE battery), not performing certain measurements determined by the particular target for which the CHO was performed, reporting measurements using some measurement IDs that are not known to the target node, etc.

[0116] Exemplary embodiments of the present disclosure address these and other issues, challenges, and / or problems by providing certain enhancements and / or improvements to mobility robustness in wireless networks. In general, the embodiments include techniques and / or mechanisms for configuring a UE with various measurement configurations in a manner that avoids confusion regarding which stored measurement configuration the UE should use after performing a conditional mobility operation (e.g., CHO). Using these embodiments, both the UE and the target node of the mobility operation have a consistent understanding of which measurements the UE will perform and / or report after performing a mobility operation towards the target node (e.g., to a target cell served by the target node).

[0117] According to various embodiments, the UE can precisely manage the measurement configurations for CHO triggering and CHO execution. In various embodiments, the UE can distinguish between three types of measurement configurations: A first measurement configuration used in the source cell, for example prior to a CHO command; A second measurement setup, also used in the source cell, but related to monitoring the CHO trigger condition; and • A third measurement configuration that is prepared for each CHO target candidate and should be applied only when performing CHO on that selected candidate.

[0118] When CHO is performed, the UE removes the second measurement configuration and applies the third measurement configuration. In case of a complete third configuration (e.g., not delta signaled), the UE may also remove the first configuration. In case of a delta signaled third configuration, the UE applies the third configuration to the second configuration. In some embodiments, the UE always has a single measurement configuration, and the network ensures that the UE is configured with accurate measurements at any time.

[0119] In the following description of the exemplary embodiments, the terms "handover" and "reconfiguration with synchronization" are used synonymously. Therefore, a conditional handover may also be referred to as a conditional reconfiguration with synchronization. In NR terminology, a handover command is typically an RRCReconfiguration message with a reconfigurationWithSync field that contains the configuration required to perform the handover. In LTE terminology, a handover command is typically an RRCConnectionReconfiguration message with a mobilityControlInfo field that contains the configuration required to perform the handover.

[0120] UE and network actions are primarily described herein using NR terminology with CHO performed in NR, e.g., CHO configuration received in NR for an NR cell. However, example embodiments are also applicable to non-NR scenarios, e.g., The UE is configured with conditional HO in NR (for candidate NR and LTE cells), then a condition is triggered for the NR cell and the UE performs HO in NR; The UE is configured with conditional HO in LTE (for candidate NR and LTE cells), then a condition is triggered for the LTE cell and the UE performs HO in LTE; The UE is configured with conditional HO in NR (for candidate NR and LTE cells), then a condition is triggered for the LTE cell and the UE performs HO in LTE; The UE is configured with conditional HO in LTE (for candidate NR and LTE cells), then a condition is triggered for the NR cell and the UE performs HO in NR; ● More generally, the UE is configured with a condition HO in RAT-1 of a cell in RAT-1 or RAT-2, then a condition is triggered and the UE performs HO in RAT-2.

[0121] Generally, the exemplary embodiments are described with respect to a conditional handover, but this is intended as an illustration and not a limitation. The embodiments are also applicable for handovers triggered by the reception of an RRCReconfiguration message with reconfigurationWithSync (or an RRCConnectionReconfiguration message with mobilityControlInfo) without an associated condition. In other words, while the UE is monitoring the CHO conditions and it has received a second measurement configuration, the UE may receive an RRCReconfiguration with reconfigurationWithSync indicating that the UE should stop monitoring the CHO conditions and perform a handover to the indicated target cell. Then, upon performing the handover to the indicated target cell, the UE may store the second measurement configuration. Thus, the actions described in this invention, e.g. deleting / releasing this second measurement configuration, are still applicable.

[0122] The exemplary embodiments are also applicable to the stored configuration during recovery, e.g. due to radio link or handover failure. In such a case, the invention also covers the case where the UE deletes / releases the second measurement configuration. The exemplary embodiments are also applicable to the suspension or release cases where the UE goes to RRC_INACTIVE or RRC_IDLE, respectively. In that case, the second measurement configuration, related to the CHO, is also deleted / released.

[0123] In general, the term "conditional handover" (or CHO) is used in the context of the described embodiments to generally refer to conditional mobility, including conditional resumption, conditional reconfiguration with synchronization, conditional reconfiguration, beam switching / recovery, as well as conditional handover. As such, CHO should be interpreted as any procedure configured by the network that includes a condition (e.g., related to a measurement event) and a mobility-related action or procedure that is executed upon triggering that condition.

[0124] For example, the resumption procedure described above with respect to FIG. 4 can also be applied to a conditional mobility solution called "conditional resume", which has similar characteristics to the conditional HO shown in FIG. 8. More specifically, the UE may be provided with a low threshold "Y" for triggering measurement reporting while in RRC_INACTIVE state, and in response to the reported measurements, the serving node can provide the UE with a "conditional resume" command including a high threshold "X" for triggering resumption towards the target cell provided by the target node. Unlike conditional HO, conditional resume relies on a context fetch by the target node. Nevertheless, embodiments of the measurement configuration techniques for conditional HO described herein are equally applicable to the conditional resume operation and can provide similar advantages to the conditional resume operation.

[0125] In general, the following description uses the term "conditional resume" to refer to a condition that is associated with any of the following triggers: a resume-like procedure (e.g. the UE sends an RRCResumeRequest like message containing a UE AS context identifier assigned by the source node, such as an I-RNTI, or a security token, such as a source C-NRTI+source physical cell identifier and a short MAC-I / restart MAC-I), or ● A re-establishment procedure (e.g. a radio link re-establishment procedure, where the UE sends an RRCReestablishmentRequest like message including a UE AS context identifier assigned by the source, such as an I-RNTI, or a security token such as a source C-NRTI+source physical cell identifier and a short MAC-I / restart MAC-I).

[0126] The exemplary embodiments are also applicable to conditional mobility configurations related to a single cell or multiple cells. In the case of a single cell, a single measurement configuration reference may be provided and linked / associated with the mobility procedure, such that the UE monitors a specific condition and when it is met, the UE performs a specific procedure towards a specific node, e.g., a specific target cell. In the case of multiple cells, a single measurement configuration reference may be provided and linked to the monitoring of multiple cells within the same measurement object / frequency, etc. Alternatively, multiple measurement configuration references may be provided that refer to or link to different cells.

[0127] As an example, for a cell to be monitored for conditional handover, the UE may be configured with RRCReconfiguration with reconfigurationWithSync (for NR) or RRCConnectionReconfiguration with mobilityControlInfo (for LTE), e.g., associated with the cell to be accessed when the condition is triggered.

[0128] As another example, for cells to be monitored for conditional resumption, the UE may be configured with at least one I-RNTI (for NR) or Resumption ID (for LTE) (or another UE identifier) ​​to be included in the RRCResumeRequest (for NR) or RRCConnectionResume-Request (for LTE) (or similar message). Alternatively, this may be the source C-RNTI+PCI, as in the re-establishment request. For NR, the source node may provide a short or long I-RNTI depending on how each potential target accepts long or short I-RNTIs depending on the coverage. The source may provide both the (short and long) I-RNTI and the condition for each cell, so that depending on which cell triggers the condition, the UE includes a message such as the RRCResumeRequest, a short or long I-RNTI.

[0129] The UE may also be configured with an RRCReconfiguration with reconfiguration-WithSync (for NR) or an RRCConnectionReconfiguration with mobility ControlInfo (for LTE) that includes some information of the target cell but not the complete configuration, as well as a UE identifier, e.g., I-RNTI or resumption ID. The target cell information may include information that is normally transmitted in the system information, e.g., RACH information for faster access in the target cell. This information may also be included in parts of the reconfiguration message other than the reconfigurationWithSync or mobility ControlInfo. Exemplary embodiments may also include monitoring a conditional mobility triggering condition upon receiving the configuration, and selecting a conditional handover or conditional resumption towards cell X based on a second condition upon triggering the condition for a particular cell X.

[0130] The following description of exemplary embodiments refers to actions when performing CHO or (non-conditional) HO. For example, 3GPP specifications may prescribe one set of actions that are the same for both CHO and HO. The distinguishing feature may be that CHO is a HO triggered by the fulfillment of a condition, and non-conditional HO is triggered by the reception of an RRCReconfiguration with reconfigurationWithSync. Thus, the embodiments are also applicable in cases where a new procedure called CHO is created or where a legacy non-conditional HO procedure is triggered by the fulfillment of a condition.

[0131] 11 illustrates a signaling flow of an improved technique for providing a UE with measurement configurations to be used during the monitoring and execution phase of conditional mobility (e.g., CHO) operations, according to various exemplary embodiments of the present disclosure. Although the exemplary technique is illustrated in FIG. 11 with certain operations in a particular order, the illustrated operations may be performed in an order different from that illustrated, and may be combined and / or divided into operations having different functionality than that illustrated. Additionally, the exemplary technique illustrated in FIG. 11 may complement other exemplary techniques, methods, and / or procedures disclosed herein, such that they may be used in concert to provide benefits, advantages, and / or solutions to various problems, including those described herein.

[0132] Figure 11 is in many ways similar to the signaling flow shown in Figure 10 and described above. Therefore, the same reference numbers are used and only the main differences are described below. Initially, the UE is configured with a measConfig (e.g. via RRCResume from the source node) which it stores (e.g. in VarMeasConfig) and which it can use to perform various measurements. The UE can report measurements made based on the measConfig to the source node.

[0133] The source node then determines that a conditional mobility operation (e.g., CHO) is required for the UE. The source node sends a request to each of one or more target node candidates to accept the conditional mobility operation for the UE. The request may include the UE's current measConfig. A single target node candidate is shown in FIG. 11 for the sake of brevity and clarity. The target node responds with a confirmation or acknowledgement of the requested operation for the UE. The response includes the measConfig that the target node has determined is required during the mobility operation, i.e., after the UE detects a condition that triggers the mobility operation. * The configuration measConfig * can be a complete setting or a delta setting with respect to measConfig. For example, delta measConfig * may be prepared based on the various required codes and AddMod list rules and / or procedures described above.

[0134] The source node then determines that measConfig' is required so that the UE can detect and / or monitor conditions that trigger mobility operations. For example, a delta measConfig' may be prepared based on the various required codes and AddMod list rules and / or procedures described above. The source node may also store measConfig'. In the embodiment shown in FIG. 11, the source node stores measConfig'. * The source node determines measConfig' after receiving measConfig' from the target node. In other embodiments, the source node may determine measConfig' (e.g., as a delta to measConfig) before sending the request to the target node. In such a case, the request to the target node may also include measConfig', and the target node may receive measConfig' and measConfig' as a delta to measConfig. * can be determined.

[0135] The source node then receives a first indication of a mobility operation to be performed, a second indication of a trigger condition, a measConfig' related to detecting the trigger condition, and a measConfig' related to performing the mobility operation with the target node. * to the UE. Upon receiving this command, the UE stores the measConfig' separately from the previously received measConfig. In other words, the UE retains the measConfig rather than simply updating it with the delta in the measConfig' as is done in the conventional manner. For example, the measConfig' may be stored in a different VarMeasConfig' or VarMeasConfigCHO. Alternatively, the measConfig' may be stored in the same VarMeasConfig used in a different field that may be distinguished as being associated with conditional mobility (e.g., CHO). The UE also uses the measConfig' to start performing measurements to detect the indicated trigger condition.

[0136] There may be cases where measConfig' and measConfig overlap. For example, both measConfig' and measConfig may indicate that the UE should perform measurements on a given carrier, e.g., f0. In some embodiments, measConfig' may point to measConfig, i.e., it need not contain a completely separate configuration. Also, since measConfig is already stored, it does not need to be stored twice unless there is some difference in the configuration (e.g., same carrier but different cell quality derived parameters, etc.). In some embodiments, measConfig' is flagged with an indication of whether it should be released when CHO is performed. It may be indicated for the entire configuration or parts of it. For example, each field in the configuration may have a flag indicating whether it should be released when CHO is performed.

[0137] The UE also * measConfig' is used instead. * It should be noted that the conditional mobility configuration may include measurement configurations of one or more candidate target cells (e.g., neighboring cells served by one or more other network nodes) served by one or more target nodes. The measurement configurations of each target cell may differ in various ways. Since the UE does not know (before trigger detection) the target cell for which it will perform the conditional mobility operation, the UE must store each of these configurations.

[0138] In some embodiments, the measConfig * can be identified by the fact that it is provided in a different field / parameter / IE / etc., or by the fact that it is carried in a different message compared to the message that provides the measConfig. For example, * may be provided in a message such as RRCReconfiguration prepared by a neighboring cell that is a target candidate.

[0139] The UE shall also receive a measConfig separately from any previously received measConfig. * In other words, the UE stores the measConfig * Preserve the measConfig instead of just updating it with deltas in * Different VarMeasConfig * Alternatively, it can be stored in measConfig *may be used but stored in the same VarMeasConfig with different fields, so that it can be distinguished as being associated with conditional mobility (e.g., CHO).

[0140] When the UE detects a trigger condition, the UE performs a mobility operation as instructed by the conditional mobility command. When performing the mobility operation, the UE stops performing measurements in the source cell using measConfig' and stores the stored VarMeasConfig in measConfig. * In some embodiments, the UE deletes and / or clears the stored measConfig'. In other embodiments, the UE updates the measConfig' (either as a delta to the measConfig / measConfig' or as a complete configuration). * If RRCReconfiguration-Complete is calculated by the target node as measConfig' and a delta to measConfig, the UE retains measConfig' since it forms part of the new measurement configuration. The UE also accesses the target cell (e.g., with an RRCReconfiguration-Complete message) and returns measConfig * The target node (i.e., serving the target cell) starts performing and reporting measurements in the target cell based on the measConfig * , the target node is fully aware of the measurements being reported by the UE while performing the mobility operation, so that mismatches are avoided.

[0141] In some embodiments, the target node may send a message (e.g., UE ContextRelease) to the source node indicating that a conditional mobility operation has been performed. In response to this indication, the source node may delete and / or release any stored measurement configurations, e.g., measConfig and measConfig', associated with the UE at the source cell.

[0142] 12 illustrates a signaling flow of another improved technique for providing a UE with measurement configurations to be used during a monitoring and execution phase of a conditional mobility (e.g., CHO) operation, according to various exemplary embodiments of the present disclosure. Although the exemplary technique is illustrated in FIG. 12 with certain operations in a particular order, the illustrated operations may be performed in an order different from that illustrated, and may be combined and / or split into operations having different functionality than that illustrated. Additionally, the exemplary technique illustrated in FIG. 12 may complement other exemplary techniques, methods, and / or procedures disclosed herein, such that they may be used in concert to provide benefits, advantages, and / or solutions to various problems, including those described herein.

[0143] Figure 12 is in many respects similar to the signalling flows shown in Figures 10-11 and described above. Therefore, the same reference numbers are used and only the main differences are described below. One notable difference with Figure 11 is that the UE simply stores the current measurement configuration and the network ensures that there is no mismatch between the UE's stored measurement configuration and the UE's network's stored measurement configuration.

[0144] measConfig * After receiving the target node response including the measConfig', the source node then determines the required measConfig' so that the UE can detect and / or monitor the conditions that trigger the mobility operation. The source node transmits a conditional mobility command to the UE, including a first indication of the mobility operation to be performed, a second indication of the trigger condition, and the measConfig' related to the detection of the trigger condition. However, the source node does not need to determine the measConfig' (determined by the target node) related to the execution of the mobility operation with the target node. * to the UE.

[0145] In some embodiments, the conditional mobility command may include an empty measConfig to be used when performing measurements in the target cell after detection of a triggering condition. In such a case, the UE may infer from this empty configuration that measConfig' should be used to perform measurements in the target cell after detection of a triggering condition. In such a case, the source node may also inform all candidate target nodes of measConfig' that the source node is configured for such UE measurements.

[0146] Upon receiving this command, the UE stores measConfig' separately from the previously received measConfig. In other words, the UE retains the measConfig rather than simply updating it with the delta in measConfig' as is done in the conventional manner. For example, measConfig' may be stored in a different VarMeasConfig' or VarMeasConfigCHO. Alternatively, measConfig' may be stored in the same VarMeasConfig used but with different fields, so that it can be distinguished as being associated with conditional mobility (e.g., CHO). The UE also uses measConfig' to start performing measurements to detect the indicated trigger conditions.

[0147] When the UE detects a triggering condition, the UE performs the mobility operation as instructed by the conditional mobility command. When performing the mobility operation, the UE stops performing measurements in the source cell using measConfig', accesses the target cell (e.g., includes an RRCReconfiguration-Complete message), and starts performing and reporting measurements in the target cell based on measConfig'. Since the target node (i.e., serving the target cell) received measConfig', the target node is fully aware of the measurements being reported by the UE during the mobility operation, so that mismatches are avoided. However, the target node may also determine that a reconfiguration is required for the UE measurements in the target cell. In such a case, the target node may determine that a reconfiguration is required for the UE measurements in the target cell using measConfig'. * Alternatively, the target node may transmit a reconfiguration message to the UE including measConfig based on determining that such a different configuration would be desirable and / or beneficial in some manner. * A different configuration (for example, measConfig ** ) can be sent.

[0148] In the embodiment illustrated by FIG. 12, the settings measConfig, measConfig′, measConfig * , and measConfig * may be communicated as a delta or full configuration in the same various ways as described above with respect to FIG.

[0149] The above-described embodiments may be further illustrated with reference to Figures 13-15, which depict example methods (e.g., procedures) performed by a UE, a source RAN node, and a target RAN node, respectively. In other words, various features of the operations described below with reference to Figures 13-15 correspond to the various embodiments described above.

[0150] In particular, Figure 13 illustrates an example method (e.g., procedure) for conditional mobility in a RAN, according to various example embodiments of the present disclosure. The example method may be performed by a user equipment (e.g., a UE, a radio device, an MTC device, an NB-IoT device, a modem, etc., or a component thereof) in communication with a network node (e.g., a base station, an eNB, a gNB, etc., or a component thereof) serving a cell in a RAN (e.g., E-UTRAN, NG-RAN). For example, the example method illustrated in Figure 13 may be implemented in a UE or device configured according to other figures described herein.

[0151] Although the example method is illustrated in FIG. 13 by certain blocks in a particular order, the operations corresponding to the blocks may be performed in an order different from that illustrated, and may be combined and / or divided into blocks having different functionality than that illustrated. Additionally, the example method illustrated in FIG. 13 may complement other example methodologies disclosed herein (e.g., FIGS. 14-15), such that they may be used in concert to provide various benefits, advantages, and / or solutions to problems, including those described herein. Optional blocks and / or operations are indicated by dashed lines.

[0152] In some embodiments, the example method may include operations of blocks 1310-1330. At block 1310, the UE may receive a first measurement configuration (e.g., measConfig) from a source RAN node serving a source cell of the UE. At block 1320, the UE may store the received first measurement configuration (e.g., in varMeasConfig). At block 1330, the UE may perform and report a first measurement at the source cell of the UE based on the first measurement configuration. These operations may be performed, for example, prior to the operation of block 1340, described below.

[0153] The example method may also include the operation of block 1340, where the UE may receive one or more mobility-related messages from one or more RAN nodes that include: a first indication of a mobility operation (e.g., any of the mobility operations described above), a second indication of a trigger condition for the mobility operation, a second measurement configuration for the source cell, and a third measurement configuration for one or more target cells. For example, the second measurement configuration (e.g., measConfig') may be usable to detect achievement of a trigger condition at the source cell, and the third measurement configuration (e.g., measConfig') may be usable to detect achievement of a trigger condition at the source cell, and the third measurement configuration (e.g., measConfig') may be usable to detect achievement of a trigger condition at the source cell. * ) may be used in one of the target cells after performing the mobility operation.

[0154] In some embodiments, the operations of block 1340 may include operations of sub-block 1341, in which the UE may store at least a portion of the second and third measurement configurations separately from the first measurement configuration (e.g., varMeasConfig, varMeasConfig', varMeasConfig * , and / or varMeasConfigCHO).

[0155] In some embodiments, the one or more mobility-related messages may include a conditional mobility command received from a source RAN node. The conditional mobility command may include a first and second indication and a second and third measurement configuration. In addition, the second and third measurement configurations may include a respective measurement configuration for each target cell that is a candidate for the indicated mobility operation. In other words, each of the second and third measurement configurations may include multiple measurement configurations, i.e., one for each candidate target cell.

[0156] In other embodiments, the one or more mobility related messages may include two messages: a conditional mobility command received from the source RAN node, the conditional mobility command including the first and second instructions and the second measurement configuration, and a reconfiguration message received from a target RAN node serving the target cell, the reconfiguration message including the third measurement configuration.

[0157] The example method may also include operations of blocks 1350-1360, in which the UE may detect achievement of a trigger condition for a particular one of the target cells based on the second measurement configuration and perform a mobility operation toward the particular target cell.

[0158] In some embodiments, detecting achievement of a trigger condition in block 1350 may include operations of sub-block 1351, where the UE may perform a second measurement at the source cell based on the second measurement configuration. In some embodiments, performing a mobility operation in block 1360 may include operations of one or more of sub-blocks 1361-1363. In sub-block 1361, the UE may stop performing the second measurement based on the second measurement configuration. In sub-block 1362, the UE may delete or release at least a portion of the stored second measurement configuration. In sub-block 1363, the UE may store a third measurement configuration.

[0159] In some embodiments, the third measurement configuration may be received as a complete measurement configuration, in which performing the mobility operation in block 1360 may include operations of sub-block 1364, in which the UE may replace the stored first measurement configuration with the third measurement configuration.

[0160] In other embodiments, the third measurement configuration may be received as a delta with respect to one or more of the first measurement configuration and the second measurement configuration. In such embodiments, performing the mobility operation in block 1360 may include operations of sub-block 1365, where the UE may determine a measurement configuration for the third measurement based on the third measurement configuration and one or more of the first measurement configuration and the second measurement configuration.

[0161] In some embodiments, performing mobility operations in block 1360 may include operations of sub-blocks 1366-1367, for example when the one or more mobility related messages include a conditional mobility command and a reconfiguration message (described above). In sub-block 1366, the UE may perform and report a third measurement at the particular target cell based on a second measurement configuration (e.g., received in the conditional mobility command). In sub-block 1367, the UE may then receive a reconfiguration message including the third measurement configuration.

[0162] The example method may also include the operation of block 1370, where the UE may subsequently perform and report a third measurement on the particular target cell based on the third measurement configuration.

[0163] In addition, Figure 14 illustrates another example method (e.g., procedure) for conditional mobility of a user equipment (UE) in a radio access network (RAN) according to various example embodiments of the present disclosure. The example method may be performed by a source RAN node (e.g., a base station, eNB, gNB, etc., or a component thereof) serving one or more user equipment (UE, e.g., a radio device, an MTC device, an NB-IoT device, a modem, etc., or a component thereof) in a cell of the RAN (e.g., E-UTRAN, NG-RAN). For example, the example method illustrated in Figure 14 may be implemented by a network node configured according to other figures described herein.

[0164] Although the example method is illustrated in Figure 14 by certain blocks in a particular order, the operations corresponding to the blocks may be performed in an order different from that illustrated, and may be combined and / or divided into blocks having different functionality than that illustrated. Additionally, the example method illustrated in Figure 14 may complement other example methodologies disclosed herein (e.g., Figures 13 and 15), such that they may be used in concert to provide various benefits, advantages, and / or solutions to problems, including those described herein. Optional blocks and / or operations are illustrated with dashed lines.

[0165] In some embodiments, the example method may include operations of blocks 1410-1430. At block 1410, the source RAN node may send to the UE a first measurement configuration (e.g., measConfig) related to a source cell of the UE served by the source RAN node. In some embodiments, the operations of block 1410 may include operations of sub-block 1412, where the source RAN node may store the first measurement configuration (e.g., in varMeasConfig). At block 1420, the source RAN node may receive a first measurement made by the UE at the source cell based on the first measurement configuration. At block 1430, the source RAN node may determine that a mobility operation is required for the UE based on the first measurement.

[0166] The example method may also include the operation of block 1440, where the source RAN node may send a request to the target RAN node to accept a mobility operation (e.g., CHO) for the UE. In some embodiments, the request may include a first measurement configuration (e.g., measConfig) for the UE. The mobility operation may be the mobility operation determined to be necessary in block 1430. The example method may also include the operation of block 145 ... * ) may be received from the target RAN node.

[0167] The example method may also include operations of block 1460, where the source RAN node may determine a second measurement configuration (e.g., measConfig') related to a trigger condition of the mobility operation. For example, the second measurement configuration may be usable to detect achievement of the trigger condition in the source cell. In some embodiments, the operations of block 1460 may include operations of sub-block 1462, where the source RAN node may store the second measurement configuration (e.g., in varMeasConfig' or varMeasConfigCHO). In some embodiments, the operations of block 1460 may include operations of sub-block 1464, where the source RAN node may transmit the second measurement configuration to the target RAN node.

[0168] The example method may also include the operation of block 1470, where the source RAN node may transmit a mobility-related message to the UE that includes: a first indication of a mobility operation (e.g., any of the mobility operations described above), a second indication of a trigger condition for the mobility operation, and a second measurement configuration (e.g., measConfig'). In some embodiments, the mobility-related message may also include a third measurement configuration (e.g., measConfig'). * In addition, the second and third measurement configurations may include a respective measurement configuration for each target cell that is a candidate for the indicated mobility operation. In other words, each of the second and third measurement configurations may include multiple measurement configurations, i.e., one for each candidate target cell.

[0169] In some embodiments, the example method may also include operations of blocks 1480-1490. At block 1480, the source RAN node may receive a third indication from the target RAN node that the mobility operation is complete. At block 1490, the source RAN node may delete or release at least a portion of the stored first and second measurement configurations in response to the third indication.

[0170] In some embodiments, at least one of the following conditions applies: the second measurement configuration is determined as a delta with respect to the first measurement configuration, the third measurement configuration is received as a delta with respect to the first measurement configuration, and the third measurement configuration is received as a delta with respect to the first and second measurement configurations.

[0171] In addition, Figure 15 illustrates another example method (e.g., procedure) for conditional mobility of a user equipment (UE) in a radio access network (RAN) according to various example embodiments of the present disclosure. The example method may be performed by a target RAN node (e.g., base station, eNB, gNB, etc., or components thereof) serving a target cell in a RAN (e.g., E-UTRAN, NG-RAN) (UE, e.g., radio device, MTC device, NB-IoT device, modem, etc., or components thereof). For example, the example method illustrated in Figure 15 may be implemented by a network node configured according to other figures described herein.

[0172] Although the example method is illustrated in FIG. 15 with certain blocks in a particular order, the operations corresponding to the blocks may be performed in an order different from that illustrated, and may be combined and / or divided into blocks having different functionality than that illustrated. Additionally, the example method illustrated in FIG. 15 may complement other example methodologies disclosed herein (e.g., FIGS. 13-14), such that they may be used in concert to provide various benefits, advantages, and / or solutions to problems, including those described herein. Optional blocks and / or operations are illustrated with dashed lines.

[0173] The example method may include operations of block 1510, where the target RAN node may receive from the source RAN node a request to accept a mobility operation (e.g., CHO) for the UE. The request may include a first measurement configuration (e.g., measConfig) for the UE. The example method may also include operations of block 1520, where the target RAN node may receive from the source RAN node a request to accept a mobility operation (e.g., CHO) for the UE. The request may include a first measurement configuration (e.g., measConfig) for the UE in association with one or more target cells served by the target RAN node. * ) may be determined. The third measurement configuration may be based on (eg, a delta with respect to) the first measurement configuration.

[0174] The example method may also include the operation of block 1530, where the target RAN node may send a confirmation of the mobility operation to the source RAN node, including the third measurement configuration. In various embodiments, the third measurement configuration may be sent as a complete measurement configuration or as a delta with respect to the first measurement configuration and / or the second measurement configuration. The example method may also include the operation of block 1570, where the target RAN node may receive, from the UE, measurements made in a particular one of the target cells based on the third measurement configuration.

[0175] In some embodiments, the example method may also include operations of blocks 1550-1560. At block 1550, the target RAN node may receive measurements made by the UE with respect to the particular target cell based on the second measurement configuration. At block 1560, the target RAN node may then transmit a reconfiguration message to the UE that includes a third measurement configuration.

[0176] In these embodiments, the example method may also include the operation of block 1540, where the target RAN node may receive a second measurement configuration for the UE from the source RAN node. The second measurement configuration (e.g., measConfig') may be received as a delta with respect to the first measurement configuration (e.g., measConfig). In such embodiments, the third measurement configuration included in the reconfiguration message is a delta with respect to the first and second measurement configurations.

[0177] In some embodiments, the example method may also include the operation of block 1580, in which the target RAN node may send an indication to the source RAN node that the mobility operation is complete.

[0178] Although the subject matter described herein may be implemented in any suitable type of system using any suitable components, the embodiments disclosed herein are described with respect to a wireless network, such as the exemplary wireless network illustrated in FIG. 16. For simplicity, the wireless network of FIG. 16 depicts only the network 1606, the network nodes 1660 and 1660b, and the WDs 1610, 1610b, and 1610c. In practice, the wireless network may further include any additional elements suitable for supporting communication between wireless devices, or between a wireless device and another communication device, such as a landline, a service provider, or any other network node or end device. Of the depicted components, the network node 1660 and the wireless device (WD) 1610 are depicted with additional details. The wireless network may provide communication and other types of services to one or more wireless devices to facilitate the wireless device's access to the wireless network and / or use of services provided by or via the wireless network.

[0179] The wireless network may comprise and / or interface with any type of communication, telecommunications, data, cellular, and / or radio network, or other similar type of system. In some embodiments, the wireless network may be configured to operate according to a particular standard or other type of predefined rules or procedures. Thus, certain embodiments of the wireless network may implement communication standards such as Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Long-Term Evolution (LTE), 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 Worldwide Interoperability for Microwave Access (WiMAX), Bluetooth, Z-Wave, and / or ZigBee standards.

[0180] The network 1606 may comprise one or more backhaul networks, core networks, IP networks, public switched telephone networks (PSTN), packet data networks, optical networks, wide area networks (WANs), local area networks (LANs), wireless local area networks (WLANs), wired networks, wireless networks, metropolitan area networks, and other networks to enable communication between devices.

[0181] The network node 1660 and the WD 1610 comprise various components, which are described in more detail below. These components cooperate to provide the functionality of a network node and / or a wireless device, such as providing wireless connectivity in a wireless network. In different embodiments, a wireless network can comprise any number of wired or wireless networks, network nodes, base stations, controllers, wireless devices, relay stations, and / or any other components or systems that can facilitate or participate in the communication of data and / or signals, whether via a wired or wireless connection.

[0182] Examples of network nodes include, but are not limited to, access points (APs) (e.g., wireless access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs), and NR Node Bs (gNBs)). Base stations may be classified based on the amount of coverage they provide (or, in other words, their transmit power level), and may then be referred to as femto, pico, micro, or macro base stations. A base station may be a relay node or a relay donor node, which controls a relay. A network node may also include one or more (or all) parts of a distributed radio base station, such as a centralized digital unit and / or a remote radio unit (RRU), which may also be referred to as a remote radio head (RRH). Such remote radio units may or may not be integrated with an antenna as an antenna-integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS).

[0183] Further examples of network nodes include MSR equipment such as a multi-standard radio (MSR) BS, a network controller such as a radio network controller (RNC) or a base station controller (BSC), a base transceiver station (BTS), a transmission point, a transmitting node, a multi-cell / multicast coordination entity (MCE), a core network node (e.g., MSC, MME), an O&M node, an OSS node, a SON node, a positioning node (e.g., E-SMLC), and / or an MDT. As another example, a network node may be a virtual network node, which is described in more detail below. However, more generally, a network node may represent any suitable device (or group of devices) that is configured, configured, and / or operable to enable and / or provide wireless devices having access to a wireless network or to provide some service to wireless devices that have accessed the wireless network.

[0184] In FIG. 16, the network node 1660 includes a processing circuit 1670, a device readable medium 1680, an interface 1690, an auxiliary device 1684, a power source 1686, a power circuit 1687, and an antenna 1662. Although the network node 1660 shown in the example wireless network of FIG. 16 may represent a device including the shown combination of hardware components, other embodiments may comprise a network node having a different combination of components. It should be understood that a network node comprises any suitable combination of hardware and / or software required to perform the tasks, features, functions, and methods and / or procedures disclosed herein. Moreover, while the components of the network node 1660 are depicted as a single box located within a larger box or nested within multiple boxes, in reality the network node may comprise multiple different physical components that create a single shown component (e.g., the device readable medium 1680 may comprise multiple separate hard drives as well as multiple RAM modules).

[0185] Similarly, the network node 1660 may be comprised of multiple physically separate components (e.g., a Node B component and an RNC component, or a BTS component and a BSC component, etc.), each of which may have their own respective components. In some scenarios in which the network node 1660 comprises multiple separate components (e.g., a BTS component and a BSC component), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control several Node Bs. In such scenarios, each unique Node B and RNC pair may be considered as a single separate network node in some instances. In some embodiments, the network node 1660 may be configured to support several radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate device-readable media 1680 for different RATs) and some components may be reused (e.g., the same antenna 1662 may be shared by the RATs). The network node 1660 may also include multiple sets of the various illustrated components for different wireless technologies integrated into the network node 1660, such as, for example, GSM, WCDMA, LTE, NR, WiFi, or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chips or sets of chips and other components within the network node 1660.

[0186] The processing circuit 1670 can be configured to perform any decision, computation, or similar operations (e.g., some acquisition operations) described herein as being provided by a network node. These operations performed by the processing circuit 1670 can include processing information acquired by the processing circuit 1670, for example, by transforming the acquired information into other information, comparing the acquired or transformed information to information stored in the network node, and / or performing one or more operations based on the acquired or transformed information and as a result of the processing making a decision.

[0187] The processing circuit 1670, either alone or in conjunction with other network node 1660 components (e.g., device readable medium 1680), may comprise one or more combinations of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit, field programmable gate array, or any other suitable computing device, resources, or combination of hardware, software, and / or coded logic operable to provide various functions of the network node 1660. Such functions may include any of the various wireless features, functions, or benefits described herein.

[0188] For example, the processing circuit 1670 may execute instructions stored on the device-readable medium 1680 or in a memory within the processing circuit 1670. In some embodiments, the processing circuit 1670 may include a system on a chip (SOC). As a more specific example, the instructions (also referred to as a computer program product) stored on the medium 1680 may include instructions that, when executed by the processing circuit 1670, can configure the network node 1660 to perform operations corresponding to various example methods (e.g., procedures) described herein.

[0189] In some embodiments, the processing circuitry 1670 may include one or more of a radio frequency (RF) transceiver circuitry 1672 and a baseband processing circuitry 1674. In some embodiments, the radio frequency (RF) transceiver circuitry 1672 and the baseband processing circuitry 1674 may be separate chips (or sets of chips), boards, or units, e.g., a radio unit and a digital unit. In alternative embodiments, some or all of the RF transceiver circuitry 1672 and the baseband processing circuitry 1674 may be on the same chip or set of chips, board, or unit.

[0190] In some embodiments, some or all of the functionality described herein as being provided by a network node, base station, eNB, or other such network device may be performed by the processing circuitry 1670 executing instructions stored in a device-readable medium 1680 or memory within the processing circuitry 1670. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry 1670 without executing instructions stored in a separate or distinct device-readable medium, such as in a hardwired manner. In any of those embodiments, the processing circuitry 1670 may be configured to perform the described functionality, whether or not it executes instructions stored in a device-readable storage medium. Benefits provided by such functionality are enjoyed by the network node 1660 as a whole, and / or by end users and wireless networks generally, but not limited to the processing circuitry 1670 alone or other components of the network node 1660.

[0191] The device readable medium 1680 may comprise any form of volatile or non-volatile computer readable memory, including, but not limited to, persistent storage, solid-state memory, remotely mounted memory, 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 drive, compact disk (CD), or digital video disk (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 that may be used by the processing circuit 1670. The device readable medium 1680 may store any suitable instructions, data, or information, including applications including one or more of computer programs, software, logic, rules, codes, tables, etc., and / or other instructions that may be executed by the processing circuit 1670 and utilized by the network node 1660. The device readable medium 1680 may be used to store any calculations performed by the processing circuit 1670 and / or any data received via the interface 1690. In some embodiments, the processing circuit 1670 and the device readable medium 1680 may be considered to be integrated.

[0192] The interface 1690 is used in wired or wireless communication of signaling and / or data between the network node 1660, the network 1606, and / or the WD 1610. As shown, the interface 1690 comprises a port / terminal 1694 for transmitting and receiving data to and from the network 1606, for example, via a wired connection. The interface 1690 also includes a radio front-end circuit 1692, which may be coupled to the antenna 1662 or, in some embodiments, may be part of the antenna 1662. The radio front-end circuit 1692 comprises a filter 1698 and an amplifier 1696. The radio front-end circuit 1692 may be connected to the antenna 1662 and the processing circuit 1670. The radio front-end circuit may be configured to condition signals communicated between the antenna 1662 and the processing circuit 1670. The radio front-end circuit 1692 may receive digital data to be sent to other network nodes or WDs via a wireless connection. The radio front-end circuitry 1692 can convert the digital data into a radio signal having appropriate channel and bandwidth parameters using a combination of filters 1698 and / or amplifiers 1696. The radio signal can then be transmitted via the antenna 1662. Similarly, when receiving data, the antenna 1662 can collect the radio signal, which is then converted into digital data by the radio front-end circuitry 1692. The digital data can be passed to the processing circuitry 1670. In other embodiments, the interface can comprise different components and / or different combinations of components.

[0193] In some alternative embodiments, the network node 1660 may not include a separate radio front-end circuit 1692, and instead the processing circuit 1670 may comprise a radio front-end circuit and may be connected to the antenna 1662 without a separate radio front-end circuit 1692. Similarly, in some embodiments, all or a portion of the RF transceiver circuit 1672 may be considered part of the interface 1690. In still other embodiments, the interface 1690 may include one or more ports or terminals 1694, the radio front-end circuit 1692, and the RF transceiver circuit 1672 as part of a radio unit (not shown), and the interface 1690 may communicate with a baseband processing circuit 1674 that is part of a digital unit (not shown).

[0194] The antenna 1662 may include one or more antennas, or an antenna array, configured to transmit and / or receive wireless signals. The antenna 1662 may be coupled to the radio front-end circuitry 1692 and may be any type of antenna capable of wirelessly transmitting and receiving data and / or signals. In some embodiments, the antenna 1662 may comprise one or more omni-directional sector or panel antennas operable to transmit / receive wireless signals, for example, between 2 GHz and 66 GHz. An omni-directional antenna may be used to transmit / receive wireless signals in any direction, a sector antenna may be used to transmit / receive wireless signals from devices in a particular area, and a panel antenna may be a line-of-sight antenna used to transmit / receive wireless signals in a relatively straight line. In some instances, the use of more than one antenna may be referred to as MIMO. In some embodiments, the antenna 1662 may be separate from the network node 1660 and may be connectable to the network node 1660 via an interface or port.

[0195] The antenna 1662, the interface 1690, and / or the processing circuit 1670 may be configured to perform any receiving operation and / or some obtaining operation described herein as being performed by a network node. Any information, data, and / or signal may be received from a wireless device, another network node, and / or any other network equipment. Similarly, the antenna 1662, the interface 1690, and / or the processing circuit 1670 may be configured to perform any transmitting operation described herein as being performed by a network node. Any information, data, and / or signal may be transmitted to a wireless device, another network node, and / or any other network equipment.

[0196] The power circuit 1687 may comprise or be coupled to a power management circuit and may be configured to supply power to the components of the network node 1660 for performing the functions described herein. The power circuit 1687 may receive power from a power source 1686. The power source 1686 and / or the power circuit 1687 may be configured to supply power to the various components of the network node 1660 in a format appropriate for each component (e.g., at voltage and current levels required for each component). The power source 1686 may either be included in the power circuit 1687 and / or the network node 1660 or may be external to the power circuit 1687 and / or the network node 1660. For example, the network node 1660 may be connectable to an external power source (e.g., an electrical outlet) via an input circuit or interface, such as an electrical cable, whereby the external power source supplies power to the power circuit 1687. As a further example, power supply 1686 can include a power source in the form of a battery or battery pack connected to or integrated within power circuit 1687. The battery can provide backup power in the event that an external power source fails. Other types of power sources, such as photovoltaic devices, can also be used.

[0197] Alternative embodiments of the network node 1660 may include additional components other than those shown in FIG. 16 that may be involved in providing some aspects of the functionality of the network node, including any of the functions described herein and / or any functionality necessary to support the subject matter described herein. For example, the network node 1660 may include user interface devices to enable and / or facilitate the input of information into the network node 1660 and to enable and / or facilitate the output of information from the network node 1660. This may enable and / or facilitate a user to perform diagnostics, maintenance, repair, and other management functions for the network node 1660.

[0198] In some embodiments, a wireless device (WD, e.g., WD1610) can be configured to transmit and / or receive information without direct human interaction. For example, a WD can be designed to transmit information to a network on a predefined 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, cell 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 appliances, wearable devices, wireless endpoints, mobile stations, tablets, laptops, laptop embedded equipment (LEE), laptop mounted equipment (LME), smart devices, wireless customer premises equipment (CPE), mobile type communication (MTC) devices, Internet of Things (IoT) devices, in-vehicle wireless terminal devices, etc.

[0199] The WD may support device-to-device (D2D) communication, for example by implementing 3GPP standards for sidelink communication, vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-everything (V2X), and in this case may be referred to as a D2D communication device. As yet another specific example, in an Internet of Things (IoT) scenario, the WD may represent a machine or other device that performs monitoring and / or measurement and transmits results of such monitoring and / or measurement to another WD and / or a network node. The WD may in this case be a machine-to-machine (M2M) device, and the M2M device may be referred to as an MTC device in the 3GPP context. As one particular example, the WD may be a UE that implements the 3GPP narrowband Internet of Things (NB-IoT) standard. Particular examples of such machines or devices are sensors, metering devices such as power meters, industrial machinery, or household or personal appliances (e.g., refrigerators, televisions, etc.), personal wearables (e.g., watches, fitness trackers, etc.). In other scenarios, the WD may represent a vehicle or other equipment capable of monitoring and / or reporting on its operational status, or other functions associated with its operation. The WD described above may represent an endpoint of a wireless connection, in which case the device may be referred to as a wireless terminal. Additionally, the WD described above may be mobile, in which case the device may be referred to as a mobile device or mobile terminal.

[0200] As shown, the wireless device 1610 includes an antenna 1611, an interface 1614, a processing circuit 1620, a device-readable medium 1630, a user interface device 1632, an auxiliary device 1634, a power source 1636, and a power circuit 1637. The WD 1610 may include multiple sets of one or more of the shown components for different wireless technologies supported by the WD 1610, such as, for example, GSM, WCDMA, LTE, NR, WiFi, WiMAX, or Bluetooth wireless technologies, just to name a few. These wireless technologies may be integrated in the same or different chip or set of chips as other components in the WD 1610.

[0201] The antenna 1611 may include one or more antennas or antenna arrays configured to transmit and / or receive wireless signals and is connected to the interface 1614. In some alternative embodiments, the antenna 1611 may be separate from the WD 1610 and connectable to the WD 1610 via an interface or port. The antenna 1611, the interface 1614, and / or the processing circuitry 1620 may be configured to perform any receiving or transmitting operations described herein as being performed by a WD. Any information, data, and / or signals may be received from a network node and / or another WD. In some embodiments, the wireless front-end circuitry and / or the antenna 1611 may be considered an interface.

[0202] As shown, the interface 1614 comprises a radio front-end circuit 1612 and an antenna 1611. The radio front-end circuit 1612 comprises one or more filters 1618 and an amplifier 1616. The radio front-end circuit 1614 is connected to the antenna 1611 and the processing circuit 1620 and can be configured to condition signals communicated between the antenna 1611 and the processing circuit 1620. The radio front-end circuit 1612 can be coupled to the antenna 1611 or can be part of the antenna 1611. In some embodiments, the WD 1610 may not include a separate radio front-end circuit 1612; rather, the processing circuit 1620 can comprise a radio front-end circuit and can be connected to the antenna 1611. Similarly, in some embodiments, some or all of the RF transceiver circuit 1622 can be considered part of the interface 1614. The radio front-end circuit 1612 can receive digital data to be sent to other network nodes or WDs via a wireless connection. The radio front-end circuitry 1612 can convert the digital data into a radio signal having appropriate channel and bandwidth parameters using a combination of filters 1618 and / or amplifiers 1616. The radio signal can then be transmitted via the antenna 1611. Similarly, when receiving data, the antenna 1611 can collect the radio signal, which is then converted into digital data by the radio front-end circuitry 1612. The digital data can be passed to the processing circuitry 1620. In other embodiments, the interface can comprise different components and / or different combinations of components.

[0203] The processing circuitry 1620 may comprise one or more combinations of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit, field programmable gate array, or any other suitable computing device, resources, or combination of hardware, software, and / or coded logic operable to provide the functionality of the WD 1610, either alone or in combination with other WD 1610 components, such as the device readable medium 1630. Such functionality may include any of the various wireless features or benefits described herein.

[0204] For example, the processing circuit 1620 may execute instructions stored on the device-readable medium 1630 or in memory within the processing circuit 1620 to provide the functionality disclosed herein. More specifically, the instructions (also referred to as a computer program product) stored on the medium 1630 may include instructions that, when executed by the processor 1620, can configure the wireless device 1610 to perform operations corresponding to various example methods (e.g., procedures) described herein.

[0205] As shown, the processing circuit 1620 includes one or more of the RF transceiver circuit 1622, the baseband processing circuit 1624, and the application processing circuit 1626. In other embodiments, the processing circuit may comprise different components and / or different combinations of components. In some embodiments, the processing circuit 1620 of the WD 1610 may comprise a SOC. In some embodiments, the RF transceiver circuit 1622, the baseband processing circuit 1624, and the application processing circuit 1626 may be on separate chips or sets of chips. In alternative embodiments, some or all of the baseband processing circuit 1624 and the application processing circuit 1626 may be combined into one chip or set of chips, and the RF transceiver circuit 1622 may be on a separate chip or set of chips. In further alternative embodiments, some or all of the RF transceiver circuit 1622 and the baseband processing circuit 1624 may be on the same chip or set of chips, and the application processing circuit 1626 may be on a separate chip or set of chips. In yet other alternative embodiments, some or all of the RF transceiver circuitry 1622, the baseband processing circuitry 1624, and the application processing circuitry 1626 may be combined within the same chip or set of chips. In some embodiments, the RF transceiver circuitry 1622 may be part of the interface 1614. The RF transceiver circuitry 1622 may condition RF signals for the processing circuitry 1620.

[0206] In some embodiments, some or all of the functionality described herein as being performed by the WD may be provided by the processing circuitry 1620 executing instructions stored on a device-readable medium 1630, which in some embodiments may be a computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry 1620 without executing instructions stored on a separate or distinct device-readable storage medium, such as in a hardwired manner. In any of those particular embodiments, the processing circuitry 1620 may be configured to perform the described functionality, whether or not it executes instructions stored on a device-readable storage medium. Benefits provided by such functionality are enjoyed by the WD 1610 as a whole, and / or by end users and wireless networks in general, but not limited to the processing circuitry 1620 alone or other components of the WD 1610.

[0207] The processing circuit 1620 can be configured to perform any of the decision, calculation, or similar operations (e.g., some of the acquisition operations) described herein as being performed by the WD. These operations performed by the processing circuit 1620 can include, for example, processing the information acquired by the processing circuit 1620 by transforming the acquired information into other information, comparing the acquired or transformed information with information stored by the WD 1610, and / or performing one or more operations based on the acquired or transformed information and as a result of the processing making a decision.

[0208] The device-readable medium 1630 may be operable to store applications including one or more of computer programs, software, logic, rules, codes, tables, etc., and / or other instructions that may be executed by the processing circuit 1620. The device-readable medium 1630 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., compact disc (CD) or digital video disc (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 that may be used by the processing circuit 1620. In some embodiments, the processing circuit 1620 and the device-readable medium 1630 may be considered to be integrated.

[0209] The user interface equipment 1632 may include components that enable and / or facilitate a human user to interact with the WD 1610. Such interaction may be of many forms, such as visual, auditory, tactile, etc. The user interface equipment 1632 may be operable to generate output to a user and to enable and / or facilitate a user to provide input to the WD 1610. The type of interaction may vary depending on the type of user interface equipment 1632 installed on the WD 1610. For example, if the WD 1610 is a smartphone, the interaction may be via a touch screen, and if the WD 1610 is a smart meter, the interaction may be through a screen that provides usage (e.g., number of gallons used) or a speaker that provides an audible alarm (e.g., if smoke is detected). The user interface equipment 1632 may include input interfaces, devices, and circuits, as well as output interfaces, devices, and circuits. The user interface devices 1632 can be configured to enable and / or facilitate input of information into the WD 1610 and are connected to the processing circuit 1620 to enable and / or facilitate the processing circuit 1620 to process the input information. The user interface devices 1632 can include, for example, a microphone, proximity or other sensor, keys / buttons, a touch display, one or more cameras, a USB port, or other input circuitry. The user interface devices 1632 are also configured to enable and / or facilitate output of information from the WD 1610 and to enable and / or facilitate the processing circuit 1620 to output information from the WD 1610. The user interface devices 1632 can include, for example, a speaker, a display, a vibration circuit, a USB port, a headphone interface, or other output circuitry.Using one or more input and output interfaces, devices, and circuits of the user interface equipment 1632, the WD 1610 can communicate with end users and / or wireless networks to enable and / or facilitate the end users and / or wireless networks to benefit from the functionality described herein.

[0210] The auxiliary devices 1634 are operable to provide more specific functions that may not generally be performed by the WD. The auxiliary devices 1634 may include specialized sensors for taking measurements for various purposes, interfaces for additional types of communication such as wired communication, etc. The inclusion and type of components of the auxiliary devices 1634 may vary depending on the embodiment and / or scenario.

[0211] The power source 1636 may be in the form of a battery or battery pack in some embodiments. Other types of power sources, such as an external power source (e.g., an electrical outlet), a photovoltaic device, or a battery, may also be used. The WD 1610 may further comprise a power circuit 1637 for delivering power from the power source 1636 to various parts of the WD 1610 that require power from the power source 1636 to perform any of the functions described or illustrated herein. The power circuit 1637 may comprise a power management circuit in some embodiments. The power circuit 1637 may additionally or alternatively be operable to receive power from an external power source, in which case the WD 1610 may be connectable to an external power source (such as an electrical outlet) via an input circuit or interface, such as a power cable. The power circuit 1637 may also be operable in some embodiments to deliver power from the external power source to the power source 1636. This may be for charging the power source 1636, for example. The power circuitry 1637 may perform any conversion or other modification on the power from the power source 1636 to make it suitable for delivery to the respective components of the WD 1610.

[0212] FIG. 17 illustrates an embodiment of a UE according to various aspects described herein. User equipment or UE as used herein does not necessarily have a user in the sense of a human user who owns and / or operates an associated device. Instead, a UE may represent a device (e.g., a smart sprinkler controller) that is intended for sale to or operation by a human user, but may not be associated with or may not be initially associated with a particular human user. Alternatively, a UE may represent a device (e.g., a smart power meter) that is not intended for sale to or operation by an end user, but may be associated with or operated for the benefit of a user. The UE 17200 may be any UE identified by the 3rd Generation Partnership Project (3GPP), including an NB-IoT UE, a machine type communication (MTC) UE, and / or an enhanced MTC (eMTC) UE. The UE 1700 shown in Figure 17 is an example of a WD configured for communication according to one or more communications standards promulgated by the 3rd Generation Partnership Project (3GPP), such as the 3GPP GSM, UMTS, LTE, and / or 5G standards. As previously mentioned, the terms WD and UE may be used interchangeably. Thus, although Figure 17 is a UE, the components described herein are equally applicable to a WD and vice versa.

[0213] In FIG. 17, the UE 1700 includes a processing circuit 1701 operatively coupled to an input / output interface 1705, a radio frequency (RF) interface 1709, a network connection interface 1711, a random access memory (RAM) 1717, a read only memory (ROM) 1719, and a memory 1715, including a storage medium 1721, a communication subsystem 1731, a power source 1733, and / or any other components, or any combination thereof. The storage medium 1721 includes an operating system 1723, an application program 1725, and data 1727. In other embodiments, the storage medium 1721 may include other similar types of information. Some UEs may utilize all of the components illustrated in FIG. 17 or only a subset of the components. The level of integration between the components may vary from UE to UE. Additionally, some UEs may include multiple instances of components, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0214] In Fig. 17, the processing circuit 1701 can be configured to process computer instructions and data. The processing circuit 1701 can be configured to implement any sequential state machine operable to execute 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 with appropriate firmware, one or more pre-programmed, general-purpose processors, such as a microprocessor or digital signal processor (DSP) with appropriate software, or any combination of the above. For example, the processing circuit 1701 can include two central processing units (CPUs). The data can be information in a format suitable for use by a computer.

[0215] In the depicted embodiment, the input / output interface 1705 can be configured to provide an input device, an output device, or a communication interface to an input / output device. The UE 1700 can be configured to use an output device via the input / output interface 1705. The output device can use the same type of interface port as the input device. For example, a USB port can be used to provide input to and output from the UE 1700. The output device can be a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smart card, another output device, or any combination thereof. The UE 1700 can be configured to use an input device via the input / output interface 1705 to enable and / or facilitate a user to capture information into the UE 1700. The input device can include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a webcam, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smart card, etc. The presence-sensitive display can include a capacitive or resistive touch sensor to sense input from a user. The sensor may be, for example, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, a light sensor, a proximity sensor, another like sensor, or any combination thereof. For example, the input device may be an accelerometer, a magnetometer, a digital camera, a microphone, and a light sensor.

[0216] In FIG. 17, the RF interface 1709 can be configured to provide a communication interface to RF components such as a transmitter, a receiver, and an antenna. The network connection interface 1711 can be configured to provide a communication interface to a network 1743a. The network 1743a can encompass a wired and / or wireless network, such as a local area network (LAN), a wide area network (WAN), a computer network, a wireless network, a communication network, another similar network, or any combination thereof. For example, the network 1743a can comprise a Wi-Fi network. The network connection interface 1711 can be configured to include a receiver and a transmitter interface used to communicate with one or more other devices over a communication network according to one or more communication protocols such as Ethernet, TCP / IP, SONET, ATM, etc. The network connection interface 1711 can implement receiver and transmitter functions suitable for a communication network link (e.g., optical, electrical, etc.). The transmitter and receiver functions can share circuit components, software, or firmware, or can alternatively be implemented separately.

[0217] The RAM 1717 can be configured to interface to the processing circuit 1701 via the bus 1702 to provide storage or caching of data or computer instructions during execution of software programs such as an operating system, application programs, and device drivers. The ROM 1719 can be configured to provide computer instructions or data to the processing circuit 1701. For example, the ROM 1719 can be configured to store unchanging low-level system code or data for basic system functions such as basic input / output (I / O), booting, or receiving keystrokes from a keyboard, which are stored in non-volatile memory. The storage medium 1721 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), magnetic disk, optical disk, floppy disk, hard disk, removable cartridge, or flash drive.

[0218] In one example, the storage medium 1721 can be configured to include an operating system 1723, an application program 1725, such as a web browser application, a widget or gadget engine, or another application, and data files 1727. The storage medium 1721 can store any of a variety of different operating systems or combinations of operating systems for use by the UE 1700. For example, the application program 1725 can include executable instructions (also referred to as a computer program product) that, when executed by the processor 1701, can configure the UE 1700 to perform operations corresponding to various example methods (e.g., procedures) described herein.

[0219] The storage medium 1721 may be configured to include several physical drive units, such as a redundant array of independent disks (RAID), a floppy disk drive, a 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 disk (HD-DVD) optical disk drive, an internal hard disk drive, a Blu-Ray optical disk drive, a holographic digital data storage (HDDS) optical disk drive, an external mini dual in-line memory module (DIMM), a synchronous dynamic random access memory (SDRAM), an external micro-DIMM SDRAM, a smart card memory such as a subscriber identity module or a removable user identity (SIM / RUIM) module, other memory, or any combination thereof. The storage medium 1721 may enable and / or facilitate the UE 1700 to access, offload data, or upload data, computer executable instructions, application programs, and the like stored in a temporary or non-transitory memory medium. An article of manufacture, such as an article of manufacture that utilizes the communication system, may be tangibly embodied in storage medium 1721, which may comprise a device-readable medium.

[0220] In FIG. 17, the processing circuit 1701 can be configured to communicate with the network 1743b using the communication subsystem 1731. The network 1743a and the network 1743b can be the same network or networks, or different networks or networks. The communication subsystem 1731 can be configured to include one or more transceivers used to communicate with the network 1743b. For example, the communication subsystem 1731 can be configured to include one or more transceivers used to communicate with one or more remote transceivers of another device capable of wireless communication, such as another WD, UE, or base station of a radio access network (RAN), according to one or more communication protocols, such as IEEE 802.17, CDMA, WCDMA, GSM, LTE, UTRAN, WiMax, etc. Each transceiver can include a transmitter 1733 and / or a receiver 1735 to respectively implement a transmitter function or receiver function appropriate for the RAN link (e.g., frequency allocation, etc.). Additionally, the transmitter 1733 and receiver 1735 of each transceiver may share circuit components, software, or firmware, or may alternatively be implemented separately.

[0221] In the illustrated embodiment, the communication functions of the communication subsystem 1731 may include data communication, voice communication, multimedia communication, short-range communication such as Bluetooth, short-range communication, location-based communication such as using a global positioning system (GPS) to determine location, another similar communication function, or any combination thereof. For example, the communication subsystem 1731 may include cellular communication, Wi-Fi communication, Bluetooth communication, and GPS communication. The network 1743b may encompass wired and / or wireless networks, such as a local area network (LAN), a wide area network (WAN), a computer network, a wireless network, a communication network, another similar network, or any combination thereof. For example, the network 1743b may be a cellular network, a Wi-Fi network, and / or a short-range network. The power source 1713 may be configured to provide alternating current (AC) power or direct current (DC) power to the components of the UE 1700.

[0222] The features, benefits, and / or functions described herein may be implemented in one of the components of the UE 1700 or may be split across multiple components of the UE 1700. 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 1731 may be configured to include any of the components described herein. Furthermore, the processing circuit 1701 may be configured to communicate with any of such components via the bus 1702. In another example, any of such components may be represented by program instructions stored in memory that, when executed by the processing circuit 1701, perform the corresponding functions described herein. In another example, the functions of any of such components may be split between the processing circuit 1701 and the communication subsystem 1731. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware, and computationally intensive functions may be implemented in hardware.

[0223] FIG. 18 is a schematic block diagram illustrating a virtualization environment 1800 in which functions implemented by some embodiments may be virtualized. In this context, virtualizing means creating a virtual version of an apparatus or device, which may include virtualizing a hardware platform, storage devices, and networking resources. Virtualization as used herein may apply to a node (e.g., a virtualized base station or a virtualized radio access node) or to a device (e.g., a UE, a wireless device, or any other type of communication device) or components thereof, and relates to implementations in which at least a portion of the functionality is implemented as one or more virtual components (e.g., via one or more applications, components, functions, virtual machines, or containers running on one or more physical processing nodes in one or more networks).

[0224] In some embodiments, some or all of the functionality described herein may be implemented as virtual components executed by one or more virtual machines implemented in one or more virtual environments 1800 hosted by one or more of the hardware nodes 1830. Furthermore, in embodiments where the virtual nodes are not wireless access nodes or do not require wireless connectivity (e.g., core network nodes), the network nodes may be fully virtualized.

[0225] The functionality may be implemented by one or more applications 1820 (which may alternatively be referred to as software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) operable to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein. The applications 1820 are run in a virtualization environment 1800, which provides hardware 1830 comprising a processing circuit 1860 and a memory 1890. The memory 1890 includes instructions 1895 executable by the processing circuit 1860 such that the applications 1820 are operable to provide one or more of the features, benefits, and / or functions disclosed herein.

[0226] The virtualization environment 1800 may include general-purpose or dedicated network hardware devices (or nodes) 1830 with a set of one or more processors or processing circuitry 1860, which may be a commercial off-the-shelf (COTS) processor, a dedicated application-specific integrated circuit (ASIC), or any other type of processing circuitry including digital or analog hardware components or dedicated processors. Each hardware device may include memory 1890-1, which may be a non-persistent memory for temporarily storing instructions 1895 or software executed by the processing circuitry 1860. For example, the instructions 1895 may include program instructions (also referred to as computer program products) that, when executed by the processing circuitry 1860, may configure the hardware node 1820 to perform operations corresponding to various example methods (e.g., procedures) described herein. Such operations may also be attributed to the virtual nodes 1820 hosted by the hardware nodes 1830.

[0227] Each hardware device may include one or more network interface controllers (NICs), also known as network interface cards, 1870 that include physical network interfaces 1880. Each hardware device may also include a non-transitory, persistent, machine-readable storage medium 1890-2 having stored thereon software 1895 and / or instructions executable by the processing circuitry 1860. The software 1895 may include any type of software, including software for instantiating one or more virtualization layers 1850 (also referred to as hypervisors), software for running virtual machines 1840, and software that enables virtual machines 1840 to perform the functions, features, and / or benefits described in connection with some embodiments described herein.

[0228] The virtual machines 1840 may comprise virtual processing, virtual memory, virtual networking or interfaces, and virtual storage, and may be run by a corresponding virtualization layer 1850 or hypervisor. Different embodiments of an instance of a virtual appliance 1820 may be implemented in one or more of the virtual machines 1840, and the implementation may be done in different ways.

[0229] During operation, the processing circuitry 1860 executes software 1895 to instantiate a hypervisor or virtualization layer 1850, which may sometimes be referred to as a virtual machine monitor (VMM). The virtualization layer 1850 may present to the virtual machines 1840 a virtual operating platform that appears to be networking hardware.

[0230] 18, the hardware 1830 may be a standalone network node having generic or proprietary components. The hardware 1830 may include an antenna 18225 and may implement some functions via virtualization. Alternatively, the hardware 1830 may be part of a larger cluster of hardware (e.g., in a data center or customer premises equipment (CPE) etc.) that is managed via a management and orchestration (MANO) 18100 where many hardware nodes work together and, among other things, oversee the lifecycle management of the applications 1820.

[0231] Hardware virtualization, in some contexts, is referred to as network functions virtualization (NFV). NFV can be used to consolidate many network equipment types onto industry-standard high-volume server hardware, physical switches, and physical storage that can be located in data centers and customer premises equipment.

[0232] In the context of NFV, a virtual machine 1840 may be a software implementation of a physical machine that runs programs as if those programs were running on a physical, non-virtualized machine. Each virtual machine 1840 and that portion of the hardware 1830 on which it runs, whether hardware dedicated to that virtual machine and / or hardware shared by that virtual machine with other ones of the virtual machines 1840, forms a separate Virtual Network Element (VNE).

[0233] Further in the context of NFV, a virtual network function (VNF) runs on one or more virtual machines 1840 on top of the hardware networking infrastructure 1830 and is responsible for handling specific network functions corresponding to the applications 1820 of FIG. 18.

[0234] In some embodiments, one or more radio units 18200, each including one or more transmitters 18220 and one or more receivers 18210, may be coupled to one or more antennas 18225. The radio units 18200 may communicate directly with a hardware node 1830 via one or more suitable network interfaces, or may be used in combination with a virtualization component to provide a virtual node having wireless capabilities, such as a radio access node or base station. A node configured in this manner may also communicate with one or more UEs, such as the UEs described elsewhere herein.

[0235] In some embodiments, some signaling may be performed via a control system 18230, which may alternatively be used for communication between the hardware node 1830 and the wireless unit 18200.

[0236] Referring to Fig. 19, according to one embodiment, a communication system includes a communication network 1910, such as a 3GPP type cellular network, comprising an access network 1911, such as a wireless access network, and a core network 1914. The access network 1911 comprises a number of base stations 1912a, 1912b, 1912c, such as NBs, eNBs, gNBs, or other types of wireless access points, each defining a corresponding coverage area 1913a, 1913b, 1913c. Each base station 1912a, 1912b, 1912c is connectable to the core network 1914 via a wired or wireless connection 1915. A first UE 1991 located within the coverage area 1913c can wirelessly connect to the corresponding base station 1912c or be configured to be paged by the corresponding base station 1912c. A second UE 1992 within the coverage area 1913a can wirelessly connect to a corresponding base station 1912a. Although multiple UEs 1991, 1992 are shown in this example, the disclosed embodiments are equally applicable to situations where only one UE is within a coverage area or only one UE is connected to.

[0237] The network 1910 is itself connected to a host computer 1930, which may be embodied in hardware and / or software of a standalone server, a cloud-implemented server, a distributed server, or as a processing resource in a server farm. The host computer 1930 may be owned or under the control of a service provider, or may be operated by or on behalf of the service provider. The connections 1921 and 1922 between the communication network 1910 and the host computer 1930 may extend directly from the core network 1914 to the host computer 1930, or may proceed through an optional intermediate network 1920. The intermediate network 1920 may be one of a public network, a private network, or a hosted network, or a combination of two or more of them, and the intermediate network 1920 may be a backbone network or the Internet, if any, and in particular the intermediate network 1920 may comprise two or more sub-networks (not shown).

[0238] The communication system of FIG. 19 as a whole enables connectivity between connected UEs 1991, 1992 and a host computer 1930. The connectivity can be described as an over-the-top (OTT) connection 1950. The host computer 1930 and connected UEs 1991, 1992 are configured to communicate data and / or signaling via the OTT connection 1950 using the access network 1911, the core network 1914, any intermediate networks 1920, and possible further infrastructure (not shown) as intermediaries. The OTT connection 1950 can be transparent in the sense that participating communication devices through which the OTT connection 1950 passes are unaware of the routing of uplink and downlink communications. For example, the base station 1912 may not be or need not be informed of the past routing of incoming downlink communications involving data originating from the host computer 1930 to be forwarded (e.g., handed over) to the connected UE 1991. Similarly, the base station 1912 does not need to be aware of the future routing of outgoing uplink communications originating from the UE 1991 and destined for the host computer 1930 .

[0239] Next, an exemplary implementation of the UE, base station, and host computer described in the previous paragraph according to an embodiment will be described with reference to FIG. 20. In the communication system 2000, the host computer 2010 comprises hardware 2015, including a communication interface 2016 configured to set up and maintain wired or wireless connections with interfaces of different communication devices of the communication system 2000. The host computer 2010 further comprises a processing circuit 2018, which may have storage and / or processing capabilities. In particular, the processing circuit 2018 may comprise one or more programmable processors, application specific integrated circuits, field programmable gate arrays, or combinations thereof (not shown) adapted to execute instructions. The host computer 2010 further comprises software 2011 stored in or accessible by the host computer 2010 and executable by the processing circuit 2018. The software 2011 includes a host application 2012. The host application 2012 may be operable to provide services to a remote user, such as the UE 2030, connecting via an OTT connection 2050 that terminates at the UE 2030 and the host computer 2010. In providing services to the remote user, the host application 2012 may provide user data that is transmitted using the OTT connection 2050.

[0240] The communication system 2000 may also include a base station 2020 provided within the communication system, the base station 2020 comprising hardware 2025 that enables the base station 2020 to communicate with the host computer 2010 and the UE 2030. The hardware 2025 may include a communication interface 2026 for setting up and maintaining wired or wireless connections with interfaces of different communication devices of the communication system 2000, as well as a wireless interface 2027 for setting up and maintaining at least a wireless connection 2070 with a UE 2030 located within a coverage area (not shown in FIG. 20) served by the base station 2020. The communication interface 2026 may be configured to facilitate a connection 2060 to the host computer 2010. The connection 2060 may be direct or the connection 2060 may pass through a core network (not shown in FIG. 20) of the communication system and / or one or more intermediate networks outside the communication system. In the illustrated embodiment, the hardware 2025 of the base station 2020 may also include processing circuitry 2028, which may comprise one or more programmable processors, application specific integrated circuits, field programmable gate arrays, or combinations thereof (not shown) adapted to execute instructions.

[0241] The base station 2020 also includes software 2021 stored internally or accessible via an external connection. For example, the software 2021 can include program instructions (also referred to as a computer program product) that, when executed by the processing circuitry 2028, can configure the base station 2020 to perform operations corresponding to various example methods (e.g., procedures) described herein.

[0242] The communications system 2000 may also include the already mentioned UE 2030, whose hardware 2035 may include a wireless interface 2037 configured to set up and maintain a wireless connection 2070 with a base station serving a coverage area in which the UE 2030 is currently located. The hardware 2035 of the UE 2030 may also include processing circuitry 2038, which may comprise one or more programmable processors, application specific integrated circuits, field programmable gate arrays, or combinations thereof (not shown) adapted to execute instructions.

[0243] The UE 2030 also includes software 2031 stored in or accessible by the UE 2030 and executable by the processing circuitry 2038. The software 2031 includes a client application 2032. The client application 2032 may be operable to provide services to a human user or a non-human user via the UE 2030 with support from the host computer 2010. At the host computer 2010, an executing host application 2012 may communicate with an executing client application 2032 via an OTT connection 2050 that terminates at the UE 2030 and the host computer 2010. In providing services to the user, the client application 2032 may receive request data from the host application 2012 and provide user data in response to the request data. The OTT connection 2050 may transfer both the request data and the user data. The client application 2032 may interact with the user to generate the user data that the client application 2032 provides. The software 2031 may also include program instructions (also referred to as a computer program product) that, when executed by the processing circuitry 2038, can configure the UE 2030 to perform operations corresponding to various example methods (e.g., procedures) described herein.

[0244] It should be noted that the host computer 2010, base station 2020, and UE 2030 shown in Figure 20 may be similar to or identical to the host computer 1230, one of the base stations 1612a, 1612b, 1612c, and one of the UEs 1691, 1692, respectively, of Figure 16. That is, the inner workings of these entities may be as shown in Figure 20, and separately, the surrounding network topology may be that of Figure 16.

[0245] In FIG. 20, the OTT connection 2050 is depicted abstractly to show communication between the host computer 2010 and the UE 2030 via the base station 2020, without explicit reference to any intermediate devices and the exact routing of messages through these devices. The network infrastructure can determine the routing, and the network infrastructure can be configured to hide the routing from the UE 2030, or from the service provider operating the host computer 2010, or both. The network infrastructure can further determine that the network infrastructure dynamically changes the routing (e.g., based on network load balancing considerations or reconfiguration) while the OTT connection 2050 is active.

[0246] The radio connection 2070 between the UE 2030 and the base station 2020 follows the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of the OTT service provided to the UE 2030 using the OTT connection 2050 of which the radio connection 2070 forms the last segment. More precisely, the exemplary embodiments disclosed herein can improve the flexibility for the network to monitor the end-to-end quality of service (QoS) of a data flow, including the corresponding radio bearer of a data flow associated with a data session between a user equipment (UE) and another entity, such as an OTT data application or service, outside the 5G network. These and other advantages can facilitate more timely design, implementation, and deployment of 5G / NR solutions. Moreover, such embodiments can facilitate flexible and timely control of data session QoS, which can lead to improvements in capacity, throughput, latency, etc., envisioned by 5G / NR and critical for the growth of OTT services.

[0247] A measurement procedure may be provided for the purpose of monitoring data rates, latencies, and other network operating conditions that one or more embodiments improve upon. There may further be an optional network function for reconfiguring the OTT connection 2050 between the host computer 2010 and the UE 2030 in response to fluctuations in the measurement results. The measurement procedure and / or the network function for reconfiguring the OTT connection 2050 may be implemented in the software 2011 and hardware 2015 of the host computer 2010, or in the software 2031 and hardware 2035 of the UE 2030, or both. In an embodiment, a sensor (not shown) may be located in or associated with the communication device through which the OTT connection 2050 passes, and the sensor may participate in the measurement procedure by providing values ​​of the monitored quantities exemplified above, or other physical quantities from which the software 2011, 2031 may calculate or estimate the monitored quantities. The reconfiguration of the OTT connection 2050 may include message formats, retransmission settings, preferred routing, etc., and the reconfiguration need not affect the base station 2020, and the reconfiguration may be unknown or imperceptible to the base station 2020. Such procedures and functions may be known and practiced in the art. In some embodiments, the measurements may involve proprietary UE signaling that facilitates the host computer 2010 measurements of throughput, propagation time, latency, etc. The measurements may be implemented in that the software 2011 and 2031 cause messages to be sent, particularly within empty or "dummy" messages, using the OTT connection 2050 while the OTT connection 2050 monitors propagation times, errors, etc.

[0248] FIG. 21 is a flow chart illustrating an example method and / or procedure implemented in a communication system, according to one embodiment. The communication system includes a host computer, a base station, and a UE, which in some example embodiments may be as described with reference to other figures herein. To simplify this disclosure, only drawing references to FIG. 21 are included in this section. In step 2110, the host computer provides user data. In sub-step 2111 (which may be optional) of step 2110, the host computer provides the user data by executing a host application. In step 2120, the host computer initiates a transmission carrying the user data to the UE. In step 2130 (which may be optional), the base station transmits the user data carried in the host computer initiated transmission to the UE, according to the teachings of the embodiments described throughout this disclosure. In step 2140 (which may also be optional), the UE executes a client application associated with the host application executed by the host computer.

[0249] FIG. 22 is a flow chart illustrating an example method and / or procedure 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 as described with reference to other figures herein. To simplify the disclosure, only drawing references to FIG. 22 are included in this section. In step 2210 of the method, the host computer provides user data. In an optional sub-step (not shown), the host computer provides the user data by executing a host application. In step 2220, the host computer initiates a transmission carrying the user data to the UE. The transmission may go through a base station, according to the teachings of the embodiments described throughout this disclosure. In step 2230 (which may be optional), the UE receives the user data carried in the transmission.

[0250] FIG. 23 is a flow chart illustrating an exemplary method and / or procedure 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 as described with reference to other figures herein. To simplify the disclosure, only drawing references to FIG. 23 are included in this section. In step 2310 (which may be optional), the UE receives input data provided by the host computer. Additionally or alternatively, in step 2320, the UE provides user data. In sub-step 2321 (which may be optional) of step 2320, the UE provides the user data by executing a client application. In sub-step 2311 (which may be optional) of step 2310, the UE executes the client application, which provides the user data in response to the received input data provided by the host computer. In providing the user data, the executed client application may further take into account user input received from the user. Regardless of the specific manner in which the user data is provided, the UE begins transmitting the user data to the host computer in sub-step 2330 (which may be optional). In method step 2340, the host computer receives user data transmitted from the UE according to the teachings of the embodiments described throughout this disclosure.

[0251] FIG. 24 is a flow diagram illustrating an example method and / or procedure 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 as described with reference to other figures herein. To simplify the disclosure, only drawing references to FIG. 24 are included in this section. In step 2410 (which may be optional), the base station receives user data from the UE in accordance with the teachings of the embodiments described throughout this disclosure. In step 2420 (which may be optional), the base station initiates transmission of the received user data to the host computer. In step 2430 (which may be optional), the host computer receives the user data carried in the transmission initiated by the base station.

[0252] As described herein, the devices and / or apparatus may be represented by semiconductor chips, chipsets, or (hardware) modules comprising such chips or chipsets, but this does not exclude the possibility that the functionality of the device or apparatus may instead be implemented in hardware as a software module, such as a computer program or computer program product comprising executable software code portions for execution on or running on a processor. Furthermore, the functionality of the device or apparatus may be implemented by any combination of hardware and software. A device or apparatus may also be considered as an assembly of multiple devices and / or apparatus, whether functionally cooperating with each other or independent of each other. Moreover, the devices and apparatus may be implemented distributed throughout a system, as long as the functionality of the device or apparatus is preserved. Such principles and similar principles are believed to be known to those skilled in the art.

[0253] Additionally, functionality described herein as being performed by a wireless device or network node may be distributed across multiple wireless devices and / or network nodes. In other words, it is contemplated that the functionality of the network nodes and wireless devices described herein is not limited to being performed by a single physical device, but may in fact be distributed among several physical devices.

[0254] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as those commonly understood by those skilled in the art to which this disclosure belongs. Terms used herein should be interpreted as having a unique meaning in the context of this specification and related art, and it will be further understood that they are not interpreted in an ideal or overly formal sense unless expressly so defined in this specification.

[0255] In addition, some terms used in this disclosure, including its specification, drawings, and exemplary embodiments, may be used synonymously in some cases, including, but not limited to, for example, data and information. It should be understood that these and / or other words that may be synonymous with each other may be used synonymously herein, but there may be instances where such words are not intended to be used synonymously. Furthermore, unless prior art knowledge has been expressly incorporated herein by reference above, prior art knowledge is expressly incorporated herein in its entirety. All publications referenced are incorporated herein by reference in their entirety.

[0256] Unless expressly stated to the contrary, as used herein, the phrases "at least one" and "one or more" following a conjunction list of enumerated items (e.g., "A and B", "A, B, and C") are intended to mean "at least one item, with each item selected from a list consisting of" the enumerated items. For example, "at least one of A and B" is intended to mean any of the following: A; B; A and B. Similarly, "one or more of A, B, and C" is intended to mean any of the following: A; B; C; A and B; B and C; A and C; A, B, and C.

[0257] Unless expressly stated to the contrary, as used herein, the phrase "plurality" following a conjunction list of enumerated items (e.g., "A and B," "A, B, and C") is intended to mean "a plurality of items, each item being selected from a list consisting of" the enumerated items. For example, "a plurality of A and B" is intended to mean any of the following: two or more A; two or more B; or at least one A and at least one B.

[0258] The above merely illustrates the principles of the present disclosure. In light of the teachings herein, various modifications and changes to the described embodiments will be apparent to those skilled in the art. It will therefore be appreciated that those skilled in the art can devise numerous systems, configurations, and procedures that, although not explicitly shown or described herein, embody the principles of the present disclosure and are within the spirit and scope of the present disclosure. As should be understood by those skilled in the art, various exemplary embodiments can be used together and interchangeably with each other.

[0259] Exemplary embodiments of the techniques and apparatus described herein include, but are not limited to, the examples listed below.

[0260] 1. A method for conditional mobility in a radio access network (RAN) performed by a user equipment (UE), comprising: A first instruction of a mobility operation; a second indication of a trigger condition for the mobility action; a second measurement configuration for the source cell; and A third measurement configuration for one or more target cells. receiving, from the RAN, one or more mobility related messages including: Detecting a trigger condition for one of the target cells based on a second measurement configuration; performing a mobility operation toward the target cell based on a third measurement configuration; A method comprising: 2. The method of embodiment 1, wherein detecting the trigger event includes performing a second measurement at the source cell based on a second measurement configuration. 3. The method of embodiment 1 or 2, wherein receiving the conditional mobility command further includes storing the second and third measurement configurations. 4. The method of any one of embodiments 1 to 3, wherein performing mobility operations includes one or more of the following operations: Stopping the performance of measurements on the source cell; Deleting the stored second measurement setting; and Performing and reporting a third measurement at the target cell based on a third measurement configuration. 5. The method of any one of embodiments 1 to 4, further comprising receiving a first measurement configuration from a source node serving the UE. 6. The method of embodiment 5, further comprising performing and reporting a first measurement at the source cell based on the first measurement configuration. 7. The method of embodiment 5 or 6, wherein receiving the first measurement configuration includes storing the first measurement configuration. 8. A third measurement configuration is received as a complete measurement configuration; performing the mobility operation further includes replacing the stored first measurement configuration with a third measurement configuration; The method of any of embodiments 5 to 7. 9. The method of any of embodiments 5 to 7, wherein at least one of the following conditions applies: A second measurement configuration is received as a delta with respect to the first measurement configuration; A third measurement configuration is received as a delta with respect to the first measurement configuration; A third measurement configuration is received as a delta with respect to the first and second measurement configurations. 10. A method of any one of embodiments 1 to 9, wherein the one or more mobility-related messages include a conditional mobility command received from the source node, the conditional mobility command including the first and second instructions and the second and third measurement configurations. 11. The method of any one of embodiments 1 to 9, wherein the one or more mobility-related messages include: a conditional mobility command received from a source node, the conditional mobility command including the first and second instructions and the second measurement configuration; A reconfiguration message received from the target node, the reconfiguration message including a third measurement configuration. 12. The method of embodiment 11, wherein performing a mobility operation based on the third configuration includes: performing and reporting a third measurement at the target cell based on the second measurement configuration; Thereafter receiving a reconfiguration message including a third measurement configuration. 13. A method, performed by a source node, for conditional mobility of a user equipment (UE) in a radio access network (RAN), the method comprising: sending a request to the target node to accept a conditional mobility operation for the UE; receiving, from the target node, a confirmation of a conditional mobility operation, the confirmation including a third measurement configuration for one or more target cells served by the target node; determining a second measurement configuration related to a trigger condition for a conditional mobility operation; sending, to the UE, a conditional mobility command comprising: Mobility operation instructions, An indication of the trigger condition, and Second measurement setup. 14. The method of embodiment 13, wherein the conditional mobility command also includes a third measurement configuration. 15. The method of embodiment 13, further comprising transmitting a second measurement configuration to the target node. 16. The method of any of embodiments 13 to 15, further comprising transmitting, to the UE, a first measurement configuration for the source cell, wherein the request to the target node also includes the first measurement configuration. 17. The method of any of embodiments 13-16, further comprising determining that a conditional mobility operation is required for the UE. 18. The method of embodiment 16 or 17, wherein determining that the conditional mobility operation is required includes receiving a first measurement made by the UE based on a first measurement configuration. 19. The method of any of embodiments 11-18, further comprising receiving an indication from the target node that the conditional mobility operation has been performed. 20. The method of any of embodiments 11 to 19, wherein transmitting the first measurement configuration includes storing the first measurement configuration. 21. The method of any of embodiments 11 to 20, wherein determining the second measurement setting includes storing the second measurement setting. 22. The method of any of embodiments 11 to 21, further comprising deleting the stored first and second measurement settings. 23. The method of any of embodiments 11 to 22, wherein at least one of the following conditions applies: A second measurement configuration is determined as a delta with respect to the first measurement configuration; A third measurement configuration is received as a delta with respect to the first measurement configuration; A third measurement configuration is received as a delta with respect to the first and second measurement configurations. 24. A method, performed by a target node, for conditional mobility of a user equipment (UE) in a radio access network (RAN), comprising: receiving, from a source node, a request to accept a conditional mobility operation for the UE, the request including a first measurement configuration for the UE; determining a third measurement configuration for the UE with respect to one or more target cells served by the target node based on the first measurement configuration; sending a conditional mobility operation confirmation to the source node, the conditional mobility operation confirmation including a third measurement configuration; Performing a conditional mobility operation at the UE in one of the target cells based on a third measurement configuration. 25. The method of embodiment 24, further comprising sending an indication to the source node that the conditional mobility operation has been performed. 26. The method of embodiment 24 or 25, wherein the third measurement configuration is transmitted as a delta with respect to the first measurement configuration. 27. The method of embodiment 24 or 25, wherein the third measurement configuration is transmitted as a complete measurement configuration. 28. The method of any of embodiments 24-27, wherein performing the conditional mobility operation includes receiving measurements made by the UE at one of the target cells based on a third measurement configuration. 29. The method of any of embodiments 24 to 27, wherein performing the conditional mobility operation includes: receiving measurements made by the UE at one of the target cells based on a second measurement configuration; Then, sending a reconfiguration message to the UE, the reconfiguration message including the third measurement configuration. 30. The method of embodiment 29, further comprising receiving a second measurement configuration for the UE from the source node, the second measurement configuration being received as a delta to the first measurement configuration. 31. The method of embodiment 30, wherein the third measurement configuration is transmitted as a delta with respect to the first and second measurement configurations. 32. A user equipment (UE) configured to support conditional mobility in a radio access network (RAN), the UE comprising: a communications circuit configured to communicate with one or more network nodes in the RAN; A processing circuit operably coupled to the communication circuit and configured to perform operations corresponding to any of the methods of embodiments 1 to 12. 33. A user equipment (UE) configured to support conditional mobility in a radio access network (RAN), the UE being configured to perform operations corresponding to any of the methods of embodiments 1-12. 34. A non-transitory computer-readable medium storing computer-executable instructions that, when executed by processing circuitry comprising a user equipment (UE), configure the UE to perform operations corresponding to any of the methods of claims 1-12. 35. A network node in a radio access network (RAN), comprising: communications circuitry configured to communicate with one or more other network nodes and one or more user equipment (UE); A processing circuit operably coupled to the communication circuit and configured to perform operations corresponding to any of the methods of embodiments 13 to 31. 36. A network node configured to support conditional mobility of a user equipment (UE) between cells in a radio access network (RAN), the network node being configured to perform operations corresponding to any of the methods of embodiments 13 to 31. 37. A non-transitory computer-readable medium storing computer-executable instructions that, when executed by processing circuitry including a network node in a radio access network (RAN), configure the network node to perform operations corresponding to any of the methods of claims 13-31. 38. A communication system including a host computer, the host computer comprising: a. processing circuitry configured to provide user data; b. A communication interface configured to transfer user data to a cellular network for transmission to a user equipment (UE) via a core network (CN) and a radio access network (RAN), where: c. The RAN comprises a first and a second node; d. a first node comprising a communications transceiver and a processing circuit configured to perform operations corresponding to any of the methods of embodiments 1 to 13; and e. The second node comprises a communication transceiver and a processing circuit configured to perform operations corresponding to any of the methods of embodiments 14-20. 39. The communication system of the previous embodiment, further comprising a UE. 40. The communication system of embodiment 38 or 39, wherein: f. processing circuitry of the host computer is configured to execute a host application thereby providing user data; g. The UE comprises processing circuitry configured to execute a client application associated with the host application. 41. A method implemented in a communication system including a host computer, a cellular network, and a user equipment (UE), the method including: a. providing user data at a host computer; b. initiating, at the host computer, a transmission conveying user data to the UE over a cellular network comprising a Radio Access Network (RAN); 21. An operation performed by a first and a second node of a RAN, corresponding to any of the methods of embodiments 1 to 20. 42. The method of embodiment 41, wherein the data message includes user data, and further includes transmitting the user data to the UE via the first node or the second node. 43. The method of embodiment 41 or 42, wherein user data is provided by executing a host application at the host computer, and the method further comprises executing, at the UE, a client application associated with the host application. 44. A communications system including a host computer having a communications interface configured to receive user data originating from a transmission from a user equipment (UE) via a first node or a second node in a radio access network (RAN), wherein: a. a first node comprising a communication interface and a processing circuit configured to perform operations corresponding to any of the methods of embodiments 1 to 13; b. A second node includes a communication interface and a processing circuit configured to perform operations corresponding to any of the methods of embodiments 14-20. 45. The communication system of embodiment 44, further comprising a UE. 46.c. Processing circuitry of a host computer is configured to execute a host application; d. The UE is configured to execute a client application associated with the host application, whereby the client application provides user data to be received by the host computer; 46. ​​A communication system according to embodiment 44 or 45.

Claims

1. 1. A method for conditional handover in a radio access network (RAN) performed by a user equipment (UE), comprising: A first indication of a conditional handover; a second indication of a triggering condition for the conditional handover; A second measurement configuration for the trigger condition; and a third measurement configuration for a candidate cell served by a target RAN node, the third measurement configuration to be applied when the conditional handover towards the candidate cell is executed; receiving (1340) a conditional handover command from a source RAN node, the conditional handover command including: detecting (1350) the fulfillment of the trigger condition with respect to the candidate cell and performing (1360) the conditional handover towards the candidate cell; applying the third measurement configuration to the candidate cell upon execution of the conditional handover by the UE towards the candidate cell; Then, performing a third measurement in the candidate cell based on the third measurement configuration and reporting the performed third measurement. A method comprising:

2. 2. The method of claim 1, wherein detecting the achievement of the trigger condition (1350) comprises performing second measurements in a source cell and the candidate cell of the UE based on the second measurement configuration (1351).

3. The performing of the conditional handover (1360) may further comprise removing or releasing at least a portion of the second measurement configuration (1362). The method of claim 1 or 2, comprising one or more of the following operations:

4. receiving 1310 a first measurement configuration for a source cell of a UE from the source RAN node serving the source cell of the UE; storing (1320) the first measurement configuration; performing and reporting (1330) a first measurement in a source cell of the UE based on the first measurement configuration and prior to receiving (1340) the conditional handover command; The method of claim 1 , further comprising:

5. the third measurement configuration is received as a complete measurement configuration; and performing the conditional handover (1360) further comprises replacing the stored first measurement configuration with the third measurement configuration (1364). The method according to claim 4.

6. the third measurement configuration is received as a delta with respect to one or more of the first measurement configuration and the second measurement configuration; performing the conditional handover towards the candidate cell (1360) includes determining a measurement configuration for the third measurement based on the third measurement configuration and one or more of the first measurement configuration and the second measurement configuration (1365). The method according to claim 4.

7. 1. A method for conditional handover of a user equipment (UE) within a radio access network (RAN), performed by a source RAN node, comprising: sending (1440) a request to accept a conditional handover for the UE to a target RAN node; receiving (1450) a confirmation of the conditional handover from the target RAN node, the confirmation including a third measurement configuration for a candidate cell served by the target RAN node; determining (1460) a second measurement configuration related to a trigger condition of the conditional handover; a first indication of the conditional handover; a second indication of the trigger condition for the conditional handover; the second measurement configuration for the trigger condition; and the third measurement configuration for the candidate cell, the third measurement configuration to be applied when the conditional handover towards the candidate cell is performed; sending (1470) a conditional handover command to the UE, the conditional handover command including: A method comprising:

8. sending (1410) a first measurement configuration for the UE relating to a source cell served by the source RAN node to the UE; receiving 1420 a first measurement made by the UE at the source cell based on the first measurement configuration; determining (1430) that the conditional handover is necessary for the UE based on the first measurement; The method of claim 7 further comprising:

9. The method of claim 8 , wherein the request sent to the target RAN node also includes the first measurement configuration.

10. 1. A method for conditional handover of a user equipment (UE) within a radio access network (RAN), performed by a target RAN node, comprising: receiving 1510 a request from a source RAN node to accept a conditional handover for the UE, the request including a first measurement configuration for the UE; determining (1520) a third measurement configuration for the UE for a candidate cell served by the target RAN node based on the first measurement configuration, the third measurement configuration to be applied upon execution of the conditional handover by the UE towards the candidate cell; sending (1530) a confirmation of the conditional handover to the source RAN node, the confirmation including the third measurement configuration; and receiving from the UE measurements performed on the candidate cells based on the third measurement configuration (1570); A method comprising:

11. 11. The method of claim 10, further comprising: sending (1580) an indication to the source RAN node that the conditional handover is complete.

12. The method according to claim 10 or 11, wherein the third measurement setup included in the verification is a complete measurement setup.

13. A user equipment (UE) (120, 810, 1010, 1610, 1700, 1991, 1992, 2030) configured for conditional handover in a radio access network (RAN) (100, 399, 1911), comprising: A first indication of a conditional handover; a second indication of a triggering condition for the conditional handover; A second measurement configuration for the trigger condition; and a third measurement configuration for a candidate cell served by a target RAN node, the third measurement configuration to be applied when the conditional handover towards the candidate cell is executed; receiving a conditional handover command from a source RAN node, the conditional handover command including: detecting fulfillment of the trigger condition with respect to the candidate cell and performing the conditional handover towards the candidate cell; applying the third measurement configuration to the candidate cell upon execution of the conditional handover by the UE towards the candidate cell; and Then, performing a third measurement in the candidate cell based on the third measurement configuration and reporting the performed third measurement. A UE configured to perform the following:

14. 14. A User Equipment (UE) (120, 810, 1010, 1610, 1700, 1991, 1992, 2030) configured for conditional handover in a Radio Access Network (RAN) (100, 399, 1911), the UE being further configured to perform the method of any one of claims 2 to 6.

15. 1. A source RAN node (105-115, 300, 350, 820, 1020, 1660, 1830, 1912, 2020) in a Radio Access Network (RAN) (100, 399, 1911) configured to facilitate conditional handover for a User Equipment (UE) (120, 810, 1010, 1610, 1700, 1991, 1992, 2030) in the RAN, comprising: sending a request to a target RAN node to accept a conditional handover for the UE; receiving a confirmation of the conditional handover from the target RAN node, the confirmation including a third measurement configuration for a candidate cell served by the target RAN node; determining a second measurement configuration related to a trigger condition for the conditional handover; a first indication of the conditional handover; a second indication of the trigger condition for the conditional handover; the second measurement configuration for the trigger condition; and The third measurement configuration for the candidate cell, the third measurement configuration to be applied upon execution of the conditional handover by the UE towards the candidate cell. sending a conditional handover command to the UE, the conditional handover command including: The source RAN node is further configured to:

16. 16. A source RAN node according to claim 15, further configured to perform the method of claim 8 or 9.

17. a target RAN node (105-115, 300, 350, 830, 1030, 1660, 1830, 1912, 2020) in a Radio Access Network (RAN) (100, 399, 1911) configured to facilitate a conditional handover for a User Equipment (UE) (120, 810, 1010, 1610, 1700, 1991, 1992, 2030) in the RAN, receiving a request from a source RAN node to accept a conditional handover for the UE, the request including a first measurement configuration for the UE; determining a third measurement configuration for the UE with respect to a candidate cell served by the target RAN node based on the first measurement configuration, the third measurement configuration to be applied upon execution of the conditional handover by the UE towards the candidate cell; sending a confirmation of the conditional handover to the source RAN node, the confirmation including the third measurement configuration; and receiving, from the UE, measurements performed in the candidate cell based on the third measurement configuration; A target RAN node that is configured to:

18. 18. A target RAN node according to claim 17, further configured to perform the method of claim 11 or 12.

Images