Fast failure recovery when user equipment is configured with level 1 or level 2 triggered mobility

Abstract

A method performed by a user equipment (UE) for performing recovery from a radio-related failure is provided. The method comprises: receiving (500) at least one level 1 (L1) or level 2 (L2) trigger mobility (LTM) candidate cell configuration and storing it in the UE; detecting (502) a radio-related failure; in response to detecting the radio-related failure, performing (504) a cell selection; determining (506) whether the selected cell corresponds to one of the stored at least one LTM candidate cell configuration; and in response to the selected cell corresponding to one of the stored at least one LTM candidate cell configuration, applying (508) the stored LTM candidate cell configuration corresponding to the selected cell as the target cell.

Description

Technical Field

[0001] This disclosure generally relates to wireless communication, and more specifically, to communication methods supporting wireless communication, as well as related devices and nodes. Background Technology

[0002] When a User Equipment (UE) moves from the coverage area of ​​one cell to another, a serving cell change may be required at some point. As defined in 3GPP Release 17 or earlier, serving cell changes can be triggered by Layer 3 (L3) measurements and can utilize synchronous reconfiguration triggered by Radio Resource Control (RRC) signaling to change the primary cell (PCell) and primary / secondary cell (PSCell), and release and add secondary cells (SCells) where applicable. Such serving cell changes can involve Layer 2 (L2) (and Layer 1 (L1)) resets, resulting in longer latency, greater overhead, and longer downtime than beam-switching mobility. In 3GPP Release 18, a concept called L1 / L2 triggered mobility (LTM) (also known as lower-layer triggered mobility) was introduced. LTM enables serving cell changes via L1 / L2 signaling, thereby reducing latency, overhead, and downtime. However, there are problems and / or challenges in utilizing LTM, including fast failure recovery when the UE is configured with LTM. Summary of the Invention

[0003] Some embodiments relate to a method performed by a user equipment (UE) for recovering from a radio-related failure. The method includes: receiving at least one Level 1 (L1) or Level 2 (L2) triggered mobility (LTM) candidate cell configuration and storing it in the UE; detecting a radio-related failure; performing cell selection in response to detecting the radio-related failure; determining whether the selected cell corresponds to one of the stored at least one LTM candidate cell configurations; and applying the stored LTM candidate cell configuration corresponding to the selected cell as the target cell in response to the selected cell corresponding to one of the stored at least one LTM candidate cell configurations.

[0004] Some embodiments relate to a method for a UE to recover from a radio-related failure when the UE has one or more LTM candidate cell configurations configured. Upon detecting a radio-related failure, the UE performs cell selection to find a suitable cell to rebuild the connection. Once a suitable cell is found, the UE determines whether it has a stored LTM candidate cell configuration associated with the selected cell. If so, the UE applies the stored LTM candidate cell configuration associated with the selected cell.

[0005] Additionally, some other embodiments relate to methods for a UE to obtain information (also known as dynamic information) required for accessing a target (selected) cell. Part of this information is typically received in the Media Access Control (MAC) element (CE) from the source cell that triggered the LTM cell handover, but the UE may not receive this information in the event of a radio-related failure. This information includes, for example, whether the UE can access the target cell without random access if it has a valid timing advance (TA), and if so, which Transport Configuration Information (TCI) states to apply, which uplink (UL) grant to use, the bandwidth portion (BWP) to use, etc. In summary, the process includes the UE performing access in the target cell using the obtained information for accessing the target cell and sending a notification message to the target node to indicate successful recovery.

[0006] Some other embodiments involve inter-node signaling for notifying the central unit (CU) of successful failure recovery, and the CU notifying the source distributed unit (DU), and sometimes, for example, when the UE recovers during an LTM cell handover process, also notifying the first target DU.

[0007] Certain embodiments may provide one or more of the following technical advantages. Some embodiments disclosed herein enable a UE configured with L1 / L2 triggered mobility to perform rapid recovery from a radio-related failure. Furthermore, some embodiments enable a UE to perform an LTM cell handover to a selected target cell configured as an LTM candidate cell during recovery, and to use the obtained dynamic information about the target cell to reduce downtime by avoiding steps used to establish downlink (DL) synchronization and / or random access. Attached Figure Description

[0008] The accompanying drawings illustrate certain non-limiting embodiments of the inventive concept. These drawings are included to provide a further understanding of the present disclosure and are incorporated in and constitute a part of this application. In the drawings:

[0009] Figure 1 This is a block diagram illustrating the system architecture according to some embodiments;

[0010] Figure 2 This is a diagram showing message sequences associated with radio-related failures according to some embodiments;

[0011] Figure 3 This is a diagram showing the message sequence associated with a Level 1 (L1) / Level 2 (L2) triggered mobility (LTM) cell handover process according to some embodiments;

[0012] Figure 4This is a flowchart illustrating operations performed by a user equipment (UE) according to some embodiments;

[0013] Figure 5 This is a flowchart illustrating an example method performed by a UE according to some embodiments;

[0014] Figure 6 This is a flowchart illustrating an example method performed by a source network node according to some embodiments;

[0015] Figure 7 This is a block diagram of a communication system according to some embodiments;

[0016] Figure 8 This is a block diagram of a user equipment according to some embodiments;

[0017] Figure 9 This is a block diagram of network nodes according to some embodiments;

[0018] Figure 10 This is a block diagram illustrating communication between a host computer and a user equipment according to some embodiments;

[0019] Figure 11 This is a block diagram of a virtualized environment according to some embodiments; and

[0020] Figure 12 This is a block diagram of a host computer that communicates with a user equipment via a base station through a partially wireless connection, according to some embodiments. Detailed Implementation

[0021] In version 18 (Rel-18), Level 1 (L1) / Level 2 (L2) triggers LTM (Low Mobility Management).

[0022] In 3GPP Release 18, a work item called “Further NR Mobility Enhancement” has been agreed upon. This work item includes a technical area called L1 / L2 based inter-cell mobility. According to the Work Item Description (WID) [1] RP-223520, 3GPP Work Item Description: Further NR Mobility Enhancement, MediaTek, Apple, 3GPP Technical Specification Group (TSG) Radio Access Network (RAN) Meeting #98-e, Electronic Meeting, December 12-16, 2022 (hereinafter referred to as “WID[1]”), when a UE moves from the coverage area of ​​one cell to another, a serving cell change needs to be performed at some point. Currently, serving cell changes are triggered by Level 3 (L3) measurements and are accomplished through synchronous reconfiguration (for changes to the primary cell (PCell) and primary secondary cell (PSCell)) triggered by Radio Resource Control (RRC) signaling and, where applicable, release and add secondary cells (SCell). These scenarios can involve complete L2 and L1 resets, resulting in longer latency, greater overhead, and longer downtime compared to beam-switching mobility. The goal of L1 / L2-based inter-cell mobility is to achieve serving cell changes via L1 / L2 signaling in order to reduce latency, overhead, and downtime.

[0023] In this work project, according to the WID[1], the following is included as one of the objectives of the work:

[0024] 1. Specify mechanisms and procedures for inter-cell mobility based on L1 / L2 to reduce mobility latency:

[0025] o Configuration and maintenance of multiple candidate cells to allow for rapid application of candidate cell configurations [RAN2, RAN3]

[0026] o For potential application scenarios based on L1 / L2 signaling, a dynamic handover mechanism between candidate serving cells (including special cells (SpCell) and SCell) [RAN2, RAN1] is proposed.

[0027] o L1 enhancements (including L1 measurement and reporting) and beam indication [RAN1, RAN2] for inter-cell beam management

[0028] - Note 1: Early RAN2 involvement is necessary, including potentially further clarifying the interactions between this project and previous projects.

[0029] o Scheduled advance management [RAN1, RAN2]

[0030] o Central Unit (CU) - Distributed Unit (DU) interface signaling to support L1 / L2 mobility (if needed) [RAN3].

[0031] Note 2: Frequency range (FR) 2 specific enhancements (if any) are not excluded.

[0032] Note 3: The process based on L1 / L2 inter-cell mobility is applicable to the following scenarios:

[0033] • Standalone, carrier aggregation (CA), and next-generation radio (NR)-dual connectivity (DC) scenarios, where serving cell changes are performed within a single configuration authorization (CG).

[0034] • DU intra-DU and CU inter-DU configurations (applicable to standalone and CA: no new RAN interfaces expected)

[0035] Both same frequency and different frequency

[0036] Both FR1 and FR2

[0037] • Source and target cells can be synchronized or not.

[0038] Within 3GPP, solutions for L1 / L2-based inter-cell mobility (sometimes referred to as L1 / L2 triggered mobility or lower-layer triggered mobility) have begun to be discussed.

[0039] The basic principle of L1 / L2-triggered mobility is as follows: The network pre-configures the RRC configuration for each LTM candidate cell for the UE, which is also known as the LTM candidate cell configuration. This LTM candidate cell configuration can be an RRCReconfiguration message or one or more information elements (IEs) / fields / parameters, such as CellGroupConfig. The UE performs measurements on these LTM candidate cells and sends the corresponding measurement reports to the network. Then, the network triggers the LTM cell handover process in the UE by sending low-layer signals (such as Medium Access Control (MAC) control elements (CEs) or Downlink Control Information (DCIs)) (sometimes also called LTM cell handover commands) to the UE. The UE then connects to the target cell and switches to the LTM candidate cell configuration.

[0040] At the 3GPP meeting, several agreements were reached regarding L1 / L2-triggered mobility, and among these agreements are the following:

[0041] The following behavior of the LTM monitoring timer is agreed upon:

[0042] - 1: When the UE receives an LTM cell handover MAC CE, it starts the LTM monitoring timer;

[0043] - 2: Upon successful completion of LTM cell handover, the UE stops the LTM monitoring timer;

[0044] - 3: If the LTM monitoring timer of the primary cell group (MCG) expires, it will be used as the baseline. The UE will consider that LTM failure has occurred and initiate RRC reconstruction (the handover situation of the secondary cell group (SCG) needs further study (FFS)).

[0045] In the event of a radio link failure (RLF) or LTM execution failure (for MCG), RAN2 tends to support rapid recovery to the candidate cell via LTM execution.

[0046] protocol

[0047] For beam indication based on the Rep. 17 (Rel-17) Unified Transmission Control Information (TCI) in version 18 LTM, at least Alternative Scheme 1 is supported:

[0048] Alternative Option 1: Receive the TCI state activation of the candidate cell before receiving the beam indication of the candidate cell.

[0049] Alternative Option 2: Receive the TCI state activation of the candidate cell along with the beam indication of the candidate cell.

[0050] o FFS: If activation and indication both occur in the same MAC CE message carrying the switching command, the signaling details indicated by the TCI status.

[0051] o Alternative Option 3: Alternative Option 1 and / or Alternative Option 2 can be supported based on UE capabilities.

[0052] FFS: Signaling details for TCI state activation.

[0053] FFS: For Alternative Scenario 1, whether / how to allow the TCI state activation of the candidate cell.

[0054] Note: If scenarios 1 and 3 are to be supported, other beam indication / TCI activation timing relationships are not excluded.

[0055] There are currently some challenges.

[0056] In 3GPP, many details of the L1 / L2 triggered mobility (LTM) process remain undetermined.

[0057] One area where agreement has not yet been reached is failure recovery. At the RAN2#121bis meeting, a high-level agreement was reached on supporting rapid recovery to candidate cells via LTM execution, but no agreement has been reached on any details.

[0058] UEs configured with Conditional Handover (CHO) already support similar functionality, where, after RLF detection and subsequent cell selection, if the selected cell is the target candidate cell, the UE should apply its stored CHO configuration for that cell. Whether the UE should apply this configuration is controlled by the network using the attemptCondReconfig field, see the field description below.

[0059] => attemptCondReconfig

[0060] => If it exists, then if the selected cell is the target candidate cell and it is the first cell selection after failure, the UE should perform conditional reconfiguration as described in Clause 5.3.7.3 of the 3GPP RRC specification (TS 38.331 v17.4.0, March 2023).

[0061] Similar functionality could also be considered for LTM to facilitate rapid recovery from RLF or execution failures. Additionally, LTM relies on the network pre-providing the UE with the RRC configuration for each candidate target cell, which the UE then applies during LTM execution. However, there are several differences between CHO and LTM in terms of configuration and execution, and these differences need to be addressed for them to function correctly. For example, LTM supports downlink (DL) and uplink (UL) pre-synchronization with LTM candidate target cells and reduces downtime during LTM execution by, for example, avoiding random access with the target cell. LTM also supports greater flexibility in user plane processing, where the network can control which protocol layers are reset or rebuilt.

[0062] A crucial component of LTM execution is the dynamic information included in the LTM command, provided in the MAC CE sent from the source cell that triggered LTM to the target cell. In failure scenarios, since the UE has lost connection with the source cell, the network cannot provide this information to the UE. Therefore, for failure recovery scenarios, it is necessary to specify how the UE should apply the LTM configuration without this dynamic information. The content of the dynamic information is still under discussion, but the following items have been discussed:

[0063] o LTM Candidate Configuration Identifier (ID)

[0064] o TCI status

[0065] Bandwidth Part (BWP) ID

[0066] o Scheduled advance (TA)

[0067] o UL authorized.

[0068] Some aspects of this disclosure may provide solutions to these or other challenges.

[0069] Some embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. These embodiments are provided by way of example only to convey the scope of the subject matter to those skilled in the art.

[0070] This document references the term "L1 / L2-based inter-cell mobility" as used in the work item descriptions in 3GPP; however, the terms L1 / L2 mobility, L1 mobility, L1-based mobility, L1 / L2-centric inter-cell mobility, L1 / L2 inter-cell mobility, L1 / L2 triggered mobility, low-layer triggered mobility, or LTM are used interchangeably. Therefore, each use of one of these terms in this description can be replaced by any of these other interchangeable terms. The basic principle of various embodiments is that the UE receives low-layer signaling from the network that instructs the UE of a change (or handover or activation) of its serving cell (e.g., changing the PCell from a source PCell to a target PCell). This low-layer signaling is a message / signaling of a low-layer protocol, which may be referred to as an L1 / L2 inter-cell mobility execution command or an LTM cell handover command. For example, in cases where this command triggers the UE to change to another cell group configuration of the same type (e.g., another MCG configuration), the change of the serving cell (e.g., the change of the PCell) may also result in a change of the Scell ​​of the same cell group. Before the UE receives an LTM cell handover command, the network configures one or more LTM candidate cell configurations for the UE (e.g., upon receiving an RRC reconfiguration message with at least one LTM candidate cell configuration). The LTM candidate cell configuration may include parameters in the IECellGroupConfig for each candidate cell and / or an embedded RRC reconfiguration for each LTM candidate cell.

