Method for cancelling or updating a conditional mobility procedure

Abstract

A method for mobility of a user equipment (UE) served by a second node in a radio access network (RAN) performed by a first node in the RAN. Such method includes receiving (1310) a request from the second node for a mobility procedure of the UE towards at least one candidate target cell associated with the first node. Such method includes determining (1320) whether the UE is acceptable for the requested mobility procedure, and if so, allocating resources to support the mobility of the UE. Such method includes transmitting (1330) a response to the second node, the response including a configuration for the mobility procedure and indicating that the UE is acceptable unless a cancellation message is subsequently received from the second node. Such method includes determining (1350) that the configuration is no longer valid, and transmitting (1360) to the second node an indication that the configuration is no longer valid.

Description

Technical Field

[0001] The present invention relates generally to wireless communication networks, and in particular to improvements in robustness and / or functionality of user equipment (UE) mobility operations (eg, handovers) between cells in a wireless communication network. Background Art

[0002] In general, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and / or implied from the context in which they are used. All references to an element, device, component, part, step, etc. are to be interpreted as references to at least one instance of that element, device, component, part, step, etc., unless otherwise expressly stated. The steps of any method and / or process disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as coming after or before another step, and / or it is implied that one step must come after or before another step. Where appropriate, any feature of any embodiment disclosed herein may be applied to any other embodiment. Similarly, any advantage of any embodiment in an embodiment may be applied to any other embodiment, and vice versa. Other objects, features, and advantages of the accompanying embodiments will become apparent from the following description.

[0003] Long Term Evolution (LTE) 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. It is also known as Evolved UTRAN (E-UTRAN). LTE targets various licensed frequency bands and is accompanied by improvements in non-radio aspects, generally referred to as System Architecture Evolution (SAE), which include the Evolved Packet Core (EPC) network. LTE continues to evolve through subsequent releases, which are developed according to the standards-setting process of 3GPP and its working groups (WGs), including the Radio Access Network (RAN) WG, and sub-working groups (e.g., RAN1, RAN2, etc.).

[0004] LTE Release 10 (Rel-10) supports bandwidths greater than 20 MHz. A key requirement for Rel-10 is to ensure backward compatibility with LTE Release-8. This also includes spectrum compatibility. Accordingly, a wideband LTE Rel-10 carrier (e.g., wider than 20 MHz) should appear as multiple carriers to LTE Rel-8 ("legacy") terminals. Each such carrier is referred to as a component carrier (CC). To efficiently utilize the wide carrier for legacy terminals, legacy terminals can be scheduled across all portions of the wideband LTE Rel-10 carrier. One exemplary way to achieve this is through carrier aggregation (CA), whereby a Rel-10 terminal can receive multiple CCs, each preferably having the same structure as a Rel-8 carrier. Similarly, one of the enhancements in LTE Rel-11 is the enhanced Physical Downlink Control Channel (ePDCCH), which aims to increase capacity and improve spatial reuse of control channel resources, improve inter-cell interference coordination (ICIC), and support transmit diversity and / or antenna beamforming for the control channel.

[0005] Figure 1 An overall exemplary architecture of a network including LTE and SAE is shown in FIG. E-UTRAN 100 includes 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 specifications, "user equipment" (or "UE") may refer to any wireless communication device (e.g., a smartphone or computing device) capable of communicating with network equipment compliant with 3GPP standards, including, in some cases, E-UTRAN and earlier generation RANs (e.g., UTRAN / "3G" and / or GERAN / "2G"), as well as later generation RANs.

[0006] As specified by 3GPP, E-UTRAN 100 is responsible for all radio-related functions in the network, including radio bearer control, radio admission control, radio mobility control, scheduling, dynamic allocation of resources to UEs in uplink (UL) and downlink (DL), and security of communications with UEs. These functions reside in eNBs (such as eNBs 105, 110, and 115) that communicate with each other via the X1 interface. The eNBs are also responsible for the E-UTRAN interface to EPC 130, in particular to Figure 1 The S1 interfaces of the Mobility Management Entity (MME) and Serving Gateway (SGW), collectively referred to as MME / S-GW 134 and 138 , are shown.

[0007] Generally speaking, the MME / S-GW handles both the overall control of the UE and the data flow between the UE (such as UE 120) and the rest of the EPC. More specifically, the MME handles the signaling (e.g., control plane CP) protocols between the UE and EPC 130, which are called non-access stratum (NAS) protocols. The S-GW handles all Internet Protocol (IP) data packets (e.g., user plane UP) between the UE and EPC 130 and acts as a local mobility anchor for data bearers when the UE moves between eNBs (such as eNBs 105, 110, and 115).

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

[0009] In some embodiments, HSS 131 may communicate with Figure 1 The HSS 131 communicates with a user data repository (UDR) designated EPC-UDR 135 in the HSS. The EPC-UDR 135 may store user credentials after they have been encrypted using AuC algorithms. These algorithms are not standardized (i.e., vendor-specific), making the encrypted credentials stored in the EPC-UDR 135 inaccessible to any vendor other than the vendor of the HSS 131.

[0010] Figure 2A A high-level block diagram of an exemplary LTE architecture is shown in terms of its constituent entities (UE, E-UTRAN, and EPC) and high-level functionality divided into Access Stratum (AS) and Non-Access Stratum (NAS). Figure 1 Also shown are two specific interface points: Uu (UE / E-UTRAN radio interface) and S1 (E-UTRAN / EPC interface), each using a specific set of protocols: a radio protocol and an S1 protocol. Each of these two protocols can be further divided into user plane (or "U-plane") and control plane (or "C-plane") protocol functionality. Over the Uu interface, the U-plane carries user information (e.g., data packets), while the C-plane carries control information between the UE and E-UTRAN.

[0011] Figure 2BA block diagram illustrates an exemplary C-plane protocol stack between the UE, eNB, and MME. The exemplary protocol stack includes the physical (PHY), media access control (MAC), radio link control (RLC), packet data convergence protocol (PDCP), and radio resource control (RRC) layers between the UE and eNB. The PHY layer is responsible for how and what features are used to transfer data across transport channels on the LTE radio interface. The MAC layer provides data transfer services over 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 correction, concatenation, segmentation, reassembly, and reordering for data transferred to or from upper layers. The PHY, MAC, and RLC layers perform the same 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.

[0012] Figure 2C A block diagram of an exemplary LTE radio interface protocol architecture from the perspective of the PHY layer is shown. The interfaces between the various layers are Figure 2C The PHY layer interfaces with the MAC and RRC protocol layers described above. In the figure, the PHY, MAC, and RRC are also referred to as layers 1-3, respectively. The MAC provides different logical channels to the RLC protocol layer (also described above), characterized by the type of information transferred, while the PHY provides transport channels to the MAC, characterized by how information is transferred over the radio interface. In providing these transport services, the PHY performs various functions, including error detection and correction; mapping coded transport channels to physical channels and rate matching; 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 layer and provides various information to the RRC layer, such as radio measurements.

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

[0014] The uplink (i.e., UE to 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). Additionally, the LTE PHY uplink includes various reference signals, including: Demodulation Reference Signals (DM-RS), which are transmitted to help network nodes receive the associated PUCCH or PUSCH; and Sounding Reference Signals (SRS), which are not associated with any uplink channel.

[0015] The multiple access scheme of LTE PHY is based on orthogonal frequency division multiplexing (OFDM) with a cyclic prefix (CP) in the downlink and single-carrier frequency division multiple access (SC-FDMA) with a cyclic prefix in the uplink. To support transmission in paired and unpaired spectrum, LTE PHY supports both frequency division duplex (FDD) (including both full-duplex and half-duplex operation) and time division duplex (TDD). The LTE FDD downlink (DL) radio frame has a fixed duration of 10 ms and consists of 20 slots labeled 0 to 19, each with a fixed duration of 0.5 ms. A 1-ms subframe consists of two consecutive slots, where the subframe i By time slot 2 i and 2 i + 1. Each exemplary FDD DL slot consists of N DL symb OFDM symbols, each of which consists of N sc OFDM subcarriers. For a subcarrier bandwidth of 15 kHz, N DL symb An exemplary value of may be 7 (with normal CP) or 6 (with extended length CP). sc The value of may be configurable based on the available channel bandwidth. As those skilled in the art are familiar with the principles of OFDM, further details are omitted in this description.

[0016] Furthermore, the combination of a particular subcarrier in a particular symbol is called a resource element (RE). Each RE is used to transmit a specific number of bits, which depends on the bit-mapping constellation and / or modulation type used for that RE. For example, some REs may use QPSK modulation to carry two bits, while other REs may use 16-QAM or 64-QAM to carry four or six bits, respectively. The radio resources of the LTE PHY are also defined in terms of physical resource blocks (PRBs). One PRB is used in one time slot (i.e., N DL symb symbols) spans N RB sc subcarriers, where N RB sc Typically 12 (in the case of 15-kHz subcarrier bandwidth) or 24 (7.5-kHz bandwidth). DL symb symbols) spanning the same N RB sc The PRBs of subcarriers are called PRB pairs. Therefore, the resources available in a subframe of LTE PHY DL include N DL RB PRB pairs, each of which contains 2N DL symb •N RB sc For a normal CP and a 15-kHz subcarrier bandwidth, a PRB pair includes 168 REs.

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

[0018] 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 the UE's UL transmissions. Similarly, the PDCCH carries scheduling assignments, channel quality feedback (e.g., CSI) for the UL channels, and other control information. Likewise, 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 may be transmitted on an aggregation of one or several consecutive control channel elements (CCEs), and the CCEs are mapped to physical resources based on resource element groups (REGs), each of which consists of a number of REs. For example, a CCE may include nine (9) REGs, each of which may include four (4) REs.

[0019] In LTE, RRC is used to configure / set up and maintain a radio connection between a UE and a network node. When the UE receives an RRC message from a network node, it applies the configuration and, if successful, generates an RRC Complete message indicating the transaction ID of the message that triggered the response.

[0020] Since LTE Release 8, three Signaling Radio Bearers (SRBs) (SRB0, SRB1, and SRB2) have been used for the transmission of RRC and Non-Access Stratum (NAS) messages between the UE and network nodes. Release 13 also introduced a new SRB, called SRB1bis, to support DoNAS (Data over NAS) in NB-IoT. SRB0 is used for RRC messages using the CCCH logical channel and is used to handle RRC connection establishment, RRC connection resumption, and RRC connection re-establishment. Once the UE is connected to the network node (i.e., RRC connection establishment or RRC connection re-establishment / resumption has succeeded), SRB1 is used to handle RRC messages (which may include piggybacked NAS messages) and NAS messages, all using the DCCH logical channel, until SRB2 is established. SRB2, on the other hand, is used for RRC messages (including logged measurement information) and NAS messages, all using the DCCH logical channel. SRB2 has a lower priority compared to SRB1 because logged measurement information and NAS messages can be long and may cause blocking of more urgent and smaller SRB1 messages. SRB2 is always configured by E-UTRAN after security activation.

[0021] To support mobility between cells and / or beams, the UE can perform periodic cell searches and signal power and / or quality measurements (e.g., Reference Signal Received Power (RSRP) and / or Reference Signal Received Quality (RSRQ)) in both RRC_CONNECTED and RRC_IDLE modes. For example, UE mobility in RRC_CONNECTED can occur through handovers, while UE mobility in RRC_IDLE can occur through cell reselection. In both cases, the UE is responsible for detecting new neighbor cells and tracking and monitoring already detected cells. Detected cells and associated measurements are reported to the network. LTE UEs can perform such measurements on various downlink reference signals (RS), including, for example, cell-specific reference signals (CRS); MBSFN reference signals; UE-specific reference signals associated with PDSCH, ePDCCH, or MPDCCH (DM-RS); positioning reference signals (PRS); and CSI reference signals (CSI-RS).

[0022] UE measurement reporting to the network can be configured to be periodic or aperiodic (e.g., based on specific events). For example, the network can configure the UE to perform measurements on various radio access technologies and various carrier frequencies corresponding to neighboring cells, and for various purposes, including, for example, mobility and positioning. The configuration for each of these measurements is referred to as a "measurement object." In addition, the UE can be configured to perform measurements according to a "measurement gap pattern," which can include a measurement gap repetition period (MGRP) (i.e., how often a regular gap available for measurement occurs) and a measurement gap length (MGL) (i.e., the length of each recurring gap).

[0023] In LTE, the concept of time to trigger (TTT) is used to ensure that the event triggering criteria are met for a sufficient duration before the UE sends a measurement report. The triggering criteria and TTT are configured in the reportConfig message (or information element IE) sent by the network to the UE. The TTT value provided in reportConfig applies to all neighbor cells of the UE that may trigger measurement reports based on the specified triggering criteria.