[0071] The term LTM cell handover process refers to the process by which a UE uses L1 / L2 triggered mobility (LTM) to hand over (or change) its cell from a source cell to a target cell (which may be referred to herein as an LTM candidate cell or neighboring cell). In the context of L1 / L2 triggered mobility (LTM), the LTM cell handover process is sometimes also referred to as L1 / L2-based inter-cell mobility execution, LTM execution, dynamic handover, LTM handover, (LTM) cell handover, (LTM) serving cell change, or (LTM) cell change. In the context of some embodiments, handover to an LTM candidate cell configuration includes the UE considering: the LTM candidate cell becoming its new special cell (SpCell), for example, PCell if LTM is configured for a primary cell group (MCG), and / or PSCell if LTM is configured for a secondary cell group (SCG); or changing its SpCell from the current PCell to the LTM candidate cell.

[0072] Even when using the term cell change, it can include changes to the entire cell group configuration, which includes changes to the cell group's SpCell (e.g., changes to the PCCell or PSCell) and SCells (e.g., the addition, modification, and / or release of one or more SCells).

[0073] As a result of recovery from radio link failure or handover failure, the LTM cell handover process can be triggered in the UE by receiving an LTM cell handover command, or alternatively, by the satisfaction of some other event, such as a condition, for example, a triggering condition for condition configuration (such as condition handover).

[0074] This article mentions LTM candidate cells, which are cells configured for a UE when L1 / L2 triggered mobility is configured. These are cells that the UE can move to during an LTM cell handover when it receives an LTM cell handover command. These cells may also be referred to as candidate cells, candidates, mobile candidates, non-serving cells, supplementary cells, target candidates, etc. An LTM candidate cell is a cell on which the UE performs measurements (e.g., Channel State Information (CSI) measurements), enabling the UE to report these measurements and allowing the network to make informed decisions about which beam (e.g., TCI state) and / or cell the UE should hand over to. An LTM candidate cell can be a candidate to become a target PCell or PSCell, or an SCell of a cell group (e.g., an MCG SCell).

[0075] This document relates to at least one LTM candidate cell configuration, and that the UE has received at least one LTM candidate cell configuration. This at least one LTM candidate cell configuration, sometimes also referred to as the LTM candidate cell configuration, can be an RRC configuration encapsulated in an RRC reconfiguration message received by the UE when L1 / L2 triggered mobility is configured. The LTM candidate cell configuration includes the configuration that the UE needs to begin operating accordingly when performing an LTM cell handover procedure to that LTM candidate cell (e.g., upon receiving an LTM cell handover command instructing the UE to perform an LTM cell handover procedure to that LTM candidate cell, which becomes the target cell and the current (new) SpCell, or SCell at the serving frequency). The LTM candidate cell configuration includes parameters for the serving cell (or multiple serving cells, such as a cell group), including one or more sets of parameters, such as an RRC reconfiguration message, IE CellGroupConfig, or IE SCellConfig (or IESCellConfig in the case of a secondary cell). In one example, an LTM candidate cell configuration may include one or more of the following: (i) a PCell configuration and one or more SCell configurations for a primary cell group (MCG); and (ii) a PSCell configuration and one or more SCell configurations for a secondary cell group (SCG). When referring to an LTM candidate cell configuration, the terms (LTM) candidate configuration, LTM configuration, (LTM) candidate target cell configuration, and (LTM) target candidate (cell) configuration are used interchangeably. An LTM candidate cell configuration is associated with an identifier that is used in signaling when referring to an LTM candidate cell configuration (e.g., when a UE receives an LTM candidate cell configuration, and when a UE receives an LTM cell handover command instructing the UE to perform an LTM cell handover procedure to that LTM candidate cell). This identifier is sometimes referred to as the LTM candidate cell configuration identifier or the LTM candidate configuration index (or similar names).

[0076] The actual LTM candidate cell configuration, its exact content, and / or the structure of the IE and / or embedded message can be referred to as the RRC model of the candidate configuration, or simply the RRC model. The LTM candidate cell configuration includes the configuration that the UE needs to perform when performing L1 / L2-based inter-cell mobility to that LTM candidate cell, either upon receiving low-layer signaling (MAC CE) indicating L1 / L2-based inter-cell mobility execution to the LTM candidate cell (which becomes the target cell and the current (new) PCell, or the SCell under the serving frequency), or upon receiving low-layer signaling (MAC CE) indicating L1 / L2-based inter-cell mobility to the LTM candidate cell configuration indicated by the candidate configuration index (sometimes also represented as the candidate configuration ID). The UE can have multiple LTM candidate cell configurations configured; therefore, the candidate DU generates multiple configurations and sends them to the CU. The actual LTM candidate cell configuration received by the UE during LTM configuration can be incremental signaling to be applied on top of the reference configuration, so that the actual configuration that the UE will use in the candidate cell during LTM cell handover is a combination of the LTM candidate cell configuration and the reference configuration (e.g., sent to the UE by the network separately via signaling).

[0077] The term "beam" can correspond to the spatial direction of signal transmission (e.g., by a network node) or reception (e.g., by a UE), or to a spatial filter applied to the transmitted or received signal. Therefore, using different beams to transmit a signal can correspond to transmitting a signal in different spatial directions. When the text refers to "selected beam," it can refer to a beam index and / or a reference signal (RS) index or identifier, such as a synchronization signal block (SSB) index or a CSI-RS resource identifier. Therefore, selecting a beam can correspond to selecting an SSB associated with an SSB index. Alternatively, selecting a beam can correspond to selecting a CSI-RS associated with a CSI-RS resource identifier.

[0078] This article mentions the phrase "radio-related failure". A radio-related failure can be triggered for either the primary cell group (MCG) or the secondary cell group (SCG), and can be one of the following:

[0079] • Beam failure detection (BFD), such as that defined in 3GPP TS 38.321;

[0080] • The LTM cell handover process failed, for example, due to the expiration of the LTM monitoring timer or the expiration of timer T304 associated with the LTM candidate cell;

[0081] • Switching failure (HOF), for example, timer T304 expires;

[0082] • Radio link failure (RLF), such as timer T310 or T316 expiring; or

[0083] • Failed to retransmit the maximum number N Radio Link Control (RLC) Protocol Data Units (PDUs).

[0084] The term "information for accessing the target cell" refers to the information a UE uses to perform access in the target cell. This includes determining whether random access is required, whether UL transmission can begin without a scheduling request when performing access in the cell, which beam to use, and whether the UE has downlink synchronization. This information may be referred to as "dynamic information," but may be valid for a limited time or only intended for a single access operation by the UE. Information for accessing the target cell may include items such as:

[0085] • UL or DL ​​TCI status;

[0086] • SSB index;

[0087] • CSI-RS Resource Identifier;

[0088] • Event BWP ID;

[0089] · TA;

[0090] • UL authorized;

[0091] • L1 measurement;

[0092] • The status of DL synchronization (synchronization, synchronization loss, etc.);

[0093] Is the community known or unknown?

[0094] • TA timer status (running / not running);

[0095] • Instructions regarding whether random access is required to access the target cell;

[0096] • Instructions regarding whether an L2 reset (e.g., MAC reset, partial MAC reset, RLC reconstruction, or Packet Data Convergence Protocol (PDCP) data recovery) is required when performing an LTM cell handover to the target cell;

[0097] • LTM candidate configuration ID.

[0098] Information used for accessing the target cell can be received by the UE in MAC CE (such as LTM cell handover command, TA command, random access response (RAR)), in beam indication or TCI state activation, or in the physical layer (such as in downlink control information or physical downlink control channel (PDCCH) command), or in RRC signaling (such as in LTM candidate cell configuration), or sent in RRCReconfiguration message or system information block.

[0099] This article will now discuss the system overview.

[0100] Figure 1 A system architecture including entities involved in some embodiments is illustrated. User equipment (UE) 1001 is a wireless terminal (e.g., a cellular smartphone) that is sometimes connected to a source network node 1002 via wireless interface 1004, and sometimes connected to a first target network node 1003, for example due to mobility, via wireless interface 1005. In some cases, such as due to mobility or failure recovery performed by the UE, UE 1001 is connected to a second target network node 1013 via wireless interface 1014.

[0101] In the context of a mobility procedure (e.g., an LTM cell handover procedure), for the UE, the source network node 1002 (sometimes referred to as the serving network node) controls the source cell 1009 (sometimes referred to as the serving cell or special cell (SpCell)). The first target network node 1003 controls the first target cell 1010 (sometimes referred to as the target cell, neighboring cell, candidate cell, or LTM candidate cell). In the context of the UE's mobility procedure or when the UE performs a failure recovery, the second target network node 1013 controls the second target cell 1016, and sometimes controls the third target cell 1017.

[0102] Each of the source network node 1002, the first target network node 1003, and the second target network node 1013 can be a base station, such as a base station in an NR (gNB), or, for example, a distributed unit in a distributed CU / DU RAN architecture, sometimes referred to as a gNB-DU or DU. Therefore, the source network node 1002 corresponds to the source DU (S-DU) (sometimes also referred to as the serving DU), the first target network node 1003 corresponds to the target DU (T-DU), and the second target network node 1013 corresponds to the second target DU. The first target DU or the second target DU is sometimes referred to as a neighboring DU or a candidate DU (C-DU).

[0103] Source network node 1002, first target network node 1003, and second target network node 1013 are all connected to third network node 1006, sometimes referred to as a service network node. Either the first target network node or the second target network node can be the same network node as the source network node. In some cases, either the first target network node or the second target network node and the source network node can be connected to different third network nodes 1006.

[0104] Furthermore, in the case of a distributed CU / DU RAN architecture, the third network node 1006 can be a central unit (CU) (sometimes also called a serving CU), which is referred to as gNB-CU, CU, gNB-CU control plane (gNB-CU-CP) or gNB-CU user plane (gNB-CU-UP), or a core network node such as user plane function (UPF) or access and mobility management function (AMF).

[0105] Some embodiments propose a method for a user equipment (UE) (1001) to perform recovery from a radio-related failure in a source cell (1009) or a target cell (1010), including the UE:

[0106] • Receive at least one LTM candidate cell configuration.

[0107] • Radio-related detection failed.

[0108] • Select the appropriate cell location.

[0109] • Determine whether the selected cell (1016) is one of the LTM candidate cells that the UE has configured with stored LTM candidate cells.

[0110] • When the selected cell (1016) is one of the LTM candidate cells:

[0111] o Apply the stored LTM candidate cell configuration associated with the selected cell (1016),

[0112] o Obtain information for accessing the target cell (1016),

[0113] o Using the obtained information for accessing the target cell, perform access in the target cell (1016).

[0114] o Send a notification message to network node (1013).

[0115] In the subordinate step, when the UE determines during cell selection that the selected cell is not one of the LTM candidate cells for which the UE has stored LTM configuration, the UE performs a reconstruction procedure with the selected cell.

[0116] In the subordinate steps, when a radio-related failure is detected (e.g., timer T304 expires, LTM monitoring timer expires, LTM execution failure detection, radio link failure, etc.), the UE initiates a reconstruction process, starts timer T311 and begins cell selection. Depending on the cell selection result, the UE determines whether to continue the reconstruction process or trigger LTM execution in the selected cell. When the UE selects a cell for which it does not have a stored LTM configuration, the UE continues the reconstruction process with the selected cell and deletes / releases LTM-related information, such as LTM candidate cell configurations.

[0117] In the subordinate steps, when a radio-related failure is detected (e.g., timer T304 expires, LTM execution failure detection, radio link failure, etc.), the UE initiates a reconstruction procedure, starts timer T311, and begins cell selection. Depending on the cell selection result, the UE determines whether to continue the reconstruction procedure (e.g., whether to send an RRC reconstruction request message) or whether to trigger LTM execution on the selected cell (e.g., whether to apply the LTM candidate cell configuration of the selected cell). When the UE selects a cell for which it has a stored LTM configuration, the UE performs an LTM cell handover. If the LTM execution also fails, the UE re-initiates the reconstruction procedure and continues it, meaning it cannot perform another LTM cell handover. When a second reconstruction is initiated, the UE deletes / releases the relevant LTM configuration before cell selection while timer T311 is running, so that when a cell is selected, the cell may not be one for which the UE has a stored LTM configuration. Due to this mechanism, after a previous failure, the UE is only allowed to attempt to perform LTM on the selected LTM candidate cell once.

[0118] In the subordinate steps, when a radio-related failure is detected (e.g., timer T304 expires, LTM execution failure detection, radio link failure, etc.), the UE initiates a reconstruction procedure, starts timer T311, and begins cell selection. Depending on the result of the cell selection, the UE determines whether to continue the reconstruction procedure (e.g., whether to send an RRC reconstruction request message) or whether to trigger LTM execution on the selected cell (e.g., whether to apply the LTM candidate cell configuration of the selected cell). When the UE selects a cell with a stored LTM configuration, the UE performs an LTM cell handover. If the LTM execution also fails, the UE re-initiates the reconstruction procedure, determining whether to continue the reconstruction procedure (i.e., unable to perform another LTM cell handover) based on a counter value. This counter value is incremented each time the UE performs LTM execution in response to cell selection after a detected radio-related failure. Due to this mechanism, after a radio-related failure has occurred, the UE is only allowed a limited number of attempts to perform LTM on the selected LTM candidate cell. In one option, the maximum counter value is configured to the UE by the network, for example, as part of the LTM configuration, possibly for each LTM candidate cell, or regardless of the LTM candidate cells.

[0119] In one option, even if the UE is allowed to attempt to perform LTM multiple times on the selected cell during radio-related failure detection, only one attempt is allowed for each LTM candidate cell. For example, if the UE selects cell A and the UE has a stored LTM candidate cell configuration for cell A, and the LTM execution fails, the UE can select cell B. If that LTM execution fails and the UE selects cell A again, the UE is not allowed to trigger the execution of LTM to cell A, even if the counter value has not yet reached its maximum value. In other words, when the UE selects a cell and that cell is an LTM candidate cell for which the UE has a stored LTM candidate configuration, the UE applies the LTM candidate configuration (i.e., performs LTM to the selected cell) only if that cell has not been previously selected since the counter started incrementing.

[0120] In this method, obtaining information for accessing the target cell may include one or more of the following steps.

[0121] If the UE has a valid timing advance (TA) value for the selected candidate cell, it accesses the target cell without random access, for example, if the timing alignment timer for the selected candidate cell is running and / or the UE has already received the TA value in the LTM cell handover command. If the UE does not have a valid TA for the selected candidate cell (e.g., the timing alignment timer has expired and / or the UE has not received the TA value for the selected LTM candidate cell), the UE triggers random access in the target cell.

[0122] In another embodiment, to improve robustness, the UE triggers random access in the selected target cell regardless of whether it has a valid TA. As part of this process, the UE releases any TA information it may have for the selected LTM candidate cell and / or other configured LTM candidate cells. In one option, the UE resets its MAC entity when it accesses the selected target cell after a random access failure.

[0123] • When a UE accesses a selected cell without performing random access (i.e., TA is active), the UE uses the TCI state previously used to perform early DL synchronization (e.g., the previously indicated TCI state), for example, when the UE has already received the candidate cell's TCI state activation before receiving the LTM cell handover command and / or the candidate cell's beam indication. In another embodiment, the TCI state for fast failure recovery can be part of the LTM candidate cell configuration.

[0124] • To support a fast recovery process in the case of LTM RLF, a dedicated fast recovery configuration can be included in the LTM candidate cell configuration, and the UE is only allowed to use this configuration if an LTM execution failure is detected. In another embodiment, the UE is allowed to use the recovery configuration after an RLF or any other radio-related failure on the serving cell is detected and the UE is selected for a cell with a stored LTM configuration. The dedicated fast recovery configuration may include one or more of the following for fast recovery:

[0125] o UL and DL TCI status

[0126] o Fast UL Authorization

[0127] o Activity BWP ID

[0128] o Instructions on whether to allow a UE to access a candidate cell without random access (if TA is valid)

[0129] o Random access configuration, in case TA is invalid.

[0130] o TA information.

[0131] • If the UE fails to perform LTM without random access, it can trigger LTM with random access to the same selected cell.

[0132] • If the UE fails to perform LTM without random access, it can treat the selected cell as a “normal cell” and can initiate a random access procedure without considering any LTM configuration for that particular cell.

[0133] • If the UE fails to perform LTM during random access, it can trigger RRC reconstruction.

[0134] • The UE can determine the L2 action based on the content of the LTM configuration associated with the selected cell. Here, the L2 action may include whether to rebuild the RLC and whether to perform a full MAC reset, a partial MAC reset, or no MAC reset. In another embodiment, to improve robustness, the UE triggers both RLC rebuild and MAC reset regardless of the indications in the LTM candidate configuration associated with the selected cell.

[0135] In one embodiment, the UE selects the BWP in the selected cell based on the firstActiveDownlinkBWP-Id / firstActiveUplinkBWP-Id fields included in the LTM candidate configuration associated with the selected cell. If these fields are not present (since BWP-Id can normally be included in the LTM MAC CE), the UE selects the initial BWP (BWP_ID=0).

[0136] In one embodiment, if the LTM candidate cell configuration does not include dynamic information for fast RLF recovery, the UE can decode the MIB or SIB1 and use the cell-specific information included in the message to access the selected cell. Note that during LTM cell handover, the UE does not need to decode the MIB and / or SIB1 because it already has the dedicated configuration for that cell.

[0137] In one embodiment, the UE receives information for accessing the target cell (i.e., information about the first target cell (1010) such as TCI state ID and BWP ID) in the LTM cell handover command (MAC CE), and further, for at least one more LTM candidate cell (e.g., for the second target cell (1016)), it receives information for accessing the target cell such as i) TA value, ii) UL authorization of the complete message in the target cell, iii) BWP ID of the BWP to be activated, and iv) TCI state ID to be activated. When the UE detects a radio-related failure (e.g., LTM cell handover failure) and selects a cell that already includes dynamic information for it, the UE uses the information for accessing the target cell to access the selected cell, for example, by applying the TA value associated with the selected cell and / or activating the indicated BWP ID, activating the indicated TCI ID, etc. Note that this can be a case where some dynamic information is available at the S-DU anyway during LTM cell handover, and therefore the signaling of the LTM cell handover command can be increased.

[0138] In the method, sending a notification message may include one or more of the following steps.

[0139] In one embodiment, the notification message is an RRCReconfigurationComplete message with stored LTM configuration sent by the UE in the selected cell to complete the process. In one embodiment, the RRCReconfigurationComplete message contains an LTM candidate configuration ID, which identifies the configuration applied by the UE.

[0140] In another embodiment, the RRCReconfigurationComplete message includes the LTM candidate configuration ID of the cell that previously failed during LTM cell handover, and the LTM candidate configuration ID identifying the configuration applied by the UE after fast RLF recovery. The CU or C-DU can use this information to release the failed LTM candidate cell configuration at the UE.

[0141] • In another embodiment, such as when the UE has already selected a beam, performs early DL synchronization using the previously received TCI state and the TA is valid, and the UE does not perform random access in the selected cell, the UE indicates the selected beam (such as the selected SSB index or the selected CSI-RS resource identifier) ​​in the notification message.

[0142] In the subordinate steps, when a radio-related failure is detected (e.g., timer T304 expires, radio link failure, etc.), the UE initiates a reconstruction procedure. Before the UE starts timer T311 and begins cell selection, the UE determines whether it has LTM configured, for example, whether it has an IE configured for LTM configuration and / or at least one LTM candidate configuration configured. When the UE has not configured LTM, the UE performs one or more of the following actions:

[0143] • Reset MAC;

[0144] • Release the SpCell configuration (spCellConfig) (if it has been configured);

[0145] • Release secondary cells (e.g., MCG SCell, if configured);

[0146] • If MR-DC is configured, then perform MR-DC release;

[0147] • Release delayBudgetReportingConfig (if configured) and stop timer T342 (if it is running);

[0148] • Release overheatingAssistanceConfig (if configured) and stop timer T345 (if it is running);

[0149] • Release idc-AssistanceConfig (if it has been configured);

[0150] • Release btNameList (if configured);

[0151] • Release wlanNameList (if configured);

[0152] • Release sensorNameList (if configured);

[0153] • Release the drx-PreferenceConfig of MCG (if configured) and stop the timer T346a associated with MCG (if it is running);

[0154] • Release the maxBW-PreferenceConfig of the MCG (if configured) and stop the timer T346b associated with the MCG (if it is running).

[0155] • Release the maxCC-PreferenceConfig of the MCG (if configured) and stop the timer T346c associated with the MCG (if it is running).

[0156] • Release the maxMIMO-LayerPreferenceConfig of the MCG (if configured) and stop the timer T346d associated with the MCG (if it is running).

[0157] • Release the minSchedulingOffsetPreferenceConfig of the MCG (if configured) and stop the timer T346e associated with the MCG (if it is running).

[0158] • Release releasePreferenceConfig (if configured) and stop timer T346f (if running);

[0159] • Release onDemandSIB-Request (if configured) and stop timer T350 (if it is running);

[0160] • Release referenceTimePreferenceReporting (if configured);

[0161] • Release sl-AssistanceConfigNR (if it is configured);

[0162] • Release obtainCommonLocation (if it is configured).

[0163] In one embodiment, the network control UE can perform a fast recovery upon detecting a radio-related failure. The network control UE can act explicitly or implicitly.

[0164] • In an example of the explicit approach:

[0165] o The network sends an indication to the UE, and the indication may include one or more of the following:

[0166] ■ Whether to allow rapid recovery when a radio-related failure is detected;

[0167] ■ Does fast recovery only apply to a subset of LTM candidate cells, and is a list of these LTM candidate cells provided?

[0168] ■ Whether rapid recovery is allowed only within the selected RAN region (RNA), tracking region (TA), or registration region (RA);

[0169] The network sends an indication to the UE, and this indication may be part of the LTM configuration. Alternatively, the indication may be part of the LTM candidate cell configuration itself. Alternatively, the indication may be broadcast via system information.

[0170] • In an example of the implicit method:

[0171] o The network indicates to the UE whether fast recovery can be performed upon detection of a radio-related failure, based on one or more of the following:

[0172] ■ By checking if there are fields related to LTM. For example, is there a special configuration used only during rapid recovery when a radio-related failure is detected?

[0173] ■ Whether dynamic information, which is usually part of LTM cell handover, is provided to the UE in advance;

[0174] ■ By checking if a configured timer exists and / or if its duration is set to a specific value. For example, if the value of timer T311 is configured to be used only when performing fast recovery, the UE considers fast recovery to be allowed.

[0175] In one embodiment, whether the UE can perform fast recovery upon detecting a radio-related failure depends on the UE implementation. Alternatively, in the specification, whether and when the UE should perform fast recovery upon detecting a radio-related failure is hard-coded.

[0176] In one embodiment, the UE receives an LTM cell handover command indicating an LTM cell handover to a first target cell (1010) controlled by a first target node (1003). The first target node (1003) is already aware that an LTM cell handover process to the first target cell 1010 has been triggered, for example, by the source network node 1002 sending an instruction regarding LTM execution to the first target network node via a third network node 1006. When the LTM cell handover process to the first target cell fails, the UE detects a radio-related failure. The UE performs cell selection and selects a second target cell (1016). The UE determines whether the selected cell (1016) is an LTM candidate cell. If the second target cell is an LTM candidate cell, the UE applies the LTM candidate cell configuration and accesses the target cell using the obtained information. The UE sends a notification message (e.g., RRCReconfigurationComplete) to the second target node 1013 regarding the second target cell 1016. When the second target network node receives this notification, it determines that the UE has performed a cell handover to the second target cell 1016. The second target network node sends an indication to the third network node regarding the LTM cell handover to the second target cell 1016. The third network node knows that the LTM cell handover to the first target cell failed, but the UE has successfully recovered to the second target cell. The third network node can then inform the source network node, for example, by requesting a UE context modification or release, and as a result, the serving network node can consider the LTM cell handover to be complete (even if it may not know which cell it performed the LTM cell handover to). The third network node can also inform the first target network node 1003 that the previously indicated LTM cell handover to the first target cell 1010 has been cancelled, and / or request the release of any resources allocated by the first target network node in the first target cell (e.g., TCI status, UL authorization, etc.) that should be released.

[0177] In one embodiment, the UE receives an LTM cell handover command indicating an LTM cell handover to a third target cell (1017) controlled by a second target node (1013). The second target node (1013) is already aware that an LTM cell handover process to the third target cell 1017 has been triggered, for example, by the source network node 1002 sending an instruction regarding LTM execution to the second target network node via the third network node 1006. When the LTM cell handover process to the third target cell fails, the UE detects a radio-related failure. The UE performs cell selection and selects a second target cell (1016). The UE determines whether the selected cell (1016) is an LTM candidate cell. If the second target cell is an LTM candidate cell, the UE applies the LTM candidate cell configuration and accesses the target cell using the obtained information. The UE sends a notification message (e.g., RRCReconfigurationComplete) to the second target node 1013 regarding the second target cell 1016. When the second target network node receives the notification, it determines that the UE performed a cell handover to the second target cell 1016 instead of the third target cell 1017. The second target network node sends an indication to the third network node regarding the LTM cell handover to the second target cell 1016. The third network node knows that the LTM cell handover to the third target cell failed, but the UE has successfully recovered to the second target cell. The third network node can then inform the source network node, for example, by requesting UE context modification or release, and as a result, the serving network node can consider the LTM cell handover process complete (even if it may not know which cell it performed the LTM cell handover to). The third network node can release resources allocated in the third target cell, such as TCI state and UL authorization. Alternatively, the third network node can explicitly request the release of these resources.

[0178] Some embodiments of this disclosure will now be discussed.

[0179] A1. A method for a user equipment (UE) to perform recovery from a radio-related failure, including the UE:

[0180] • Receive at least one LTM candidate cell configuration.

[0181] • Radio-related detection failed.

[0182] • Select the appropriate cell location.

[0183] • Determine whether the selected cell (1016) is one of the LTM candidate cells that the UE has configured with stored LTM candidate cells.

[0184] • When the selected cell (1016) is one of the LTM candidate cells:

[0185] o Apply the stored LTM candidate cell configuration associated with the selected cell.

[0186] o Obtain information for accessing the target cell (1016),

[0187] o Using the obtained information for accessing the target cell, perform access in the target cell (1016).

[0188] o Send a notification message to the second target network node.

[0189] A2. According to the method described in A1, the UE performs an LTM cell handover to the target cell (1016).

[0190] A3. According to the method described in A1, the UE's access procedure in the target cell does not include a random access procedure following cell selection.

[0191] The method includes: the UE transmitting UL data or signaling in the target cell without a prior random access procedure.

[0192] A4. According to the method in A1, the UE performing access in the target cell includes a random access procedure after cell selection has been performed.

[0193] The method includes: after performing a random access procedure, the UE transmits UL data or signaling in the target cell.

[0194] A5. According to the method described in A1, the UE performs access within the beam in the target cell.

[0195] • This method involves the UE using information obtained for accessing the target cell (such as TCI status) to select a beam.

[0196] B1. A method for a source network node (source DU) (such as a source gNB, source DU, or source CU) to process UE recovery from a radio-related failure, including:

[0197] • Send at least one LTM candidate cell configuration to the UE, including a configuration of how the UE should perform the LTM cell handover procedure after a radio-related failure is detected.

[0198] B2. The method according to B1, wherein the configuration includes an indication configured for each LTM candidate cell regarding whether the UE is allowed to trigger an LTM cell handover based on a radio-related failure detected in the source cell.

[0199] B3. The method according to B2, wherein the instruction is applied to all LTM candidate cell configurations.

[0200] C1. A method for a first target network node (first target DU) (such as a target gNB, target DU, or target CU) to process a UE's recovery from a radio-related failure, comprising: receiving a notification message from the UE.

[0201] D1. A method for controlling a second target network node (second target DU) (such as a target gNB, target DU, or target CU) of a second target cell to handle UE recovery from radio-related failures, including:

[0202] • Receive notification messages from the UE.

[0203] D2. According to the method described in D1, wherein the notification message indicates that the UE has performed an LTM cell handover to the second target cell.

[0204] D3. The method described in D1 or D2, wherein the notification message includes an indication that the UE has detected a radio-related failure.

[0205] D4. According to the method described in D1, D2, or D3, wherein, after receiving the notification message,

[0206] • Send an indication to the third network node (1006) that the UE has performed an LTM cell handover.

[0207] D3. According to the method described in D4, the indication is a "successful access" message.