[0024] While LTE was primarily designed for user-to-user communications, 5G (also known as "NR") cellular networks are foreseen to support both high single-user data rates (e.g., 1 Gb / s) and massive machine-to-machine communications involving short burst transmissions from many different devices sharing a frequency bandwidth. The 5G radio standard (also known as "New Radio" or "NR") currently targets 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 is designed to provide services with extremely stringent error and latency requirements (e.g., with error probabilities as low as 10 -5 For eMBB, the requirements for latency and error probability may be less stringent, while the required supported peak rate and / or spectral efficiency may be higher.

[0025] UE mobility operates similarly in NR and LTE. As described above, an RRC_CONNECTED UE can be configured by the network to perform measurements, and when measurement reporting is triggered, the network can send a handover (HO) command to the UE. In LTE, this command is an RRConnection-Reconfiguration message with a mobilityControlInfo field. In NR, this command is an RRCReconfiguration message with a reconfigurationWithSync field.

[0026] However, this handover process has various robustness issues. For example, a HO command (e.g., RRCConnectionReconfiguration with mobilityControlInfo or RRCReconfiguration with reconfigurationWithSync) is normally sent when the UE's radio conditions are already quite poor. As such, the HO command may need to be segmented (e.g., to allow for redundancy to prevent 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 in time before the downgraded connection with the target node is disconnected. Summary of the Invention

[0027] Therefore, exemplary embodiments of the present disclosure address these and other mobility-related issues in wireless communication networks by providing improvements to conditional mobility operations, such as conditional handover between a source node (or cell) and a target node (or cell).

[0028] Example embodiments of the present disclosure include methods (e.g., procedures) for mobility of a user equipment (UE) served by a second node in a RAN. These example methods may be performed by a first node (e.g., a base station, eNB, gNB, etc.) in a RAN (e.g., E-UTRAN, NG-RAN) associated with a target cell for the UE.

[0029] These example methods may include receiving, from a second node, a request for a mobility procedure for a UE regarding at least one candidate target cell associated with a first node. In various embodiments, the mobility procedure may be any of the following: handover, recovery, reestablishment, reconfiguration with synchronization, beam switch, and secondary cell (SCell) addition. For example, the request may be a message such as or similar to the conditional handover request described above.

[0030] These example methods may also include determining whether the UE is acceptable for the requested mobility procedure, and if so, allocating resources to support the mobility of the UE. Examples of allocated resources may include bearers, bandwidth, radio resources, power, typical UL / DL resources, C-RNTI or any other UE identifier, RACH resources (e.g., preamble and / or UL time / frequency resources), etc.

[0031] These example methods may also include transmitting a response to the second node, the response including a configuration for the mobility procedure and indicating that the UE can accept it unless a cancellation message is subsequently received from the second node. In some embodiments, the configuration may include one or more conditions for triggering the UE to perform the mobility procedure. In some embodiments, the response may be an RRCReconfiguration message including a reconfigurationWithSync configuration, or an RRCConnection-Reconfiguration message including a mobilityControlInfo configuration.

[0032] In some embodiments, these example methods may further include starting a resource reservation timer associated with the allocated resources. For example, when performing a handover to the target node, the timer may be stopped upon receiving a handover complete message (e.g., RRCConnection-ReconfigurationComplete or RRCReconfigurationComplete) transmitted by the UE. The timer may also be stopped based on an indication that the allocated resources are no longer needed, such as indicated by receiving a cancel message from the source node.

[0033] These example methods may also include determining that the configuration is no longer valid. In some embodiments, this determination may be based on the expiration of a resource reservation timer that was started earlier. In other embodiments, the determination may include monitoring the use of the allocated resources and detecting any of the following conditions during the monitoring: a resource overload condition; a need to use the allocated resources for another mobility procedure (e.g., handover, conditional handover, conditional recovery, conditional reestablishment, etc.); and / or other conditions related to resource use.

[0034] These exemplary methods may also include transmitting an indication to the source node that the configuration is no longer valid. In some embodiments, this operation may include transmitting a cancellation indication and a reason why the configuration is no longer valid. In response to determining that the configuration is no longer valid, the cancellation indication may be transmitted.

[0035] In other embodiments, the operation may include transmitting an updated configuration to the UE. In addition to indicating that the configuration is no longer valid, the updated configuration may overwrite and / or replace the now invalid configuration. In response to determining that the configuration is no longer valid, the updated configuration may be transmitted. In some embodiments, the update may be transmitted from the first node to the second node as a conditional handover update message. In various embodiments, the updated configuration may include any of the following:

[0036] an updated list of PDU session resources of the UE admitted by the first node;

[0037] an updated list of PDU session resources of the UE to which access is not permitted by the first node;

[0038] An updated HandoverCommand message related to the current operating conditions of the candidate target cell; and

[0039] Conditions used to trigger the UE to perform one or more updates of the mobility procedures.

[0040] Other exemplary embodiments of the present disclosure include additional methods (e.g., procedures) for mobility of a user equipment (UE) served by a second node in a RAN. These exemplary methods may be performed by a second node (e.g., a base station, eNB, gNB, etc.) in a RAN (e.g., E-UTRAN, NG-RAN).

[0041] These example methods may include transmitting a request for a mobility procedure for a UE to a first node in a RAN regarding at least one candidate target cell associated with the first node. In various embodiments, the mobility procedure may be any of the following: handover, recovery, reestablishment, synchronization reconfiguration, beam switching, and secondary cell (SCell) addition. For example, the request may be a message such as or similar to the conditional handover request described above.

[0042] These example methods may also include receiving a response from the first node, the response including a configuration for the mobility procedure and indicating that the UE can accept it unless a cancellation message is subsequently received from the second node. In some embodiments, the configuration may include one or more conditions for triggering the UE to perform the mobility procedure. For example, an example condition may be that the quality of the target cell becomes X dB better than the quality of a serving cell of the UE associated with the second node. In some embodiments, the response may be an RRCReconfiguration message including a reconfigurationWithSync configuration, or an RRCConnection-Reconfiguration message including a mobilityControlInfo configuration.

[0043] The example methods may also include transmitting the configuration to the UE; receiving an indication from the first node that the configuration is no longer valid; and reconfiguring the UE based on the indication.

[0044] In some embodiments, the indication that the configuration is no longer valid may include a cancellation indication and a reason why the configuration is no longer valid. For example, the cancellation indication may be received as a conditional handover cancel message. In such an embodiment, reconfiguring the UE may include canceling a mobility procedure. For example, canceling the mobility procedure may include sending a conditional handover cancel message to the UE.

[0045] In other embodiments, the indication that the configuration is no longer valid may include an updated configuration for the mobility procedure. For example, the updated configuration may be received as (or within) a Conditional Handover Update message. In such embodiments, reconfiguring the UE may include transmitting the updated configuration to the UE. For example, the update may be sent to the UE as a Conditional Handover Update message. In some embodiments, the update may utilize delta signaling to modify, add, and / or remove specific fields and / or IEs of a previously provided configuration.

[0046] In various embodiments, the updated configuration may include any of the following:

[0047] an updated list of PDU session resources of the UE admitted by the first node;

[0048] an updated list of PDU session resources of the UE to which access is not permitted by the first node;

[0049] An updated HandoverCommand message related to the current operating conditions of the candidate target cell; and

[0050] Conditions used to trigger the UE to perform one or more updates of the mobility procedures.

[0051] Other exemplary embodiments of the present disclosure include methods (e.g., procedures) performed by a user equipment (UE, e.g., a wireless device) served by a second node in a radio access network (RAN). These exemplary methods may include receiving, from the second node, a configuration for a mobility procedure regarding at least one candidate target cell associated with a first node in the RAN. In various embodiments, the mobility procedure may be any of the following: handover, recovery, reestablishment, synchronization reconfiguration, beam switching, and SCell addition. In some embodiments, the configuration may include one or more conditions for triggering the execution of the mobility procedure. For example, an exemplary condition may be that the quality of the candidate target cell (or beam) becomes X dB stronger than the UE's serving cell.

[0052] In some embodiments, the example methods may further include performing radio resource management (RRM) measurements (e.g., of a reference signal) to determine whether one or more conditions for triggering the performance of the mobility procedure have been met. The example methods may further include receiving an indication from the second node that the configuration is no longer valid before the one or more conditions are met.

[0053] In some embodiments, the indication that a configuration is no longer valid may include a cancellation indication and a reason why the configuration is no longer valid. For example, the indication may be received as (or within) a conditional handover canceled message. In such embodiments, these example methods may also include canceling a mobility procedure associated with the configuration (e.g., in response to the conditional handover canceled message).

[0054] In other embodiments, the indication that a configuration is no longer valid may include an updated configuration for a mobility procedure. For example, the updated configuration may be received as (or within) a Conditional Handover Updated message. In some embodiments, the updated configuration may incorporate and / or utilize incremental signaling to modify, add, and / or remove specific fields and / or IEs associated with a previously provided configuration. In such embodiments, these exemplary methods may also include (e.g., in response to the Conditional Handover Updated message) reconfiguring the mobility procedure associated with the configuration.

[0055] In various embodiments, the updated configuration may include any of the following:

[0056] an updated list of PDU session resources of the UE admitted by the first node;

[0057] an updated list of PDU session resources of the UE to which access is not permitted by the first node;

[0058] An updated HandoverCommand message related to the current operating conditions of the candidate target cell; and

[0059] Conditions used to trigger the UE to perform one or more updates of the mobility procedures.

[0060] In some of these embodiments, these example methods may further include, based on determining that one or more updated conditions have been met, performing a mobility procedure associated with the candidate target cell based on the updated configuration.

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

[0062] These and other objects, features, and advantages of the exemplary embodiments of the present disclosure will become apparent upon reading the following detailed description in view of the accompanying drawings which are briefly described below. BRIEF DESCRIPTION OF THE DRAWINGS

[0063] Figure 1 is a high-level block diagram of an exemplary architecture of the Long Term Evolution (LTE) Evolved-UTRAN (E-UTRAN) and Evolved Packet Core (EPC) network standardized by 3GPP.

[0064] Figure 2A is a high-level block diagram of an exemplary E-UTRAN architecture in terms of its constituent components, protocols, and interfaces.

[0065] Figure 2B is a block diagram of exemplary protocol layers for the control plane portion of the radio (Uu) interface between user equipment (UE) and E-UTRAN.

[0066] Figure 2C is a block diagram of an exemplary LTE radio interface protocol architecture from the perspective of the PHY layer.

[0067] Figure 3 A high-level view of the 5G network architecture is shown, including a split Central Unit (CU)-Distributed Unit (DU) split architecture of the gNB.

[0068] Figure 4 (which is divided into Figure 4A and 4B ) shows an exemplary 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.

[0069] Figure 5 The signaling flow of an exemplary conditional HO such as described above involving a single serving cell and a single target cell is shown.

[0070] Figure 6A shows an exemplary ASN.1 data structure describing the contents of a HandoverPreparationInformation message, and Figure 6B Provided a description Figure 6A Various tables showing the contents of certain fields in the ASN.1 data structure shown in .

[0071] Figure 7 An exemplary ASN.1 data structure describing the contents of a HandoverCommand message is shown.

[0072] Figure 8 (which includes Figures 8A-8C ) shows the signaling flows of various exemplary handover-related operations in an NR network.

[0073] Figure 9 An exemplary signaling flow for disassociation with a conditional mobility procedure (eg, conditional HO) according to various exemplary embodiments of the present disclosure is shown.

[0074] Figure 10 An exemplary signaling flow associated with an update of a conditional mobility procedure (eg, conditional HO) according to various exemplary embodiments of the present disclosure is shown.

[0075] Figure 11 An exemplary conditional handover cancel message from a target node to a source node according to various exemplary embodiments of the present disclosure is shown.

[0076] Figure 12 An exemplary conditional handover update message from a target node to a source node according to various exemplary embodiments of the present disclosure is shown.

[0077] Figure 13-15 Exemplary methods (eg, procedures) for conditional mobility in a radio access network (RAN) performed by a source node, a target node, and a user equipment (UE), respectively, according to various exemplary embodiments of the present disclosure are illustrated.

[0078] Figure 16 An exemplary embodiment of a wireless network in accordance with various aspects described herein is shown.

[0079] Figure 17 An exemplary embodiment of a UE in accordance with various aspects described herein is shown.

[0080] Figure 18 is a block diagram illustrating an exemplary virtualization environment that may be used to implement various embodiments of the network node described herein.

[0081] Figure 19-20 is a block diagram of various exemplary communication systems and / or networks according to various exemplary embodiments of the present disclosure.

[0082] Figures 21-24 is a flow chart of exemplary methods and / or processes for user data transmission and / or reception according to various exemplary embodiments of the present disclosure. DETAILED DESCRIPTION

[0083] 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 disclosed subject matter should not be construed as being limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art. Additionally, throughout the description given below, the following terms are used:

[0084] Radio node: As used herein, a “radio node” may be a “radio access node” or a “wireless device”.

[0085] 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 communication network that is operable to transmit and / or receive signals wirelessly. Some examples of radio access nodes include, but are not limited to, base stations (e.g., 3GPP fifth generation (5G) New Radio (NR) base stations (gNBs) in 3GPP NR networks or enhanced or evolved Node Bs (eNBs) in 3GPP LTE networks), 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.

[0086] Core network node: As used herein, a "core network node" is any type of node in the 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.

[0087] Wireless Device: As used herein, a "wireless device" (or simply "WD") is any type of device that is authorized to access (i.e., be served by) a cellular communication network by wirelessly communicating with network nodes and / or other wireless devices. Unless otherwise noted, the term "wireless device" is used interchangeably herein with "user equipment" (or simply "UE"). Some examples of wireless devices include, but are not limited to, UEs in 3GPP networks and machine-type communication (MTC) devices. Wireless communication may 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.

[0088] Network Node: As used herein, a "network node" is any node that is part of a radio access network or a core network of a cellular communication network. Functionally, a network node is a device that is capable of, configured, arranged, and / or operable to communicate directly or indirectly with a wireless device and / or with other network nodes or devices in a cellular communication network to enable and / or provide wireless access to the wireless device and / or to perform other functions (e.g., management) in the cellular communication network.

[0089] Note that the description presented herein focuses on 3GPP cellular communication systems, and as such, 3GPP terminology or terminology similar to 3GPP terminology is often used. However, the concepts disclosed herein are not limited to 3GPP systems. Furthermore, while the term "cell" is used herein, it should be understood that beams may be used instead of cells (particularly with respect to 5G NR), and as such, the concepts described herein are equally applicable to both cells and beams.

[0090] In the following, the terms eNB (eNodeB), gNB (gNodeB), MCG (Master Cell Group), and Primary Cell (PCell) are used interchangeably to refer to the node or cell to which a UE is connected with single connectivity. Similarly, the terms SN (Secondary Node), SeNB (Secondary eNodeB), SgNB (Secondary gNodeB), SCG (Secondary Cell Group), and PSCell (Primary Secondary Cell) are used interchangeably to refer to the secondary node or cell to which a UE is connected when dual connectivity (DC) is configured.

[0091] As discussed above, current handover procedures in LTE and NR have various issues related to robustness. These issues and specific improvements provided by exemplary embodiments of the present disclosure are discussed in more detail below.

[0092] Figure 3 A high-level view of the 5G network architecture is shown, consisting of the Next Generation RAN (NG-RAN) 399 and the 5G Core (5GC) 398. The NG-RAN 399 may include one or more gNodeBs (gNBs) connected to the 5GC via one or more NG interfaces (such as gNBs 300 and 350, connected via interfaces 302 and 352, respectively). More specifically, gNBs 300 and 350 may connect to one or more access and mobility management functions (AMFs) in the 5GC 398 via corresponding NG-C interfaces. Similarly, gNBs 300 and 350 may connect to one or more user plane functions (UPFs) in the 5GC 398 via corresponding NG-U interfaces.

[0093] Although not shown, in some deployments, the 5GC 398 may be replaced by the Evolved Packet Core (EPC), which is conventionally used with LTE E-UTRAN. In such deployments, the gNBs 300 and 350 may connect to one or more Mobility Management Entities (MMEs) in the EPC via corresponding S1-C interfaces. Similarly, the gNBs 300 and 350 may connect to one or more Serving Gateways (SGWs) in the EPC via corresponding NG-U interfaces.

[0094] Furthermore, 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 used for NG-RAN is often referred to as "New Radio" (NR). For the NR interface to the UE, each gNB may support frequency division duplex (FDD), time division duplex (TDD), or a combination thereof.

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

[0096] Figure 3 The NG-RAN logical nodes shown in 3GPP TS 38.401 v15.3.0 and described in 3GPP TR 38.801 v14.0.0 include a central unit (CU or gNB-CU) and one or more distributed units (DUs or gNB-DUs). For example, gNB 300 includes gNB-CU 310 and gNB-DUs 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 DUs. The DUs (e.g., gNB-DUs 320 and 330) are distributed logical nodes that host lower-layer protocols and may include various subsets of gNB functions depending on the functional split options. As such, each CU and DU may include various circuits necessary to perform their respective functions, including processing circuitry, transceiver circuitry (e.g., for communication), and power supply circuitry. Furthermore, the terms "central unit" and "centralized unit" are used interchangeably herein, as are the terms "distributed unit" and "decentralized unit."

[0097] gNB-CU through the corresponding F1 logical interface (such as Figure 3The F1 interface (shown in Figure 3) connects to one or more gNB-DUs. However, a gNB-DU can only be connected to a single gNB-CU. The gNB-CU and the connected gNB-DU(s) are visible only as gNBs to other gNBs and the 5GC. In other words, the F1 interface is not visible outside the gNB-CU. Furthermore, the F1 interface between the gNB-CU and gNB-DU is specified and / or based on the following general principles:

[0098] F1 is an open interface;

[0099] F1 supports the exchange of signaling information between corresponding endpoints and the transmission of data to corresponding endpoints;

[0100] From a logical standpoint, F1 is a point-to-point interface between endpoints (even in the absence of a physical direct connection between the endpoints);

[0101] F1 supports separation of the control plane (CP) and user plane (UP), allowing the gNB-CU to be separated in the CP and UP;

[0102] F1 separates the radio network layer (RNL) and the transport network layer (TNL);

[0103] F1 enables the exchange of user equipment (UE)-related information and non-UE-related information;

[0104] F1 is defined as future proof against new requirements, services and features;

[0105] The gNB terminates the X2, Xn, NG, and S1-U interfaces, and for the F1 interface between the DU and CU, utilizes the F1 application part protocol (F1-AP) defined in 3GPP TS 38.473 (v15.3.0).

[0106] Furthermore, the CU may host protocols such as RRC and PDCP, while the DU may host protocols such as RLC, MAC, and PHY. However, there may be other variations of protocol distribution between the CU and DU, such as hosting RRC, PDCP, and a portion of the RLC protocol in the CU (e.g., Automatic Repeat Request (ARQ) functionality), while hosting the remainder of the RLC protocol along with MAC and PHY in the DU. In some exemplary embodiments, the CU may host RRC and PDCP, where it is assumed that PDCP handles both UP traffic and CP traffic. However, other exemplary embodiments may utilize other protocol splits by hosting certain protocols in the CU and certain other protocols in the DU. Exemplary embodiments may also locate centralized control plane protocols (e.g., PDCP-C and RRC) in different CUs relative to centralized UP protocols (e.g., PDCP-U).

[0107] 3GPP has also agreed to support the separation of the gNB-CU into CU-CP functionality (including PDCP and RRC for signaling radio bearers) and CU-UP functionality (including PDCP for UP). The CU-CP and CU-UP functions can communicate with each other over the E1 interface using the E1-AP protocol. In addition to the new E1 interface, the F1 interface can also be logically divided into CP (F1-C) and UP (F1-U) functionalities. 3GPP TR 38.804 defines the following scenarios for splitting the CU-UP / CP:

[0108] CU-CP and CU-UP centralized;

[0109] CU-CP distributed and CU-UP centralized; and

[0110] CU-CP centralized and CU-UP distributed;

[0111] Similar to LTE, NR PHY uses CP-OFDM (Cyclic Prefix Orthogonal Frequency Division Multiplexing) in the DL and both CP-OFDM and DFT-spread OFDM (DFT-S-OFDM) in the UL. In the time domain, NR DL and UL physical resources are organized into 1-ms subframes of equal size. Each subframe consists of one or more slots, and each slot consists of 14 (for normal cyclic prefix) or 12 (for extended cyclic prefix) time-domain symbols.

[0112] As mentioned above, an RRC_CONNECTED UE can be configured by the network to perform measurements, and when measurement reporting is triggered, the network can send a handover (HO) command to the UE. In LTE, this command is an RRConnection-Reconfiguration message with a mobilityControlInfo field. In NR, this command is an RRCReconfiguration message with a reconfigurationWithSync field.

[0113] These reconfigurations are prepared by the handover target node based on a request from the source node, in LTE via the X2 or S1 interface (see e.g. Figure 1 ) exchange, or in the case of NR via the NG interface (see e.g. Figure 3 ) exchange. These reconfigurations typically take into account the existing RRC configuration that the UE has with the source cell, as provided in the inter-node request. These reconfiguration parameters provided by the target contain all the information the UE needs to access the target cell, such as the random access configuration, the new C-RNTI assigned by the target cell, and security parameters that enable the UE to calculate new security keys associated with the target cell. The new security keys enable the UE to send a ciphered and integrity-protected Handover Complete message on SRB1 when accessing the target cell.

[0114] However, this handover process has various robustness issues. For example, a HO command (e.g., RRCConnectionReconfiguration with mobilityControlInfo or RRCReconfiguration with reconfigurationWithSync) is normally sent when the UE's radio conditions are already quite poor. As such, the HO command may need to be segmented (e.g., to allow for redundancy to prevent 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 in time before the downgraded connection with the target node is disconnected.

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

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

[0117] As shown in Figure 4, there are three phases of the handover process: handover preparation, handover execution, and handover completion. During the handover preparation phase, the network prepares the target cell before the UE accesses it. 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 UE's handover with the target node (e.g., operations 3-5).

[0118] During handover execution, the source node provides the UE with various information to trigger a handover to a target cell served by the target node (operation 6), and also provides the target node with the UE's current state in 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., the parameters from which keys for ciphering / integrity protection are derived) for sending the HO Complete message (e.g., RRCConnection-ReconfigurationComplete). The source node provides the UE with the target C-RNTI so that the target node can identify the UE for the HO Complete message from the MAC-level random access message 3. This information is received from the target node during the handover preparation phase. Therefore, the target node does not need to perform UE context extraction unless a failure occurs.

[0119] Furthermore, to accelerate HO, the source node provides the UE with the necessary information on how to access the target node (e.g., RACH configuration), eliminating the need for the UE to obtain target node system information (e.g., from broadcast SI) prior to handover. Both full and incremental reconfiguration are supported, minimizing HO commands. Contention-free random access (CFRA) resources can be provided to the UE; in this case, the target node can identify the UE from the RACH preamble (also known as msg1). More generally, dedicated resources, such as CFRA resources, can be consistently used to optimize the normal HO process.

[0120] Also during the handover execution phase, the UE detaches 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). Concurrently with these operations, the source node delivers buffered user data for the UE to the target node, which can then pass the user data to the UE after the UE completes the handover.

[0121] During the handover completion phase, the target node and source node in the NG-RAN communicate with the 5GC (e.g., AMF) to update the path information associated with the UE (e.g., operations 9 and 11). Furthermore, nodes or functions within the 5GC (e.g., AMF and UPF) may communicate to update the UE path based on the handover (e.g., operation 10). Finally, the target node may notify the source node that it may release the UE's context (e.g., operation 12).

[0122] In LTE and NR, various solutions for increasing mobility robustness have been discussed. One solution being discussed for NR Rel-16 is called "conditional handover" or "early handover command." To avoid undesirable reliance on degraded radio conditions for the serving radio link when the UE should perform a handover, this solution offers the possibility of providing RRC signaling for handover to the UE earlier, before such degraded radio conditions occur. To achieve this, the HO command can be associated with a condition (e.g., a radio condition similar to that associated with an A3 event) where a given neighbor becomes X dB better than a target. Once the condition is met, the UE performs the handover according to the handover command provided earlier.

[0123] For example, an exemplary execution condition might be that the quality of the target cell or beam becomes X dB stronger than that of the serving cell. A previous measurement report event might use a threshold Y that is selected to be lower than the threshold in the handover execution condition. This allows the serving cell to prepare for the handover when the early measurement report is received and to provide an RRCConnectionReconfiguration (LTE) with mobilityControlInfo or an RRCReconfiguration with reconfigurationWithSync while the radio link between the source cell and the UE is still relatively stable. The handover is then performed at a later point in time (and threshold) that is optimal and / or preferred for the handover execution.

[0124] Figure 5 An exemplary signal flow between a user equipment (UE), a source node, and a target node for conditional handover (HO) according to an exemplary embodiment of the present disclosure is shown. The serving and target network nodes may be, for example, a gNB and / or components of a gNB, such as a CU and / or DU.

[0125] This process involves two different measurement thresholds: a low threshold and a high threshold. These two thresholds can be expressed as different levels of a specific metric, such as signal strength, signal quality, etc. For example, the high threshold could be when the quality of the Mobility RS (MRS) of the target cell or beam becomes X dB stronger than the quality of the MRS of the UE's serving cell (e.g., provided by the source node), where the low threshold is less than the high threshold (i.e., the target exceeds the source by a lower amount). As used in this context, MRS refers to a reference signal used for any mobility-related purpose. For example, in NR, an MRS can be an SSB (SS / PBCH block) or a CSI-RS. As a further example, for NR operating in unlicensed spectrum (referred to as NR-U), in addition to any of the signals mentioned above, the MRS can also be a Discovery Reference Signal (DRS).

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

[0127] The target node performs admission control for the UE and responds with a handover confirmation including the RRC configuration (operation 3), similar to the basic handover shown in Figure 4. 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 to perform measurements and, as long as the high threshold condition is met, it may move to the target node and perform handover (e.g., operations 5-7). However, the UE may also remain in the serving cell (i.e., provided by the source node) for an extended amount of time in case the high threshold condition is not met.

[0128] This procedure allows the serving cell to prepare for handover upon receipt of early measurement reports and provide a conditional HO command (e.g. RRCConnectionReconfiguration with mobilityControlInfo for LTE or RRCReconfiguration with reconfigurationWithSync or CellGroupConfig for NR) while 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 later time point (and threshold).

[0129] although Figure 5An example conditional handover involving a single serving cell and a single target cell is shown, but other scenarios may involve many 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 one or more of those candidates. The RRCConnectionReconfiguration for each of those candidates may be different in terms of the HO execution conditions (e.g., reference signals (RS) to be measured, thresholds exceeded, etc.) and / or the RA preamble to be sent when the conditions are met.

[0130] An alternative solution relies on UE context extraction, where conditions are also provided to the UE and when the conditions are met, the UE performs an RRC resumption procedure towards at least one target cell. In general, both conditional handover and this conditional resumption procedure are examples of conditional mobility procedures discussed herein.

[0131] In summary, in both NR and LTE, two inter-node messages are typically used for HO. The HandoverPreparationInformation message is used to transfer NR RRC information used by the target gNB during handover preparation, including UE capability information. When the source node decides to handover a UE, the source node provides the target node with information in the HandoverPreparationInformation message, which enables the target node to prepare an RRCReconfiguration message (later provided in the HandoverCommand) that the UE can use in the target node when the handover is performed.

[0132] Figure 6A shows an exemplary ASN.1 data structure describing the contents of a HandoverPreparationInformation message, and Figure 6B Provided a description Figure 6A Various tables showing the contents of the fields in the ASN.1 data structure of the HandoverCommand message. The HandoverCommand message is used to transfer the handover command generated by the target gNB to the source gNB. Figure 7 An exemplary ASN.1 data structure describing the contents of a HandoverCommand message is shown.

[0133] 3GPP TS 38.420 (v15.1.0) defines a function called "Handover Preparation Function," which allows information to be exchanged between source and target NG-RAN nodes to initiate a handover of a UE to the target. For Dual Connectivity (DC) setup, an equivalent function called "S-NG-RAN-node Add Preparation" exists. Furthermore, 3GPP TS 38.420 defines a "Handover Cancel Function," which allows an already prepared target NG-RAN node to be informed that the prepared handover will not take place. This allows the release of resources allocated during the preparation period.

[0134] Figure 8A The successful operation of the Handover Preparation function is shown. The source NG-RAN node initiates the procedure by sending a HANDOVERREQUEST message to the target NG-RAN node. When the source NG-RAN node sends the HANDOVERREQUEST message, it shall start the timer TXn RELOCprep Upon receiving the Handover Request message, the target NG-RAN node prepares the configuration of the AS security relationship between the UE and the target NG-RAN node by using the information in the AS Security Information IE and the UE Security Capabilities IE in the UE Context Information IE as specified in 3GPP TS 33.501 (v15.2.0).

[0135] Figure 8B Indicates unsuccessful operation of the handover preparation function. If the target NG-RAN node does not admit at least one PDU Session resource, or a failure occurs during handover preparation, the target NG-RAN node sends a HANDOVER PREPARATION FAILURE message to the source NG-RAN node. The message shall contain a Cause information element (IE) with an appropriate value. If the timer TXn is exceeded in the source NG-RAN node RELOCprep If there is no response to the Handover Request message from the target NG-RAN node before the expiration date, the source NG-RAN node shall cancel the Handover Preparation procedure towards the target NG-RAN node by initiating a Handover Cancel procedure with an appropriate value for the Cause IE. The source NG-RAN node ignores any Handover Request Acknowledgement (HANDOVER REQUEST ACKNOWLEDGE) or Handover Preparation Failure message received after initiating the Handover Cancel procedure and releases any resources related to the signalling associated with the involved Xn UE.

[0136] Furthermore, if the supported algorithms for ciphering defined in the UE Security Capability IE in the UE Context Information IE plus the mandatory support for EEA0 and NEA0 algorithms in all UEs (see, e.g., 3GPP TS 33.501 v15.2.0) do not match any allowed algorithms defined in the configured list of allowed ciphering algorithms in the NG-RAN node, the NG-RAN node rejects the procedure with a HANDOVER PREPARE FAILURE message. Similarly, if the supported algorithms for integrity defined in the UE Security Capability IE in the UE Context Information IE plus the mandatory support for EIA0 and NIA0 algorithms in all UEs (see, e.g., 3GPP TS 33.501 v15.2.0) do not match any allowed algorithms defined in the configured list of allowed integrity protection algorithms in the NG-RAN node, the NG-RAN node rejects the procedure with a HANDOVER PREPARE FAILURE message.

[0137] Figure 8C The successful operation of the Handover Cancel procedure is shown. As briefly mentioned above, this procedure enables the source NG-RAN node to cancel an ongoing handover preparation or an already prepared handover. If the HANDOVER CANCEL message refers to a non-existent context, the target NG-RAN shall ignore the message.

[0138] In conventional mobility procedures (e.g., handover), inter-node messaging between the source and target nodes can be inter-node RRC and / or X2 / Xn messaging, as described above. In existing conditional handover solutions, the source node requests the target node to prepare a conditional handover message for a candidate target cell. When the target node prepares this message, it also needs to reserve / prepare / allocate resources, such as the target C-RNTI, RACH (e.g., contention-free RACH resources), transmit power, bandwidth, etc. Furthermore, the target node needs to ensure that the services / bearers currently running on the UE are supported with minimum QoS in the target cell.

[0139] One issue with this solution is that the target does not actually know when the UE will meet the conditions that will trigger a handover or (for DC scenarios) a secondary cell group (SCG) change or SCG addition. Furthermore, because conditional handover can support the configuration of multiple target cell candidates, potentially from multiple target candidate nodes, a particular target candidate node is uncertain whether the UE will perform a handover to that node. Furthermore, because operating conditions (e.g., load) in mobile networks can be quite volatile, such operating conditions can vary significantly between the time a particular target candidate for conditional handover accepts a request from the source node and the time the UE performs the handover.

[0140] A solution has been proposed in 3GPP RAN2 WG contribution R2-1816691. This proposal introduces a timer to indicate to the UE how long the dedicated RACH resources allocated by the target candidate node for conditional handover will remain valid. This proposal focuses solely on RACH validity. Furthermore, it assumes that the target candidate node can predict the UL RACH load in the target cell so that the additional RACH resources allocated for conditional handover do not overwhelm RACH capacity. Typically, the target node may not be able to respond quickly to significant changes in load conditions.

[0141] Furthermore, in the case of multiple candidate targets, each target would have to provide its own timer value, which could be different. As such, in order to determine when the UE needs to be reconfigured with a new conditional HO configuration, the source node would have to receive and interpret messages with timer values ​​from the target candidate to the UE. These requirements are both complex and inefficient in terms of signaling overhead.

[0142] The exemplary embodiments of the present disclosure are directed to addressing these and other problems, challenges and / or issues by providing specific enhancements and / or improvements to mobility robustness in wireless communication networks. Generally speaking, the exemplary embodiments include techniques and / or mechanisms that enable a target node that has committed to accepting a UE in a conditional handover to cancel the commitment and subsequently use the resources previously allocated to the UE (e.g., C-RNTI, RACH resources, etc.) for other purposes and / or users. The exemplary embodiments also include techniques and / or mechanisms that enable a source node to update a UE to indicate that a previously provided conditional handover command associated with the target node is no longer valid. In response, the UE may cease handover-related actions toward the target node, such as measurements, monitoring, execution triggering conditions, etc.

[0143] Compared to existing techniques and / or mechanisms (including those described herein), exemplary embodiments of the present disclosure improve mobility robustness by facilitating conditional mobility operations (e.g., conditional handover) while giving the target node some control over the conditional mobility process via the ability to cancel and / or update a previous conditional mobility commitment in light of changes in the conditions under which the commitment was made. As such, exemplary embodiments improve the overall functionality and robustness of conditional mobility in wireless communication networks.

[0144] In this disclosure, the term "conditional mobility" is used to refer to various operations, such as conditional handover, conditional resumption, conditional synchronization reconfiguration, and conditional reconfiguration. More generally, "conditional mobility" is meant to include any UE mobility-related procedure (e.g., resumption, handover, synchronization reconfiguration, beam switching, etc.) that is configured by the network and contains conditions (e.g., associated with a measurement event) that, if triggered, causes the UE to perform the mobility-related procedure.

[0145] The exemplary embodiments disclosed herein are applicable to conditional mobility configurations associated with a single cell or multiple cells. For example, a cancellation mechanism triggered by a target node towards a source node may cancel any of the following alternatives:

[0146] For a single conditional handover of a single UE, the single UE uses a target cell in a target node as a candidate for conditional handover;

[0147] For multiple conditional handovers of a single UE, the single UE uses at least one target cell in the target node as a candidate for conditional handover;

[0148] For multiple conditional handovers of multiple UEs, the multiple UEs use at least one target cell in the target node as a candidate for conditional handover; or

[0149] For all conditional handovers of the plurality of UEs, the plurality of UEs take at least one target cell in the target node as a candidate for the conditional handover.

[0150] In general, exemplary embodiments are often described herein as being performed in an NR or LTE network. For example, the configuration of a UE's conditional HO is received and performed in an NR network. However, exemplary embodiments are also applicable to inter-RAT conditional mobility, such as:

[0151] The UE is configured with conditional HO in NR, then the condition is triggered and the UE performs HO in LTE;

[0152] The UE is configured for conditional HO in LTE, then the condition is triggered and the UE performs HO in NR; or

[0153] More generally, the UE is configured with conditional HO in RAT-1, then the condition is triggered and the UE performs HO in RAT-2.

[0154] Many of the UE (and network) operations described herein are based on handover or synchronous reconfiguration, which may include a cell change. However, exemplary embodiments are also applicable to scenarios where cells are added, such as multi-connectivity scenarios such as carrier aggregation (CA), dual connectivity (DC), multi-RAT dual connectivity, etc. In such cases, conditional mobility configurations may be used for SCG addition, SCell addition, etc.

[0155] The exemplary embodiments are also applicable to intra-cell conditional mobility procedures, such as synchronous reconfiguration with the same cell identity as the serving cell. In addition, inter-node procedures and / or messages supporting conditional mobility may include any of the following:

[0156] inter-node intra-RAT intra-system, such as NRgNB on Xn;

[0157] Inter-node intra-RAT system, such as ng-eNB on Xn;

[0158] Inter-node intra-RAT intra-system, such as LTE eNB on X2;

[0159] Inter-node inter-RAT system, such as ng-eNB and gNB on Xn; or

[0160] Inter-node, Inter-RAT, and Inter-system, such as E-UTRAN and NG-RAN, i.e., gNB / en-gNB and eNB on NG and S1.

[0161] Figure 9 An exemplary signaling flow for disassociation with a conditional mobility procedure (eg, conditional HO) according to certain exemplary embodiments is shown. Portions of this procedure may be specified by the exemplary text given in Appendix A. Figure 10 An exemplary signaling flow associated with updating a conditional mobility procedure (e.g., conditional HO) according to other exemplary embodiments is shown. Portions of the procedure may be specified by the exemplary text given in Appendix B. The text in Appendix A and / or B may be included in a 3GPP specification (e.g., 3GPP TS 38.423 v15.1.0). The following describes in more detail the following procedures associated with updating a conditional mobility procedure (e.g., conditional HO). Figure 9-10 Various exemplary embodiments of the associations of the various nodes shown in FIG.

[0162] The embodiments described above can be referred to Figure 13-15 Further explanation: Figure 13-15 Described are exemplary methods and / or processes performed by a first node in a RAN, a second node in a RAN, and a UE, respectively. In other words, the following reference is made to Figure 13-15 Various features of the operations described correspond to the various embodiments described above.

[0163] In particular, Figure 13Exemplary methods (eg, procedures) for mobility of a user equipment (UE) served by a second node in a RAN according to various exemplary embodiments of the present disclosure are illustrated. Figure 13 The example method shown in FIG may be performed by a first node (e.g., base station, eNB, gNB, etc.) in a RAN (e.g., E-UTRAN, NG-RAN) such as shown in and / or described with respect to other figures herein. Although the example method is Figure 13 Although the present invention is shown by specific blocks in a specific order, the operations corresponding to these blocks may be performed in an order different from that shown and may be combined and / or separated into blocks and / or operations having functionality different from that shown. Figure 13 The exemplary methods shown in can supplement other exemplary methods disclosed herein (e.g., Figure 14-15 ), so that they can be used in conjunction to provide benefits, advantages and / or solutions to the problems described herein. Optional boxes and / or operations are indicated by dashed lines.

[0164] The example method may include the operations of block 1310, wherein a first node may receive, from a second node, a request for a UE to perform a mobility procedure for at least one candidate target cell associated with the first node. In various embodiments, the mobility procedure may be any of the following: handover, recovery, reestablishment, synchronization reconfiguration, beam switching, and secondary cell (SCell) addition. For example, the request may be a message such as or similar to the conditional handover request described above.

[0165] The example method may also include the operation of block 1320, wherein the first node may determine whether the UE is acceptable for the requested mobility procedure, and if so, allocate resources to support the mobility of the UE. Examples of allocated resources may include bearers, bandwidth, radio resources, power, typical UL / DL resources, C-RNTI or any other UE identifier, RACH resources (e.g., preamble and / or UL time / frequency resources), etc.

[0166] The example method may also include the operation of block 1330, wherein the first node may transmit a response to the second node, the response including a configuration for the mobility procedure and indicating that the UE may accept the mobility procedure unless a cancellation message is subsequently received from the second node. In some embodiments, the configuration may include one or more conditions for triggering the UE to perform the mobility procedure. In some embodiments, the response may be an RRCReconfiguration message including a reconfigurationWithSync configuration, or an RRCConnection-Reconfiguration message including a mobilityControlInfo configuration.

[0167] In some embodiments, the example method may further include the operation of block 1340, wherein the first node may start a resource reservation timer associated with the allocated resources (e.g., the resources allocated in block 1320). For example, when performing a handover to the target node, the timer may be stopped upon receiving a handover complete message (e.g., RRCConnection-ReconfigurationComplete or RRCReconfigurationComplete) transmitted by the UE. The timer may also be stopped based on an indication that the allocated resources are no longer needed, such as indicated by receiving a cancellation message from the source node.

[0168] The exemplary method may also include the operation of block 1350, in which the first node may determine that the configuration is no longer valid. In some embodiments, this determination may be based on the expiration of the resource reservation timer started in block 1340. In other embodiments, the operations of block 1350 may include the operations of sub-blocks 1352-1354. In sub-block 1352, the first node may monitor the use of the allocated resources (e.g., the resources allocated in block 1320). In sub-block 1354, the first node may detect any of the following conditions during the monitoring: a resource overload condition; a need to use the allocated resources for another mobility procedure (e.g., handover, conditional handover, conditional recovery, conditional reestablishment, etc.); and / or other conditions related to resource usage.

[0169] The example method may also include the operation of block 1360, where the first node may transmit an indication to the source node that the configuration is no longer valid. In some embodiments, this operation may include transmitting a cancellation indication and the reason why the configuration is no longer valid (e.g., in sub-block 1362). The cancellation indication may be transmitted in response to the operation of block 1350, such as the expiration of a resource reservation timer (e.g., started in block 1340) or the detection of certain conditions (e.g., in sub-block 1354).

[0170] For example, the indication may be transmitted from the first node to the second node as a conditional handover cancel message, such as Figure 9 and 11 The message may include at least some of the information described below, which is further summarized in Table 1:

[0171] Message type identifier.

[0172] Identifier of the UE-source node relationship assigned at the source node, e.g. the source NG-RAN node UE XnAP ID in case of NG-RAN and XnAP protocol between the source and target nodes. This parameter uniquely identifies the UE on the Xn interface within the source NG-RAN node.

[0173] Identifier of the UE-target relationship assigned at the target node, e.g. the target NG-RAN node UE XnAP ID in case of NG-RAN and XnAP protocol between source and target nodes. This parameter uniquely identifies the UE on the Xn interface within the target NG-RAN node.

[0174] The reason for canceling the operation, for example, timer expiration, overload, etc. Table 2 below shows an exemplary information element (IE) that provides one possible way to convey the reason for canceling the operation, with further definitions provided in Tables 3-4 below.

[0175] Table 1

[0176] IE / Group Name IE Type / Chapter Reference Semantic Description Message Type 9.2.3.1 Source NG-RAN node UE XnAP ID NG-RAN node UE XnAP ID 9.2.3.16 Allocated at the source NG-RAN node Target NG-RAN node UE XnAP ID NG-RAN node UE XnAP ID 9.2.3.16 Allocated at the target NG-RAN node reason 9.2.3.2

[0177] Table 2

[0178]

[0179] Table 3

[0180]

[0181]

[0182] Table 4

[0183]

[0184]

[0185] Additional reason values ​​may be defined for cancel messages, such as:

[0186] Target timer expiry: expiry of a timer value indicating the validity of target cell resources allocated to the UE in a conditional handover; and / or

[0187] Load increase: The load in the target cell, eg, UL and / or DL, has increased such that a UE entering via conditional handover will not be accepted.

[0188] In other embodiments, the operations in block 1360 may include transmitting an updated configuration to the UE (e.g., in sub-block 1364). In addition to indicating that the configuration is no longer valid, the updated configuration may overwrite and / or replace the now invalid configuration. The updated configuration may be transmitted in response to the operations in block 1350, such as the expiration of a resource reservation timer (e.g., started in block 1340) or the detection of certain conditions (e.g., in sub-block 1354).

[0189] In some embodiments, the updated configuration may be transmitted from the first node to the second node as (or in) a conditional handover update message, such as Figure 10 and 12 Similar to the cancellation indication discussed above, the update message may contain any of the following information listed below:

[0190] Message type identifier.

[0191] Identifier of the UE-source node relationship assigned at the source node, e.g. the source NG-RAN node UE XnAP ID in case of NG-RAN and XnAP protocol between the source and target nodes. This parameter uniquely identifies the UE on the Xn interface within the source NG-RAN node.

[0192] Identifier of the UE-target relationship assigned at the target node, e.g. the target NG-RAN node UE XnAP ID in case of NG-RAN and XnAP protocol between source and target nodes. This parameter uniquely identifies the UE on the Xn interface within the target NG-RAN node.

[0193] An updated list of PDU session resources admitted to this UE.

[0194] An updated list of PDU session resources to which the UE is not admitted.

[0195] An updated HandoverCommand message reflecting the new conditions at the target node / cell.

[0196] Conditions used to trigger the UE to perform one or more updates of the mobility procedures.

[0197] Table 5 below provides further details on some of these information fields.

[0198] Table 5

[0199]

[0200] For example, if the PDU Session Resource Admit List IE or the PDU Session Resource Not Admit List IE is included in the Conditional Handover Update message, the source node shall update the list of PDU Session Resources that are admitted or not admitted by the target node. When the target node reports an unsuccessful establishment of a PDU Session Resource, the cause value shall be precise enough to enable the source node to understand the reason for the unsuccessful establishment. If a Transparent Container IE from the target NG-RAN node to the source NG-RAN node is included in the Conditional Handover Update message (e.g., containing a Handover Command message), the source node shall consider the Handover Command message to have been updated (e.g., due to a load) and shall act as defined in 3GPP TS 38.300 (v15.3.1).

[0201] also, Figure 14 An exemplary method (e.g., process) for mobility of a user equipment (UE) served by a second node in a RAN according to various exemplary embodiments of the present disclosure is shown. This exemplary method may be performed by a second node (e.g., base station, eNB, gNB, etc.) in a RAN (e.g., E-UTRAN, NG-RAN) such as shown in and / or described with respect to other figures herein. Although this exemplary method may be performed in Figure 14 Although the present invention is shown by specific blocks in a specific order, the operations corresponding to these blocks may be performed in an order different from that shown and may be combined and / or separated into blocks and / or operations having functionality different from that shown. Figure 14 The exemplary methods shown in can supplement other exemplary methods disclosed herein (e.g., Figure 13 and 15 ), so that they can be used in conjunction to provide benefits, advantages and / or solutions to the problems described herein. Optional boxes and / or operations are indicated by dashed lines.

[0202] The example method may also include the operation of block 1410, wherein the second node may transmit a request to the first node in the RAN for a mobility procedure for the UE regarding at least one candidate target cell associated with the first node. In various embodiments, the mobility procedure may be any of the following: handover, recovery, reestablishment, synchronization reconfiguration, beam switching, and secondary cell (SCell) addition. For example, the request may be a message such as or similar to the conditional handover request described above.

[0203] The exemplary method may also include the operation of block 1420, wherein the second node may receive a response from the first node that includes a configuration for the mobility procedure and indicates that the UE can accept it unless a cancellation message is subsequently received from the second node. In some embodiments, the configuration may include one or more conditions for triggering the UE to perform the mobility procedure. For example, an exemplary condition may be that the quality of the target cell becomes X dB better than the quality of the serving cell of the UE associated with the second node. In some embodiments, the response may be an RRCReconfiguration message including a reconfigurationWithSync configuration, or an RRCConnection-Reconfiguration message including a mobilityControlInfo configuration.

[0204] The exemplary method may also include the operations of blocks 1430-1450. In block 1430, the second node may transmit the configuration to the UE. In block 1440, the second node may receive an indication from the first node that the configuration is no longer valid. In block 1450, the second node may reconfigure the UE based on the indication.

[0205] In some embodiments, the indication that the configuration is no longer valid may include a cancellation indication and the reason why the configuration is no longer valid. For example, the cancellation indication may be received as a conditional handover cancellation message, such as Figure 9 and 11 In such an embodiment, the operation of block 1450 may include the operation of sub-block 1452, wherein the second node may cancel the mobility procedure. For example, canceling the mobility procedure may include sending a conditional handover canceled message to the UE, such as Figure 9 As shown in .

[0206] In other embodiments, the indication that the configuration is no longer valid may include an updated configuration for the mobility procedure. For example, the updated configuration may be received as (or in) a conditional handover update message, such as Figure 10 and 12 In such an embodiment, the operation of block 1450 may include the operation of sub-block 1454, wherein the second node may transmit the updated configuration to the UE. For example, the update may be sent to the UE as a conditional handover update message, such as Figure 10 In some embodiments, the update may utilize incremental signaling to modify, add, and / or remove specific fields and / or IEs of a previously provided conditional handover configuration.

[0207] In various embodiments, the updated configuration may include any of the following:

[0208] an updated list of PDU session resources of the UE admitted by the first node;

[0209] an updated list of PDU session resources of the UE to which access is not permitted by the first node;

[0210] An updated HandoverCommand message related to the current operating conditions of the candidate target cell; and

[0211] Conditions used to trigger the UE to perform one or more updates of the mobility procedures.

[0212] also, Figure 15 An exemplary method (e.g., process) performed by a user equipment (UE, e.g., a wireless device) served by a second node in a radio access network (RAN) according to various exemplary embodiments of the present disclosure is shown. The exemplary method may be performed by a UE such as shown in and / or described with respect to other figures herein. Although the exemplary method is not described in Figure 15 Although the present invention is shown by specific blocks in a specific order, the operations corresponding to these blocks may be performed in an order different from that shown and may be combined and / or separated into blocks having functionality different from that shown. Figure 15 The exemplary methods shown in can supplement other exemplary methods disclosed herein (e.g., Figure 13-14 ), so that they can be used in conjunction to provide benefits, advantages and / or solutions to the problems described herein. Optional boxes and / or operations are indicated by dashed lines.

[0213] This example method may include the operations of block 1510, wherein the UE may receive, from a second node (e.g., associated with the UE's serving cell), a configuration for a mobility procedure regarding at least one candidate target cell associated with a first node in the RAN. In various embodiments, the mobility procedure may be any of the following: handover, recovery, reestablishment, synchronization reconfiguration, beam switching, and SCell addition. In some embodiments, the configuration may include one or more conditions for triggering the execution of the mobility procedure. For example, an example condition may be that the quality of the candidate target cell (or beam) becomes X dB stronger than the UE's serving cell.

[0214] In some embodiments, the example method may further include the operation of block 1520, wherein the UE may perform radio resource management (RRM) measurements (e.g., of reference signals) to determine whether one or more conditions for triggering execution of the mobility procedure have been met. The example method may further include the operation of block 1530, wherein the UE may receive an indication from the second node that the configuration is no longer valid before the one or more conditions have been met.

[0215] In some embodiments, the indication that the configuration is no longer valid includes a cancellation indication and the reason why the configuration is no longer valid. For example, the indication may be received as (or in) a conditional handover canceled message, such as Figure 9 As shown in and described above. In such an embodiment, the exemplary method may also include the operation of block 1540, wherein the UE may cancel the mobility procedure associated with the configuration. For example, in response to the conditional handover canceled message, the UE may stop handover-related actions toward the target node, such as measuring, monitoring, performing triggering conditions, etc.

[0216] In other embodiments, the indication that the configuration is no longer valid may include an updated configuration for the mobility procedure. For example, the updated configuration may be received as (or in) a conditional handover updated message, such as Figure 10 , and as described above. In some embodiments, the updated configuration may incorporate and / or utilize incremental signaling to modify, add, and / or remove specific fields and / or IEs associated with the previously provided configuration. In such embodiments, the exemplary method may also include the operations of subblock 1550, where the UE may reconfigure mobility procedures associated with the configuration (e.g., in response to the Conditional Handover Updated message).

[0217] In various embodiments, the updated configuration may include any of the following:

[0218] an updated list of PDU session resources of the UE admitted by the first node;

[0219] an updated list of PDU session resources of the UE to which access is not permitted by the first node;

[0220] An updated HandoverCommand message related to the current operating conditions of the candidate target cell; and

[0221] Conditions used to trigger the UE to perform one or more updates of the mobility procedures.

[0222] In some of these embodiments, the exemplary method may further include the operation of block 1560, where the UE may perform a mobility procedure associated with the candidate target cell based on the updated configuration based on determining that one or more updated conditions have been met.

[0223] In some embodiments, as described above, the update may be received in response to the expiration of a resource reservation timer set by the target node. In other embodiments, as described above, the update may be received in response to the target node detecting a condition while monitoring its resource usage. For example, this may include detecting any of the following: an overload condition; a need to use the allocated resources for another handover, a conditional handover, or other conditional mobility operation (e.g., conditional recovery, conditional reestablishment, etc.); and / or other conditions related to resource usage.

[0224] While the subject matter described herein may be implemented in any suitable type of system using any suitable components, the embodiments disclosed herein relate to wireless networks such as Figure 16 For simplicity, Figure 16 The wireless network shown in FIG. 1 depicts only network 1606, network nodes 1660 and 1660b, and wireless devices (WDs) 1610, 1610b, and 1610c. In practice, a wireless network may further include any additional components suitable for supporting communications between wireless devices, or between a wireless device and another communication device, such as a landline telephone, a service provider, or any other network node or end device. Among the components shown, network node 1660 and wireless device (WD) 1610 are depicted with additional detail. A wireless network may provide communication and other types of services to one or more wireless devices to facilitate access and / or use by the wireless devices of services provided by or via the wireless network.

[0225] A wireless network may include and / or interface with any type of communication, telecommunication, data, cellular, and / or radio network or other similar type of system. In some embodiments, a wireless network may be configured to operate according to a particular standard or other type of predefined rules or procedures. Thus, particular embodiments of a 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 IEEE 802.11 standards; and / or any other suitable wireless communication standards such as Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, and / or ZigBee standards.

[0226] The network 1606 may include one or more backhaul networks, core networks, IP networks, public switched telephone networks (PSTNs), 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 that enable communication between devices.

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

[0228] Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs), and NR Node Bs (gNBs)). Base stations can be categorized based on the amount of coverage they provide (or, in other words, their transmit power level) and may also be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node that 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), sometimes referred to as a remote radio head (RRH). Such a remote radio unit 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).

[0229] Further examples of network nodes include multi-standard radio (MSR) equipment (such as an 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 transmission node, a multi-cell / multicast coordination entity (MCE), a core network node (e.g., an MSC, an MME), an O&M node, an OSS node, a SON node, a positioning node (e.g., an E-SMLC), and / or an MDT. As another example, a network node may be a virtual network node as described in more detail below. However, more generally, a network node may represent any suitable device (or group of devices) that is capable of, configured to, arranged to, and / or operable to enable and / or provide a wireless device with access to a wireless network or to provide a service to a wireless device that has accessed the wireless network.

[0230] exist Figure 16In FIG. 1 , the network node 1660 includes a processing circuit 1670, a device readable medium 1680, an interface 1690, an auxiliary device 1684, a power supply 1686, a power circuit 1687, and an antenna 1662. Figure 16 The network node 1660 shown in the example wireless network of FIG. 1660 may represent a device including the illustrated combination of hardware components, but other embodiments may include network nodes having different combinations of components. It is understood that the network node includes any suitable combination of hardware and / or software required to perform the tasks, features, functions, and methods and / or processes disclosed herein. Furthermore, although the components of the network node 1660 are depicted as being nested within multiple boxes or as a single box within a larger box, in reality, the network node may include multiple different physical components that make up the single illustrated component (e.g., the device readable medium 1680 may include multiple separate hard drives and multiple RAM modules).

[0231] Similarly, network node 1660 may be comprised of multiple physically separate components (e.g., a NodeB component and an RNC component, or a BTS component and a BSC component, etc.), each of which may have its own corresponding components. In certain scenarios where network node 1660 includes 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 multiple NodeBs. In such scenarios, each unique NodeB and RNC pair may be considered a single, separate network node in some instances. In some embodiments, network node 1660 may be configured to support multiple 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 all RATs). Network node 1660 may also include various combinations of the illustrated components for different wireless technologies integrated into 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 chipsets and other components within network node 1660 .