[0208] E1. A method for a third network node (CU) (or serving network node) (such as a (serving) central unit (CU), (serving) gNB-CU) to handle UE recovery from radio-related failures, including:

[0209] • Receive an indication from the second target network node (1013) that the UE has performed an LTM cell handover.

[0210] D2. According to the method described in D1, wherein the indication is a "successful access" message.

[0211] Now let's discuss sequence diagrams.

[0212] Figure 2 A message sequence diagram associated with a radio-related failure is shown as an example in some embodiments. In this example, the UE detects a radio-related failure and determines that the selected cell is an LTM candidate cell. The UE then triggers an LTM cell handover to the selected cell, using information for accessing the target cell during the access process.

[0213] refer to Figure 2 The operation or action in this example is as follows.

[0214] Step 2001. The network prepares LTM candidate cells for the UE. One of these cells is the second target cell (1016) controlled by the second target DU (1013).

[0215] Steps 2002 to 2003. Service DU (1002) configures LTM candidate cell configuration for UE.

[0216] Step 2004. The UE detects radio-related failures, such as radio link failures or failures in performing the LTM cell handover process to the first target cell (1010).

[0217] Step 2005. The UE performs cell selection and determines whether the selected cell is configured as an LTM candidate cell. In this example, the selected cell is the second target cell (1016) configured as an LTM candidate cell, so the UE performs an LTM cell handover to the candidate cell by applying the corresponding LTM candidate cell configuration. For the second target cell, the UE obtains information for accessing the target cell. When the obtained information includes, for example, TA and TCI states, the UE can skip random access and start UL transmission directly in the second target cell using the obtained information. Otherwise, the UE first performs a random access procedure.

[0218] Steps 2006 to 2007: The second target DU detects the first UL transmission from the UE and sends an "access successful" message to the CU to indicate the arrival of the UE.

[0219] Steps 2008 to 2009: The UE sends an RRCReconfigurationComplete message to the second target DU in the second target cell, and the second target DU forwards the message to the CU.

[0220] Steps 2010 to 2011. Based on the receipt of the "Access Successful" and RRCReconfigurationComplete messages, the CU determines that the UE has performed failure recovery to the second target cell. Then, the UE requests the Serving DU (1002) to modify the UE context, because the Serving DU will no longer provide services to the UE (but can be configured as an LTM candidate cell).

[0221] Figure 3 A message sequence diagram associated with an LTM cell handover procedure is shown as an example in some embodiments. In this example, an LTM cell handover procedure to a first target cell is triggered, and the UE detects a radio-related failure (such as an LTM cell handover procedure failure) and determines that the selected cell is an LTM candidate cell. The UE then triggers an LTM cell handover to the selected cell, using information for accessing the target cell during the access process.

[0222] refer to Figure 3 The operation or action in this example is as follows.

[0223] Step 3001. The network prepares LTM candidate cells for the UE. These cells are the first target cell (1010) controlled by the first target DU (1003) and the second target cell (1016) controlled by the second target DU (1013).

[0224] Steps 3002 to 3003. Service DU (1002) configures LTM candidate cell configuration for the UE.

[0225] Step 3004. The UE receives an LTM cell handover command, which indicates an LTM cell handover to the first target cell.

[0226] Steps 3005 to 3006: The service DU informs the CU of the execution, and the CU then informs the first target DU.

[0227] Step 3007. The UE detects a radio-related failure, in which case the LTM cell handover process to the first target cell (1010) fails (e.g., due to an LTM monitoring timer timeout).

[0228] Step 3008. The UE performs cell selection and determines whether the selected cell is configured as an LTM candidate cell. In this example, the selected cell is the second target cell (1016) configured as an LTM candidate cell, so the UE performs an LTM cell handover to the candidate cell by applying the corresponding LTM candidate cell configuration. For the second target cell, the UE obtains information for accessing the target cell. When the obtained information includes, for example, TA and TCI states, the UE can skip random access and start UL transmission directly in the second target cell using the obtained information. Otherwise, the UE first performs a random access procedure.

[0229] Steps 3009 to 3010: The second target DU detects the first UL transmission from the UE and sends an "access successful" message to the CU to indicate the arrival of the UE.

[0230] Steps 3011 to 3012: The UE sends an RRCReconfigurationComplete message to the second target DU in the second target cell, and the second target DU forwards the message to the CU.

[0231] Steps 3013 to 3014. Based on the received “Access Successful” and RRCReconfigurationComplete messages, the CU determines that the UE has performed failure recovery to the second target cell. Then, the UE requests the Serving DU (1002) to modify the UE context, because the Serving DU will no longer provide services to the UE (but can be configured as an LTM candidate cell).

[0232] Steps 3015 to 3016: The CU informs the first target DU that the previously instructed LTM cell handover execution to the first target cell has been cancelled and the first target DU should release any dynamic resources allocated to the UE, such as TCI status or UL authorization.

[0233] Figure 4 An example of an operation performed by the UE is shown in some embodiments.

[0234] refer to Figure 4 The operation performed by the UE in this example is as follows.

[0235] Step 4001. The UE receives at least one LTM candidate cell configuration.

[0236] Step 4002. The UE detects radio-related failures, such as radio link failures or failures in performing the LTM cell handover process to the first target cell (1010).

[0237] Step 4003. The UE performs cell selection. In this example, the selected cell is the second target cell (1016).

[0238] Step 4004. The UE determines whether the selected cell (1016) is an LTM candidate cell. If the selected cell is not an LTM candidate cell, the UE proceeds to step 4008; otherwise, it proceeds to the next step.

[0239] Step 4005. When the selected cell is an LTM candidate cell, the UE applies the stored LTM candidate cell configuration to the second target cell.

[0240] Step 4006. For the second target cell, the UE obtains information for accessing the target cell, such as TA and TCI status.

[0241] Step 4007. By using the information obtained for accessing the target cell when performing access in the second target cell, the UE can skip random access and directly start UL transmission.

[0242] Step 4008. The UE sends an RRCReconfigurationComplete message in the second target cell.

[0243] Step 4009. When the selected cell is not an LTM candidate cell, in this example, the UE initiates an RRC reconstruction procedure and sends an RRC reconstruction request message in the second target cell.

[0244] The specification text changes for the 3GPP TS 38.331 RRC protocol are as follows: [...]

[0246] 5.3.7.3 Actions after cell selection while T311 is running

[0247] When selecting a suitable NR cell, the UE should:

[0248] 1> Ensure that the basic system information is valid and up-to-date as specified in Clause 5.2.2.2;

[0249] 1> Stop timer T311;

[0250] 1> If T390 is running:

[0251] 2> Stop timer T390 for all access categories;

[0252] 2> Perform the actions specified in 5.3.14.4;

[0253] 1> Stop the relay (re)selection process (if it is in progress);

[0254] 1> If cell selection is triggered by detecting radio link failure of the MCG, synchronization reconfiguration failure of the MCG, or mobility failure from the NR, and

[0255] 1> If attemptCondReconfig is configured; and

[0256] 1> If the selected cell is not configured with CondEventT1, or if the selected cell is configured with CondEventT1 but the leave condition has not yet been met; and

[0257] 1> If the selected cell is one of the candidate cells in the masterCellGroup that includes reconfigurationWithSync in MCGVarConditionalReconfig:

[0258] 2> If the UE supports RLF-Report for conditional handover, set choCellId in VarRLF-Report to the global cell identifier (if available), otherwise set to the physical cell identifier and carrier frequency of the selected cell;

[0259] 2> Apply the stored condRRCReconfig associated with the selected cell and perform the actions specified in 5.3.5.3;

[0260] Note 1: In the absence of key changes, after a failed switchover, and in the case of CHO-based recovery, how to avoid key stream reuse is left to the network implementation.

[0261] 1> If the selected cell is one of the candidate cells for which the UE has a stored LTM configuration in the UE-LTM-Config within VarLTM-UE-Config:

[0262] 2> Apply the stored LTM configuration in the UE-LTM-Config within the VarLTM-UE-Config associated with the selected cell and perform the actions specified in 5.3.5.3;

[0263] Note 1: In the absence of key changes, after a failed handover, and in the case of LTM-based recovery, how to avoid key stream reuse is left to the network implementation.

[0264] 1> Otherwise:

[0265] 2> If the UE is configured with attemptCondReconfig:

[0266] 3> Reset MAC;

[0267] 3> Release spCellConfig (if it has been configured);

[0268] 3> Release the MCG SCell (if configured);

[0269] 3> Release delayBudgetReportingConfig (if configured) and stop timer T342 (if it is running);

[0270] 3> Release overheatingAssistanceConfig (if configured) and stop timer T345 (if running);

[0271] 3> If MR-DC is configured:

[0272] 4> Perform MR-DC release as specified in Clause 5.3.5.10;

[0273] 3> Release idc-AssistanceConfig (if it has been configured);

[0274] 3> Release btNameList (if configured);

[0275] 3> Release wlanNameList (if it is configured);

[0276] 3> Release sensorNameList (if configured);

[0277] 3> Release the drx-PreferenceConfig of MCG (if configured) and stop the timer T346a associated with MCG (if it is running);

[0278] 3> Release the maxBW-PreferenceConfig of the MCG (if configured) and stop the timer T346b associated with the MCG (if it is running).

[0279] 3> Release the maxCC-PreferenceConfig of the MCG (if configured) and stop the timer T346c associated with the MCG (if it is running).

[0280] 3> Release the maxMIMO-LayerPreferenceConfig of the MCG (if configured) and stop the timer T346d associated with the MCG (if it is running);

[0281] 3> Release minSchedulingOffsetPreferenceConfig (if configured) and stop timer T346e associated with MCG (if it is running);

[0282] 3> Release rlm-RelaxationReportingConfig (if configured) and stop timer T346j associated with MCG (if running);

[0283] 3> Release bfd-RelaxationReportingConfig (if configured) and stop timer T346k associated with MCG (if running);

[0284] 3> Release releasePreferenceConfig (if configured) and stop timer T346f (if running);

[0285] 3> Release onDemandSIB-Request (if configured) and stop timer T350 (if it is running);

[0286] 3> Release referenceTimePreferenceReporting (if configured);

[0287] 3> Release sl-AssistanceConfigNR (if it is configured);

[0288] 3> Release obtainCommonLocation (if configured);

[0289] 3> Release scg-DeactivationPreferenceConfig (if configured) and stop timer T346i (if running);

[0290] 3> Release musim-GapAssistanceConfig (if configured) and stop timer T346h (if running);

[0291] 3> Release musim-LeaveAssistanceConfig (if it is configured);

[0292] 3> Release propDelayDiffReportConfig (if it is configured);

[0293] 3> Release ul-GapFR2-PreferenceConfig (if it has been configured);

[0294] 3> Release rrm-MeasRelaxationReportingConfig (if it is configured);

[0295] 3> Release maxBW-PreferenceConfigFR2-2 (if it is configured);

[0296] 3> Release maxMIMO-LayerPreferenceConfigFR2-2 (if it is configured);

[0297] 3> Release minSchedulingOffsetPreferenceConfigExt (if it is configured);

[0298] 3> Suspend all radio bearers (RBs) and backhaul (BH) RLC channels for integrated access and backhaul (IAB) - multiple transceiver (MT), except for signaling radio bearer (SRB) 0 and broadcast multicast RB (MRB);

[0299] 2> Remove all entries (if any) from MCG VarConditionalReconfig;

[0300] 2> For each measId, if the associated reportConfig has a reportType that is set to condTriggerConfig:

[0301] 3> For the associated reportConfigId:

[0302] 4> Remove entries with a matching reportConfigId from reportConfigList within VarMeasConfig;

[0303] 3> If the associated measObjectId is only associated with a reportConfig that has a reportType set to condTriggerConfig:

[0304] 4> Remove entries with matching measObjectId from measObjectList within VarMeasConfig;

[0305] 3> Remove entries with matching measId from measIdList within VarMeasConfig;

[0306] 2> Release the PC5 RLC entity used for SL-RLC0 (if any);

[0307] 2> Start timer T301;

[0308] 2> Apply the default L1 parameter values ​​specified in the corresponding physical layer specification, except for the parameters provided in SIB1;

[0309] 2> Apply the default MAC cell group configuration specified in 9.2.2;

[0310] 2> Apply the CCCH configuration specified in 9.1.1.2;

[0311] 2> Use the timeAlignmentTimerCommon included in SIB1;

[0312] 2> Initiate the transmission of the RRCReestablishmentRequest message according to 5.3.7.4;

[0313] Note 2: This procedure also applies to the case where the UE returns to the source PCell.

[0314] When selecting an inter-RAT cell, the UE should:

[0315] 1> Perform the action specified in 5.3.11 when entering RRC_IDLE, releasing the cause as "RRC connection failed". [...]

[0317] Figure 5 An example of a method performed by the UE is shown in some embodiments.

[0318] refer to Figure 5 In this example, the operation performed by the UE is as follows.

[0319] At box 500, the UE receives at least one LTM candidate cell configuration and stores it in the UE.

[0320] At box 502, the UE detects a radio-related failure, such as a radio link failure or a failure to perform an LTM cell handover procedure (1010) to the first target cell.

[0321] At box 504, the UE performs cell selection in response to the detection of a radio-related failure, for example, the selected cell is the second target cell (1016).

[0322] At box 506, the UE determines whether the selected cell corresponds to one of the at least one of the stored LTM candidate cell configurations.

[0323] At box 508, in response to the selected cell corresponding to one of the stored at least one LTM candidate cell configurations, the UE applies the stored LTM candidate cell configuration corresponding to the selected cell as the target cell.

[0324] Figure 6 A method for handling UE recovery from radio-related failures, performed by a source network node, is shown as an example in some embodiments.

[0325] refer to Figure 6 In this example, the operations performed by the source network node to handle the UE's recovery from a radio-related failure are as follows.

[0326] At box 600, the source network node sends at least one LTM candidate cell configuration to the UE, which indicates how the UE should perform the LTM cell handover procedure after a radio-related failure is detected.

[0327] Figure 7 An example of a communication system 700 according to some embodiments is shown.