[0232] The processing circuit 1670 may be configured to perform any determination, calculation, or similar operation described herein as provided by the network node (e.g., certain obtaining operations). These operations performed by the processing circuit 1670 may include, for example, processing the information obtained by the processing circuit 1670 by converting it into other information, comparing the obtained information or the converted information with information stored in the network node, and / or performing one or more operations based on the obtained information or the converted information, and making a determination as a result of the processing.

[0233] The processing circuitry 1670 may include a combination of one or more of a microprocessor, a controller, a microcontroller, a central processing unit, a digital signal processor, an application specific integrated circuit, a field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software, and / or encoded logic operable to provide various functionality of the network node 1660, either alone or in conjunction with other network node 1660 components (e.g., device-readable media 1680). Such functionality may include providing any of the various wireless features, functions, or benefits discussed herein.

[0234] For example, processing circuit 1670 may execute instructions stored in device-readable medium 1680 or in a memory within processing circuit 1670. In some embodiments, 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 in medium 1680 may include instructions that, when executed by processor 1670, may configure network node 1660 to perform operations corresponding to the various exemplary methods (e.g., processes) described herein.

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

[0236] In certain 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 processing circuit 1670 executing instructions stored in memory within processing circuit 1670 or on device-readable medium 1680. In alternative embodiments, some or all of the functionality may be provided by processing circuit 1670 (e.g., in a hardwired manner) without executing instructions stored on a separate or discrete device-readable medium. In any of those embodiments, processing circuit 1670 may be configured to perform the described functionality regardless of whether instructions stored on a device-readable storage medium are executed. The benefits provided by such functionality are not limited to processing circuit 1670 alone or to other components of network node 1660, but may be enjoyed by network node 1660 as a whole and / or by end users and the wireless network generally.