[0328] In this example, the communication system 700 includes: a telecommunications network 702, including an access network 704 such as a radio access network (RAN); and a core network 706, including one or more core network nodes 708. The access network 704 includes one or more access network nodes, such as network nodes 710a and 710b (one or more of which may generally be referred to as network node 710), or any other similar 3GPP access node or non-3GPP access point. Furthermore, those skilled in the art will understand that network nodes are not necessarily limited to implementations provided by a single vendor and integrating the radio and baseband portions. Therefore, it will be understood that network nodes include decomposed implementations or portions thereof. For example, in some embodiments, the telecommunications network 702 includes one or more Open RAN (ORAN) network nodes. ORAN network nodes are nodes in the telecommunications network 702 that support ORAN specifications (e.g., specifications published by the O-RAN Alliance or any similar organization) and can operate independently or in conjunction with other nodes to implement one or more functions of any node in the telecommunications network 702 (including one or more network nodes 710 and / or core network nodes 708).

[0329] Examples of ORAN network nodes include Open Radio Units (O-RUs), Open Distributed Units (O-DUs), Open Central Units (O-CUs), including O-CU control planes (O-CU-CPs) or O-CU user planes (O-CU-UPs), managed software or software plug-ins (e.g., near real-time control applications (e.g., xApps) or non-real-time control applications (e.g., rApps)), RAN intelligent controllers (near real-time or non-real-time), or any combination thereof (the adjective "open" indicates support for the ORAN specification). Network nodes can support the specification by, for example, supporting interfaces defined by the ORAN specification (e.g., A1, F1, W1, E1, E2, X2, Xn interfaces), open fronthaul user plane interfaces, or open fronthaul management plane interfaces. Furthermore, ORAN access nodes can be logical nodes within physical nodes. Additionally, ORAN network nodes can be implemented in a virtualized environment (described further below) where one or more network functions are virtualized. For example, a virtualized environment may include an open cloud (O-Cloud) computing platform orchestrated by a service management and orchestration framework via an O-2 interface or equivalent technology defined by the O-RAN Alliance. Network node 710 facilitates direct or indirect connections of user equipment (UEs), such as connecting UEs 712a, 712b, 712c, and 712d (one or more of which may generally be referred to as UE 712) to core network 706 via one or more wireless connections.

[0330] Examples of wireless communication via wireless connection include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for transmitting information without using wiring, cables, or other conductors. Furthermore, in various embodiments, communication system 700 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that can facilitate or participate in the communication of data and / or signals (whether via wired or wireless connections). Communication system 700 may include any type of communication, telecommunications, data, cellular, radio network, and / or other similar system, and / or interface with any type of communication, telecommunications, data, cellular, radio network, and / or other similar system.

[0331] UE 712 can be any of a wide variety of communication devices, including wireless devices that are arranged, configured, and / or operable to communicate wirelessly with network node 710 and other communication devices. Similarly, network node 710 is arranged, capable of, configured, and / or operable to communicate directly or indirectly with UE 712 and / or with other network nodes or devices in telecommunication network 702 to achieve and / or provide network access (e.g., wireless network access) and / or to perform other functions (e.g., management) in telecommunication network 702.

[0332] In the depicted example, core network 706 connects network node 710 to one or more hosts (such as host 716). These connections can be direct connections or indirect connections via one or more intermediate networks or devices. In other examples, network nodes may be directly coupled to hosts. Core network 706 includes one or more core network nodes (e.g., core network node 708) that are formed together with hardware and software components. The characteristics of these components may be substantially similar to those described with respect to UEs, network nodes, and / or hosts, such that the description is generally applicable to the corresponding components of core network node 708. Example core network nodes include the functions of one or more of the following: Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier Unhiding Function (SIDF), Unified Data Management (UDM), Security Edge Protection Agent (SEPP), Network Open Function (NEF), and / or User Plane Function (UPF).

[0333] Host 716 may be owned or under the control of a service provider other than the operator or provider of access network 704 and / or telecommunications network 702, and may be operated by or on behalf of the service provider. Host 716 may host a variety of applications to provide one or more services. Examples of such applications include real-time and pre-recorded audio / video content, data collection services (e.g., retrieving and compiling data about various environmental conditions detected by multiple UEs), analytics functions, social media, functions for controlling or otherwise interacting with remote devices, functions for alarm and monitoring centers, or any other such functions performed by a server.

[0334] As a whole, Figure 7The communication system 700 enables connections between the UE, network nodes, and hosts. In this sense, the communication system can be configured to operate according to predefined rules or processes such as specific standards, including but not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE) and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G); Wireless Local Area Network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard (WiFi); and / or any other suitable wireless communication standards, such as Global Microwave Access Interoperability (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and / or any Low Power Wide Area Network (LPWAN) standards such as LoRa and Sigfox.

[0335] In some examples, telecommunications network 702 is a cellular network implementing 3GPP standardized features. Therefore, telecommunications network 702 can support network slicing to provide different logical networks to different devices connected to it. For example, telecommunications network 702 can provide ultra-reliable low-latency communication (URLLC) services to some UEs while providing enhanced mobile broadband (eMBB) services to other UEs, and / or massive machine-type communication (mMTC) / massive IoT services to yet another UE.

[0336] In some examples, UE 712 is configured to send and / or receive information without direct human interaction. For example, the UE may be designed to send information to access network 704 according to a predetermined schedule when triggered by internal or external events or in response to a request from access network 704. Additionally, the UE may be configured to operate in single-RAT mode, multi-RAT mode, or multi-standard mode. For example, the UE may operate using any one or a combination of Wi-Fi, NR (New Radio), and LTE, i.e., configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved UMTS Terrestrial Radio Access Network) New Radio Dual Connectivity (EN-DC).

[0337] In this example, the central hub 714 communicates with the access network 704 to facilitate indirect communication between one or more UEs (e.g., UEs 712c and / or 712d) and a network node (e.g., network node 710b). In some examples, the central hub 714 may be a controller, router, content source and analyzer, or any other communication device described herein relating to the UE. For example, the central hub 714 may be a broadband router that enables the UE to access the core network 706. As another example, the central hub 714 may be a controller that sends commands or instructions to one or more actuators of the UE. Commands or instructions may be received from the UE, network node 710, or via executable code, scripts, procedures, or other instructions in the central hub 714. As another example, the central hub 714 may be a data collector that acts as a temporary storage device for UE data, and in some embodiments, data analysis or other processing may be performed. As another example, the central hub 714 may be a content source. For example, for a UE acting as a VR headset, display, speaker, or other media delivery device, hub 714 can retrieve VR assets, video, audio, or other media or data related to perceived information via a network node, and then provide them directly to the UE after performing local processing and / or adding additional local content. In yet another example, hub 714 acts as a proxy server or orchestrator for the UE, particularly if one or more of the UEs are low-power IoT devices.

[0338] The hub 714 may have a persistent / persistent or intermittent connection to network node 710b. The hub 714 may also allow different communication schemes and / or scheduling between the hub 714 and UEs (e.g., UEs 712c and / or 712d) and between the hub 714 and the core network 706. In other examples, the hub 714 is connected to the core network 706 and / or one or more UEs via a wired connection. Furthermore, the hub 714 may be configured to connect to an M2M service provider via access network 704, and / or to another UE via a direct connection. In some scenarios, a UE may establish a wireless connection with network node 710 while still being connected via the hub 714 through a wired or wireless connection. In some embodiments, the hub 714 may be a dedicated hub, i.e., a hub whose primary function is to route communication from network node 710b to UE / to network node 710b. In other embodiments, the hub 714 may be a non-dedicated hub, i.e., a device capable of operating to route communication between the UE and network node 710b, but additionally capable of operating as a communication start point and / or endpoint for certain data channels.

[0339] Figure 8A UE 800 according to some embodiments is illustrated. As used herein, a UE refers to a device capable of, configured, positioned, and / or operable to wirelessly communicate with network nodes and / or other UEs. Examples of UEs 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, gaming consoles or devices, music storage devices, playback devices, wearable terminal devices, wireless endpoints, mobile stations, tablet computers, laptop computers, laptop embedded devices (LEEs), laptop-mounted devices (LMEs), smart devices, wireless client devices (CPEs), vehicle-mounted or vehicle-embedded / integrated wireless devices, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including Narrowband Internet of Things (NB-IoT) UEs, Machine Type Communication (MTC) UEs, and / or Enhanced MTC (eMTC) UEs.

[0340] The UE can support device-to-device (D2D) communication, for example, by implementing 3GPP standards for sidelink communication, Dedicated Short-Range Communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2X). In other examples, the UE may not necessarily be a user in the sense of a human user who owns and / or operates the associated device. Alternatively, the UE may represent a device intended to be sold to or operated by a human user but which may not or initially may not be associated with a particular human user (e.g., a smart sprinkler controller). Alternatively, the UE may represent a device not intended to be sold to or operated by an end user but which may be associated with or operated for the benefit of the user (e.g., a smart power meter).

[0341] UE 800 includes processing circuitry 802, which is operatively coupled via bus 804 to input / output interface 806, power supply 808, memory 810, communication interface 812, and / or any other component or any combination thereof. Some UEs may utilize... Figure 8 The components shown may be all or a subset. The level of integration between components can vary depending on the UE. Furthermore, some UEs may include multiple instances of components, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0342] Processing circuitry 802 is configured to process instructions and data and can be configured to implement any sequential state machine operable to execute instructions stored in memory 810 as machine-readable computer processes. Processing circuitry 802 can be implemented as: one or more hardware-implemented state machines (e.g., implemented with discrete logic, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), etc.); programmable logic together with appropriate firmware; one or more stored computer programs, general-purpose processors (e.g., microprocessors or digital signal processors (DSPs)) together with appropriate software; or any combination of the foregoing. For example, processing circuitry 802 may include multiple central processing units (CPUs).

[0343] In the example, input / output interface 806 can be configured to provide one or more interfaces to input devices, output devices, or one or more input and / or output devices. Examples of output devices include speakers, sound cards, video cards, displays, monitors, printers, actuators, transmitters, smart cards, other output devices, or any combination thereof. Input devices can allow users to capture information into UE 800. Examples of input devices include touch-sensitive or presence-sensitive displays, cameras (e.g., digital cameras, digital camcorders, webcams, etc.), microphones, sensors, mice, trackballs, directional keyboards, touchpads, scroll wheels, smart cards, etc. Presence-sensitive displays may include capacitive or resistive touch sensors to sense input from the user. Sensors may be, for example, accelerometers, gyroscopes, tilt sensors, force sensors, magnetometers, optical sensors, proximity sensors, biometric sensors, etc., or any combination thereof. Output devices can use the same type of interface port as input devices. For example, a Universal Serial Bus (USB) port can be used to provide both input and output devices.

[0344] In some embodiments, power supply 808 is configured as a battery or battery pack. Other types of power sources can be used, such as external power sources (e.g., power outlets), photovoltaic devices, or batteries. Power supply 808 may also include power supply circuitry for delivering power from power supply 808 itself and / or external power sources to various parts of UE 800 via input circuitry or an interface such as a power cable. The delivery of power can, for example, be used for charging power supply 808. The power supply circuitry can perform any formatting, conversion, or other modifications on the power from power supply 808 to suit the power for the corresponding components of UE 800 to which it is supplied power.

[0345] Memory 810 may be or be configured to include memory such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), disk, optical disk, hard disk, removable magnetic tape, flash drive, etc. In one example, memory 810 includes one or more application processes 814, such as an operating system, web browser application, widget, utility engine, or other application, and corresponding data 816. Memory 810 may store any one or a combination of various operating systems used by UE 800.

[0346] The memory 810 can be configured to include multiple physical drive units, such as a redundant array of independent disks (RAID), flash memory, a USB flash drive, an external hard drive, a thumb drive, a pen drive, a key drive, a high-density digital multifunction optical disc (HD-DVD) drive, an internal hard drive, a Blu-ray disc drive, a holographic digital data storage (HDDS) disc drive, an external mini dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro DIMM SDRAM, smart card memory (e.g., a tamper-proof module in the form of a universal integrated circuit card (UICC) including one or more subscriber identification modules (SIMs), such as USIM and / or ISIM), other memory, or any combination thereof. The UICC can be, for example, an embedded UICC (eUICC), an integrated UICC (iUICC), or a removable UICC commonly referred to as a "SIM card." The memory 810 can allow the UE 800 to access instructions, applications, etc., stored on transient or non-transient storage media to offload or upload data. Articles of manufacture, such as those utilizing a communication system, may be tangibly embodied in or contained in memory 810, which may be or include a device-readable storage medium.

[0347] Processing circuitry 802 can be configured to communicate with an access network or other network using communication interface 812. Communication interface 812 may include one or more communication subsystems and may include antenna 822 or be communicatively coupled to antenna 822. Communication interface 812 may include one or more transceivers for communication, such as communication with one or more remote transceivers capable of wireless communication (e.g., another UE or a network node in the access network). Each transceiver may include a transmitter 818 and / or a receiver 820 suitable for providing network communication (e.g., optical, electrical, frequency allocation, etc.). Furthermore, transmitter 818 and receiver 820 may be coupled to one or more antennas (e.g., antenna 822) and may share circuitry, software, or firmware, or alternatively, be implemented separately.

[0348] In the illustrated embodiment, the communication functions of the communication interface 812 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communication such as Bluetooth, near-field communication, location-based communication (e.g., using a Global Positioning System (GPS) to determine location), another type of communication function, or any combination thereof. Communication may be implemented according to one or more communication protocols and / or standards (e.g., IEEE 802.11, Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, Transmission Control Protocol / Internet Protocol (TCP / IP), Synchronous Optical Network (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), etc.).

[0349] Regardless of the sensor type, the UE can provide the output of data captured by its sensors via its communication interface 812 through a wireless connection with a network node. Data captured by the UE's sensors can be transmitted via another UE through the same wireless connection. The output can be periodic (e.g., every 15 minutes if it reports the sensed temperature), random (e.g., to balance the load of reports from several sensors), responsive to a triggering event (e.g., sending an alarm when humidity is detected), responsive to a request (e.g., a user-initiated request), or a continuous stream (e.g., real-time video feed of a patient).

[0350] As another example, the UE includes actuators, motors, or switches associated with a communication interface configured to receive wireless input from a network node via a wireless connection. The state of the actuator, motor, or switch can change in response to the received wireless input. For example, the UE may include a motor that adjusts the control surfaces or rotors of a flying drone based on the received input, or adjusts a robotic arm performing a medical procedure based on the received input.

[0351] When the UE is in the form of an Internet of Things (IoT) device, the UE can be a device used in one or more application areas, including but not limited to urban wearable technology, extended industrial applications, and healthcare. Non-limiting examples of such IoT devices include or embedded in the following devices: connected refrigerators or freezers, televisions, connected lighting devices, electricity meters, robotic vacuum cleaners, voice-controlled smart speakers, home security cameras, motion detectors, thermostats, smoke detectors, door and window sensors, flood / humidity sensors, electronic door locks, connected doorbells, air conditioning systems (such as heat pumps), autonomous vehicles, surveillance systems, weather monitoring devices, vehicle parking monitoring devices, electric vehicle charging stations, smartwatches, fitness trackers, head-mounted displays for augmented reality (AR) or virtual reality (VR), wearable devices for haptic or sensory enhancement, sprinklers, animal or item tracking devices, sensors for monitoring plants or animals, industrial robots, unmanned aerial vehicles (UAVs), and any kind of medical device (such as heart rate monitors or remote-controlled surgical robots). In addition to the above... Figure 8 In addition to the other components described in the UE 800 shown, UEs in the form of IoT devices also include circuitry and / or software depending on the intended application of the IoT device.

[0352] As another specific example, in an IoT scenario, a UE can represent a machine or other device that performs monitoring and / or measurement and sends the results of such monitoring and / or measurement to another UE and / or network node. In this case, the UE can be an M2M device, which can be referred to as an MTC device in the 3GPP context. As a specific example, this UE can implement the 3GPP NB-IoT standard. In other scenarios, a UE can represent a vehicle (e.g., a car, bus, truck, ship, and aircraft) or other device capable of monitoring and / or reporting its operational status or other functions associated with its operation.

[0353] In practice, any number of UEs can be used together for a single use case. For example, the first UE can be a drone or integrated into a drone, and provides the drone's speed information (obtained via a speed sensor) to a second UE, which is a remote controller for operating the drone. When the user makes a change from the remote controller, the first UE can adjust the throttle on the drone (e.g., by controlling the actuators) to increase or decrease the drone's speed. The first UE and / or the second UE can also include more than one of the functions described above. For example, the UE can include sensors and actuators, and handle data communication between both the speed sensor and the actuators.

[0354] Figure 9 A network node 900 according to some embodiments is illustrated. As used herein, a network node refers to a device that is capable of, configured, arranged, and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or devices in a telecommunications network. 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, NodeBs, evolved NodeBs (eNBs), and NR NodeBs (gNBs)), O-RAN nodes, or components of O-RAN nodes (e.g., O-RUs, O-DUs, O-CUs).

[0355] Base stations can be classified based on the coverage they provide (or, in other words, their transmission power levels); therefore, depending on the coverage provided, a base station can be called a femtobase, picobase, microbase, or macrobase. A base station can be a relay node or a relay donor for control relays. Network nodes can also include one or more (or all) portions of a distributed radio base station, such as centralized digital units, distributed units (e.g., in O-RAN access nodes), and / or remote radio units (RRUs), sometimes referred to as remote radio headends (RRHs). These remote radio units can be integrated with antennas to form an antenna-integrated radio, or they can be independent of antenna integration. A portion of a distributed radio base station can also be referred to as a node in a distributed antenna system (DAS).

[0356] Other examples of network nodes include multi-transmitter point (multi-TRP) 5G access nodes, multi-standard radio (MSR) devices (e.g., MSR BS), network controllers (e.g., radio network controllers (RNC) or base station controllers (BSC)), base transceiver stations (BTS), transmitter points, transmitter nodes, multi-cell / multicast coordination entities (MCE), operations and maintenance (O&M) nodes, operations support system (OSS) nodes, self-organizing network (SON) nodes, location nodes (e.g., evolved Serving Mobility Location Center (E-SMLC)) and / or minimized drive test (MDT).

[0357] Network node 900 includes processing circuitry 902, memory 904, communication interface 906, and power supply 908. Network node 900 may consist of multiple physically separate components (e.g., Node B components and RNC components, BTS components and BSC components, etc.), each with its own corresponding components. In some scenarios where network node 900 includes multiple separate components (e.g., BTS and BSC components), one or more separate components may be shared among several network nodes. For example, a single RNC can control multiple NodeBs. In such scenarios, each unique “NodeB and RNC pair” can be considered a single, separate network node in some cases. In some embodiments, network node 900 may be configured to support multiple Radio Access Technologies (RATs). In such embodiments, some components may be replicated (e.g., separate memory 904 exists for different RATs) and some components may be reused (e.g., the same antenna 910 may be shared by different RATs). Network node 900 may also include multiple sets of various components shown for different wireless technologies (e.g., GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, RFID, or Bluetooth wireless technologies). These wireless technologies may be integrated into the same or different chips or chipsets and other components within network node 900.

[0358] The processing circuitry 902 may include one or more of the following: a microprocessor, a controller, 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 coding logic, operable to provide network node 900 functionality, either alone or in combination with other network node 900 components (e.g., memory 904).

[0359] In some embodiments, the processing circuitry 902 includes a system-on-a-chip (SOC). In some embodiments, the processing circuitry 902 includes one or more of a radio frequency (RF) transceiver circuitry 912 and a baseband processing circuitry 914. In some embodiments, the RF transceiver circuitry 912 and the baseband processing circuitry 914 may be on separate chips (or chipsets), boards, or units (e.g., radio units and digital units). In alternative embodiments, some or all of the RF transceiver circuitry 912 and the baseband processing circuitry 914 may be on the same chip or chipset, board, or unit group.