[0237] Device-readable medium 1680 may include any form of volatile or non-volatile computer-readable memory, including, but not limited to, permanent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (e.g., a hard disk), removable storage media (e.g., a flash drive, a compact disk (CD), or a digital video disk (DVD)), and / or any other volatile or non-volatile, non-transitory, device-readable and / or computer-executable memory device for storing information, data, and / or instructions usable by processing circuit 1670. Device-readable medium 1680 may store any suitable instructions, data, or information, including computer programs, software, applications including one or more of logic, rules, code, tables, and / or other instructions executable by processing circuit 1670 and utilized by network node 1660. Device-readable medium 1680 may be used to store any computations performed by processing circuit 1670 and / or any data received via interface 1690. In some embodiments, the processing circuit 1670 and the device readable medium 1680 may be considered integrated.

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

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

[0240] Antenna 1662 may include one or more antennas or antenna arrays configured to transmit and / or receive wireless signals. Antenna 1662 may be coupled to radio front-end circuitry 1690 and may be any type of antenna capable of wirelessly transmitting and receiving data and / or signals. In some embodiments, antenna 1662 may include one or more omnidirectional, sectored, or flat panel antennas operable to transmit / receive radio signals between, for example, 2 GHz and 66 GHz. Omnidirectional antennas can be used to transmit / receive radio signals in any direction, sectored antennas can be used to transmit / receive radio signals from devices within a specific area, and flat panel antennas may be line-of-sight antennas for transmitting / receiving radio signals in a relatively straight line. In some instances, the use of more than one antenna may be referred to as MIMO. In certain embodiments, antenna 1662 may be separate from network node 1660 and may be connected to network node 1660 via an interface or port.

[0241] Antenna 1662, interface 1690, and / or processing circuitry 1670 may be configured to perform any receive operations and / or certain obtain operations described herein as being performed by a network node. Any information, data, and / or signals may be received from a wireless device, another network node, and / or any other network equipment. Similarly, antenna 1662, interface 1690, and / or processing circuitry 1670 may be configured to perform any transmit operations described herein as being performed by a network node. Any information, data, and / or signals may be transmitted to a wireless device, another network node, and / or any other network equipment.

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

[0243] Alternative embodiments of network node 1660 may include, in addition to Figure 16 , which may be responsible for providing certain aspects of the functionality of the network node, including any of the functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, network node 1660 may include user interface devices to allow and / or facilitate the input of information into network node 1660 and the output of information from network node 1660. This may allow and / or facilitate a user to perform diagnostics, maintenance, repair, and other management functions on network node 1660.

[0244] In some embodiments, a WD (e.g., WD 1610) 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 predetermined schedule when triggered by an internal or external event or in response to a request from the network. Examples of WDs include, but are not limited to, smartphones, mobile phones, cellular phones, voice over IP (VoIP) phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, game consoles or devices, music storage devices, rechargeable batteries, wearable devices, wireless endpoints, mobile stations, tablets, laptop computers, laptop embedded devices (LEEs), laptop mounted devices (LMEs), smart devices, wireless customer premises equipment (CPE), mobile machine communication (MTC) devices, Internet of Things (IoT) devices, vehicle-mounted wireless terminal devices, and the like.