[0360] Memory 904 may include any form of volatile or non-volatile computer-readable memory, including but not limited to permanent storage devices, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (e.g., hard disk), removable storage media (e.g., flash drives, optical discs (CDs), or digital video discs (DVDs)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory device that stores information, data, and / or instructions that can be used by processing circuitry 902. Memory 904 may store any suitable instructions, data, or information, including computer processes, software, applications including logic, rules, codes, tables, and / or other instructions that can be executed by processing circuitry 902 and used by network node 900. Memory 904 may be used to store any calculations performed by processing circuitry 902 and / or any data received via communication interface 906. In some embodiments, processing circuitry 902 and memory 904 are integrated together.

[0361] Communication interface 906 is used for wired or wireless communication of signaling and / or data between network nodes, access networks, and / or UEs. As shown, communication interface 906 includes a port / terminal 916 for transmitting and receiving data to and from the network, for example, via a wired connection. Communication interface 906 also includes radio front-end circuitry 918, which may be coupled to antenna 910, or in some embodiments to a portion of antenna 910. Radio front-end circuitry 918 includes a filter 920 and an amplifier 922. Radio front-end circuitry 918 may be connected to antenna 910 and processing circuitry 902. Radio front-end circuitry 918 may be configured to modulate the signal transmitted between antenna 910 and processing circuitry 902. Radio front-end circuitry 918 may receive digital data to be transmitted to other network nodes or UEs via a wireless connection. Radio front-end circuitry 918 may use a combination of filter 920 and / or amplifier 922 to convert the digital data into a radio signal with appropriate channel and bandwidth parameters. The radio signal may then be transmitted via antenna 910. Similarly, when data is received, antenna 910 can collect radio signals, which are then converted into digital data by radio front-end circuitry 918. The digital data can then be passed to processing circuitry 902. In other embodiments, the communication interface may include different components and / or different combinations of components.

[0362] In some alternative embodiments, network node 900 does not include a separate radio front-end circuitry 918; instead, processing circuitry 902 includes radio front-end circuitry and is connected to antenna 910. Similarly, in some embodiments, all or some of the RF transceiver circuitry 912 is part of communication interface 906. In yet another embodiment, communication interface 906 includes one or more ports or terminals 916, radio front-end circuitry 918, and RF transceiver circuitry 912 as part of a radio unit (not shown), and communication interface 906 communicates with baseband processing circuitry 914, which is part of a digital unit (not shown).

[0363] Antenna 910 may include one or more antennas or antenna arrays configured to transmit and / or receive wireless signals. Antenna 910 may be coupled to radio front-end circuitry 918 and may be any type of antenna capable of wirelessly transmitting and receiving data and / or signals. In some embodiments, antenna 910 is decoupled from network node 900 and may be connected to network node 900 via an interface or port.

[0364] Antenna 910, communication interface 906, and / or processing circuitry 902 can be configured to perform any receive operation and / or certain acquire operation described herein by a network node. Any information, data, and / or signals can be received from the UE, another network node, and / or any other network device. Similarly, antenna 910, communication interface 906, and / or processing circuitry 902 can be configured to perform any transmit operation described herein by a network node. Any information, data, and / or signals can be transmitted to the UE, another network node, and / or any other network device.

[0365] Power supply 908 provides power to the various components of network node 900 in a form suitable for the various components (e.g., at the voltage and current levels required by each respective component). Power supply 908 may also include or be coupled to power management circuitry to supply power to the components of network node 900 for performing the functions described herein. For example, network node 900 may be connected to an external power source (e.g., mains, power outlet) via input circuitry or an interface (e.g., cable), thereby supplying power to the power circuitry of power supply 908. As another example, power supply 908 may include a power source in the form of a battery or battery pack, which is connected to or integrated into the power circuitry. The battery can provide backup power if the external power source fails.

[0366] Implementations of network node 900 may include more than Figure 9The components shown are additional components used to provide certain aspects of the functionality of the network node, including any functionality described herein and / or any functionality required to support the topics described herein. For example, network node 900 may include a user interface device to allow information to be input into and output from network node 900. This allows users to perform diagnostic, maintenance, repair, and other management functions on network node 900.

[0367] Figure 10 This is a block diagram of host 1000 based on the various aspects described herein, which host 1000 may be Figure 7 The embodiment of host 716. As used herein, host 1000 can be or include various combinations of hardware and / or software, including processing resources in a standalone server, blade server, cloud-implemented server, distributed server, virtual machine, container, or server cluster. Host 1000 can provide one or more services to one or more UEs.

[0368] Host 1000 includes processing circuitry 1002, which is operatively coupled via bus 1004 to input / output interface 1006, network interface 1008, power supply 1010, and memory 1012. Other components may be included in other embodiments. The features of these components may be substantially similar to those with respect to the previous figures (e.g., Figure 8 and Figure 9 The characteristics described for the device make its description generally applicable to the corresponding components of the host 1000.

[0369] Memory 1012 may include one or more computer programs, including data 1016 and one or more host applications 1014. Data 1016 may include user data, such as data generated by the UE for the host 1000, or data generated by the host 1000 for the UE. Embodiments of the host 1000 may utilize only a subset or all of the illustrated components. Host application 1014 may be implemented in a container-based architecture and may provide support for video codecs (e.g., Universal Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), MPEG, VP9) and audio codecs (e.g., FLAC, Advanced Audio Coding (AAC), MPEG, G.711), including transcoding for various categories, types, or implementations of UEs (e.g., mobile phones, desktop computers, wearable display systems, head-up display systems). Host application 1014 may also provide user authentication and authorization checks and may periodically report health status, routing, and content availability to a central node (such as a device in the core network or a device at the edge of the core network). Therefore, host 1000 can select and / or indicate different hosts for over-the-top services for the UE. Host application 1014 can support various protocols, such as HTTP Live Streaming (HLS), Real-time Messaging Protocol (RTMP), Real-time Streaming Protocol (RTSP), Dynamic Adaptive Streaming over HTTP (MPEG-DASH), etc.

[0370] Figure 11 This is a block diagram illustrating a virtualization environment 1100, in which functionality implemented by some embodiments can be virtualized. In this context, virtualization means creating a virtual version of an apparatus or device that may include a virtualized hardware platform, storage devices, and network resources. As used herein, virtualization can be applied to any device or component thereof described herein, and involves at least a portion of its functionality being implemented as an implementation of one or more virtual components. Some or all of the functionality described herein can be implemented as virtual components executed by one or more virtual machines (VMs) in one or more virtual environments 1100 hosted by one or more hardware nodes (e.g., hardware computing devices operating as network nodes, UEs, core network nodes, or hosts). Furthermore, in embodiments where virtual nodes do not require radio connectivity (e.g., core network nodes or hosts), the nodes can be fully virtualized. In some embodiments, the virtualization environment 1100 includes components defined by the O-RAN Alliance, such as an open cloud environment orchestrated via an O-2 interface by a service management and orchestration framework.

[0371] Application 1102 (which may alternatively be referred to as a software instance, virtual device, network function, virtual node, virtual network function, etc.) operates in a virtualized environment Q400 to implement some of the features, functions, and / or benefits of some embodiments disclosed herein.

[0372] Hardware 1104 includes processing circuitry, memory storing software and / or instructions executable by the hardware processing circuitry, and / or other hardware devices described herein (such as network interfaces, input / output interfaces, etc.). The software can be executed by the processing circuitry to instantiate one or more virtualization layers 1106 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 1108a and 1108b (one or more of which may generally be referred to as VM 1108), and / or perform any functionality, features, and / or benefits described in relation to some embodiments described herein. Virtualization layer 1106 can present a virtual operating platform to VM 1108, which appears as network hardware.

[0373] VM 1108 includes virtual processing, virtual memory, virtual network or interface, and virtual storage, and can be operated by a corresponding virtualization layer 1106. Different embodiments of instances of virtual device 1102 can be implemented on one or more VMs 1108, and these implementations can be carried out in different ways. In some contexts, hardware virtualization is referred to as Network Functions Virtualization (NFV). NFV can be used to unify numerous network device types onto industry-standard high-capacity server hardware, physical switches, and physical storage that can reside in data centers and customer premises equipment (CPE).

[0374] In the context of NFV, VM 1108 can be a software implementation of a physical machine, whose operating procedures are executed as if on a physical, non-virtualized machine. Each VM 1108, along with the hardware portion of hardware 1104 that executes that VM (whether it is dedicated hardware for that VM and / or hardware shared by that VM with other VMs), forms a separate virtual network element. Still within the context of NFV, the virtual network function is responsible for handling the specific network functions operating on one or more VMs 1108 above hardware 1104 and corresponding to application 1102.

[0375] Hardware 1104 can be implemented in a standalone network node with general or specific components. Hardware 1104 may implement some functions via virtualization. Alternatively, hardware 1104 may be part of a larger hardware cluster (e.g., in a data center or CPE) where many hardware nodes work together and are managed through management and orchestration 1110, which in particular oversees the lifecycle management of application 1102. In some embodiments, hardware 1104 is coupled to one or more radio units, each radio unit including one or more transmitters and one or more receivers that can be coupled to one or more antennas. The radio units may communicate directly with other hardware nodes via one or more suitable network interfaces and may be used in conjunction with virtual components to provide radio capabilities to virtual nodes (e.g., radio access nodes or base stations). In some embodiments, some signaling may be provided using a control system 1112, which may alternatively be used for communication between hardware nodes and radio units.

[0376] Figure 12 A communication diagram is shown illustrating how host 1202 communicates with UE 1206 via network node 1204 through a partial wireless connection, according to some embodiments. Reference will now be made to... Figure 12 Describe the UE discussed in the preceding paragraphs (e.g., Figure 7 UE712a and / or Figure 8 UE 800), network nodes (e.g., Figure 7 Network node 710a and / or Figure 9 Network node 900) and host (e.g., Figure 7 Host 716 and / or Figure 10 Example implementations of the host 1000 according to various embodiments.

[0377] Similar to host 1000, embodiments of host 1202 include hardware such as a communication interface, processing circuitry, and memory. Host 1202 also includes software stored in or accessible by host 1202 and executable by the processing circuitry. This software includes a host application operable to provide services to a remote user, such as UE 1206 connected via an over-the-top (OTT) connection 1250 extending between UE 1206 and host 1202. When providing services to a remote user, the host application can provide user data transmitted using OTT connection 1250.

[0378] Network node 1204 includes hardware that enables it to communicate with host 1202 and UE 1206. Connection 1260 can be a direct connection or via a core network (such as...). Figure 7The connection to the core network (706) and / or one or more other intermediate networks (e.g., one or more public, private, or hosted networks). For example, an intermediate network could be a backbone network or the Internet.

[0379] UE 1206 includes hardware and software, the software being stored in or accessible by UE 1206 and executable by the UE's processing circuitry. This software includes client applications (e.g., web browsers or carrier-specific "applications") operable to provide services to human or non-human users via UE 1206, supported by host 1202. In host 1202, the executing host application can communicate with the executing client application via OTT connection 1250, which terminates between UE 1206 and host 1202. When providing services to a user, the UE's client application can receive request data from the host application of the host and, in response to the request data, provide user data. OTT connection 1250 can send both request data and user data. The UE's client application can interact with the user to generate user data provided to the host application via OTT connection 1250.

[0380] OTT connection 1250 can be extended via connection 1260 between host 1202 and network node 1204 and via wireless connection 1270 between network node 1204 and UE 1206 to provide connectivity between host 1202 and UE 1206. Connection 1260 and wireless connection 1270, which provide OTT connection 1250, have been abstractly drawn to illustrate communication between host 1202 and UE 1206 via network node 1204, without explicitly involving any intermediate devices and the precise routing of messages via these devices.

[0381] As an example of sending data via OTT connection 1250, in step 1208, host 1202 provides user data, which can be performed by executing a host application. In some embodiments, the user data is associated with a specific human user interacting with UE 1206. In other embodiments, the user data is associated with UE 1206, which shares data with host 1202 without explicit human interaction. In step 1210, host 1202 initiates a transmission to UE 1206 carrying user data. Host 1202 may initiate the transmission in response to a request sent by UE 1206. This request may be caused by human interaction with UE 1206 or by the operation of a client application executed on UE 1206. According to the teachings of the embodiments described throughout this disclosure, this transmission may be carried out via network node 1204. Therefore, in step 1212, according to the teachings of the embodiments described throughout this disclosure, network node 1204 sends the user data carried in the transmission initiated by host 1202 to UE 1206. In step 1214, UE 1206 receives user data carried in the transmission, which can be performed by a client application running on UE 1206, which is associated with a host application running by host 1202.

[0382] In some examples, UE 1206 executes a client application that provides user data to host 1202. User data can be provided as a response to data received from host 1202. Therefore, in step 1216, UE 1206 can provide user data, which can be done by executing the client application. When providing user data, the client application may also consider user input received from a user via the input / output interface of UE 1206. Regardless of the specific manner in which user data is provided, in step 1218, UE 1206 initiates a transmission of user data to host 1202 via network node 1204. In step 1220, in accordance with the teachings of the embodiments described throughout this disclosure, network node 1204 receives user data from UE 1206 and initiates the transmission of the received user data to host 1202. In step 1222, host 1202 receives the user data carried in the transmission initiated by UE 1206.

[0383] One or more embodiments in various examples improve the performance of OTT services provided to UE 1206 using OTT connection 1250, in which wireless connection 1270 forms the final part. More specifically, the teachings of these embodiments can improve data rate, latency, and power consumption of communications by reducing the signaling used to perform UE recovery from radio-related failures, thereby providing benefits such as reduced user wait time, relaxed restrictions on file size used for communications, better responsiveness, and extended battery life.

[0384] In the example scenario, host 1202 can collect and analyze plant status information. As another example, host 1202 can process audio and video data that may have been retrieved from the UE for creating mappings. As another example, host 1202 can collect and analyze real-time data to help control vehicle congestion (e.g., control service lights). As another example, host 1202 can store surveillance video uploaded by the UE. As another example, host 1202 can store or control access to media content such as video, audio, VR, or AR, which can be broadcast, multicast, or unicast to the UE. As other examples, host 1202 can be used for energy pricing, remote control of non-time-critical power loads to balance generation demand, location services, presentation services (e.g., compiling charts based on data collected from remote devices), or any other function that collects, retrieves, stores, analyzes, and / or transmits data.

[0385] In some examples, a measurement process may be provided for the purpose of monitoring improved data rates, latency, and other factors in one or more embodiments. Optional network functions may also be present for reconfiguring the OTT connection 1250 between host 1202 and UE 1206 in response to changes in measurement results. The measurement process and / or the network functions for reconfiguring the OTT connection may be implemented in the software and hardware of host 1202 and / or UE 1206. In some embodiments, sensors (not shown) may be deployed in or associated with other devices traversed by the OTT connection 1250; the sensors may participate in the measurement process by providing values ​​of the monitored quantities exemplified above or by providing values ​​of other physical quantities from which software can calculate or estimate the monitored quantities. Reconfiguration of the OTT connection 1250 may include message formats, retransmission settings, preferred routing, etc.; reconfiguration does not require a direct change in the operation of network node 1204. Such processes and functions may be known and practiced in the art. In some embodiments, the measurement may involve proprietary UE signaling that facilitates host 1202's measurement of throughput, propagation time, latency, etc. Measurements can be achieved by having the software use an OTT connection 1250 to send messages (especially empty or “virtual” messages) while monitoring propagation time, errors, etc.

[0386] While the computing devices described herein (e.g., UE, network node, host) may include combinations of the hardware components shown, other embodiments may include computing devices with different combinations of components. It should be understood that these computing devices may include any suitable combination of hardware and / or software required to perform the tasks, features, functions, and methods disclosed herein. The determination, calculation, acquisition, or similar operations described herein may be performed by processing circuitry that processes information in ways such as: converting acquired information into other information, comparing the acquired or converted information with information stored in a network node, and / or performing one or more operations based on the acquired or converted information, and making a determination based on the result of said processing. Furthermore, although components are depicted as single boxes located within larger boxes or nested within multiple boxes, in practice, a computing device may include multiple different physical components constituting a single illustrated component, and functionality may be partitioned between individual components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of a component may be partitioned between processing circuitry and the communication interface. In another example, the non-computationally intensive functions of any such component may be implemented in software or firmware, and the computationally intensive functions may be implemented in hardware.

[0387] In some embodiments, some or all of the functions described herein may be provided by processing circuitry that executes instructions stored in memory, which in some embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functions may be provided by the processing circuitry, for example, in a hard-wired manner, without executing instructions stored on a separate or discrete device-readable storage medium. In any of these particular embodiments, the processing circuitry may be configured to perform the described functions regardless of whether instructions stored on a non-transitory computer-readable storage medium are executed. The benefits provided by such functions are not limited to the individual processing circuitry or other components of the computing device, but are enjoyed holistically by the computing device and / or generally by the end user and wireless network.

[0388] Example

[0389] Group A Examples

[0390] A1. A method for recovering from a radio-related failure, performed by a user equipment (UE), the method comprising:

[0391] Receive (500) at least one Level 1 "L1" or Level 2 "L2" trigger mobility LTM candidate cell configuration and store it in the UE;

[0392] The radio correlation test (502) failed.

[0393] In response to the detection of the radio correlation failure, perform (504) cell selection;

[0394] Determine (506) whether the selected cell corresponds to one of the stored at least one LTM candidate cell configurations; and

[0395] In response to the selected cell corresponding to one of the stored at least one LTM candidate cell configurations,

[0396] The application (508) stores the LTM candidate cell configuration corresponding to the selected cell as the target cell.

[0397] A1.1. The method according to any embodiment of the foregoing Group A embodiments, the method further comprising: in response to the selected cell corresponding to one of the stored at least one LTM candidate cell configuration,

[0398] Obtain information for accessing the target cell;

[0399] Using the obtained information, perform access in the target cell; and

[0400] Send notification messages to network nodes.

[0401] A1.2. The method described in any of the embodiments of Group A above, wherein the LTM candidate cell configuration includes parameters in the information element (IE) CellGroupConfig defined for the candidate cell and / or parameters in the embedded RRC reconfiguration defined for the candidate cell.

[0402] A2. The method according to any embodiment of the foregoing Group A embodiments further includes:

[0403] Perform an LTM cell handover to the target cell.

[0404] A3. The method according to any embodiment of the foregoing Group A embodiments further includes:

[0405] After cell selection has been performed, access is performed in the target cell without performing a random access procedure.

[0406] A3.1. The method according to the foregoing Group A embodiments further includes:

[0407] After cell selection has been performed, uplink UL data or signaling is sent in the target cell without performing the random access procedure.

[0408] A4. The method according to any embodiment of the foregoing Group A embodiments further includes:

[0409] After cell selection has been performed, access is performed in the target cell after the random access procedure has been executed.

[0410] A4.1. The method according to the foregoing Group A embodiments further includes:

[0411] After performing the random access procedure, uplink UL data or signaling is transmitted in the target cell.

[0412] A5. The method according to any embodiment of the foregoing Group A embodiments, the method further comprising: responding to the selected cell corresponding to one of the stored at least one LTM candidate cell configuration,

[0413] Obtain information for accessing the target cell;

[0414] Using the obtained information, access is performed in the target cell within the beam.

[0415] A5.1. The method according to the foregoing Group A embodiments further includes:

[0416] Use the obtained information to select the beam.

[0417] A5.2. The method according to the aforementioned Group A embodiments further includes:

[0418] Use the obtained information to determine the Transport Configuration Indicator (TCI) status.

[0419] The beam is selected based on the TCI state.

[0420] A6. The method according to any embodiment of the foregoing Group A embodiments further includes:

[0421] Provide user data; and

[0422] The user data is forwarded to the host via transmission to network nodes.

[0423] Group B Implementation Examples

[0424] B1. A method performed by a source network node for processing user equipment (UE) recovery from a radio-related failure, the method comprising:

[0425] Send (600) at least one Level 1 (L1) or Level 2 (L2) triggered Mobility TM (LTM) candidate cell configuration to the UE, the at least one LTM candidate cell configuration indicating how the UE should perform the LTM cell handover procedure after the radio-related failure is detected.

[0426] B1.1. The method according to the aforementioned Group B embodiments, wherein the candidate cell configuration includes information to be used by the UE to perform the LTM cell handover procedure to access the target cell after the radio-related failure is detected.

[0427] B2. The method according to any embodiment of the foregoing Group B embodiments, wherein:

[0428] The configuration includes at least one indication configured for the at least one LTM candidate cell, the at least one indication indicating whether the UE is allowed to trigger the execution of the LTM cell handover procedure based on the detection of a radio-related failure.

[0429] B3. The method according to the aforementioned embodiments of group B, wherein:

[0430] The indication of whether the UE is allowed to trigger the execution of the LTM cell handover procedure based on the detection of a radio-related failure applies to all of the at least one LTM candidate cell configuration.

[0431] B4. The method according to any embodiment of the foregoing Group B embodiments further includes:

[0432] Obtaining user data; and

[0433] The user data is forwarded to the host or the UE.

[0434] Group C Implementation Examples

[0435] C1. A method performed by a first target network node for processing recovery of a user equipment (UE) from a radio-related failure, the method comprising:

[0436] Receive notification messages from the UE.

[0437] C2. The method described in the aforementioned C group embodiments, wherein the first target node is a target gNB, a target distributed unit, or a target central unit.

[0438] C3. The method described in any of the embodiments of the preceding C group embodiments, wherein the notification message indicates that the UE has performed a Level 1 (L1) or Level 2 (L2) triggered mobility (LTM) cell handover to the first target cell.

[0439] Group D Implementation Examples

[0440] D1. A method for processing user equipment (UE) recovery from radio-related failures, executed by a second target network node, the method comprising:

[0441] Receive notification messages from the UE.

[0442] D1.1. The method described in any of the embodiments of Group D and / or Group C, wherein the second target node controls the second target cell and is a target gNB, a target distributed unit, or a target central unit.

[0443] D2. The method according to any of the embodiments in Group D and / or the embodiments in Group C, wherein the notification message indicates that the UE has performed a Level 1 (L1) or Level 2 (L2) triggered mobility (LTM) cell handover to the second target cell.

[0444] D3. The method according to any of the embodiments in Group D and / or Group C, wherein the notification message includes an indication that the UE has detected a radio-related failure.

[0445] D4. The method according to any embodiment of the preceding D group embodiments and / or any embodiment of the preceding C group embodiments further includes:

[0446] Based on the received notification message, an indication is sent to the third network node that the UE has performed a Level 1 (L1) or Level 2 (L2) triggered mobility (LTM) cell handover.

[0447] D5. The method described in any of the embodiments of the preceding D group embodiments, wherein the indication is a "successful access" message.

[0448] Group E Implementation Examples

[0449] E1. A method for processing user equipment (UE) recovery from radio-related failures, executed by a third target network node, the method comprising:

[0450] Receive an indication from the second target network node that the UE has performed a Level 1 (L1) or Level 2 (L2) triggered mobility (LTM) cell handover.

[0451] E2. The method described in any embodiment of the preceding E group embodiments and / or any embodiment of the preceding D group embodiments and / or any embodiment of the preceding C group embodiments, wherein the indication is an "access successful" message.

[0452] Group F Implementation Examples

[0453] F1. A user equipment (UE) for performing recovery from a radio-related failure, comprising:

[0454] The processing circuitry is configured to perform any of the steps described in any embodiment of Group A; and

[0455] The power supply circuit is configured to supply power to the processing circuit.

[0456] F2. A network node for processing user equipment (UE) recovery from radio-related failures, the network node comprising:

[0457] The processing circuitry is configured to perform any of the steps described in any of the embodiments of Group B, Group C, Group D, and / or Group E.

[0458] The power supply circuit is configured to supply power to the processing circuit.

[0459] F3. A user equipment (UE) for performing recovery from a radio-related failure, the UE comprising:

[0460] The antenna is configured to transmit and receive wireless signals;

[0461] A radio front-end circuit, connected to the antenna and processing circuitry, and configured to modulate the signal transmitted between the antenna and processing circuitry;

[0462] The processing circuitry is configured to perform any of the steps described in any embodiment of Group A embodiments;

[0463] An input interface is connected to the processing circuitry and is configured to allow information to be input into the UE for processing by the processing circuitry.

[0464] An output interface, connected to the processing circuitry, is configured to output information already processed by the processing circuitry from the UE; and

[0465] The battery is connected to the processing circuitry and is configured to supply power to the UE.

[0466] F4. A host configured to operate in a communication system to provide over-the-top (OTT) services, the host comprising:

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

[0468] A network interface is configured to initiate the transmission of user data to a network node in a cellular network for transmission to a user equipment (UE). The network node has a communication interface and processing circuitry, which is configured to perform any operation described in any of the embodiments of Group B, Group C, Group D, and / or Group E to transmit user data from a host to the UE.

[0469] F5. The host according to the foregoing embodiments, wherein:

[0470] The host's processing circuitry is configured to execute a host application that provides user data; and

[0471] The UE includes processing circuitry configured to execute a client application associated with a host application to receive user data from the host.

[0472] F6. A method implemented in a host configured to operate in a communication system, the communication system further comprising a network node and a user equipment (UE), the method comprising:

[0473] Provide user data to the UE; and

[0474] A transmission to the UE is initiated via a cellular network including network nodes, the transmission carrying user data, wherein the network nodes perform any operation described in any of the embodiments of Group B, Group C, Group D and / or Group E to send the user data from the host to the UE.

[0475] F7. The method according to the foregoing embodiments further includes: at a network node, transmitting user data provided by the host to the UE.

[0476] F8. The method according to any of the two embodiments above, wherein user data is provided at the host by executing a host application, the host application interacting with a client application executed on the UE, the client application being associated with the host application.

[0477] F9. A communication system configured to provide over-the-top (OTT) services, the communication system comprising:

[0478] The host includes:

[0479] Processing circuitry is configured to provide user data to a user equipment (UE) associated with an over-the-top service; and

[0480] A network interface is configured to initiate the transmission of user data to a cellular network node for transmission to a UE. The network node has a communication interface and processing circuitry, and the processing circuitry of the network node is configured to perform any operation described in any of the embodiments of Group B, Group C, Group D, and / or Group E to transmit user data from a host to a UE.

[0481] F10. The communication system according to the foregoing embodiments further includes:

[0482] The network node; and / or

[0483] The UE.

[0484] F11. A host configured to operate in a communication system to provide over-the-top (OTT) services, the host comprising:

[0485] The processing circuitry is configured to initiate the reception of user data; and

[0486] A network interface is configured to receive user data from a network node in a cellular network, the network node having a communication interface and processing circuitry, the processing circuitry of the network node being configured to perform any operation as described in any of the embodiments of Group B, Group C, Group D and / or Group E to receive user data from a user equipment (UE) for a host.

[0487] F12. The host according to the foregoing two embodiments, wherein:

[0488] The host's processing circuitry is configured to execute a host application that receives user data; and

[0489] The host application is configured to interact with a client application running on the UE, which is associated with the host application.

[0490] F13. The host according to any of the two embodiments described above, wherein initiating the reception of user data includes requesting user data.

[0491] F14. A method implemented by a host configured to operate in a communication system, the communication system further comprising a network node and a user equipment (UE), the method comprising:

[0492] At the host, the reception of user data from the UE is initiated. This user data originates from a transmission that the network node has already received from the UE. The network node performs any of the steps described in any of the embodiments of Group B, Group C, Group D, and / or Group E to receive user data from the UE for the host.

[0493] F15. The method according to the foregoing embodiments further includes: at the network node, sending the received user data to the host.

[0494] F16. A host configured to operate in a communication system to provide over-the-top (OTT) services, the host comprising:

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

[0496] A network interface is configured to initiate the transmission of user data to a cellular network for transmission to a user equipment (UE), wherein the UE includes a communication interface and processing circuitry, the communication interface and processing circuitry of the UE being configured to perform any operation described in any embodiment of the Group A embodiments to receive user data from a host.

[0497] F17. The host according to the foregoing embodiments, wherein the cellular network further includes a network node configured to communicate with the UE to send user data from the host to the UE.

[0498] F18. The host according to the foregoing two embodiments, wherein:

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

[0500] The host application is configured to interact with a client application running on the UE, which is associated with the host application.

[0501] F19. A method implemented by a host operating in a communication system, the communication system further comprising a network node and a user equipment (UE), the method comprising:

[0502] Provide user data to the UE; and

[0503] A transmission to the UE is initiated via a cellular network including network nodes, the transmission carrying user data, wherein the UE performs any operation as described in any embodiment of the Group A embodiments to receive user data from the host.

[0504] F20. The method according to the foregoing embodiments further includes:

[0505] At the host, a host application associated with the client application running on the UE is executed to receive user data from the host application.

[0506] F21. The method according to the foregoing embodiments further includes:

[0507] At the host, input data provided by executing the host application is sent to the client application running on the UE.

[0508] User data is provided by the client application in response to input data from the host application.

[0509] F22. A host configured to operate in a communication system to provide over-the-top (OTT) services, the host comprising:

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

[0511] A network interface is configured to initiate the transmission of user data to a cellular network for transmission to a user equipment (UE), wherein the UE includes a communication interface and processing circuitry, the communication interface and processing circuitry of the UE being configured to perform any of the steps described in any embodiment of the Group A embodiments to transmit user data to a host.

[0512] F23. The host according to any of the foregoing embodiments, wherein the cellular network further includes a network node configured to communicate with the UE to send user data from the UE to the host.

[0513] F24. The host according to the foregoing two embodiments, wherein:

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

[0515] The host application is configured to interact with a client application running on the UE, which is associated with the host application.

[0516] F25. A method implemented by a host configured to operate in a communication system, the communication system further comprising a network node and a user equipment (UE), the method comprising:

[0517] At the host, user data sent by the UE to the host via a network node is received, wherein the UE performs any of the steps described in any embodiment of Group A embodiments to send user data to the host.

[0518] F26. The method according to the foregoing embodiments further includes:

[0519] At the host, a host application associated with the client application running on the UE is executed to receive user data from the UE.

[0520] F27. The method according to the foregoing two embodiments further includes:

[0521] At the host, input data provided by executing the host application is sent to the client application running on the UE.

[0522] User data is provided by the client application in response to input data from the host application.

Claims

1. A method performed by a user equipment, UE, for performing recovery from a radio related failure, the method comprising: receiving (500) at least one level 1, “Ll”, or level 2, “L2”, triggered mobility, LTM, candidate cell configuration and storing it in the UE; detecting (502) the radio related failure; in response to detecting the radio related failure, performing (504) cell selection; determining (506) whether the selected cell corresponds to one of the stored at least one LTM candidate cell configuration; and in response to the selected cell corresponding to one of the stored at least one LTM candidate cell configuration, applying (508) the stored LTM candidate cell configuration corresponding to the selected cell as a target cell.

2. The method of claim 1, further comprising: in response to the selected cell corresponding to one of the stored at least one LTM candidate cell configuration, obtaining information for accessing the target cell; using the obtained information, performing access in the target cell; and sending a notification message to a network node.

3. The method of any one of claims 1 or 2, wherein, The LTM candidate cell configuration comprises parameters in an information element, IE, CellGroupConfig defined for a candidate cell and / or parameters in an embedded RRC reconfiguration defined for a candidate cell.

4. The method of any one of claims 1-3, further comprising: performing an LTM cell handover to the target cell.

5. The method of any one of claims 1-4, further comprising: after having performed cell selection, performing access in the target cell without performing a random access procedure.

6. The method of any one of claims 1-5, further comprising: after having performed cell selection, sending uplink, UL, data or signaling in the target cell without performing the random access procedure.

7. The method of any one of claims 1-6, further comprising: after having performed cell selection, performing access in the target cell after performing a random access procedure.

8. The method of claim 7, further comprising: after performing the random access procedure, sending uplink, UL, data or signaling in the target cell.

9. The method of any one of claims 1 to 8, further comprising: in response to the selected cell corresponding to one of the stored at least one LTM candidate cell configuration, obtaining information for accessing the target cell; and using the obtained information, performing access in the target cell in a beam.

10. The method of claim 9, further comprising: using the obtained information to select the beam.

11. The method of claim 10, further comprising: using the obtained information to determine a transmission configuration indication, TCI, state, wherein the beam is selected based on the TCI state.

12. The method of any one of claims 1-11, further comprising: providing user data; and forwarding the user data to a host via a transmission to a network node. If the LTM cell handover fails, the UE reinitiates a reestablishment procedure and continues the reestablishment procedure without again attempting an LTM cell handover to the target cell. ​ 13. The method of claim 4, wherein, ​ 14. The method of claim 4, wherein, The UE is allowed to attempt performing LTM on the target cell only once after the radio related failure.

15. The method of any one of claims 1 to 14, wherein, The LTM candidate cell configuration indicates how the UE is to perform an LTM cell change procedure after detecting the radio related failure.

16. The method of claim 15, wherein, The LTM candidate cell configuration comprises information to be used by the UE for performing the LTM cell change procedure to access the target cell after detecting the radio related failure.

17. The method of any one of claims 15 or 16, wherein: The LTM candidate cell configuration comprises at least one indication for the at least one LTM candidate cell configuration indicating whether the UE is allowed to trigger performing the LTM cell change procedure based on detecting a radio related failure.

18. The method of claim 17, wherein: The indication indicating whether the UE is allowed to trigger performing the LTM cell change procedure based on detecting a radio related failure applies to all of the at least one LTM candidate cell configuration.

19. A user equipment, UE, (800) for performing recovery from a radio related failure, comprising: a power supply circuit (808) configured to supply power to the processing circuitry; and a processing circuitry (802) configured to perform operations comprising: receiving (500) at least one level 1, “L1”, or level 2, “L2”, triggered mobility, LTM, candidate cell configuration and storing it in the UE; detecting (502) the radio related failure; in response to detecting the radio related failure, performing (504) cell selection; determining (506) whether the selected cell corresponds to one of the stored at least one LTM candidate cell configuration; and in response to the selected cell corresponding to one of the stored at least one LTM candidate cell configuration, applying (508) the stored LTM candidate cell configuration corresponding to the selected cell as a target cell.

20. The UE of claim 19, wherein, in response to the selected cell corresponding to one of the stored at least one LTM candidate cell configuration, the processing circuitry is further configured to perform further operations comprising: obtaining information for accessing the target cell; using the obtained information to perform access in the target cell; and sending a notification message to a network node.

21. The UE of any one of claims 19 or 20, wherein, The LTM candidate cell configuration comprises parameters in an information element, IE, CellGroupConfig defined for a candidate cell and / or parameters in an embedded RRC reconfiguration defined for a candidate cell.

22. The UE of any one of claims 19-21, wherein, The processing circuitry is configured to perform further operations comprising: performing an LTM cell change to the target cell.

23. The UE of any one of claims 19-22, wherein, The processing circuitry is configured to perform further operations comprising: after having performed cell selection, performing access in the target cell without performing a random access procedure.

24. The UE of any one of claims 19-23, wherein, The processing circuitry is configured to perform further operations comprising: after cell selection, transmitting uplink, UL, data or signaling in the target cell without performing the random access procedure.

25. The UE of any one of claims 19 to 24, wherein, The processing circuitry is configured to perform further operations, the further operations comprising: after cell selection, performing access in the target cell after performing a random access procedure.

26. The UE of claim 25, wherein, The processing circuitry is configured to perform further operations, the further operations comprising: transmitting uplink, UL, data or signaling in the target cell after performing the random access procedure.

27. The UE of any one of claims 19 to 26, wherein, In response to the selected cell corresponding to one of the stored at least one LTM candidate cell configuration, the processing circuitry is further configured to perform further operations, the further operations comprising: obtaining information for accessing the target cell; and performing access in a beam in the target cell using the obtained information.

28. The UE of claim 27, wherein, The processing circuitry is configured to perform further operations, the further operations comprising: selecting the beam using the obtained information.

29. The UE of claim 28, wherein, The processing circuitry is configured to perform further operations, the further operations comprising: determining a transmission configuration indication, TCI, state using the obtained information, wherein the beam is selected based on the TCI state.

30. The UE of any one of claims 19 to 29, wherein, The processing circuitry is configured to perform further operations, the further operations comprising: providing user data; and forwarding the user data to a host via a transmission to a network node.

31. The UE of claim 22, wherein, If the LTM cell switch fails, the UE reinitiates a reestablishment procedure and continues the reestablishment procedure without again attempting an LTM cell switch to the target cell.

32. The UE of claim 22, wherein, The UE is allowed to attempt performing LTM on the target cell only once after the radio related failure.

33. The UE of any one of claims 19 to 32, wherein, The LTM candidate cell configuration indicates how the UE is to perform an LTM cell switch procedure after detecting the radio related failure.

34. The UE of claim 33, wherein, The LTM candidate cell configuration comprises information to be used by the UE for performing the LTM cell switch procedure to access the target cell after detecting the radio related failure.

35. The UE of any one of claims 33 or 34, wherein: The LTM candidate cell configuration comprises at least one indication for the at least one LTM candidate cell configuration indicating whether the UE is allowed to trigger performing the LTM cell switch procedure based on detecting a radio related failure.

36. The UE of claim 35, wherein: The indication indicating whether the UE is allowed to trigger performing the LTM cell switch procedure based on detecting a radio related failure applies to all of the at least one LTM candidate cell configuration.

37. A non-transitory computer-readable medium comprising instructions that, when executed on at least one processor of a user equipment, UE, cause the at least one processor to perform operations comprising: receiving (500) at least one level 1, “L1”, or level 2, “L2”, triggered mobility, LTM, candidate cell configuration and storing it in the UE; detecting (502) the radio related failure; In response to detecting the radio-related failure, performing (504) cell selection; determining (506) whether the selected cell corresponds to one of the at least one stored LTM candidate cell configuration; and in response to the selected cell corresponding to one of the at least one stored LTM candidate cell configuration, applying (508) the stored LTM candidate cell configuration corresponding to the selected cell as a target cell.

Images