[0245] A WD may, for example, support device-to-device (D2D) communication by implementing 3GPP standards for sidelink communication, vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-everything (V2X), and in this context may be referred to as a D2D communication device. As another specific example, in the Internet of Things (IoT) context, a WD may represent a machine or other device that monitors and / or measures other devices and transmits the results of such monitoring and / or measurement to another WD and / or network node. In this context, the WD may be a machine-to-machine (M2M) device, which in the 3GPP context may be referred to as an MTC device. As a specific example, a WD may be a UE that implements the 3GPP Narrowband Internet of Things (NB-IoT) standard. Specific examples of such machines or devices include sensors, metering devices (such as power meters), industrial machinery, household or personal appliances (e.g., refrigerators, televisions, etc.), and personal wearable devices (e.g., watches, fitness trackers, etc.). In other scenarios, a WD may represent a vehicle or other device capable of monitoring and / or reporting its operating status or other functions associated with its operation. As described above, WD may represent an endpoint of a wireless connection, in which case the device may be referred to as a wireless terminal. In addition, as described above, WD may be mobile, in which case it may also be referred to as a mobile device or a mobile terminal.

[0246] As shown, WD 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 supply 1636, and a power circuit 1637. WD 1610 may include multiple sets of one or more of the illustrated components for different wireless technologies supported by WD 1610, such as, for example, GSM, WCDMA, LTE, NR, WiFi, WiMax, or Bluetooth wireless technologies, to name a few. These wireless technologies may be integrated into the same or different chips or chipsets as other components within WD 1610.

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

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

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

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

[0251] As shown, processing circuitry 1620 includes one or more of the following: RF transceiver circuitry 1622, baseband processing circuitry 1624, and application processing circuitry 1626. In other embodiments, the processing circuitry may include different components and / or different combinations of components. In certain embodiments, processing circuitry 1620 of WD 1610 may include a system-on-chip (SoC). In some embodiments, RF transceiver circuitry 1622, baseband processing circuitry 1624, and application processing circuitry 1626 may be implemented on separate chips or chipsets. In alternative embodiments, part or all of baseband processing circuitry 1624 and application processing circuitry 1626 may be combined into a single chip or chipset, and RF transceiver circuitry 1622 may be implemented on a separate chip or chipset. In still other alternative embodiments, part or all of RF transceiver circuitry 1622 and baseband processing circuitry 1624 may be implemented on the same chip or chipset, and application processing circuitry 1626 may be implemented on a separate chip or chipset. In still other alternative embodiments, part or all of RF transceiver circuitry 1622, baseband processing circuitry 1624, and application processing circuitry 1626 may be combined in the same chip or chipset. In some embodiments, RF transceiver circuitry 1622 may be part of interface 1614. RF transceiver circuitry 1622 may condition RF signals for processing circuitry 1620.

[0252] In certain embodiments, some or all of the functionality described herein as being performed by the WD may be provided by processing circuitry 1620 executing instructions stored on device-readable medium 1630, which in certain embodiments may be a computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by processing circuitry 1620 (e.g., in a hardwired manner) without executing instructions stored on a separate or discrete device-readable storage medium. In any of those specific embodiments, processing circuitry 1620 may be configured to perform the described functionality regardless of whether or not instructions are executed on a device-readable storage medium. The benefits provided by such functionality are not limited to processing circuitry 1620 alone or to other components of WD 1610, but may be enjoyed by WD 1610 as a whole and / or by end users and the wireless network generally.

[0253] Processing circuitry 1620 may be configured to perform any determinations, calculations, or similar operations described herein as being performed by the WD (e.g., certain acquisition operations). These operations, as performed by processing circuitry 1620, may include, for example, processing the information obtained by processing circuitry 1620 by transforming it into other information, comparing the obtained or transformed information with information stored by WD 1610, and / or performing one or more operations based on the obtained or transformed information, and making determinations as a result of the processing.

[0254] Device-readable medium 1630 can be operable to store computer programs, software, applications including one or more of logic, rules, code, tables, etc., and / or other instructions executable by processing circuit 1620. Device-readable medium 1630 can include computer memory (e.g., random access memory (RAM) or read-only memory (ROM)), mass storage media (e.g., a hard disk), removable storage media (e.g., a 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 usable by processing circuit 1620. In some embodiments, processing circuit 1620 and device-readable medium 1630 can be considered integrated.

[0255] User interface device 1632 may include components that allow and / or facilitate interaction between a human user and WD 1610. Such interaction can take various forms, such as visual, auditory, tactile, and the like. User interface device 1632 can be operable to generate output to the user and allow and / or facilitate the user providing input to WD 1610. The type of interaction may vary depending on the type of user interface device 1632 installed in WD 1610. For example, if WD 1610 is a smartphone, interaction may occur via a touchscreen; if WD 1610 is a smart meter, interaction may occur through a screen that provides usage information (e.g., gallons used) or a speaker that provides an audible alarm (e.g., if smoke is detected). User interface device 1632 may include input interfaces, devices, and circuitry, as well as output interfaces, devices, and circuitry. User interface device 1632 may be configured to allow and / or facilitate the input of information into WD 1610 and be connected to processing circuitry 1620 to allow and / or facilitate processing of the input information by processing circuitry 1620. User interface device 1632 may include, for example, a microphone, a proximity sensor or other sensor, a key / button, a touch display, one or more cameras, a USB port, or other input circuitry. User interface device 1632 is also configured to allow and / or facilitate output of information from WD 1610 and to allow and / or facilitate output of information from processing circuitry 1620 from WD 1610. User interface device 1632 may include, for example, a speaker, a display, a vibration circuit, a USB port, a headphone jack, or other output circuitry. Using one or more input and output interfaces, devices, and circuitry of user interface device 1632, WD 1610 may communicate with an end user and / or wireless network and allow and / or facilitate them to benefit from the functionality described herein.

[0256] Auxiliary devices 1634 may be operable to provide more specialized functionality not typically performed by a WD. This may include specialized sensors for taking measurements for various purposes, interfaces for additional types of communication such as wired communication, etc. The inclusion and types of components of auxiliary devices 1634 may vary depending on the embodiment and / or scenario.

[0257] In some embodiments, power source 1636 may take the form of a battery or battery pack. Other types of power sources may also be used, such as an external power source (e.g., an electrical outlet), a photovoltaic device, or a power cell. WD 1610 may further include power circuitry 1637 for delivering power from power source 1636 to various components of WD 1610 that require power from power source 1636 to perform any functionality described or indicated herein. In some embodiments, power circuitry 1637 may include power management circuitry. Power circuitry 1637 may additionally or alternatively be operable to receive power from an external power source; in this case, WD 1610 may be connectable to the external power source (such as an electrical outlet) via an input circuit or interface (such as a power cable). In some embodiments, power circuitry 1637 may also be operable to deliver power from the external power source to power source 1636. This may be used, for example, to charge power source 1636. Power circuitry 1637 may perform any conversion or other modification of the power from power source 1636 to make it suitable for supply to the corresponding components of WD 1610.

[0258] Figure 17 One embodiment of a UE according to various aspects described herein is shown. As used herein, a user equipment or UE may not necessarily have a user in the sense of a human user who owns and / or operates the associated device. Rather, a UE may represent a device that is intended to be sold to or operated by a human user, but that may not be, or may not initially be, associated with a particular human user (e.g., a smart sprinkler controller). Alternatively, a UE may represent a device that is not intended to be sold to or operated by an end user, but that may be associated with or operated for the benefit of a user (e.g., a smart meter). UE 17200 may be any UE identified by 3GPP, including NB-IoT UE, Machine Type Communication (MTC) UE, and / or Enhanced MTC (eMTC) UE. As Figure 17 The UE 1700 shown in FIG is an example of a WD configured to communicate in accordance with one or more communication standards promulgated by 3GPP, such as 3GPP's GSM, UMTS, LTE, and / or 5G standards. As previously mentioned, the terms WD and UE are used interchangeably. Therefore, although Figure 17 It is a UE, but the components discussed in this article are also applicable to WD, and vice versa.

[0259] exist Figure 17In the embodiment, UE 1700 includes a processing circuit 1701, which is operatively coupled to an input / output interface 1705, a radio frequency (RF) interface 1709, a network connection interface 1711, a memory 1715 including a random access memory (RAM) 1717, a read-only memory (ROM) 1719, and a storage medium 1721, a communication subsystem 1731, a power supply 1733, and / or any other components or any combination thereof. The storage medium 1721 includes an operating system 1723, an application 1725 (e.g., including executable instructions corresponding to the operations of any of the exemplary methods disclosed herein), and data 1727. In other embodiments, the storage medium 1721 may include other similar types of information. Some UEs may utilize Figure 17 All of the components shown in the , or only a subset of the components may be utilized. The level of integration between components may vary from one UE to another. In addition, some UEs may include multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0260] exist Figure 17 In the present invention, processing circuitry 1701 can be configured to process computer instructions and data. Processing circuitry 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, an FPGA, an ASIC, etc.); programmable logic along with appropriate firmware; one or more stored-program, general-purpose processors (such as a microprocessor or a digital signal processor (DSP)) along with appropriate software; or any combination of the foregoing. For example, processing circuitry 1701 may include two central processing units (CPUs). Data can be information in a form usable by a computer.

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

[0262] exist Figure 17 RF interface 1709 can be configured to provide a communication interface to RF components (such as a transmitter, receiver, and antenna). Network connection interface 1711 can be configured to provide a communication interface to network 1743a. Network 1743a can include wired and / or wireless networks, such as a local area network (LAN), a wide area network (WAN), a computer network, a wireless network, a telecommunications network, another similar network, or any combination thereof. For example, network 1743a can include a Wi-Fi network. Network connection interface 1711 can be configured to include receiver and transmitter interfaces for communicating 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.). Network connection interface 1711 can implement receiver and transmitter functionality suitable for a communication network link (e.g., optical, electrical, etc.). The transmitter and receiver functionality can share circuit components, software, or firmware, or alternatively, can be implemented separately.

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

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

[0265] Storage medium 1721 can be configured to include multiple physical drive units, such as a redundant array of independent disks (RAID), a floppy disk drive, flash memory, a USB flash drive, an external hard drive, a thumb drive, a pen drive, a key drive, a High-Density Digital Versatile Disk (HD-DVD) optical drive, an internal hard drive, a Blu-ray Disc drive, a Holographic Digital Data Storage (HDDS) optical drive, an external mini dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), an external micro-DIMM SDRAM, smart card memory (such as a subscriber identity module or removable user identity (SIM / RUIM) module), other memory, or any combination thereof. Storage medium 1721 can enable and / or facilitate UE 1700 to access computer-executable instructions, applications, and the like stored on transitory or non-transitory storage media to download or upload data. An article of manufacture (such as one utilizing a communication system) can be tangibly embodied in storage medium 1721, which may include device-readable media.

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

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

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

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

[0270] 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. Additionally, in embodiments where the virtual node is not a radio access node, or does not require radio connectivity (e.g., a core network node), then the network node may be fully virtualized.

[0271] These functions may be implemented by one or more applications 1820 (alternatively 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 run in a virtualized environment 1800, which provides hardware 1830 including processing circuitry 1860 and memory 1890. The memory 1890 contains instructions 1895 executable by the processing circuitry 1860, whereby the applications 1820 are operable to provide one or more of the features, benefits, and / or functions disclosed herein.

[0272] Virtualized environment 1800 includes general-purpose or specialized network hardware devices 1830, which include a set of one or more processors or processing circuits 1860. Processors or processing circuits 1860 may be commercial off-the-shelf (COTS) processors, specialized application-specific integrated circuits (ASICs), or any other type of processing circuitry including digital or analog hardware components or specialized processors. Each hardware device may include memory 1890-1, which may be non-volatile memory for temporarily storing software or instructions 1895 executed by processing circuit 1860. For example, instructions 1895 may include program instructions (also referred to as a computer program product) that, when executed by processing circuit 1860, configure hardware node 1820 to perform operations corresponding to the various exemplary methods (e.g., processes) described herein. Such operations may also be attributable to the virtual node(s) 1820 hosted by hardware node 1830.

[0273] Each hardware device may include one or more network interface controllers (NICs) 1870 (also referred to as network interface cards), which include a physical network interface 1880. Each hardware device may also include a non-transitory, persistent, machine-readable storage medium 1890-2 having stored therein instructions and / or software 1895 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 executing virtual machines 1840, and software that enables them to perform the functions, features, and / or benefits described in connection with some embodiments described herein.

[0274] The virtual machines 1840 include virtual processing, virtual memory, virtual networking or interfaces, and virtual storage devices, and can be run by corresponding virtualization layers 1850 or hypervisors. Different embodiments of instances of the virtual appliances 1820 can be implemented on one or more of the virtual machines 1840, and the implementation can be done in different ways.

[0275] During operation, 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). Virtualization layer 1850 may present a virtual operating platform that appears to be networked hardware to virtual machines 1840.

[0276] like Figure 18 As shown in FIG, hardware 1830 can be a standalone network node with common or specialized components. Hardware 1830 can include antennas 18225 and can implement some functionality via virtualization. Alternatively, hardware 1830 can be part of a larger hardware cluster (e.g., such as in a data center or customer premises equipment (CPE)) where many hardware nodes work together and are managed via management and orchestration (MANO) 18100, which, among other things, oversees the lifecycle management of applications 1820.

[0277] Hardware virtualization is sometimes referred to as Network Function Virtualization (NFV). NFV can be used to consolidate many network device types onto industry-standard high-volume server hardware, physical switches, and physical storage devices, which can be located in data centers and customer premises.

[0278] In the context of NFV, a virtual machine 1840 can be a software implementation of a physical machine that runs programs as if they were executed on a physical, non-virtualized machine. Each of the virtual machines 1840 and the portion of the hardware 1830 on which it executes (whether it is hardware dedicated to that virtual machine and / or hardware shared by that virtual machine and other virtual machines in the virtual machines 1840) form a separate virtual network element (VNE).

[0279] Still in the context of NFV, a virtual network function (VNF) is responsible for handling specific network functions running in one or more virtual machines 1840 on top of the hardware networking infrastructure 1830 and is associated with Figure 18 Corresponding to application 1820.

[0280] 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 the hardware nodes 1830 via one or more appropriate network interfaces and may be used in combination with virtual components to provide radio capabilities to a virtual node, such as a radio access node or base station.

[0281] In some embodiments, some signaling may be accomplished using a control system 18230 , which may alternatively be used for communications between the hardware node 1830 and the radio unit 18200 .

[0282] refer to Figure 19 According to an embodiment, a communications system includes a telecommunications network 1910, such as a 3GPP-type cellular network, including an access network 1911, such as a radio access network, and a core network 1914. Access network 1911 includes multiple base stations 1912a, 1912b, and 1912c, such as NBs, eNBs, gNBs, or other types of wireless access points, each defining a corresponding coverage area 1913a, 1913b, and 1913c. Each base station 1912a, 1912b, and 1912c can be connected to core network 1914 via a wired or wireless connection 1915. A first UE 1991 located in coverage area 1913c can be configured to wirelessly connect to or be paged by the corresponding base station 1912c. A second UE 1992 located in coverage area 1913a can be wirelessly connected to the corresponding base station 1912a. Although multiple UEs 1991 , 1992 are shown in this example, the disclosed embodiments are equally applicable to situations where a single UE is in the coverage area or where a single UE is connecting to the corresponding base station 1912 .

[0283] Telecommunications network 1910 itself is connected to a host computer 1930, which may be embodied in the hardware and / or software of a standalone server, a cloud-enabled server, a distributed server, or as processing resources in a server farm. Host computer 1930 may be under the ownership or control of a service provider, or may be operated by or on behalf of the service provider. Connections 1921 and 1922 between telecommunications network 1910 and host computer 1930 may extend directly from core network 1914 to host computer 1930, or may be via an optional intermediary network 1920. Intermediary network 1920 may be one or a combination of public, private, or managed networks; if present, intermediary network 1920 may be a backbone network or the Internet; in particular, intermediary network 1920 may include two or more subnetworks (not shown).

[0284] Figure 19The communication system as a whole enables connectivity between connected UEs 1991, 1992 and a host computer 1930. This connectivity can be described as an over-the-top (OTT) connection 1950. The host computer 1930 and the 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 possibly additional infrastructure (not shown) as intermediaries. The OTT connection 1950 can be transparent, in the sense that the 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 or need not be informed of the past routing of incoming downlink communications containing data originating from the host computer 1930 to be forwarded (e.g., handed off) to the connected UE 1991. Similarly, base station 1912 need not be aware of the future routing of outgoing uplink communications originating from UE 1991 toward host computer 1930 .

[0285] According to the embodiment, reference will now be made to Figure 20 An example implementation of the UE, base station, and host computer discussed in the previous paragraphs is described. In communication system 2000, host computer 2010 includes hardware 2015, which includes a communication interface 2016 configured to establish and maintain wired or wireless connections to interface with various communication devices of communication system 2000. Host computer 2010 further includes processing circuitry 2018, which may have storage and / or processing capabilities. In particular, processing circuitry 2018 may include one or more programmable processors, application-specific integrated circuits, field-programmable gate arrays, or a combination thereof (not shown) adapted to execute instructions. Host computer 2010 further includes software 2011, which is stored in or accessible by host computer 2010 and executable by processing circuitry 2018. Software 2011 includes a host application 2012. Host application 2012 may be operable to provide services to remote users (such as UE 2030 connected via an OTT connection 2050 terminating between UE 2030 and host computer 2010). In providing services to remote users, the host application 2012 may provide user data transmitted using the OTT connection 2050 .

[0286] The communication system 2000 may also include a base station 2020, which is provided in the telecommunications system and includes hardware 2025 that enables it to communicate with the host computer 2010 and the UE 2030. The hardware 2025 may include a communication interface 2026 for establishing and maintaining a wired or wireless connection with different communication devices of the communication system 2000, and for establishing and maintaining a connection with at least a network located in the coverage area ( Figure 20 The communication interface 2026 may be configured to facilitate a connection 2060 to the host computer 2010. The connection 2060 may be direct, or it may pass through a core network (e.g., a core network of the telecommunications system) of the telecommunications system. Figure 20 (not shown) and / or through one or more intermediate networks external to the telecommunications system. In the illustrated embodiment, the hardware 2025 of the base station 2020 may also include processing circuitry 2028, which may include one or more programmable processors, application specific integrated circuits, field programmable gate arrays, or a combination thereof (not shown) adapted to execute instructions.

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

[0288] The communication system 2000 may also include the already mentioned UE 2030, whose hardware 2035 may include a radio interface 2037 configured to establish and maintain a wireless connection 2070 with a base station serving the coverage area in which the UE 2030 is currently located. The hardware 2035 of the UE 2030 may also include a processing circuit 2038, which may include one or more programmable processors, application specific integrated circuits, field programmable gate arrays, or a combination of these (not shown) suitable for executing instructions.

[0289] UE 2030 also includes software 2031, which is stored in or accessible by UE 2030 and executable by processing circuitry 2038. Software 2031 includes a client application 2032. Client application 2032 may be operable to provide services to human or non-human users via UE 2030 with the support of host computer 2010. Within host computer 2010, an executing host application 2012 may communicate with the executing client application 2032 via an OTT connection 2050 terminated between UE 2030 and host computer 2010. In providing services to users, client application 2032 may receive request data from host application 2012 and provide user data in response to the request data. OTT connection 2050 may transfer both the request data and the user data. Client application 2032 may interact with the user to generate the user data it provides. The software 2031 may also include program instructions (also referred to as a computer program product) that, when executed by the processing circuit 2038 , may configure the UE 2030 to perform operations corresponding to the various exemplary methods (eg, procedures) described herein.

[0290] Notice, Figure 20 The host computer 2010, base station 2020, and UE 2030 shown in FIG may be similar to or identical to Figure 19 The host computer 1930, one of the base stations 1912a, 1912b, 1912c and one of the UEs 1991, 1992. That is, the internal workings of these entities may be as follows: Figure 20 As shown in , and independently, the surrounding network topology can be Figure 19 network topology.

[0291] exist Figure 20 In FIG, OTT connection 2050 has been abstractly drawn to illustrate communication between host computer 2010 and UE 2030 via base station 2020, without explicitly mentioning any intermediary devices and the precise routing of messages via these devices. The network infrastructure may determine the routing, which may be configured to be hidden from UE 2030, the service provider operating host computer 2010, or both. While OTT connection 2050 is active, the network infrastructure may further make decisions that dynamically change the routing (e.g., based on network reconfiguration or load balancing considerations).

[0292] A wireless connection 2070 between a UE 2030 and a base station 2020 is provided in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of over-the-top (OTT) services provided to the UE 2030 using an OTT connection 2050, with the wireless connection 2070 forming the final segment. More specifically, the exemplary embodiments disclosed herein may improve the network's flexibility in monitoring the end-to-end quality of service (QoS) of data flows 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), including their corresponding radio bearers. These and other advantages may facilitate more timely design, implementation, and deployment of 5G / NR solutions. Furthermore, such embodiments may facilitate flexible and timely control of data session QoS, which may lead to the improvements in capacity, throughput, latency, etc. envisioned by 5G / NR and important for the growth of OTT services.

[0293] A measurement process may be provided for the purpose of monitoring data rates, latency, and other aspects of network operation improved by one or more embodiments. Optional network functionality may further be provided for reconfiguring the OTT connection 2050 between the host computer 2010 and the UE 2030 in response to changes in measurement results. The measurement process and / or network functionality for reconfiguring the OTT connection 2050 may be implemented using software 2011 and hardware 2015 of the host computer 2010, software 2031 and hardware 2035 of the UE 2030, or both. In embodiments, sensors (not shown) may be deployed in or associated with the communication devices through which the OTT connection 2050 passes. The sensors may participate in the measurement process by supplying values ​​for the monitored quantities exemplified above, or values ​​for other physical quantities from which the software 2011 or 2031 calculates or estimates the monitored quantities. Reconfiguration of the OTT connection 2050 may include message formats, retransmission settings, preferred routing, and the like. The reconfiguration need not affect the base station 2020 and may be unknown or imperceptible to the base station 2020. Such processes and functionality may be known and practiced in the art. In certain embodiments, the measurements may involve proprietary UE signaling that facilitates host computer 2010 to measure throughput, propagation time, latency, etc. The measurements may be achieved because software 2011 and 2031 uses OTT connection 2050 to cause messages (particularly empty or 'dummy' messages) to be transmitted while it monitors propagation time, errors, etc.

[0294] Figure 21 is a flow chart illustrating an exemplary method and / or process implemented in a communication system according to one embodiment. The communication system includes a host computer, a base station, and a UE. In some exemplary embodiments, the host computer, the base station, and the UE may be reference Figure 19and 20 To simplify this disclosure, only the host computers, base stations, and UEs described herein will be included in this section. Figure 21 Reference is made to the accompanying drawings. In step 2110, the host computer provides user data. In sub-step 2111 of step 2110 (which may be optional), 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), in accordance with the teachings of the embodiments described throughout this disclosure, the base station transmits the user data carried in the host computer-initiated transmission to the UE. In step 2140 (which may also be optional), the UE executes a client application associated with the host application executed by the host computer.

[0295] Figure 22 is a flow chart illustrating an exemplary method and / or process 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 a reference Figure 19 and 20 To simplify this disclosure, only the host computers, base stations, and UEs described herein will be included in this section. Figure 22 Reference is made to the accompanying drawings. In step 2210 of the method, a 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. According to the teachings of the embodiments described throughout this disclosure, the transmission may be delivered via a base station. In step 2230 (which may be optional), the UE receives the user data carried in the transmission.

[0296] Figure 23 is a flow chart illustrating an exemplary method and / or process 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 a reference Figure 19 and 20 To simplify this disclosure, only the host computers, base stations, and UEs described herein will be included in this section. Figure 23Reference is made to the accompanying drawings. 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 input data received from the host computer. In providing the user data, the executed client application may further consider user input received from the user. Regardless of the specific manner in which the user data is provided, in sub-step 2330 (which may be optional), the UE initiates transmission of the user data to the host computer. In step 2340 of the method, the host computer receives the user data transmitted from the UE in accordance with the teachings of the embodiments described throughout this disclosure.

[0297] Figure 24 is a flow chart illustrating an exemplary method and / or process 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 a reference Figure 19 and 20 To simplify this disclosure, only the host computers, base stations, and UEs described herein will be included in this section. Figure 24 Reference is made to the accompanying drawings. In step 2410 (which may be optional), in accordance with the teachings of the embodiments described throughout this disclosure, the base station receives user data from the UE. 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.

[0298] The foregoing merely illustrates the principles of the present disclosure. In light of the teachings herein, various modifications and variations to the described embodiments will be readily apparent to those skilled in the art. Thus, it will be appreciated that those skilled in the art will be able to devise numerous systems, arrangements, and processes that, although not explicitly shown or described herein, embody the principles of the present disclosure and are thus within the spirit and scope of the present disclosure. As will be appreciated by those skilled in the art, the various exemplary embodiments may be used together and interchangeably with one another.

[0299] The term "unit" as used herein may have the conventional meaning in the field of electronics, electrical devices and / or electronic devices, and may include, for example, electrical and / or electronic circuits, devices, modules, processors, memories, logical solid-state and / or discrete devices, computer programs or instructions for performing corresponding tasks, processes, calculations, output and / or display functions, etc., such as those described herein.

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

[0301] As described herein, a device and / or apparatus may be represented by a semiconductor chip, a chipset, or a (hardware) module comprising such a chip or chipset; however, this does not exclude the possibility that the functionality of the device or apparatus is not implemented by hardware, but rather as a software module, such as a computer program or computer program product, which includes executable software code portions for execution or running on a processor. In addition, 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 an assembly of multiple devices and / or apparatuses, whether functionally cooperating with each other or independent of each other. In addition, devices and apparatuses may be implemented in a distributed manner throughout the system, as long as the functionality of the device or apparatus is retained. Such and similar principles are considered to be known to those skilled in the art.

[0302] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. It will be further understood that, unless expressly defined otherwise herein, the terms used herein should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this specification, and will not be interpreted in an idealized or overly formal sense.

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

[0304] Example embodiments of the techniques and devices described herein include, but are not limited to, the following enumerated examples:

[0305] 1. A method for conditional mobility of a user equipment (UE), performed by a network node as a target node candidate, the method comprising:

[0306] receiving, from a source node serving the UE, a request to prepare a conditional mobility procedure for the UE with respect to a candidate target cell associated with a target node;

[0307] determining whether the UE is acceptable for the requested conditional mobility procedure, and if the UE is acceptable, allocating resources to support conditional mobility of the UE;

[0308] transmitting a response to the received request to the source node, the response including the conditional mobility configuration and indicating that the UE is acceptable unless a cancellation message is subsequently received from the source node;

[0309] determining that the conditional mobility configuration is no longer valid; and

[0310] An indication is transmitted to the source node that the conditional handover configuration is no longer valid.

[0311] 2. The method of embodiment 1 further comprises: starting a resource reservation timer associated with the allocated resources.

[0312] 3. The method of embodiment 2, wherein determining that the conditional mobility configuration is no longer valid is based on expiration of a resource reservation timer.

[0313] 4. The method of embodiment 1 further comprises: monitoring usage of allocated resources in the target cell.

[0314] 5. The method of embodiment 2, wherein determining that the conditional mobility configuration is no longer valid is based on detecting any of the following conditions during the monitoring: a resource overload condition and a need to use the allocated resources for another mobility procedure.

[0315] 6. The method of any of embodiments 1-5, wherein the indication that the conditional mobility configuration is no longer valid includes a cancellation indication and a reason why the conditional handover configuration is invalid.

[0316] 7. The method of any of embodiments 1-5, wherein the indication that the conditional mobility configuration is no longer valid further comprises an updated conditional mobility configuration for the UE.

[0317] 8. The method of embodiment 7, wherein the updated conditional mobility configuration includes one or more of the following:

[0318] The UE's updated list of PDU session resources admitted by the target node;

[0319] An updated list of the UE's PDU session resources that are not admitted by the target node;

[0320] An updated HandoverCommand message related to the current operating conditions of the target cell; and

[0321] One or more updated conditions under which the UE may perform the conditional mobility procedure.

[0322] 9. The method of any of embodiments 1-8, wherein the conditional mobility procedure comprises one of the following procedures: handover, resumption, re-establishment, synchronization reconfiguration, beam switching, and secondary cell (SCell) addition.

[0323] 10. A method, performed by a source node, for conditional mobility of a user equipment (UE) served by the source node, the method comprising:

[0324] transmitting, to the target node, a request to prepare a conditional mobility procedure of the UE with respect to a candidate target cell associated with the target node;

[0325] receiving a response to the request from the target node, the response including the conditional mobility configuration and indicating that the UE is acceptable unless a cancel message is subsequently received from the source node;

[0326] Configuring the UE with the conditional mobility configuration received from the target node;

[0327] receiving an indication from the target node that the conditional mobility configuration is no longer valid; and

[0328] The UE is reconfigured based on the indication.

[0329] 11. The method of embodiment 10, wherein:

[0330] The indication that the conditional mobility configuration is no longer valid includes a cancellation indication and a reason why the conditional mobility configuration is invalid; and

[0331] Reconfiguring the UE based on the received indication includes canceling the conditional mobility procedure.

[0332] 12. The method of embodiment 10, wherein:

[0333] The indication of the conditional handover configuration further includes an updated conditional mobility configuration of the UE; and

[0334] Reconfiguring the UE based on the received indication includes transmitting an updated conditional mobility configuration to the UE.

[0335] 13. The method of embodiment 12, wherein the updated conditional mobility configuration includes one or more of the following:

[0336] The UE's updated list of PDU session resources admitted by the target node;

[0337] An updated list of the UE's PDU session resources that are not admitted by the target node;

[0338] An updated HandoverCommand message related to the current operating conditions of the target cell; and

[0339] One or more updated conditions under which the UE may perform the conditional mobility procedure.

[0340] 14. The method of any of embodiments 10-13, wherein the conditional mobility procedure comprises one of the following procedures: handover, resumption, re-establishment, synchronization reconfiguration, beam switching, and secondary cell (SCell) addition.

[0341] 15. A method, performed by a user equipment (UE), for conditional mobility from a source node serving the UE in a radio access network (RAN) to a target cell associated with a target node, the method comprising:

[0342] receiving, from a source node, a conditional mobility configuration associated with at least one target cell that is a candidate for a conditional mobility procedure for the UE; and

[0343] Prior to determining that one or more conditions for triggering the conditional mobility procedure have been met, an indication is received from the source node that the conditional mobility configuration is no longer valid.

[0344] 16. The method of embodiment 15, further comprising: performing radio resource management (RRM) measurements to determine whether one or more trigger conditions are met.

[0345] 17. The method of any of embodiments 15-16, wherein:

[0346] The indication that the conditional mobility configuration is no longer valid includes a cancellation indication and a reason why the conditional mobility configuration is invalid; and

[0347] The method further includes canceling a conditional mobility procedure associated with the conditional mobility configuration.

[0348] 18. The method of any of embodiments 15-16, wherein:

[0349] The indication of the conditional handover configuration further includes an updated conditional mobility configuration for the UE; and

[0350] The method further includes reconfiguring the conditional mobility procedure based on the updated conditional mobility configuration.

[0351] 19. The method of embodiment 18, wherein the updated conditional mobility configuration includes one or more of the following:

[0352] The UE's updated list of PDU session resources admitted by the target node;

[0353] An updated list of the UE's PDU session resources that are not admitted by the target node;

[0354] An updated HandoverCommand message related to the current operating conditions of the target cell; and

[0355] One or more updated conditions under which the UE may perform the conditional mobility procedure.

[0356] 20. The method of embodiment 19 further comprises: upon determining that one or more updated conditions have been met, performing a conditional mobility process relative to the target cell based on the updated conditional mobility configuration.

[0357] 21. The method of any of embodiments 15-20, wherein the conditional mobility procedure comprises one of the following procedures: handover, resumption, re-establishment, synchronization reconfiguration, beam switching, and secondary cell (SCell) addition.

[0358] 22. A network node in a radio access network (RAN), comprising:

[0359] communications circuitry configured to communicate with one or more other network nodes and one or more user equipments (UEs);

[0360] The processing circuit is operatively coupled to the communication circuit and configured to perform operations corresponding to any of the methods of embodiments 1-14.

[0361] 23. 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 arranged to perform operations corresponding to any of the methods of embodiments 1-14.

[0362] 24. A non-transitory computer-readable medium storing computer-executable instructions that, when executed by processing circuitry comprising a network node in a radio access network (RAN), configure the network node to perform operations corresponding to any of the methods of embodiments 1-14.

[0363] 25. A user equipment (UE) configured for conditional mobility between cells in a radio access network (RAN), the UE comprising:

[0364] communication circuitry configured to communicate with one or more network nodes;

[0365] The processing circuit is operably coupled to the communication circuit and configured to perform operations corresponding to any of the methods of embodiments 15-21.

[0366] 26. A user equipment (UE) configured for conditional mobility between cells in a radio access network (RAN), the UE being arranged to perform operations corresponding to any of the methods of embodiments 15-21.

[0367] 27. A non-transitory computer-readable medium storing computer-executable instructions that, when executed by processing circuitry comprising a user equipment (UE) configured for conditional mobility in a radio access network (RAN), configure the UE to perform operations corresponding to any of the methods of embodiments 15-21.

[0368] 28. A communication system comprising a host computer, the host computer comprising:

[0369] a processing circuit configured to provide user data; and

[0370] b. a communication interface configured to forward user data to a cellular network through a core network (CN) and a radio access network (RAN) for transmission to a user equipment (UE);

[0371] in:

[0372] c. RAN includes a first node and a second node;

[0373] d. The first node includes a communication transceiver and a processing circuit configured to perform operations corresponding to any of the methods of embodiments 1-9; and

[0374] e. The second node includes a communication transceiver and a processing circuit configured to perform operations corresponding to any of the methods of embodiments 10-14.

[0375] 29. The communication system of the aforementioned embodiment further comprises the UE, wherein the UE is configured to perform operations corresponding to any of the methods of embodiments 15-21.

[0376] 30. The communication system of any one of the two preceding embodiments, wherein:

[0377] f. The processing circuit of the host computer is configured to execute a host application, thereby providing user data; and

[0378] g. The UE includes a processing circuit configured to execute a client application associated with the host application.

[0379] 31. A method implemented in a communication system comprising a host computer, a cellular network, and a user equipment (UE), the method comprising:

[0380] a. Providing user data at the host computer;

[0381] b. At the host computer, initiating a transmission carrying user data to the UE via a cellular network including a radio access network (RAN); and

[0382] c. Operations performed by the first and second nodes of the RAN corresponding to any of the methods of embodiments 1-14.

[0383] 32. The method of the preceding embodiment, wherein the data message comprises user data, and further comprising transmitting the user data to the UE via the first node or the second node.

[0384] 33. The method of any one of the two preceding embodiments, wherein the user data is provided by executing a host application at a host computer, the method further comprising: executing a client application associated with the host application at a UE.

[0385] 34. The method of any of the three aforementioned embodiments further includes operations performed by the UE corresponding to any of the methods of embodiments 15-21.

[0386] 35. A communication system comprising a host computer, the host computer comprising a communication interface configured to receive user data originating from a transmission from a UE via a first node or a second node in a radio access network (RAN), wherein:

[0387] a. The first node comprises a communication interface and a processing circuit configured to perform operations corresponding to any of the methods of embodiments 1-9; and

[0388] b. The second node includes a communication interface and a processing circuit configured to perform operations corresponding to any of the methods of embodiments 10-14.

[0389] 36. The communication system of the aforementioned embodiment further comprises a UE, wherein the UE is configured to perform operations corresponding to any of embodiments 15-21.

[0390] 37. The communication system of any one of the two preceding embodiments, wherein:

[0391] a processing circuit of the host computer is configured to execute a host application;

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

Claims

1. A method for mobility of a user equipment UE served by a second node in a radio access network RAN, the method comprising: receiving (1310) from the second node a request for a mobility procedure for the UE regarding at least one candidate target cell associated with the first node; determining (1320) whether the UE is acceptable for the requested mobility procedure, and if so, allocating resources to support mobility of the UE; transmitting (1330) a response to the second node, the response including a configuration for the mobility procedure and indicating that the UE can be accepted unless a cancellation message is subsequently received from the second node; determining (1350) that the configuration is no longer valid; as well as An indication is transmitted (1360) to the second node that the configuration is no longer valid.

2. The method of claim 1, wherein: The configuration includes one or more conditions for triggering the UE to perform the mobility procedure.

3. The method according to any one of claims 1 to 2, further comprising: A resource reservation timer associated with the allocated resources is started (1340).

4. The method of claim 3, wherein: Determining (1350) that the configuration is no longer valid is based on expiration of the resource reservation timer.

5. The method according to any one of claims 1 to 2, wherein: Determining (1350) that the configuration is no longer valid includes: monitoring (1352) usage of the allocated resources; and During the monitoring period any of the following conditions are detected (1354): Resource overload conditions; and The allocated resources are used as required for another mobility procedure.

6. The method according to any one of claims 1 to 2, wherein: The indication that the configuration is no longer valid includes a cancellation indication and a reason why the configuration is no longer valid.

7. The method according to any one of claims 1 to 2, wherein: The indication that the configuration is no longer valid further comprises an updated configuration of the UE.

8. The method of claim 7, wherein: The updated configuration includes one or more of the following: an updated list of PDU session resources of the UE admitted by the first node; an updated list of PDU session resources of the UE to which access is denied by the first node; An updated HandoverCommand message related to the current operating conditions of the candidate target cell; as well as Conditions for triggering the UE to perform one or more updates of the mobility procedure.

9. The method according to any one of claims 1 to 2, wherein: The mobility procedure includes one of the following procedures: handover, recovery, reestablishment, synchronization reconfiguration, beam change, and secondary cell (SCell) addition.

10. A method performed by a second node in a radio access network RAN ​​for mobility of a user equipment UE served by the second node, the method comprising: transmitting (1410) to a first node in the RAN a request for a mobility procedure for the UE regarding at least one candidate target cell associated with the first node; receiving (1420) a response from the first node, the response including a configuration for the mobility procedure and indicating that the UE can be accepted unless a cancellation message is subsequently received from the second node; transmitting (1430) the configuration to the UE; receiving (1440) from the first node an indication that the configuration is no longer valid; and The UE is reconfigured (1450) based on the indication.

11. The method of claim 10, wherein: The configuration includes one or more conditions for triggering the UE to perform the mobility procedure.

12. The method of any one of claims 10-11, wherein: the indication that the configuration is no longer valid comprises a cancellation indication and a reason why the configuration is no longer valid; and Reconfiguring (1450) the UE based on the received indication includes canceling (1452) the mobility procedure.

13. The method of any one of claims 10-11, wherein: said indication that said configuration is no longer valid comprises an updated configuration for said mobility procedure; and Reconfiguring (1450) the UE based on the received indication includes transmitting (1454) the updated configuration to the UE.

14. The method of claim 13, wherein: The updated configuration includes one or more of the following: an updated list of PDU session resources of the UE admitted by the first node; an updated list of PDU session resources of the UE to which access is denied by the first node; An updated HandoverCommand message related to the current operating conditions of the candidate target cell; as well as Conditions for triggering the UE to perform one or more updates of the mobility procedure.

15. The method according to any one of claims 10 to 11, wherein: The mobility procedure includes one of the following procedures: handover, recovery, reestablishment, synchronization reconfiguration, beam change, and secondary cell (SCell) addition.

16. A method performed by a user equipment UE served by a second node in a radio access network RAN, the method comprising: receiving (1510) from the second node a configuration for a mobility procedure regarding at least one candidate target cell associated with a first node in the RAN; as well as Before one or more conditions for triggering performance of the mobility procedure have been satisfied, receiving (1530) an indication from the second node that the configuration is no longer valid.

17. The method of claim 16, wherein: The configuration includes the one or more conditions for triggering performance of the mobility procedure.

18. The method of any one of claims 16-17, further comprising: Radio resource management (RRM) measurements are performed (1520) to determine whether the one or more conditions have been met.

19. The method of any one of claims 16-17, wherein: the indication that the configuration is no longer valid comprises a cancellation indication and a reason why the configuration is no longer valid; and The method further includes canceling (1540) a mobility procedure associated with the configuration.

20. The method of any one of claims 16-17, wherein: The indication that the configuration is no longer valid further comprises an updated configuration for the mobility procedure; and The method further includes reconfiguring (1550) the mobility process based on the updated configuration.

21. The method of claim 20, wherein: The updated configuration includes one or more of the following: an updated list of PDU session resources of the UE admitted by the first node; an updated list of PDU session resources of the UE to which access is denied by the first node; An updated HandoverCommand message related to the current operating conditions of the candidate target cell; as well as Conditions for triggering the UE to perform one or more updates of the mobility procedure.

22. The method of claim 21, further comprising: Upon determining that the one or more updated conditions have been met, a mobility procedure associated with the candidate target cell is performed (1560) based on the updated configuration.

23. The method of any one of claims 16-17, wherein: The mobility procedure includes one of the following procedures: handover, recovery, reestablishment, synchronization reconfiguration, beam change, and secondary cell (SCell) addition.

24. A network node (105-115, 300, 350, 520, 530, 1660, 1820, 2020) of a radio access network RAN ​​(100, 399), configured to facilitate mobility of one or more user equipments UE in the RAN, the network node comprising: interface circuitry (1690, 1870, 18200, 2027) operable to communicate with at least another network node in the RAN; as well as A processing circuit (1670, 1860, 2028) is operably coupled to the interface circuit, whereby the processing circuit and the interface circuit are configured to perform operations corresponding to any of the methods as claimed in claims 1-15.

25. A network node (105-115, 300, 350, 520, 530, 1660, 1820, 2020) of a radio access network RAN ​​(100, 399), the network node comprising: Processing circuit; and a memory containing instructions executable by the processing circuit, whereby the network node is configured to facilitate mobility of one or more user equipments UE in the RAN, the network node being further arranged to perform operations corresponding to any of the methods as claimed in claims 1-15.

26. A non-transitory computer-readable medium (1680, 1890) storing computer-executable instructions (1895, 2021) which, when executed by a processing circuit (1670, 1860, 2028) of a network node (105-115, 300, 350, 520, 530, 1660, 1820, 2020) of a radio access network RAN ​​(100, 399), configures the network node to perform operations corresponding to any of the methods described in claims 1-15.

27. A computer program product comprising computer executable instructions (1895, 2021) which, when executed by a processing circuit (1670, 1860, 2028) of a network node (105-115, 300, 350, 520, 530, 1660, 1820, 2020) of a radio access network RAN ​​(100, 399), configures the network node to perform operations corresponding to any of the methods as claimed in claims 1-15.

28. A user equipment UE (120, 510, 1610, 1700, 2030) configured for mobility in a radio access network RAN ​​(100, 399) comprising a first node and a second node, the UE comprising: an interface circuit (1614, 1731, 2037) configured to communicate with at least the first node and the second node; as well as A processing circuit (1620, 1701, 2038) is operably coupled to the interface circuit, whereby the processing circuit and the interface circuit are configured to perform operations corresponding to any of the methods as claimed in claims 16-23.

29. A user equipment UE (120, 510, 1610, 1700, 2030), comprising: Processing circuit; and a memory containing instructions executable by the processing circuit, whereby the UE is configured for mobility in a radio access network RAN ​​(100, 399) comprising a first node and a second node, the UE being further arranged to perform operations corresponding to any of the methods as claimed in claims 16-23.

30. A non-transitory computer-readable medium (1630, 1715, 1821) storing computer-executable instructions (1725, 2031), which, when executed by a processing circuit (1620, 1701, 2038) of a user device (120, 510, 1610, 1700, 2030), configures the user device to perform operations corresponding to any of the methods described in claims 16-23.

31. A computer program product comprising computer executable instructions (1725, 2031), which, when executed by a processing circuit (1620, 1701, 2038) of a user device (120, 510, 1610, 1700, 2030), configures the user device to perform operations corresponding to any of the methods described in claims 16-23.

Images