Method and apparatus for managing LTM-related configuration for resumed suspend connection

Abstract

The disclosed methods and apparatus provide mobility (LTM) configuration information for managing L1 / L2 triggers between a user equipment (UE) and a telecommunications network, particularly in the event of a suspension involving a connection between the UE and the telecommunications network. In accordance with the techniques disclosed herein, LTM configurations used by the network and the UE remain "consistent" with respect to suspension of the connected UE and subsequent recovery of the connection.

Description

TECHNICAL FIELD

[0001] The methods and apparatus disclosed herein relate to wireless communication networks and the recovery of suspended connections between such networks and user equipment (UEs), as well as the corresponding management of Layer 1 / Layer 2 triggered mobility (LTM) related configurations. BACKGROUND

[0002] Until Release 17 of the Third Generation Partnership Project (3GPP) Technical Specifications (TSs), serving cell changes for user equipment (UEs) were triggered based on Layer 3 (L3) measurements and performed through Radio Resource Control (RRC) signaling. L3-based mobility involves reconfiguration of upper layers of the radio protocol stack (e.g., the RRC and / or Packet Data Convergence Protocol (PDCP) layers) and / or resetting of lower layers (e.g., the Medium Access Control (MAC) and / or Physical (PHY) layers). See, e.g., Section 4.4 of 3GPP TS 38.300 v17.5.0, which illustrates the various layers of the radio protocol architecture used in New Radio (NR) Fifth Generation (5G) networks.

[0003] Release 17 introduced L1 / L2 triggered mobility, also referred to as “lower layer triggered mobility” or LTM. LTM provides a mechanism for preserving upper layer configurations and minimizing changes to lower layer configurations. An example control plane protocol stack includes an RRC layer, below which is a PDCP layer, below which is an RLC layer, below which is a MAC layer, and below which is a PHY layer. In this context, the PHY layer is Layer 1 (L1), while Layer 2 (L2) includes the MAC, RLC, and PDCP layers, and Layer 3 (L3) includes the RRC layer.

[0004] The basic principle of LTM is that the network configures the UE with RRC configurations for LTM candidate cells, sometimes also referred to as LTM candidate cell configurations. Such LTM candidate cell configurations can take the form of an RRCReconfiguration message, or the form of one or more information elements (IEs), or fields or parameters, e.g., CellGroupConfig.

[0005] The UE performs measurements on these LTM candidate cells and sends corresponding measurement reports to the network. The network then triggers the execution of an LTM cell change procedure in the UE by sending a lower layer signal (e.g., a MAC Control Element (CE) or Downlink Control Information (DCI)) to the UE. Such a lower layer signal can be referred to as an LTM cell change command, and the UE responds by connecting to the target cell and switching to the corresponding LTM candidate cell configuration.

[0006] There are one or more challenges with LTM. Consider, for example, the so-called “suspension” and “resumption” procedures, which involve releasing a UE from an active connection state to an inactive state, and then the UE later attempts to resume its connection. See Section 7.2 of 3GPP TS 38.300 v17.5.0 for a discussion of RRC states (including RRC_IDLE, RRC_INACTIVE, and RRC_CONNECTED).

[0007] A UE that receives an indication to suspend its connection with a network, e.g., based on receiving an RRC release message containing a suspendConfig element, cannot determine whether its LTM-related configuration should be released or saved for use when resuming the suspended connection. The phrase “LTM-related configuration” encompasses configuration information used for or used in LTM operations, and includes, for example, any one or more of the following: LTM candidate cell configuration, one or more uplink (UL) pre-synchronization configurations, one or more downlink (DL) pre-synchronization configurations, and L2 reset information for LTM.

[0008] Accordingly, there is a mismatch between the LTM-related configuration information saved in the network for the UE and the LTM-related configuration information saved in the UE for the UE, and this mismatch results in a reconfiguration failure when the UE attempts to resume its connection. Such failures trigger a re-establishment procedure or a transition to RRC_IDLE, which results in increased network signaling and increased UE power consumption. Moreover, if the UE decides to release its LTM-related configuration while the network retains the LTM-related configuration, saving this information in the network during the UE’s suspension operation will waste network resources. SUMMARY

[0009] The disclosed methods and apparatus provide for managing L1 / L2 triggered mobility (LTM) configuration information between a user equipment (UE) and a telecommunications network, particularly in situations involving suspension of a connection between the UE and the telecommunications network. According to the techniques disclosed herein, the LTM configuration used by the network and the UE remains “consistent” with respect to suspension and subsequent resumption of the connection of the UE.

[0010] One embodiment includes a method performed by a UE configured to operate with respect to a telecommunications network. The method includes, while the UE is connected to the telecommunications network, the UE receiving information from the telecommunications network, where the information indicates an LTM configuration for LTM-based mobility of the UE. The method further includes the UE receiving additional information from the telecommunications network, the additional information indicating that the UE is to suspend the connection with the telecommunications network. Moreover, the method further includes the UE releasing the LTM configuration.

[0011] Another embodiment includes a method performed by a network node in a telecommunications network. The method includes the network node sending an LTM configuration to a UE connected to the telecommunications network. Furthermore, the method includes the network node sending additional information to the UE instructing the UE to suspend its connection to the telecommunications network, thereby releasing the LTM configuration.

[0012] Another embodiment includes a UE. The UE includes a communication interface configured to communicate with network nodes of a telecommunications network, and also includes processing circuitry. The processing circuitry is configured to receive information from the telecommunications network via the communication interface when the UE is connected to the telecommunications network. This information indicates an LTM configuration for LTM-based mobility of the UE. Furthermore, the processing circuitry is configured to receive additional information via the communication interface indicating that the UE intends to suspend its connection to the telecommunications network, and the processing circuitry is configured to release the LTM configuration.

[0013] Another embodiment includes a network node configured to operate in a telecommunications network. The network node includes a communication interface configured to communicate directly or indirectly with a UE connected to the telecommunications network. Furthermore, the network node includes processing circuitry configured to send an LTM configuration to the UE via the communication interface, the LTM configuration being used for the UE's LTM-based mobility. Additionally, the processing circuitry is configured to send additional information to the UE via the communication interface, the additional information indicating that the UE intends to suspend its connection to the telecommunications network, thereby releasing the LTM configuration.

[0014] Of course, the present invention is not limited to the features and advantages described above. In fact, those skilled in the art will recognize other features and advantages after reading the following detailed description and reviewing the accompanying drawings. Attached Figure Description

[0015] Figure 1 This is a block diagram of a telecommunications network and associated user equipment (UE) according to an example embodiment.

[0016] Figure 2 This is a signaling flowchart illustrating, according to an example embodiment, the signaling and corresponding operations associated with the suspension of the UE for releasing a first set of mobility (LTM) related configurations triggered by one or more L1 / L2 for the UE.

[0017] Figure 3 This is a signaling flowchart illustrating, according to an example embodiment, the signaling and corresponding operations associated with the restoration of a suspended connection for releasing a first set of one or more LTM-related configurations for the UE.

[0018] Figure 4The following is a signaling flowchart illustrating, according to an example embodiment, the signaling and corresponding operations associated with the restoration of a suspended connection for providing one or more LTM-related configurations for the UE.

[0019] Figure 5 The following is a signaling flowchart illustrating, according to an example embodiment, the signaling and corresponding operations associated with the restoration of a suspended connection for releasing a first set of one or more LTM-related configurations for the UE at one or more candidate distributed units (DUs).

[0020] Figure 6 The following is a signaling flowchart illustrating, according to an example embodiment, the signaling and corresponding operations associated with the restoration of a suspended connection for restoring a first set of one set of LTM-related configurations for the UE at one or more candidate distributed units (DUs).

[0021] Figure 7 The following is a signaling flowchart illustrating, according to an example embodiment, the signaling and corresponding operations associated with the restoration of a suspended connection for releasing a first set of one or more LTM-related configurations for the UE at one or more candidate distributed units (DUs).

[0022] Figure 8 This is a logic flowchart of an example operation method at the UE according to an example embodiment.

[0023] Figure 9 This is a logical flowchart of an example operation method at a network node according to an example embodiment.

[0024] Figure 10 This is a block diagram of a telecommunications system according to an example embodiment.

[0025] Figure 11 This is a block diagram of a UE according to an example embodiment.

[0026] Figure 12 This is a block diagram of network nodes according to an example embodiment. Detailed Implementation

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

[0028] This document uses the term "LTM" to refer to L1 / L2 triggered mobility, and this term is interchangeable with "L1 / L2-based inter-cell mobility" as used in the work item descriptions in 3GPP, and is also interchangeable with L1 / L2 mobility, L1 mobility, L1-based mobility, L1 / L2-centric inter-cell mobility, and L1 / L2 inter-cell mobility.

[0029] The basic principle of LTM is that the User Equipment (UE) receives lower-layer signaling from the network, such as a MAC control element (MACCE), which instructs the UE to change (or handover or activation) its serving cell. This change may be from a source primary cell (PCell) to a target PCell. A PCell change may also result in changes in one or more secondary cells (SCells) within the same cell group. For example, an LTM handover command may trigger the UE to change to another cell group configuration of the same type, such as another primary cell group (MCG) configuration.

[0030] Before the UE receives an LTM cell handover command, the relevant wireless communication network configures one or more LTM candidate cell configurations for the UE. For example, a gNB or other network node sends a Radio Resource Configuration (RRC) reconfiguration message indicating at least one LTM candidate cell configuration. The LTM candidate cell configuration includes, for example, parameters in the candidate cell's Information Element (IE) CellGroupConfig and / or nested RRC reconfigurations of LTM candidate cells.

[0031] The term LTM cell handover process refers to the process by which a UE hands over or changes its cell from a source cell to a target cell. In the LTM context, the target cell may be referred to as an LTM candidate cell or a neighboring cell. In the context of this disclosure, a UE handover to an LTM candidate cell configuration includes: the UE considering the LTM candidate cell as its new special cell (SpCell), for example, a new PCell in the case of LTM configuration for an MCG, and / or a PSCell in the case of LTM configuration for a secondary cell group (SCG), or the UE changing its SpCell from its current PCell to an LTM candidate cell. Broadly speaking, when referring to cell changes, it should be understood that the change may involve cell group configuration, which may include changes in SpCells, such as changes in PCells or PSCells, and changes in SCells within the cell group. SCell changes include one or more of the following: the addition, modification, or release of one or more SCells.

[0032] The LTM cell handover process can be triggered in the UE by the UE receiving an LTM cell handover command, or alternatively by certain other events, such as the fulfillment of triggering conditions for conditional configuration, such as conditional handover being met due to recovery from radio link failure or handover failure.

[0033] In this disclosure, an "LTM candidate cell" refers to a cell that a UE can move to during an LTM cell handover process after receiving an LTM cell handover command. The UE is provided with corresponding LTE candidate cell configurations. LTE candidate cells can also be abbreviated as one or more candidate cells, candidate, mobility candidate, non-serving cell, supplementary cell, target candidate cell, target candidate, etc.

[0034] The UE performs measurements on LTM candidate cells, such as Channel State Information (CSI) measurements, and reports these measurements to the network. The network uses the reported measurements to make informed decisions about which beam (e.g., Transport Configuration Indicator (TCI)) and / or which cell the UE will be handed over to. An LTM candidate cell can be a target PCell or PSCell, or an SCell of a cell group (e.g., an MCG SCell). In the case of LTM fast recovery, when a failure is detected, the UE selects a cell, and if that cell is an LTM candidate cell, the UE does not need to perform a re-establishment; instead, it performs an LTM cell handover to the selected LTM candidate cell, for example, by applying the LTM candidate cell configuration associated with the selected LTM candidate cell.

[0035] This disclosure relates to a UE receiving at least one LTM candidate cell configuration, which may be an RRC configuration, for example, encapsulated in an RRC reconfiguration message received by the UE when LTM is configured. The LTM candidate cell configuration includes a configuration that the UE needs to begin operation when performing an LTM cell handover procedure to that LTM candidate cell.

[0036] LTM candidate cell configuration includes parameters for the serving cell or multiple serving cells (e.g., cell groups) and includes one or more parameter groups. Examples of LTM candidate cell configuration parameters include RRC reconfiguration messages (IEs), such as CellGroupConfig or SpCellConfig, or SCellConfig in the case of SCells. Specifically, in one example, LTM candidate cell configuration includes one or more of the following: i) the PCell configuration of the MCG and one or more SCell configurations; or ii) the PSCell configuration of the SCG and one or more SCell configurations. The terms LTM candidate configuration, LTM configuration, LTM target candidate cell configuration, and LTM target candidate cell configuration are used interchangeably with "LTM candidate cell configuration".

[0037] Each LTM candidate cell configuration is associated with an identifier, and signaling sent from the network to the UE uses these identifiers to reference a specific LTM candidate cell configuration. For example, the UE receives an LTM candidate cell configuration with a corresponding identifier, and subsequently, when the UE receives an LTM cell handover command, the network signals the identifier of that LTM candidate cell. This identifier is sometimes referred to as the LTM candidate cell configuration identifier or the LTM candidate configuration index.

[0038] The actual LTM candidate cell configuration, along with the specific content and / or structure of this IE and / or nested messages, can be referred to as the RRC model for the candidate configuration, or simply the RRC model. The LTM candidate cell configuration includes a configuration that the UE needs to operate accordingly when performing or operating L1 / L2 based inter-cell mobility in the corresponding LTM candidate cell.

[0039] A UE can be configured with multiple LTM candidate cell configurations. Furthermore, the LTM candidate cell configuration signaled to the UE can be indicated using differential signaling, which refers to the signaling changes to be applied to a reference configuration. When using differential signaling, the actual LTM candidate cell configuration includes the default configuration modified according to the differential signaling. The reference configuration can be signaled to the UE separately by the network.

[0040] The term "beam" can correspond to the spatial direction in which a signal is transmitted (e.g., by a network node) or received (e.g., by a UE), or to a spatial filter applied to the transmitted or received signal. Therefore, transmitting a signal via different beams can correspond to transmitting the signal in different spatial directions. When referred to herein as "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.

[0041] Example UE-related embodiments for suspending operations include a first method at the UE for deleting LTM-related configurations. This example method includes the UE: for example, while connected to the network in an active state, receiving a first set of one or more LTM-related configurations; receiving a message from the network for suspending the connection and transitioning to an inactive state; and deleting the first set of one or more LTM-related configurations in response to one or more of the following events: (i) receiving a message from the network for suspending the connection, or (ii) during the initiation of a recovery process.

[0042] In a specific example, a UE connected to the network receives information indicating an LTM configuration for the UE's LTM-related mobility. The UE then receives additional information indicating that it intends to suspend its connection to the network, and the UE releases the LTM configuration. In at least one such embodiment, this additional information (which may be a release message, or may be sent in association with a release message) includes an implicit or explicit indication for the UE to release the LTM configuration.

[0043] Here, “release” means to delete, discard, or otherwise remove the LTM configuration. Accordingly, the LTM configuration received by the UE and then subsequently released may include a first set of one or more LTM-related configurations, the first set of one or more LTM-related configurations including, for example, any one or more of the following: (a) one or more lower-layer (CSI) measurement configurations for LTM; (b) time alignment (TA) acquisition (also known as UL pre-synchronization configuration); (c) one or more TCI state configurations for pre-synchronization (also known as DL pre-synchronization configuration); (d) one or more LTM reference configurations; (e) one or more LTM candidate cell configurations; or (f) one or more complete LTM candidate configurations generated when the UE is configured with LTM.

[0044] In at least one embodiment, the example method of the UE operation described above further includes the UE initiating a recovery procedure, sending an RRC recovery request message, and receiving an RRC recovery message containing a new LTM configuration, such as a second set of one or more LTM-related configurations. Therefore, in one or more embodiments, the method includes the UE using new or updated LTM-related configuration information when restoring its connection to the network, instead of using earlier LTM configuration information released by the UE that was associated with the suspension of the connection.

[0045] A second set of one or more LTM-related configurations may be the same as or different from a first set of one or more LTM-related parameters. Accordingly, the UE discards the first set of one or more LTM-related configurations and then applies the second set of one or more LTM-related configurations. In at least one embodiment or at least one operating scenario, the UE is in multi-radio dual connectivity (MR-DC or NR-DC), and the first set of one or more LTM-related configurations is used for the primary cell group (MCG) or secondary cell group (SCG).

[0046] A further example operation performed by the UE is based on storing or restoring LTM-related configurations. This method includes the UE receiving a first set of one or more LTM-related configurations; receiving a message from the network to suspend its connection with the network and correspondingly transitioning to an inactive state; and in response to receiving the message from the network to suspend the connection, storing the first set of one or more LTM-related configurations.

[0047] In at least one embodiment, the method further includes initiating a recovery process, sending an RRC recovery request message, receiving an RRC recovery message containing a first indication (e.g., a restoreLTM field), and, in response to the first indication, restoring a first set of stored one or more LTM-related configurations. In at least one embodiment, the method includes initiating a recovery process, sending an RRC recovery request message, receiving an RRC recovery message, and, upon determining that the first indication does not exist, deleting a first set of one or more LTM-related configurations.

[0048] In at least one embodiment, the RRC recovery message further includes: a second set of one or more LTM-related configurations, which is applied by the UE as part of the RRC recovery process. The second set of one or more LTM-related configurations may be the same as or different from a first set of one or more LTM-related parameters. In one or more embodiments, the second set of one or more LTM-related configurations is added to, modified, or released from the first set of one or more LTM-related configurations.

[0049] In at least one embodiment or at least one operating scenario, the UE is in MR-DC or NR-DC, and a first set of one or more LTM-related configurations is used for MCG or SCG. The RRC recovery message may include a restoreSCG indication as an example, such as the first indication described above.

[0050] On the network side, one embodiment disclosed herein includes a first operational method performed by a network node of a wireless communication network. In at least one specific example, the network node is a Service Center Unit (CU) for a UE. For example, for details on the CU, see 3GPP TS 38.470 v17.5.0, which describes an “F1” interface for connecting a gNB-CU to a gNB-DU, where “DU” stands for “Distributed Unit”. Furthermore, for details on the gNB, see 3GPP TS 38.300 v17.5.0, and for details on additional CUs and DUs, see 3GPP TS 38.401 v17.5.0.

[0051] Using a CU / DU layout, the radio protocol stack is split, with the CU handling higher layers and the DU handling lower layers, including the physical (PHY) layer for radio transmission and reception over the air interface. In one or more embodiments, the serving CU performs a method comprising: sending a first set of one or more LTM-related configurations to the UE; sending messages from the network to the UE for suspending a connection and for transitioning the UE to an inactive state (e.g., moving the UE from an RRC connected state to an RRC inactive state); and deleting (releasing / discarding / removing) the first set of one or more LTM-related configurations in response to one or more defined events. For example, example defined events that trigger the deletion of the first set of one or more LTM-related configurations at the CU include: sending a message to the UE for transitioning the UE to an inactive state, or during the initiation of a recovery procedure.

[0052] In one or more example embodiments, the network sends an LTM configuration to a UE connected to the network, the LTM configuration being used for LTM-related mobility performed by the UE. Subsequently, the network sends additional information indicating that the connection is to be suspended, thereby causing the UE to release the LTM configuration. In at least one such embodiment, the additional information includes or is sent in association with a release message. Furthermore, in at least one such embodiment, the additional information includes an implicit or explicit indication to prompt the UE to release the LTM configuration.

[0053] Such operations are performed by service nodes in the network, such as service CUs. In at least one such embodiment, the service node further performs or initiates the release of LTM configuration in the network, for example, removing LTM information from the UE context information stored for the UE in the network.

[0054] As described, an LTM configuration may include a first set of one or more LTM-related configurations, and "releasing" an LTM configuration means deleting or otherwise removing the LTM configuration. Releasing the first set of one or more LTM-related configurations includes, for example, the serving CU sending a release message to at least one candidate DU to release the first set of one or more LTM-related configurations at the at least one candidate DU. Here, the first set of one or more LTM-related configurations is associated with an LTM candidate cell of the at least one candidate DU.

[0055] Regarding the restoration of connection between the UE and the same serving CU, in one or more embodiments, the operation method performed by the serving CU includes: the serving CU receiving an RRC restoration request message from the UE, and the serving CU sending an RRC restoration message in response. Here, the RRC restoration message contains a second set of one or more LTM-related configurations, wherein the second set of one or more LTM-related configurations may be the same as or different from a first set of one or more deleted LTM-related parameters.

[0056] Another embodiment includes another or second operational method by a network node (in a particular example, which is a serving CU). This method includes the serving CU sending a first set of one or more LTM-related configurations to the UE, and sending a message to the UE for suspending the connection with the UE and transitioning the UE to an inactive state. The method also includes the serving CU storing the first set of one or more LTM-related configurations in response to sending the message to the UE transitioning the UE to an inactive state. Furthermore, the method includes the serving CU receiving an RRC recovery request message from the UE, and accordingly sending an RRC recovery message for that UE.

[0057] If the UE is to resume connection using a first set of one or more LTM-related configurations sent to it before the connection was suspended, the serving CU may include a first indication in the RRC recovery message, for example, instructing the UE to restore to use the first set of one or more LTE-related configurations. An example indication is the inclusion of a `restoreLTM` field in the RRC recovery message, which instructs the UE to restore the first set of one or more stored LTM-related configurations. Alternatively, omitting this indication from the RRC recovery message instructs the UE to delete the first set of one or more previously stored LTM-related configurations—that is, the absence of this indication in the RRC recovery message serves as an instruction to the UE not to use (and should delete) the first set of one or more LTM-related configurations stored before or in conjunction with a previously suspended connection to the network.

[0058] In one or more embodiments, the serving CU prompts the UE to delete the first set of one or more stored LTM-related parameters by omitting an indication from the recovery message that these parameters should be used in restoring the UE's connection, and / or by including a second set of one or more LTM-related configurations in the UE. As a specific example, omitting this indication tells the UE that it should not restore the first set of one or more stored LTM-related parameters, but rather should use the second set of one or more LTM-related parameters to restore the connection, wherein the second set of one or more LTM-related parameters is included in the RRC recovery message sent from the serving CU to the UE.

[0059] The second set can be the same as or different from the first set. As a specific example, the second set can replace the first set. As yet another example, the second set can modify the first set; for example, the second set contains one or more values ​​that replace or adjust one or more values ​​in the first set. As yet another example, the second set supplements the first set.

[0060] In one or more embodiments, associated with the Serving CU releasing the UE to an inactive state (i.e. suspending the UE's connection), the Serving CU stores a first set of one or more LTM-related configurations and sends a message to the Candidate DU associated with the first set of one or more LTM-related configurations to indicate that the first set of one or more LTM-related configurations is suspended.

[0061] Consider another aspect of the example operation at the CU. Suppose that the CU provides a first set of one or more LTM-related configurations to a UE served by that CU. For example, when the UE is active and has a connection to the network via the serving CU, the CU provides the UE with a first set of one or more LTM-related configurations. As a specific example, the CU provides the UE with a first set of one or more LTM-related configurations in an RRC connection release message, and it stores the first set of one or more LTM-related configurations as a "pending" configuration for the currently pending UE.

[0062] Subsequently, the CU receives a message from another node in the network requesting the UE context for the suspended UE. The CU responds to the request message by sending the UE Inactive AS context for the suspended UE, but omits a first set of one or more LTM-related configurations from the sent context.

[0063] As an example of the advantages of the disclosed technology, when a UE is configured with one or more LTM-related configurations before being transitioned to RRC_INACTIVE, no mismatch occurs between the UE and the network when the UE transitions from RRC_INACTIVE to RRC_CONNECTED. Preventing such mismatches prevents reconfiguration failures on every attempt to restore the connection. This prevention avoids the need to trigger a re-establishment process or transition to RRC_IDLE, and allows for successful connection restoration, thereby reducing network signaling and UE power consumption. As another advantage, the disclosed technology eliminates, for example, LTM configuration mismatches between the serving CU and one or more candidate DUs.

[0064] Figure 1A wireless communication network 10 according to an example embodiment is illustrated, wherein one or more nodes of network 10 and an example user equipment (UE) 12 are configured to manage LTM configurations regarding connection suspension and resumption. Here, "connection" refers to a communication link between UE 12 and network 10, wherein network 10 and UE 12 operate to suspend and resume the connection. For example, UE 12 operates in an RRC_ACTIVE state, which includes having an active connection with network 10, and is then released to an RRC_INACTIVE state, in which the connection is suspended. During suspension, UE 12 has one or more LTM-related configurations stored therein, as well as those stored by its serving network nodes in network 10.

[0065] In at least one embodiment, UE 12 releases one or more LTM-related configurations associated with a connection suspension so that the UE does not attempt to reuse one or more LTM-related configurations when the connection is later restored. In one or more other embodiments, the UE retains the one or more LTM-related configurations, and one or more techniques disclosed herein provide mechanisms for controlling whether the retained one or more LTM configurations are reused or released in association with connection restoration to prevent mismatches between network 10 and UE 12.

[0066] UE 12 is a wireless terminal, such as a cellular smartphone, and can sometimes be connected to the first network node 14 via wireless interface 16, and can (e.g., as a result of a mobility process) subsequently be connected to the second network node 18 via wireless interface 20.

[0067] The first network node 14 controls the first cell 22 (sometimes referred to as the serving cell, special cell (SpCell), or primary cell (PCell)). The second network node 18 controls the second cell 24, which, for the purposes of this example, is configured as an LTM candidate cell or target cell for UE 12.

[0068] Each of the first network node 14 and the second network node 18 can be a base station, such as a gNB, or, for example, a distributed unit, sometimes referred to as a gNB-DU or DU, in the case of a distributed CU / DU RAN architecture. The first network node 14 is sometimes referred to as the serving DU, and the second network node 18 is sometimes referred to as the candidate DU or the target DU. The first network node and the second network node can be the same network node.

[0069] First network node 14 and second network node 18 are connected to third network node 26, sometimes referred to as serving network node. Third network node 26 can be (e.g., in the case of a distributed CU / DU RAN architecture) a central unit (CU), sometimes referred to as a serving CU, known as gNB-CU, CU, gNB-CU-CP, or gNB-CU-UP, or a core network node, such as a user plane function (UPF) or access and mobility management function (AMF). Therefore, in the example scenario, first network node 14 is the first DU, second network node 18 is the second DU, and third network node 26 is the CU typically associated with first DU 14 and second DU 18.

[0070] In some cases, UE 12 is configured with Multiple Radio Dual Connectivity (MR-DC), sometimes also referred to as NR Dual Connectivity (NR-DC). In these cases, UE 12 is configured with a Primary Cell Group (MCG) controlled by a Primary Node (MN) (sometimes known as the Primary gNB (MgNB)) and a Secondary Cell Group (SCG) controlled by a Secondary Node (SN) (sometimes known as the Secondary gNB (SgNB)). In these cases, the first network node 14, the second network node 18, and the third network node 26 can belong to the Primary Node (MN), and UE 12 is also connected to a fourth network node 30 via radio interface 28, which can belong to the Secondary Node (SN).

[0071] Furthermore, in these cases, the first cell 22 may belong to the primary cell group (MCG), while the third cell 32, controlled by the fourth network node 30, may belong to the secondary cell group (SCG). The third cell 32 may be referred to as the serving cell, special cell (SpCell), or primary SCG cell (PSCell). In the context of this example, the third cell 32 is an LTM candidate cell or target cell for UE 12. To support this connection arrangement, the fourth network node 30 is connected to the third network node 26 via interface 34, which may be an Xn-type interface. The first network node 14 and the second network node 18 have similar interfaces 36 and 38, communicatively coupling them to the third network node 26.

[0072] Regarding one or more LTM-related configurations, the techniques disclosed herein relate to respective or complementary operational methods for the UE and network nodes for so-called one or more LTM-related configurations. Such methods include various operations or steps, including storing, removing, or deleting a set of one or more LTM-related configurations.

[0073] As an example of LTM-related configuration (or more simply, LTM configuration), Network 10 provides UE 12 with one or more lower-layer measurement configurations for UE 12 to use or adopt for performing measurements on the corresponding cells identified as LTM candidate cells for UE 12. Example measurements include measurements performed by UE 12 on synchronization signal bursts (SSBs) transmitted in LTM candidate cells and / or measurements on channel state information reference signals (CSI-RS) transmissions in LTM candidate cells. UE 12 reports these measurements to Network 10 to assist Network 10 in making LTM handover decisions. Examples of reported measurements include SS-RSRP, L1-RSRP, SS reference signal reception quality (RSRQ) or L1-RSRQ, and SS signal-to-noise ratio (SINR) or L1-SINR.

[0074] In one option, the lower-layer measurement configuration includes one or more reporting configurations that are contained within the serving cell configuration (e.g., ServingCellConfig, as part of the CSI measurement configuration or LTM measurement configuration) of the serving cell (e.g., PCell or MCG SCell) that will report lower-layer measurement reports for LTM. One or more reporting configurations may include one or more parameters that instruct the UE 12 how to perform reporting, such as periodic, non-periodic, semi-persistent, etc. Instances of reporting configurations may be defined in the IE CSI-ReportConfig, or in a new IE referred to herein as LTM-CSI-ReportConfig.

[0075] When UE 12 removes one or more lower-layer measurement configurations, UE 12 will also remove one or more LTM-related reporting configurations from each serving cell configuration (e.g., CSI measurement configurations on each SCell configuration and CSI measurement configurations on each SpCell configuration).

[0076] In one option, the report configuration indicates which / which LTM candidate cells will be reported based on the report configuration.

[0077] In one option, the lower-layer measurement configuration includes one or more resource configurations, such as indicating what will be measured by UE 12, such as one or more LTM candidate cells and / or one or more RSs of LTM candidate cells (e.g., one or more SSBs and / or one or more CSI-RS resources).

[0078] In one sub-option, resource configuration is included in each LTM candidate cell configuration, for example, in the lower-layer measurement configuration.

[0079] In another sub-option, the resource configuration (e.g., an instance of IE LTM-CSI-ResourceConfig) is included within the overall LTM candidate cell configuration received by the UE when LTM is configured, which is contained within IELTM-Config. In this case, the resource configuration can reference one or more LTM candidate cells, for example, by referencing one or more LTM candidate identifiers.

[0080] In one option, the lower-layer measurement configuration further includes one or more of the following: frequency indication of SS / PBCH blocks associated with LTM candidates; subcarrier spacing of SSBs; periodicity of SS / PBCH blocks in subframe number; temporal location indication of SS blocks transmitted in half-frames containing SS / PBCH blocks; average EPRE (in dBm) of resource elements carrying secondary synchronization signals for SSB transmission of LTM candidates; physical cell identifier (PCI) of LTM candidates; a list of one or more LTM-CSI-ResourceConfigs; a list of LTM-CSI-ResourceConfigs to be released; a group of one or more LTM-CSI-SSB-ResourceSets; SS / PBCH block resource sets from one or more candidate cells; identifier of SS / PBCH block resource sets; indication of SS / PBCH block resources from one or more candidate cells; or indication of the PCI of SSBs in the LTM-CSI-SSB-Resourcelist.

[0081] As described herein, one advantage of the technology disclosed herein is that it prevents mismatches between UE 12 and Network 10 regarding LTM-related configurations, especially in the context of resuming a suspended connection. That is, UE 12 and Network 10 are aligned on whether UE 12 needs to perform lower-layer measurements, and further aligned on the LTM configuration that will be used for these measurements. Mismatches prevent UE power saving and prevent UL interference on the network side, which could degrade the performance of UE 12 and other UEs operating in Network 10. For example, a mismatch in LTM-related configurations could cause UE 12 to unnecessarily perform lower-layer measurements after resuming a connection that was suspended before it, thus wasting UE power.

[0082] Besides power wastage, UE 12, after restoring its connection, may attempt to report lower-layer measurements via the serving cell's UL channel when network 10 is not yet ready to receive them. This situation can lead to the aforementioned UL interference and corresponding performance degradation. Conversely, a mismatch between one or more LTM-related configurations stored at UE 12 and one or more LTM-related configurations expected by network 10 may prevent UE 12 from performing lower-layer measurements expected by network 10. This situation results in wasted UL resources allocated by network 10 for UE 12 reporting.

[0083] Here are a few example options for Time Alignment (TA) acquisition configuration (also known as UL pre-synchronization configuration). The TA acquisition configuration provides UE 12 with the necessary information to send UL messages to LTM candidate cells. A random access preamble on the Physical Random Access Channel (PRACH) time / frequency resources is one example of such a UL message. In other words, network 10 calculates a TA value for UE 12 with respect to LTM candidate cells, ensuring UE 12's UL synchronization with the candidate LTM candidate cells, and provides this TA value to UE 12 in the corresponding TA acquisition configuration.

[0084] In one option, the TA acquisition configuration is received by the UE 12 per LTM candidate cell. In one option, the TA acquisition configuration (or UL pre-synchronization configuration) provided to the UE 12 includes one or more random access related parameters, such as: one or more indications of one or more preambles (e.g., per one or more beams and / or one or more SSBs), such as random access preamble indexes; one or more indications of random access timing with associated SSB indices configured for each candidate cell; or one or more parameters associated with power boost for preamble transmission / retransmission.

[0085] In one option, the TA acquisition configuration (which may be passed as IE EarlyUL-SyncConfig) is included within the configuration for LTM candidate cells. For example, each LTM candidate cell is represented by an IE LTM-Candidate provided to UE 12, where the IE LTM-Candidate passes the IE EarlyUL-SyncConfig, which indicates the TA value that UE 12 will use for UL synchronization with the LTM candidate cell.

[0086] These aspects of the broad technologies described herein have the advantage of ensuring consistency between UE 12 and Network 10 regarding whether the UE is configured for TA acquisition. A mismatch in this situation could occur where the UE has a random access-related configuration for TA acquisition and is potentially ready for Network 10 to send a Physical Downlink Dedicated Channel (PDDCH) command that triggers preamble transmission, but due to the mismatch, based on Network 10's erroneous understanding that UE 12 does not have the corresponding stored TA acquisition configuration, Network 10 does not send the PDDCH command.

[0087] Therefore, a consistent state or understanding of the TA acquisition configuration between Network 10 and UE 12 prevents wasted UE actions. Further preventing such actions is the following: Network 10 sends a PDDCH command to trigger UE 12 to transmit a preamble for an LTM candidate cell, but the UE lacks the corresponding TA acquisition configuration for that LTM candidate cell. Receiving a PDDCH command intended for a given RRC configuration, which UE 12 does not possess, can lead to, for example, RRC reconfiguration failure or other errors.

[0088] Regarding downlink (DL) synchronization, LTM relies on the use of one or more TCI state configurations for DL ​​pre-synchronization, and such configurations are also referred to as DL pre-synchronization configurations. The TCI configurations for DL ​​pre-synchronization include one or more necessary configurations for UE 12 to obtain DL pre-synchronization with LTM candidate cells. Example configuration information includes one or more indications of reference signals, such as SSB indexes or CSI-RS resource identifiers, and one or more associated configurations.

[0089] In one option, UE 12 receives TCI configuration for DL ​​pre-synchronization per LTM candidate cell. For example, the IE LTM-Candidate sent to UE 12 for an LTM candidate cell contains the corresponding TCI configuration for that LTM candidate cell. In an example embodiment, the TCI configuration for the LTM candidate cell includes one or more TCI state configurations, such as one or more IECandidateTCI-StatesToAddModList-r18 LTM-CandidateTCI-States-ToAddModList-r18.

[0090] In one option, the TCI configuration for DL ​​pre-synchronization includes one or more of the following: a list of TCI states indicating a transport configuration that includes quasi-co-address (QCL) relationships between DL RSs (e.g., SSB indexes and / or CSI-RS resource identifiers and / or TRS identifiers) in a set of RSs and Physical Downlink Shared Channel (PDSCH) demodulation reference signal (DMRS) ports; a list of UL TCI states for LTM candidate cells; a uniform TCI state type configured for the UE for LTM candidate cells; or an association between one or two DL reference signals and their corresponding quasi-co-address (QCL) types.

[0091] Preventing LTM-related configuration mismatches between UE 12 and Network 10 (e.g., suspension and resumption of the connection between UE 12 and Network 10) offers many advantages as described herein. In the context of TCI configuration for pre-synchronization, one advantage is preventing UE 12 from performing one or more DL pre-synchronization operations, such as measurements of SSB and / or CSI-RS resources of the LTM candidate cell, which Network 10 never sends LTM cell handover commands that would benefit from such measurements. Eliminating such measurements saves UE power, and another problem prevented is that UE 12 does not receive DL pre-synchronization commands from Network 10 if it does not have the corresponding DL pre-synchronization acquisition configuration. DL pre-synchronization commands can be sent as MAC CE before the UE receives the LTM cell handover command, and if UE 12 does not have the corresponding TCI configuration for pre-synchronization of the LTM candidate cell it is handing to, it may lead to RRC reconfiguration failure or other errors.

[0092] In the context of this disclosure, the reference configuration or LTM reference configuration includes the configuration provided to UE 12 by network 10. This configuration is common to multiple configured LTM candidate cells, and UE 12 uses this configuration to generate a complete LTM candidate cell configuration, that is, based on UE 12 applying the LTM candidate cell configuration to the LTM reference configuration.

[0093] In one option, the LTM reference configuration is configured as an RRC reconfiguration message, for example, as shown in the IE LTM-Config code in the following Abstract Syntax Notation 1 (ASN.1):

[0094] LTM-Config-r18 ::= SEQUENCE {

[0095] [...]

[0096] ltm-ReferenceConfiguration-r18 OCTET STRING (includes RRCReconfiguration), optional, -- Cond FirstLTM-Candidate

[0097] [...]

[0098] }

[0099] In one or more embodiments herein, the LTM candidate cell configuration is a configuration associated with an LTM candidate cell. The LTM candidate cell configuration can be a complete LTM candidate cell configuration or a differential configuration relative to an LTM reference configuration. In one option, the LTM candidate configuration is configured as a list of RRC reconfiguration messages, for example, as shown in the ASN.1 example below:

[0100] LTM-CandidateToAddModList-r18 ::= SEQUENCE (SIZE (1..maxNrofCellsLTM-r18)) OF LTM-Candidate-r18

[0101] LTM-Candidate-r18 ::= SEQUENCE {

[0102] ltm-CandidateId-r18 LTM-CandidateId-r18,

[0103] ltm-CandidateConfig-r18 OCTET STRING (includes RRCReconfiguration), optional, -- requires M

[0104] [...]

[0105] }

[0106] Considering the foregoing, one or more LTM candidate configurations include a complete LTM candidate configuration for each LTM candidate cell, and therefore can also be referred to as a complete LTM candidate cell configuration. This configuration is defined as containing all the necessary fields required for UE 12 to perform the LTM cell handover procedure. The complete configuration can be the LTM candidate cell configuration itself, or it can be generated by applying the LTM candidate cell configuration to an LTM reference configuration. That is, in one or more embodiments or in one or more operating scenarios, a complete LTM candidate cell configuration is generated by UE 12 applying the LTM candidate cell configuration to an LTM reference configuration, wherein this application includes UE 12 performing one or more of the following steps:

[0107] 1> If there is no entry in VarLTM-UE-Config's ue-ltm-ConfigCandidateList whose ltm-CandidateId value is set to the ltm-CandidateId value contained in LTM-Candidate:

[0108] 2> Create an entry with an ltm-CandidateId value in ue-ltm-ConfigCandidateList within VarLTM-UE-Config;

[0109] 2> Set the value of ltm-CandidateId in this entry to the value contained in LTM-Candidate; 1> In the ue-ltm-ConfigCandidateList within VarLTM-UE-Config, for entries with ltm-CandidateId whose values ​​are set to the ltm-CandidateId contained in LTM-Candidate:

[0110] 2> If LTM-Candidate contains ltm-ConfigComplete;

[0111] 3> The ltm-CandidateConfig received within ltm-Candidate will be considered a complete LTM candidate cell configuration;

[0112] 3> If VarLTM-UE-Config is stored in ue-LTM-config:

[0113] 4> Replace ue-LTM-Config with ltm-CandidateConfig contained within LTM-Config;

[0114] 3> Otherwise:

[0115] 4> Store the ltm-CandidateConfig contained in LTM-Config into ue-LTM-Config;

[0116] 2> Otherwise:

[0117] 3> According to Clause 5.3.5.x.5, a complete LTM candidate cell configuration is generated by applying ltm-CandidateConfig to ltm-referenceConfiguration. 3> VarLTM-UE-Config contains ue-LTM-config:

[0118] 4> Replace ue-LTM-config with the generated complete LTM candidate cell configuration;

[0119] 3> Otherwise:

[0120] 4> Store the generated complete LTM candidate cell configuration in ue-LTM-config.

[0121] This may involve other LTM-related configurations. For example, when an LTM cell handover from cell A to cell B is about to be performed, one or more configurations indicate whether the UE should perform a Layer 2 reset. This configuration can be specified using the field ltm-ServingCellNoResetID-r18 of IE INTEGER (1..maxNrofCellsLTM-r18-plus-1).

[0122] Another example of LTM-related configuration is an indication of whether LTM fast recovery will be performed, such as attempt-LTM which can be set to 'TRUE'. If this indication is included, it tells UE 12 that when a failure is triggered, UE 12 will perform LTM fast recovery, for example, when timer T311 is running and the selected cell is an LTM candidate cell, UE 12 performs an LTM cell handover.

[0123] As mentioned earlier, the actual or complete LTM candidate cell configuration can be indicated using differential signaling based on the reference configuration, for example, by using the ltm-CandidateConfig-r18 OCTET STRING (which contains the RRCReconfiguration within the IE LTM-Candidate) signal.

[0124] The UE 12 and network 10 perform multiple steps according to a first method for releasing LTM-related configurations to maintain consistency between network 10 and UE 12, for example, regarding the suspension and resumption of the connection between UE 12 and network 10. In at least one embodiment, UE 12 receives the LTM configuration, for example, in an RRC reconfiguration message. For example, UE 12 receives this message when transitioning from RRC_IDLE to RRC_CONNECTED, or during handover, or during reconfiguration with synchronization, or for intra-cell reconfiguration from its serving cell.

[0125] In one option, UE 12 receives the LTM configuration when it is able to process one or more LTM-related configurations. For example, based on UE 12's ability to perform UL pre-synchronization for LTM, UE 12 receives one or more UL pre-synchronization configurations as the LTM configuration.

[0126] The UE operation in the context of the first method also includes UE 12 receiving a message from the network for suspending the connection, and UE 12 accordingly transitioning to an inactive state, such as RRC_INACTIVE. For example, UE 12 receives an RRC release message containing a suspend configuration (suspendConfig).

[0127] In at least one embodiment, as part of the UE operation in the first method, UE 12 deletes the LTM configuration in response to receiving an RRC release message with suspendConfig. An example RRC model can be included in the RRC specification, wherein new or modified specification details are shown in bold italics:

[0128] *****************************************************************

[0129] 5.3.8.3 UE receives RRCrease

[0130] UE should:

[0131] [...]

[0132] 1> If RCRelease contains suspendConfig:

[0133] [...]

[0134]

[0135] 2> If in response to RRCResumeRequest or RRCResumeRequest1, an RRCRelease message with suspendConfig is received: [...]

[0137] 2> Otherwise:

[0138] 3> Store in the UE inactive AS context: nextHopChainingCount received in the RRC release message, current KgNB and KRRCint keys, ROHC state, one or more EHC contexts, stored QoS flow to DRB mapping rules, C-RNTI used in the source PCell, cellIdentity and physical cell identifier of the source PCell, spCellConfigCommon in ReconfigurationWithSync of the NR PSCell (if configured), and all other configured parameters, except for the following:

[0139] - Parameters within PCell's ReconfigurationWithSync;

[0140] - Parameters within NR PSCell's ReconfigurationWithSync (if configured);

[0141] - Parameters within the MobilityControlInfoSCG of the E-UTRA PSCell (if configured);

[0142] - servingCellConfigCommonSIB;

[0143] [...]

[0145] 2> Enter RRC_INACTIVE and perform cell selection as specified in TS 38.304

[20] ;

[0146] 1> Otherwise

[0147] 2> As specified in 5.3.11, the action is executed after entering RRC_IDLE, and the release reason is "other".

[0148] *****************************************************************

[0149] In other embodiments or other operational scenarios, during the recovery process, UE 12 deletes a first set of one or more LTM-related configurations stored in UE 12. In the RRC specification, this method is modeled as follows (without adding an exception for storage in the UE inactive AS context, and the removal being performed during recovery startup):

[0150] *****************************************************************

[0151] 5.3.13 RRC Connection Restoration

[0152] [...]

[0153] 5.3.13.2 Startup

[0154] [...]

[0155] When initiating this process, the UE should:

[0156] [...]

[0157] 1> If the UE is in NE-DC or NR-DC:

[0158] 2> If the UE does not support maintaining the SCG configuration when the connection is restored:

[0159] 3> If MR-DC related configurations are stored in the UE inactive AS context (i.e., as specified in 5.3.5.10), then release the MR-DC related configurations from the UE inactive AS context;

[0160]

[0161] [...]

[0162] *****************************************************************

[0163] 5.3.5.4 Auxiliary Community Group Release

[0164] UE should:

[0165] 1> As a result of SCG release triggered by E-UTRA (i.e., (NG)EN-DC case) or NR (i.e., NR-DC case):

[0166] 2> Reset SCG MAC, if configured;

[0167] 2> For each RLC bearer that is part of the SCG configuration:

[0168] 3> Perform the RLC bearer release procedure as specified in 5.3.5.5.3;

[0169] 2> For each BH RLC channel that is part of the SCG configuration:

[0170] 3> Perform the BH RLC channel release procedure as specified in 5.3.5.5.10;

[0171] 2> Release SCG configuration;

[0172]

[0173] 2> If the SCG release is triggered by NR (i.e., the NR-DC case):

[0174] 3> Remove all entries in MCG VarConditionalReconfig (if they exist). For all these entries, the RRCReconfiguration in condRRCReconfig will not contain masterCellGroup with reconfigurationWithSync.

[0175] 2> Otherwise (i.e., EN-DC case):

[0176] 3> Perform the VarConditionalReconfiguration CPC removal as specified in Clause 5.3.5.9.7 of TS 36.331

[10] ;

[0177] 2> If the timer T310 for the corresponding SpCell is running, stop the timer;

[0178] 2> If the timer T312 for the corresponding SpCell is running, stop the timer;

[0179] 2> If the timer T304 for the corresponding SpCell is running, stop the timer.

[0180] Note: Releasing a cell group only refers to releasing the lower-level configuration of the cell group; RadioBearerConfig may not be released. *********************************************************************

[0181] Another possibility for modeling this in RRC is to define a function for releasing one or more LTM-related configurations, as shown below (where "x" and "y" represent the numbers to be determined):

[0182] ********************************************************************

[0183] 5.3.5.xy Release LTM-related configurations

[0184]

[0185] 5.3.13 RRC Connection Restoration [...]

[0187] 5.3.13.2 Startup [...]

[0189] When initiating this process, the UE should: [...]

[0191] 1> If the UE is in NE-DC or NR-DC:

[0192] 2> If the UE does not support maintaining the SCG configuration when the connection is restored:

[0193] 3> If stored, release the MR-DC related configuration from the UE inactive AS context (i.e., as specified in 5.3.5.10).

[0194] [...]

[0196] *************************************************************

[0197] An example method for removing a first set of one or more previously configured LTE-related configurations from a UE 12 involves the UE removing entries from one or more UE variables in which a first set of one or more LTM-related configurations has been configured. The example above illustrates this method, where the UE 12 removes all entries (if any) within the MCG or SCG VarLTM-UE-Config, and when the UE 12 removes all entries (if any) within the MCG or SCG VarLTM-Config.

[0198] For example, in one or more embodiments, UE 12 stores LTM-related information in two UE variables: (1) VarLTM-Config and (2) VarLTM-UE-Config. The first UE variable stores the reference configuration and the LTM candidate cell configuration, and the second UE variable stores the generated UE configuration associated with the received LTM candidate cell configuration.

[0199] The ASN.1 example for VarLTM-Config is as follows:

[0200] -- ASN1START

[0201] -- TAG-VARLTM-CONFIG-START

[0202] VarLTM-Config-r18-IEs ::= SEQUENCE {

[0203] ltm-ReferenceConfiguration-r18 OCTET STRING (including RRCReconfiguration),

[0204] ltm-CandidateList-r18 LTM-CandidateList-r18

[0205] }

[0206] LTM-CandidateList-r18 ::= SEQUENCE (SIZE (1..maxNrofCellsLTM-r18)) OF LTM-Candidate-r18

[0207] -- TAG-VARLTM-CONFIG-STOP

[0208] -- ASN1STOP

[0209] An ASN.1 example for VarLTM-UE-Config is as follows:

[0210] -- ASN1START

[0211] -- TAG-VARLTM-CONFIG-START

[0212] VarLTM-UE-Config-r18-IEs ::= SEQUENCE {

[0213] ue-ltm-ConfigCandidateList-r18 UE-LTM-ConfigCandidateList-r18

[0214] }

[0215] UE-LTM-ConfigCandidateList-r18 ::= SEQUENCE (SIZE(1..maxNrofCellsLTM-r18)) OF UE-LTM-Candidate-r18

[0216] UE-LTM-Candidate-r18 ::= SEQUENCE {

[0217] ltm-CandidateId-r18LTM-CandidateId-r18,

[0218] ue-LTM-Config-r18OCTET STRING (includes RRCReconfiguration)

[0219] }

[0220] -- TAG-VARLTM-CONFIG-STOP

[0221] -- ASN1STOP

[0222] Based on the above variable example, the first set of UE 12 removing one or more LTM-related configurations during recovery startup or transition to RRC_INACTIVE includes: UE 12 removing all entries in VarLTM-UE-Config (if they exist) and removing all entries in VarLTM-Config (if they exist).

[0223] In at least one embodiment, UE 12 removes a first set of one or more LTM-related configurations previously configured in UE 12, which is part of its current UE configuration, by removing an IE containing LTM-related configurations (e.g., IE LTM-Config and the IEs inside it).

[0224] The following is an example of ASN 1.1 for LTM-Config IE:

[0225] -- ASN1START

[0226] -- TAG-LTM-CONFIG-START

[0227] LTM-Config-r18 ::= SEQUENCE {

[0228] ltm-ReferenceConfiguration-r18 OCTET STRING (includes RRCReconfiguration), optional, -- Cond FirstLTM-Candidate

[0229] ltm-CandidateToReleaseList-r18 LTM-CandidateToReleaseList-r18 is optional, -- requires N

[0230] ltm-CandidateToAddModList-r18 LTM-CandidateToAddModList-r18 is optional, -- requires N

[0231] ltm-ServingCellNoResetID-r18 INTEGER (1.. maxNrofCellsLTM-r18-plus-1) Optional, -- Cond FirstLTM-Only

[0232] ltm-CSI-ResourceConfigToAddModList-r18 SEQUENCE (SIZE(1..maxNrofCSI-ResourceConfigurations)) OF LTM-CSI-ResourceConfig

[0233] Optional, -- requires N

[0234] ltm-CSI-ResourceConfigToReleaseList-r18 SEQUENCE (SIZE(1..maxNrofCSI-ResourceConfigurations)) OF LTM-CSI-ResourceConfigId

[0235] Optional, -- requires N ...

[0237] }

[0238] Editor's Note: Further research is needed regarding whether the LTM-CandidateNoResetL2-List field should include a separate reset flag for RLC and PDCP recovery.

[0239] LTM-CandidateToReleaseList-r18 ::= SEQUENCE (SIZE(1..maxNrofCellsLTM-r18)) OF LTM-CandidateId-r18

[0240] Optional -- Requires N

[0241] -- TAG-LTM-CONFIG-STOP

[0242] -- ASN1STOP

[0243]

[0244] A first set of one or more LTM-related configurations may correspond to one or more of the following: (i) one or more lower-layer measurement configurations for LTM; (ii) TA acquisition (also known as UL pre-synchronization configuration); (iii) one or more TCI state configurations for pre-synchronization (also known as DL pre-synchronization configuration); (iv) one or more LTM reference configurations; (v) one or more LTM candidate cell configurations; (vi) one or more complete LTM candidate cell configurations generated when the UE is configured with LTM; or (vii) one or more other LTM-related configurations.

[0245] In one set of embodiments, UE 12, having deleted a first set of one or more LTM-related configurations (previously stored), initiates a recovery process by sending an RRC recovery request message (e.g., RRCResumeRequest or RRCResumeRequest1) and, in response, receives an RRC recovery message (RRCResume). The RRCResume message contains a second set of one or more LTM-related configurations, which, instead of the first set, will be used by UE 12.

[0246] In one option, a second set of one or more LTM-related configurations is included within IE LTM-Config, as shown below, with modified or added content shown in bold italics:

[0247] *****************************************************************

[0248]

[0249] LTM-Config Information Element

[0250] -- ASN1START

[0251] -- TAG-LTM-CONFIG-START

[0252] LTM-Config-r18 ::= SEQUENCE {

[0253] ltm-ReferenceConfiguration-r18 OCTET STRING (includes RRCReconfiguration), optional, -- Cond FirstLTM-Candidate

[0254] ltm-CandidateToReleaseList-r18 LTM-CandidateToReleaseList-r18 is optional, -- requires N

[0255] ltm-CandidateToAddModList-r18 LTM-CandidateToAddModList-r18 is optional, -- requires N

[0256] ltm-ServingCellNoResetID-r18 INTEGER (1.. maxNrofCellsLTM-r18-plus-1) Optional, -- Cond FirstLTM-Only

[0257] ltm-CSI-ResourceConfigToAddModList-r18 SEQUENCE (SIZE

[0258] (1..maxNrofCSI-ResourceConfigurations)) OF LTM-CSI-ResourceConfig

[0259] Optional, -- requires N

[0260] ltm-CSI-ResourceConfigToReleaseList-r18 SEQUENCE (SIZE(1..maxNrofCSI-ResourceConfigurations)) OF LTM-CSI-ResourceConfigId

[0261] Optional, -- requires N ...

[0263] }

[0264] Editor's Note: Further research is needed regarding whether the LTM-CandidateNoResetL2-List field should include a separate reset flag for RLC and PDCP recovery.

[0265] LTM-CandidateToReleaseList-r18 ::= SEQUENCE (SIZE(1..maxNrofCellsLTM-r18)) OF LTM-CandidateId-r18 Optional -- Requires N

[0266] -- TAG-LTM-CONFIG-STOP

[0267] -- ASN1STOP

[0268]

[0269] *****************************************************************

[0270] The following example describes process text in an RRC according to one embodiment, where new or modified content is shown in bold italics compared to existing specification text:

[0271] *****************************************************************

[0272] 5.3.13.4 UE receives RRCresume

[0273] UE should:

[0274] [...]

[0275]

[0276] [...]

[0277] **************************************************************

[0278] In an example scenario, where UE 12's connection is suspended, and UE 12 has stored or previously stored a first set of one or more LTM-related configurations, the disclosed technology provides a mechanism to ensure that, regarding UE 12's operations associated with connection resumption, the one or more LTM-related configurations used by UE 12 match one or more LTM-related configurations expected by Network 10. That is, while UE 12 may have stored a first set of one or more LTM-related configurations, it may be provided with a second set of one or more LTM-related configurations in connection with the resumption of a suspended connection. The second set of one or more LTM-related configurations may be the same as or different from the first set of one or more LTM-related configurations.

[0279] In one or more embodiments, the first network node of network 10 operates as a central CU serving UE 12 and performs an operating method.

[0280] The method includes the serving CU sending a first set of one or more LTM-related configurations to the UE 12. In at least one embodiment, the UE 12 receives the first set of one or more LTM-related configurations in a message corresponding to an RRC reconfiguration message. The UE 12 may receive the message in various ways, such as when the UE 12 transitions to RRC_CONNECTED (e.g., from RRC_IDLE), or during handover, or during a reconfiguration with synchronization, or for intra-cell reconfiguration from the serving cell.

[0281] In at least one embodiment, when the UE 12 is capable of processing one or more LTM-related configurations, it receives a first set of one or more LTM-related configurations. For example, when the UE is capable of performing UL pre-synchronization for LTM, the UE receives one or more UL pre-synchronization configurations in the first set.

[0282] In at least one embodiment, the message sent from the network for suspending a connection and transitioning to an inactive state corresponds to an RRC release message containing a suspend configuration. Furthermore, in at least one such embodiment, a message from a first network node (e.g., the CU control plane (CP)) is sent to another network node (e.g., the CU user plane (UP)) with an indication to suspend connections for one or more bearers established for LTM operations, for example, in an E1AP bearer context modification request message.

[0283] Further operations at the serving CU according to the example method include: the serving CU responding to one or more triggering events to delete a first set of one or more LTM-related configurations, such as those stored for UE 12 in network 10. For example, the serving CU performs the deletion in response to sending an RRRCRelease message to UE 12 to transition UE 12 to an inactive state.

[0284] For example, the RRCRelease message is included within a UE context release command (sent via F1AP signaling), which is sent to the serving DU. Here, the serving DU forwards the RRCRelease message containing suspendConfig to UE 12. Correspondingly, the serving DU sends a UE context release complete message (sent via F1AP signaling) to the serving CU. When this message is received at the serving CU, the serving CU sends another UE context release command, this time to one or more candidate DUs associated with a first set of one or more LTM-related configurations. This prompts one or more candidate DUs to release the first set of one or more LTM configurations and responds with a UE context release complete message.

[0285] In at least one such embodiment, when the serving DU receives a UE context release command from the serving CU, the serving DU releases the UE context in the serving DU and sends a UE context release complete message to the serving CU. Therefore, if or when UE12 attempts to re-establish its connection with the same serving DU, a UE context establishment procedure is required, and Figure 2 The signaling flow described in the document illustrates the corresponding steps.

[0286] exist Figure 2 In this context, "S-DU" stands for Serving DU, "S-CU" stands for Serving CU, and "C-DU" stands for Candidate DU, which is a DU associated with one of the candidate LTM cells in a first set of one or more candidate LTM cells involved in one or more LTM-related configurations that are being deleted.

[0287] In one or more other embodiments, the message is included within a UE Context Modification Request message (sent via F1AP signaling), which contains an indication of the lower-level suspension and is sent to the serving DU. Here, the serving DU forwards an RRC release message containing suspendConfig to UE 12. Accordingly, the serving DU (via F1AP signaling) sends a UE Context Modification Response message to the serving CU. Upon receiving this response message at the serving CU, the serving CU sends another UE Context Release Command message, this time to one or more candidate DUs associated with a first set of one or more LTM-related configurations. This prompts each candidate DU to release the first set of one or more LTM configurations and responds to the serving CU with a UE Context Release Complete message.

[0288] In at least one such embodiment, when the serving DU receives a UE context modification request message (via F1AP signaling) containing an indication of lower-layer suspend, the serving DU retains all or one lower-layer configurations for UE 12 and does not send data to or receive data from the UE. If the UE later attempts to re-establish its connection with the same serving DU, it sends a UE context modification request message with a lower-layer presence state change IE set to "Restore Lower Layer," and therefore the gNB-DU should use the previously stored lower-layer configurations for the UE.

[0289] In one or more embodiments or one or more operating scenarios, the deletion of a first set of (outdated or obsolete) LTM-related configurations saved in network 10 for a UE 12 with a suspended connection and operating in the RRC_INACTIVE state occurs during the initiation of the recovery process for the UE 12.

[0290] For example, when the serving CU receives an RRC recovery request, it recognizes that UE 12 is releasing a first set of LTM-related configurations stored in UE 12. Therefore, the serving CU responds by sending a UE context release command to one or more candidate DUs associated with the first set of one or more LTM-related configurations, thereby prompting one or more candidate DUs to release the first set of LTM configurations for UE 12 stored in the candidate DUs. Each candidate DU responds to the serving CU with a UE context release complete message.

[0291] As a specific example in this context, when the UE context in the service DU has been suspended rather than released, the service DU sends a UE context modification request for restoring the UE context before it sends an RRC recovery message to UE 12.

[0292] As another specific example, the service CU-CP sends an indication to another network node or logical entity (e.g., to the service CU-UP), such as in an E1AP bearer context modification response message, to restore the connection used to establish one or more bearers for LTM operations. See also Figure 3 The signaling steps shown are as follows: Figure 3 This can be understood as an example release illustrating the LTM-related configuration when UE 12 attempts to restore its connection.

[0293] In one or more embodiments, the serving CU receives an RRC recovery request message (e.g., an RRCResumeRequest or RRCResumeRequest1 message) from the UE 12 and determines a second set of configurations for configuring one or more LTM-related configurations for the UE 12. Here, it will be understood that "second" is used as a label to distinguish the second set from a first set of one or more LTM-related configurations previously determined for the UE 12. For example, it can be assumed that the network 10 previously determined the first set, wherein the corresponding configuration information is stored in the UE 12 and one or more candidate DUs related to the first set.

[0294] Therefore, through these actions, Network 10 and UE 12 will operate in unison, meaning that both Network 10 and UE 12 will operate according to a second set of one or more LTM-related configurations.

[0295] Associated with a second set of LTM-related configurations determined for UE 12, the serving CU requests at least one candidate DU to configure LTM for UE 12, which may be about to enter the cell of that candidate DU. For example, the serving CU sends a UE context establishment request to the candidate DU. Subsequently, the serving CU receives a UE context establishment response from the candidate DU, which contains at least one configuration from the second set of one or more LTM-related configurations, such as configuration by LTM candidate cell, UL pre-synchronization configuration, DL pre-synchronization configuration, and / or other LTM-related configurations.

[0296] Then, the serving CU includes a second set of one or more LTM-related configurations in the RRC recovery message to be sent to UE 12. Therefore, even if UE 12 stored a first set of one or more LTM-related configurations while its connection was suspended, network 10 can update UE 12 with a second set of one or more LTM-related configurations in the RRC recovery message. In this way, UE 12 resumes operation using one or more LTM-related configurations consistent with network 10.

[0297] Figure 4Example signaling is shown that includes a second set of one or more LTM-related configurations in an RRC recovery message sent to UE 12.

[0298] Regarding example steps for storing / restoring LTM-related configurations for UE 12 and Network 10, consider example operations at UE 12. Example operations include UE 12 receiving a first set of one or more LTM-related configurations. For example, UE 12 receives an RRC reconfiguration message indicating a first set of one or more LTM-related configurations when it transitions from the RRC_IDLE state to the RRC_CONNECTED state. Other examples include UE 12 receiving the first set during handover, during reconfiguration synchronization, or for intra-cell reconfiguration from the serving cell. Yet another example is that UE 12 receives a first set of one or more LTM-related configurations when it is able to process one or more of the one or more LTM-related configurations. For example, when the UE is able to perform UL pre-synchronization for LTM, UE 12 receives one or more UL pre-synchronization configurations in the first set.

[0299] The UE operation also includes UE 12 subsequently receiving a message from network 10 to suspend its connection to network 10 and transition to an inactive state, such as RRC_INACTIVE. This message contains, for example, a suspendConfig element, and in response to this, UE 12 stores a first set of one or more LTM-related configurations.

[0300] Such operations are modeled in the RRC specification according to the following example, where new or modified text is shown in bold italics.

[0301] *****************************************************************

[0302] 5.3.8.3 UE receives RRCrease

[0303] UE should:

[0304] [...]

[0305] 1> If RCRelease contains suspendConfig:

[0306] [...]

[0307] 2> If in response to RRCResumeRequest or RRCResumeRequest1, an RRCRelease message with suspendConfig is received:

[0308] [...]

[0309] 2> Otherwise:

[0310] 3> Store in the UE inactive AS context: nextHopChainingCount received in the RRC release message, current KgNB and KRRCint keys, ROHC state, one or more EHC contexts, stored QoS flow to DRB mapping rules, C-RNTI used in the source PCell, cellIdentity and physical cell identifier of the source PCell, spCellConfigCommon in ReconfigurationWithSync of the NR PSCell (if configured), and all other configured parameters (including LTM-related parameters), except for the following:

[0311] - Parameters within PCell's ReconfigurationWithSync;

[0312] - Parameters within NR PSCell's ReconfigurationWithSync (if configured);

[0313] - Parameters within the MobilityControlInfoSCG of the E-UTRA PSCell (if configured);

[0314] - servingCellConfigCommonSIB;

[0315]

[0316] [...]

[0317] 2> Enter RRC_INACTIVE and perform cell selection as specified in TS 38.304

[20] ;

[0318] 1> Otherwise

[0319] 2> As specified in 5.3.11, the action is executed when entering RRC_IDLE, and the release reason is "other".

[0320] *****************************************************************

[0321] In one or more embodiments, UE 12 stores a first set of one or more LTM-related configurations configured by network 10 for UE 12, based on entries stored in one or more UE variables by UE 12. Such an example is shown above with reference to the VarLTM-Config and VarLTM-UE-Config variables. Furthermore, note that in one or more embodiments, UE 12 stores LTM-related configurations for MCG and SCG respectively. In one or more embodiments, network 10 uses RRC recovery messages to control whether UE 12, upon resuming its connection, restores the LTM-related configurations stored in UE 12 at or before the connection was previously suspended. That is, one or more LTM-related configurations stored in UE 12 while returning to an active state (resuming a suspended connection) may or may not be suitable for UE 12's use, and network 10 controls whether the previously stored configuration information is used by UE 12 while returning to an active state or replaced with updated LTM-related configuration information.

[0322] As an example, UE 12 initiates a recovery process and sends an RRC recovery request message to the target CU (i.e., the CU associated with the DU of the network cell in which UE 12 is attempting to restore its connection). Assuming the CU has LTM capability, the CU decides whether UE 12 should use its previously stored LTM-related configuration or a new or otherwise updated LTM-related configuration. The CU uses the RRC recovery message to indicate this decision to UE 12. Specifically, in at least one embodiment, the RRC recovery message may or may not contain an indication. Including this indication (e.g., the restoreLTM field) serves as a signal to UE 12 that UE 12 should restore its stored LTM-related configuration. The absence of this indication in the RRC recovery message serves as a signal to UE 12 that UE 12 should delete (remove) its previously stored LTM-related configuration.

[0323] The above logic also has the following advantages: ensuring correct behavior in UE 12 even when the target CU lacks LTM capability. That is, if the target CU lacks LTM capability, the RRRCResume message sent to UE 12 does not contain an indication that UE 12 should restore one or more previously stored LTM configurations associated with the restored connection. Therefore, UE 12 interprets this lack of indication as a signal to delete one or more previously stored LTM-related configurations, and thus restores its connection without using outdated / obsolete LTM-related configurations.

[0324] Regarding MCG and SCG, in one or more embodiments, the RCResume message may independently include or omit two separate indications. That is, the inclusion or omission of the first indication in the RCResume message controls whether UE 12 restores the previously stored LTM-related configuration for MCG. Similarly, the inclusion or omission of the second indication in the RCResume message controls whether the UE restores the previously stored LTM-related configuration for SCG. Alternatively, UE 12 must have both the first and second indications present to restore the previously stored LTM-related configuration for SCG—that is, UE 12 will not restore the SCG-related information unless UE 12 also restores the MCG-related information.

[0325] The above logic can be specified in the RRC specification, as shown in the example below. New or modified text is displayed in bold italics compared to existing specification text.

[0326] *****************************************************************

[0327] 5.3.13.4 UE receives RRCresume

[0328] UE should:

[0329] [...]

[0330] 1> If RCResume contains fullConfig:

[0331] 2> Perform the complete configuration process as specified in 5.3.5.11;

[0332] 1> Otherwise:

[0333] [...]

[0334] 2> If RCResume does not contain restoreSCG:

[0335] 3> If stored, release the MR-DC related configuration from the UE inactive AS context (i.e., as specified in 5.3.5.10).

[0336]

[0337] [...]

[0339] 1> Discard the UE inactive AS context; [...]

[0341] 5.3.5.10 MR-DC Release

[0342] UE should:

[0343] 1> As a result of MR-DC release triggered by E-UTRA or NR:

[0344] 2> If it has already been established, release SRB3 as specified in 5.3.5.6.2;

[0345] 2> Release the measConfig associated with SCG;

[0346] 2> If the UE is configured with NR SCG:

[0347] 3> Release the SCG configuration as specified in Clause 5.3.5.4;

[0348] 3> If configured, release otherConfig associated with SCG;

[0349] 3> If it is running, stop the timers T346a, T346b, T346c, T346d, T346e, T346j and T346k associated with SCG;

[0350] 3> If configured, release the bap-Config associated with SCG;

[0351] 3> If bap-Config is not configured, the BAP entity shall be released in accordance with the provisions of TS 38.340

[47] ;

[0352] 3> If configured, release the iab-IP-AddressConfigurationList associated with SCG;

[0353] 2> Otherwise, if the UE is configured with E-UTRA SCG:

[0354] 3> Release the SCG in accordance with Clause 5.3.10.19 of TS 36.331

[10] to release the E-UTRA SCG; [...]

[0356] 5.3.5.4 Auxiliary Community Group Release

[0357] UE should:

[0358] 1> The result of SCG release triggered by E-UTRA (i.e., (NG)EN-DC case) or NR (i.e., NR-DC case):

[0359] 2> If configured, reset the SCG MAC;

[0360] 2> For each RLC bearer that is part of the SCG configuration:

[0361] 3> Perform the RLC bearer release procedure as specified in 5.3.5.5.3;

[0362] 2> For each BH RLC channel that is part of the SCG configuration:

[0363] 3> Perform the BH RLC channel release procedure as specified in 5.3.5.5.10;

[0364] 2> Release SCG configuration;

[0365]

[0366] 2> If the SCG release is triggered by NR (i.e., the NR-DC case):

[0367] 3> Remove all entries in MCG VarConditionalReconfig (if they exist). For all these entries, the RRCReconfiguration in condRRCReconfig will not contain masterCellGroup with reconfigurationWithSync.

[0368] 2> Otherwise (i.e., EN-DC case):

[0369] 3> Perform the VarConditionalReconfiguration CPC removal as specified in Clause 5.3.5.9.7 of TS 36.331

[10] ;

[0370] 2> If the timer T310 for the corresponding SpCell is running, stop the timer;

[0371] 2> If the timer T312 for the corresponding SpCell is running, stop the timer;

[0372] 2> If the timer T304 for the corresponding SpCell is running, stop the timer.

[0373] Note: Releasing a cell group only refers to releasing the lower-level configuration of the cell group, but RadioBearerConfig may not be released.

[0374] RRCResume-v18xy-Ies ::= SEQUENCE {

[0375] restoreLTM-r18 ENUMERATED {true}

[0376] Optional, -- requires N

[0377] nonCriticalExtension SEQUENCE {}

[0378] Optional

[0379] }

[0380] restoreLTM

[0381] Instruct the UE to restore the LTM-related configuration from the UE inactive AS context (if stored).

[0382] *****************************************************************

[0383] Consider another example occurring in the following context: UE 12 stores a first set of one or more LTM-related configurations while its connection to network 10 is suspended, and then later sends an RRC recovery request message (e.g., RRCResumeRequest or RRCResumeRequest1). Network 10 responds to this request by sending an RRC recovery message (RRCResume) to UE 12, which includes a second set of one or more LTM-related configurations. The inclusion of a second set of one or more LTM-related configurations in the RRC recovery message can serve as a signal to UE 12 indicating that the previously stored first set of one or more LTM-related configurations should not be restored for the restored connection, but rather the second set of one or more LTM-related configurations should be used. The second set can be a complete replacement for the first set, or the second set can supplement or otherwise modify the first set—for example, by adding, deleting, or changing one or more items in the first set. In at least one embodiment, when the network 10 requests the UE 12 to delete a first set of one or more previously stored LTM-related parameters and instead use a second set of one or more LTM-related parameters associated with the restored connection, the restoreLTM indication is omitted from the RRC recovery message, and the message contains a second set of one or more LTM-related configurations.

[0384] The following is an example of a second set of LTM-related configurations that includes one or more LTM-related configurations in the IE LTM-Config described above.

[0385] *****************************************************************

[0386] [...]

[0387] LTM-Config information elements

[0388] -- ASN1START

[0389] -- TAG-LTM-CONFIG-START

[0390] LTM-Config-r18::= SEQUENCE {

[0391] ltm-ReferenceConfiguration-r18 OCTET STRING (including RRCReconfiguration), optional, -- Cond FirstLTM-Candidate

[0392] ltm-CandidateToReleaseList-r18 LTM-CandidateToReleaseList-r18 is optional, -- requires N

[0393] ltm-CandidateToAddModList-r18 LTM-CandidateToAddModList-r18 is optional, -- requires N

[0394] ltm-ServingCellNoResetID-r18 INTEGER (1... maxNrofCellsLTM-r18-plus-1) Optional, -- Cond FirstLTM-Only

[0395] ltm-CSI-ResourceConfigToAddModList-r18 SEQUENCE(SIZE(1...maxNrofCSI-ResourceConfigurations))OF LTM-CSI-ResourceConfig

[0396] Optional, -- requires N

[0397] ltm-CSI-ResourceConfigToReleaseList-r18 SEQUENCE(SIZE(1…maxNrofCSI-ResourceConfigurations))OF LTM-CSI-ResourceConfigId

[0398] Optional, -- requires N ...

[0400] }

[0401] Editor's Note: Further research is needed regarding whether the LTM-CandidateNoResetL2-List field should include a separate reset flag for RLC and PDCP recovery.

[0402] LTM-CandidateToReleaseList-r18::= SEQUENCE(SIZE(1..maxNrofCellsLTM-r18))OF LTM-CandidateId-r18 Optional -- Requires N

[0403] -- TAG-LTM-CONFIG-STOP

[0404] -- ASN1STOP

[0405]

[0406] ***************************************************************** The RRC content shown below is an example procedure text.

[0407] *****************************************************************5.3.13.4 UE receives RRCresume message

[0408] UE should:

[0409] [...]

[0410] 1> If the RRCresume message contains ltm-Config:

[0411] 2> If ltm-Config is set to setup:

[0412] 3> Perform the LTM configuration process as specified in 5.3.5.x;

[0413] 2> Otherwise:

[0414] 3> Release LTM configuration;

[0415] 1> Set the content of the RRRCResumeComplete message as follows:

[0416] [...]

[0417] *****************************************************************

[0418] A second set of one or more LTM-related configurations may be the same as or different from a first set of one or more LTM-related parameters.

[0419] As a further example operation in one or more embodiments, when an active UE 12 is suspended, and associated with the suspension of its connection to network 10, the UE stores one or more LTM-related configurations most recently provided to it by the network during the active operation. The then-serving CU of UE 12 also stores one or more LTM-related configurations for UE 12 at that time, for example, stored in the UE inactive AS context. However, associated with the suspension of the connection and the transition of UE 12 to an inactive state, the then-serving CU releases the then-serving LTM-related configurations from the one or more candidate DUs involved. Removing such information from one or more candidate DUs implies that context establishment will be triggered during recovery operation. Alternatively, instead of releasing one or more configurations, the serving CU suspends one or more LTM-related configurations from one or more candidate DUs to trigger context modification during recovery operation.

[0420] More specifically, consider UE 12, which is operating in an active state and has a first set of one or more LTM-related configurations. Therefore, LTM-related configuration information is stored in UE 12, and the corresponding LTM-related configuration information is stored in one or more DUs identified by UE 12 as LTM candidate cells. Associated with the Serving CU suspending the connection of UE 12, as UE 12 transitions to an inactive state, the Serving CU stores the first set of one or more LTM-related configurations in the UE inactive context on the network side. The Serving CU also sends a UE context modification request to each candidate DU involved with the first set of one or more LTM-related configurations. This request indicates a lower-layer suspension, and each candidate DU responds by suspending the first set of one or more LTM-related configurations. Furthermore, each candidate DU sends a UE context modification response back to the Serving CU.

[0421] Compared to configuration release (where the released configuration information is discarded), the "suspended" configuration is stored. Therefore, in response to a UE context modification request for each candidate DU involved in a first set of one or more LTM-related configurations sent by the serving CU, each candidate DU stores one or more LTM-related configurations for UE 12 for possible subsequent reuse upon subsequent connection restoration. Figure 5 Example signaling for such a suspension is shown, which is embodied in the steps performed at each candidate DU.

[0422] Now consider an example scenario: The serving CU suspends a first set of one or more LTM-related configurations for UE 12 at each of the involved candidate DUs, but associated with the serving CU subsequently receiving an RRC recovery request message from UE 12, the serving CU decides that the first set of one or more LTM-related configurations should be released rather than restored. In this case, the serving CU sends a message to each such candidate DU prompting the candidate DU to delete the first set of one or more LTM-related configurations. As a specific example, the serving CU sends a UE context release command to each candidate DU. Each candidate DU responds to the UE context release command by releasing, for example, the first set of one or more LTM-related configurations or a portion thereof stored at that candidate DU. Releasing a “part” of the stored information refers to the following example situation: multiple candidate DUs are involved in the first set of one or more LTM-related configurations, in which case each candidate DU deletes information specific to it.

[0423] In the opposite scenario: the serving CU has suspended a first set of one or more LTM-related configurations for UE 12 at one or more candidate DUs and determines that this first set should be restored in connection with the restoration of the connection to UE 12. The serving CU sends, for example, a UE context modification request to each candidate DU. This request contains an indication that the candidate DU should restore the first set of one or more LTM-related configurations for UE 12. Each candidate DU responds by restoring (restoring use of) the first set of one or more LTM-related configurations for UE 12 or a relevant portion thereof.

[0424] In order for the Serving CU to enable one or more candidate DUs to resume their use of the first set of one or more LTM-related configurations, the context information for UE 12 (e.g., UE inactive AS context) needs to contain information about one or more candidate DUs, such as node identifiers, one or more F1AP signaling associations, tunnel identifiers, etc. Figure 6 The document shows an example of one or more LTM-related configurations that cause a recovery for UE 12 that are currently suspended.

[0425] Now consider example details for an embodiment or operational scenario, wherein the service CU receives an RRC recovery request from UE 12, UE 12 stores a first set of one or more LTM-related configurations for UE 12, and the service CU decides to configure a second set of one or more LTM-related configurations to replace or modify the first set of one or more LTM-related configurations.

[0426] Before sending an RRC recovery message to UE 12, the serving CU sends a context establishment request to one or more candidate DUs, requesting the candidate DUs to determine one or more LTM-related configurations for UE 12. Each candidate DU responds to the serving CU by sending a UE context establishment response containing one or more LTM-related configurations determined by the candidate DU for UE 12. The serving CU aggregates the one or more LTM configurations determined by the candidate DUs into a second set of one or more LTM-related configurations. This second set is used by the UE to replace or modify a first set of one or more LTM-related configurations stored in UE 12 before UE 12 was suspended. Example LTM-related configurations included in this second set are UL and / or DL ​​pre-synchronization configurations determined by the candidate DUs.

[0427] Now consider the following example: UE 12 attempts to restore its connection, but has moved, such that the CU in network 10 receiving the RRC restoration request is not the same CU that previously served UE 12 and suspended its connection. In other words, the "second" CU receiving the restoration request is not the "first" CU that previously served UE 12. Here, assume that a first set of one or more LTM-related configurations associated with the suspended connection of UE 12 is stored in UE 12 and network 10.

[0428] When UE 12 attempts to re-establish its connection, the first CU receives a message from the second CU requesting the UE context for UE 12. For example, the second CU sends an XnAP: UE Context Retrieval Request to the first CU. The first CU responds by deleting a first set of one or more stored LTM-related configurations from the UE inactive AS context it maintains for UE 12, and it sends a UE context response message to the second CU (e.g., XnAP: UE Context Retrieval Response). This response message contains the UE inactive AS context (but does not contain the first set of one or more LTM-related configurations). As part of these operations, the first CU also deletes the first set of one or more LTM-related configurations from the one or more candidate DUs involved in the first set of one or more LTM-related configurations by sending a UE context release command to each such candidate DU.

[0429] Figure 7The signaling flow illustrating this type of operation is shown. Although Figure 7 The first (serving) CU and the second (target) CU, along with their corresponding associated candidate DUs, are shown, but these operations can be broadly understood as occurring within the context of a new and an old gNB or a new and an old radio base station. That is, in connection with determining that UE 12 is resuming its suspended connection with the "new" gNB, when UE 12 is released to an inactive state, the "old" gNB, which serves as the serving gNB for UE 12, removes the LTM-related configuration for UE 12 from the context information stored for UE 12.

[0430] Figure 7 The logic embodied in the signaling flow it describes takes into account the following scenario: when UE 12 is released to an inactive state, UE 12 has LTM-related configurations associated with it, and UE 12 moves while inactive with cell reselection, attempting to restore its connection in a network cell not associated with the gNB / CU that released it. This action triggers the release of one or more stored LTM-related configurations associated with UE 12 in both network 10 and UE 12. Advantageously, this behavior automatically considers the following scenario: the new (target) gNB / CU does not support LTM. In this case, the target gNB / CU will not receive any LTM-related configurations from the previous serving gNB / CU in the UE inactive AS context.

[0431] In association with the above example, the following text is suggested for use in TS 38.473, with the new suggested text shown in bold italics.

[0432] *********************************************************

[0433] 8.3.4 UE Context Modification (Initiated by gNB-CU)

[0434] 8.3.4.1 Overview

[0435] The purpose of the UE context modification procedure is to modify the established UE context, such as establishing, modifying, and releasing radio resources or sidelink resources. This procedure is also used to command the gNB-DU to stop data transmission for mobility for that UE (see TS 38.401 [4]). The procedure uses UE-associated signaling.

[0436] Omitted text

[0437]

[0438] Omitted text

[0439] 9.2.2.7 UE Context Modification Request

[0440] This message is sent by gNB-CU to provide gNB-DU with information about changes in UE context information.

[0441] Direction: gNB-CU –> gNB-DU

[0442]

[0443] Omitted text

[0444] 9.3.1.x LTM has a state change.

[0445] 9.3.1.xLTM has a state change.

[0446] This IE instruction indicates that the underlying configuration of the LTM configuration should be changed.

[0447]

[0448] *****************************************************************

[0449] Figure 8 An operational method 800 performed by a UE 12 according to one or more embodiments is illustrated. Specifically, method 800 is performed by a UE 12 configured to operate with respect to a telecommunications network, and it includes the UE 12: receiving (block 802) information from the telecommunications network when the UE 12 is connected to the telecommunications network, the information indicating a lower-layer triggered mobility (LTM) configuration for LTM-based mobility of the UE 12; receiving (block 804) additional information indicating that the UE 12 will suspend its connection with the telecommunications network; and releasing (block 806) the LTM configuration.

[0450] For example, in the context of method 800, when in an active state with the network (i.e., when connected to the network), UE 12 receives a release message from its serving node indicating that the connection is to be suspended. The release message contains the following implicit or explicit indication: associated with the suspension, the LTM configuration will be released, and UE 12 responds by releasing (deleting) the LTM configuration from its memory or storage device.

[0451] Figure 9Method 900, performed by a network node in a telecommunications network, is illustrated. For example, a gNB or gNB-CU performs method 900 with respect to a connected UE 12. Method 900 includes the network node: sending (box 902) information to the UE 12 indicating an LTM configuration for LTM-related mobility to be used by the UE; and sending (box 904) additional information to the UE indicating that the UE intends to suspend its connection to the network, thereby releasing the LTM configuration.

[0452] The transmission of additional information occurs, for example, at an indeterminate time after the transmission of information indicating the LTM configuration. That is, UE 12 and network 10 can operate using the LTM configuration for a period of time after UE 12 is connected. Furthermore, in at least one implementation of method 900, additional information is sent in a release message indicating the suspension of the connection and the release of UE 12. For example, the release message contains implicit or explicit indications that, associated with the suspension of the connection, the UE will release the LTM configuration. Additionally, in one or more embodiments, method 900 includes the serving node and / or any other involved node in network 10 releasing the LTM configuration so that it is not reused for subsequent connection restoration.

[0453] Figure 10 An example of a communication system QQ100 according to some embodiments is shown.

[0454] For example, the communication system QQ100 is a more detailed example of network 10. The communication system QQ100 should be understood as being configured according to the above-described techniques to maintain consistency of LTM-related configuration information between the UE and the network, particularly in the context of the UE resuming its suspended connection, wherein one or more LTM-related configurations previously determined for the UE, such as those prior to the UE's connection suspension, have been stored for the UE.

[0455] In this example, the communication system QQ100 includes a telecommunications network QQ102, which contains an access network QQ104 (e.g., a radio access network (RAN)) and a core network QQ106, which contains one or more core network nodes QQ108. The access network QQ104 contains one or more access network nodes, such as network nodes QQ110a and QQ110b (one or more of which may generally be referred to as network node QQ110), or any other similar 3GPP access node or non-3GPP access point. These “network nodes” can be configured as described above in the example gNB-CU / gNB-DU example to maintain consistency of LTM-related information for UEs resuming suspended connections.

[0456] Furthermore, as those skilled in the art will understand, network nodes are not necessarily limited to implementations of the radio and baseband portions provided and integrated by a single supplier. Therefore, it will be understood that network nodes include their decomposed implementations or portions. For example, in some embodiments, the telecommunications network QQ102 includes one or more Open-RAN (ORAN) network nodes. An ORAN network node is a node in the telecommunications network QQ102 that supports 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 QQ102 (including one or more network nodes QQ110 and / or core network node QQ108).

[0457] Examples of ORAN network nodes include Open Radio Units (O-RUs), Open Distributed Units (O-DUs), Open Central Units (O-CUs), O-CU control planes (O-CU-CPs) or O-CU user planes (O-CU-UPs), RAN intelligent controllers (near real-time or non-real-time) with managed software or software plugins, such as near real-time control applications (e.g., xApps) or non-real-time control applications (e.g., rApps), 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 contain an O-Cloud computing platform orchestrated by a service management and orchestration framework via the O-2 interface or comparable technologies defined by the O-RAN Alliance. Network node QQ110 facilitates direct or indirect connections for user equipment (UEs), such as connecting UEs QQ112a, QQ112b, QQ112c, and QQ112d (one or more of which may generally be referred to as QQ112) to the core network QQ106 via one or more radio connections. One or more of these UEs QQ112 should be understood as being configured similarly to UE 12 in relation to LTM-related configurations for managing / processing storage in the context of resuming suspended connections.

[0458] Examples of wireless communication via wireless connection include sending and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for transmitting information without the use of wires, cables, or other conductors. Furthermore, in different embodiments, the communication system QQ100 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. The communication system QQ100 may include and interface with any type of communication, telecommunications, data, cellular, radio network, and / or other similar type of system.

[0459] QQ112 can be any of a wide variety of communication devices, including wireless devices that are deployed, configured, and / or operable to communicate wirelessly with network node QQ110 and other communication devices. Similarly, network node QQ110 is deployed, capable, configured, and / or operable to communicate directly or indirectly with QQ112 and / or with other network nodes or devices in telecommunication network QQ102 to enable and / or provide network access (e.g., wireless network access) and / or perform other functions (e.g., management in telecommunication network QQ102).

[0460] In the depicted example, core network QQ106 connects network node QQ110 to one or more hosts (e.g., host QQ116). These connections can be direct or indirect, via one or more intermediate networks or devices. In other examples, network nodes can be directly coupled to hosts. Core network QQ106 includes one or more core network nodes (e.g., core network node QQ108), which are composed of hardware and software components. The characteristics of these components can be substantially similar to those described for UEs, network nodes, and / or hosts, such that the description generally applies to the corresponding components of core network node QQ108. Example core network nodes include 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 Dehiding Function (SIDF), Unified Data Management (UDM), Security Edge Protection Agent (SEPP), Network Open Function (NEF), and / or User Plane Function (UPF).

[0461] The host QQ116 may be owned or controlled by a service provider other than the operator or provider of access network QQ104 and / or telecommunications network QQ102, and may be operated by or on behalf of the service provider. The host QQ116 may host various applications to provide one or more services. Examples of such applications include live and pre-recorded audio / video content, data collection services (e.g., retrieving and compiling data from 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 the server.

[0462] Overall, Figure 10 The QQ100 communication system 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 procedures, 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.

[0463] In some examples, the QQ102 telecom network is a cellular network implementing 3GPP standardized features. Therefore, the QQ102 telecom network can support network slicing to provide different logical networks to different devices connected to it. For example, the QQ102 telecom network can provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs while providing enhanced mobile broadband (eMBB) services to other UEs, and / or providing massive machine-type communication (mMTC) / massive IoT services to even more UEs.

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

[0465] In this example, hub QQ114 communicates with access network QQ104 to facilitate indirect communication between one or more UEs (e.g., UE QQ112c and / or QQ112d) and network nodes (e.g., network node QQ110b). In some examples, hub QQ114 may be a controller, router, content source and analytics, or any other communication device described herein with respect to the UE. For example, hub QQ114 may be a broadband router that enables the UE to access core network QQ106. As another example, hub QQ114 may be a controller that sends commands or instructions to one or more actuators in the UE. Commands or instructions may be received from the UE, network node QQ110, or by executable code, scripts, procedures, or other instructions in hub QQ114. As another example, hub QQ114 may be a data collector that acts as temporary storage for UE data, and in some embodiments, may perform data analytics or other processing. As another example, hub QQ114 may be a content source. For example, for a UE acting as a VR headset, display, speaker, or other media delivery device, the QQ114 hub can retrieve VR assets, video, audio, or other media or sensor-related data via network nodes, and then provide it to the UE directly, after performing local processing, and / or after adding additional local content. In yet another example, the QQ114 hub acts as a proxy server or coordinator for the UE, particularly when one or more of the UEs are low-power IoT devices.

[0466] Hub QQ114 can have a constant / persistent or intermittent connection to network node QQ110b. Hub QQ114 can also allow different communication schemes and / or scheduling between hub QQ114 and UEs (e.g., UEs QQ112c and / or QQ112d) and between hub QQ114 and core network QQ106. In other examples, hub QQ114 is connected to core network QQ106 and / or one or more UEs via a wired connection. Furthermore, hub QQ114 can be configured to connect to an M2M service provider via access network QQ104 and / or to another UE via a direct connection. In some scenarios, a UE can establish a wireless connection with network node QQ110 while still being connected via a wired or wireless connection via hub QQ114. In some embodiments, hub QQ114 may be a dedicated hub, i.e., a hub whose primary function is to route communication from the UE to network node QQ110b and / or from network QQ110b to the UE. In other embodiments, hub QQ114 may be a non-dedicated hub, i.e., a device capable of operating to route communication between the UE and network node QQ110b, but also capable of operating as a communication start and / or end point for some data channels.

[0467] The communication system QQ100 can be configured according to the techniques disclosed herein. For example, one or more UE QQ112s are configured to perform the condition restore / delete operations described herein for LTM-related configurations in a connection suspension / resumption context. Accordingly, one or more network nodes QQ110s are configured as CU / DU systems, and at least one such CU is configured to perform the service CU operations described herein. Regarding the following figures (e.g.) Figure 11 The above content also applies.

[0468] Figure 11A UE QQ200 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, VoIP phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, game consoles or devices, music storage devices, playback devices, wearable terminal devices, wireless endpoints, mobile stations, tablets, laptops, laptop embedded devices (LEEs), laptop mounted devices (LMEs), smart devices, wireless client devices (CPEs), vehicles, in-vehicle or in-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.

[0469] 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), the UE can support device-to-device (D2D) communication. In other examples, the UE may not necessarily have a user in the sense of a human user who owns and / or operates the associated equipment. Instead, the UE may represent a device intended for sale to or operated by a human user, but may not be associated with a particular human user, or may not initially be associated with a particular human user (e.g., a smart sprinkler controller). Alternatively, the UE may represent a device not intended for sale to or operated by an end user, but may be associated with or operated for the benefit of a user (e.g., a smart meter).

[0470] UE QQ200 includes processing circuitry QQ202, which is operatively coupled via bus QQ204 to input / output interface QQ206, power supply QQ208, memory QQ210, communication interface QQ212, and / or any other component, or any combination thereof. Some UEs may use... Figure 11 The components shown may be all or some of the components. The degree of integration between components may vary from UE to UE. In addition, some UEs may contain multiple instances of components, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0471] The processing circuit QQ202 is configured to process instructions and data and can be configured to implement any sequential state machine operable to execute instructions stored as a machine-readable computer program in memory QQ210. The processing circuit QQ202 can be implemented as one or more hardware-implemented state machines (e.g., discrete logic, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), etc.); programmable logic along with appropriate firmware; one or more stored computer programs, a general-purpose processor (e.g., a microprocessor or digital signal processor (DSP)) along with appropriate software; or any combination of the foregoing. For example, the processing circuit QQ202 may include multiple central processing units (CPUs).

[0472] In this example, the input / output interface QQ206 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 the UE QQ200. Examples of input devices include touch-sensitive or presence-sensitive displays, cameras (e.g., digital cameras, digital camcorders, webcams, etc.), microphones, sensors, mice, trackballs, steering wheels, 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, biosensors, 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.

[0473] In some embodiments, the power supply QQ208 is configured as a battery or battery pack. Other types of power sources can be used, such as an external power source (e.g., a power outlet), a photovoltaic device, or a battery. The power supply QQ208 may also include power circuitry for delivering power from the power supply QQ208 itself and / or an external power source to various components of the UEQQ200 via input circuitry or an interface (e.g., a power cable). The power delivery may be used, for example, to charge the power supply QQ208. The power circuitry may format, convert, or otherwise modify the power from the power supply QQ208 to suit the power supply for the various components of the UE QQ200 being powered.

[0474] The memory QQ210 can be a memory or is 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 cassette tape, flash drive, etc. In one example, the memory QQ210 includes one or more application programs QQ214, such as an operating system, web browser application, widget, utility engine, or other application, and corresponding data QQ216. The memory QQ210 can store any of a variety of operating systems or combinations of operating systems for use by the UE QQ200.

[0475] The QQ210 memory 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 versatile optical disc (HD-DVD) drive, an internal hard drive, a Blu-ray disc drive, a holographic digital data storage (HDDS) disc drive, an external micro 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 Identity Modules (SIMs), such as USIM and / or ISIM), other memory, or any combination thereof. The UICC can be an embedded UICC (eUICC), an integrated UICC (iUICC), or a removable UICC commonly referred to as a "SIM card." The QQ210 memory can allow the UE to... QQ200 accesses instructions, applications, etc., stored on temporary or non-temporary storage media to unload or upload data. An article of manufacture (e.g., an article utilizing a communication system) may be tangibly embodied in or located within memory QQ210, which may be or include a device-readable storage medium.

[0476] The processing circuitry QQ202 can be configured to communicate with an access network or other network using a communication interface QQ212. The communication interface QQ212 may include one or more communication subsystems and may include or be communicatively coupled to an antenna QQ222. The communication interface QQ212 may include one or more transceivers for communication, such as through one or more remote transceivers (e.g., another UE or network node in the access network) of another device capable of wireless communication. Each transceiver may include a transmitter QQ218 and / or a receiver QQ220 suitable for providing network communication (e.g., optical, electrical, frequency allocation, etc.). Furthermore, the transmitter QQ218 and receiver QQ220 may be coupled to one or more antennas (e.g., antenna QQ222) and may share circuitry, software, or firmware, or alternatively may be implemented separately.

[0477] In the illustrated embodiment, the communication functions of the communication interface QQ212 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communication (e.g., Bluetooth, near-field communication), location-based communication (e.g., using a Global Positioning System (GPS) to determine location), other similar communication functions, or any combination thereof. Communication may be implemented according to one or more communication protocols and / or standards, such as 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 Fiber Network (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), etc.

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

[0479] 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.

[0480] When a UE is in the form of an Internet of Things (IoT) device, it 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 are embedded in the following devices: connected refrigerators or freezers, televisions, connected lighting fixtures, electricity meters, robotic vacuum cleaners, voice-controlled smart speakers, home security cameras, motion detectors, thermostats, smoke detectors, door / window sensors, flood / humidity sensors, electric 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 object tracking devices, sensors for monitoring plants or animals, industrial robots, unmanned aerial vehicles (UAVs), and any type of medical device (such as heart rate monitors or remote-controlled surgical robots). UEs in the form of IoT devices, in addition to including those related to… Figure 11 In addition to the other components described in the UE QQ200 description, it further includes circuitry and / or software depending on the intended application of the IoT device.

[0481] As another specific example, in IoT scenarios, a UE can represent a machine or other device that performs monitoring and / or measurement and transmits 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, a UE can implement the 3GPP NB-IoT standard. In other scenarios, a UE can represent a vehicle, such as a car, bus, truck, ship, and aircraft, or other devices capable of monitoring and / or reporting their operational status or other functions related to their operation.

[0482] In practice, any number of UEs can be used for a single use case. For example, the first UE may be a drone or integrated into a drone, providing the drone's speed information (obtained via a speed sensor) to a second UE, i.e., a remote controller 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 actuators) to increase or decrease the drone's speed. The first UE and / or the second UE may also include more than one of the functions described above. For example, the UE may include sensors and actuators, as well as communication for processing data from the speed sensors and actuators.

[0483] Figure 12 A network node QQ300 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 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, Node Bs, evolved Node Bs (eNBs), and NR Node Bs (gNBs)), O-RAN nodes, or components of O-RAN nodes (e.g., O-RUs, O-DUs, O-CUs).

[0484] Base stations can be classified according to the coverage they provide (or, in other words, their transmit power level); therefore, depending on the coverage provided, a base station can be referred to as a femtobase, picobase, microbase, or macrobase. A base station can be a relay node or a relay donor node controlling a relay. Network nodes can also include one or more (or all) parts 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). Such remote radio units may or may not be integrated with an antenna as antenna-integrated radios. The parts of a distributed radio base station can also be referred to as nodes in a distributed antenna system (DAS).

[0485] Other examples of network nodes include multiple transport point (multiple TRP) 5G access nodes, multi-standard radio (MSR) equipment (e.g., MSR BS), network controllers (e.g., radio network controller (RNC) or base station controller (BSC)), base transceiver stations (BTS), transport points, transport nodes, multi-cell / multicast coordination entities (MCE), operation and maintenance (O&M) nodes, operations support system (OSS) nodes, self-organizing network (SON) nodes, location nodes (e.g., evolved servicing mobile location center (E-SMLC)), and / or minimized drive test (MDT).

[0486] Network node QQ300 includes processing circuitry QQ302, memory QQ304, communication interface QQ306, and power supply QQ308. Network node QQ300 can consist of multiple physically independent components (e.g., node B components and RNC components, or BTS components and BSC components, etc.), each component may have its own components. In some scenarios where network node QQ300 includes multiple independent components (e.g., BTS and BSC components), one or more of these independent components can be shared among multiple network nodes. For example, a single RNC can control multiple node Bs. In this case, each unique node B and RNC pair can be considered a single independent network node in some situations. In some embodiments, network node QQ300 can be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory QQ304 for different RATs), and some components may be reused (e.g., the same antenna QQ310 may be shared by different RATs). The network node QQ300 may also include various components for different wireless technologies integrated into the network node QQ300, such as GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, radio frequency identification (RFID), or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chips or chipsets and other components within the network node QQ300.

[0487] The processing circuitry QQ302 may include a combination of one or more of the following: a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field-programmable gate array or any other suitable computing device, resource or combination of hardware, software and / or coding logic, which may be used alone or in combination with other network node QQ300 components (e.g., memory QQ304) to provide network node QQ300 functionality.

[0488] In some embodiments, the processing circuit QQ302 includes a system-on-a-chip (SOC). In some embodiments, the processing circuit QQ302 includes one or more of a radio frequency (RF) transceiver circuit QQ312 and a baseband processing circuit QQ314. In some embodiments, the RF transceiver circuit QQ312 and the baseband processing circuit QQ314 may be located on separate chips (or chipsets), circuit boards, or units (e.g., radio units and digital units). In alternative embodiments, some or all of the RF transceiver circuit QQ312 and the baseband processing circuit QQ314 may be located on the same chip or a set of chips, boards, or units.

[0489] The memory QQ304 may include any form of volatile or non-volatile computer-readable memory, including but not limited to persistent memory, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (e.g., hard disk), removable storage media (e.g., flash drive, optical disc (CD), or digital video disc (DVD)) and / or any other volatile or non-volatile, non-transient device-readable and / or computer-executable memory device, used to store information, data, and / or instructions that can be used by the processing circuitry QQ302. The memory QQ304 may store any suitable instructions, data, or information, including computer programs, software, applications, including one or more of the following: logic, rules, code, tables, and / or other instructions that can be executed by the processing circuitry QQ302 and utilized by the network node QQ300. The memory QQ304 may be used to store any calculations performed by the processing circuitry QQ302 and / or any data received via the communication interface QQ306. In some embodiments, the processing circuitry QQ302 and the memory QQ304 are integrated.

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

[0491] In some alternative embodiments, network node QQ300 does not include a separate radio front-end circuit QQ318; instead, processing circuitry QQ302 includes radio front-end circuitry and is connected to antenna QQ310. Similarly, in some embodiments, all or part of RF transceiver circuitry QQ312 is part of communication interface QQ306. In other embodiments, communication interface QQ306 includes one or more ports or terminals QQ316, radio front-end circuitry QQ318, and RF transceiver circuitry QQ312 (not shown) as part of a radio unit, and communication interface QQ306 communicates with baseband processing circuitry QQ314, which is part of a digital unit (not shown).

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

[0493] Antenna QQ310, communication interface QQ306, and / or processing circuitry QQ302 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 QQ310, communication interface QQ306, and / or processing circuitry QQ302 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.

[0494] The power supply QQ308 provides power to the various components of the network node QQ300 in a manner suitable for each component (e.g., at the voltage and current levels required by each individual component). The power supply QQ308 may also include or be coupled to power management circuitry to provide power to the components of the network node QQ300 for performing the functions described herein. For example, the network node QQ300 may be connected to an external power source (e.g., the mains or a power outlet) via input circuitry or an interface such as a cable, thereby supplying power to the power circuitry of the power supply QQ308. As a further example, the power supply QQ308 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 in the event of an external power failure.

[0495] Implementations of the network node QQ300 may include, except Figure 12Additional components beyond those shown may be used to provide certain aspects of the network node's functionality, including any of the functions described herein and / or any functionality required to support the topics described herein. For example, the network node QQ300 may include a user interface device to allow information to be input into and output from the network node QQ300. This can allow users to perform diagnostic, maintenance, repair, and other management functions on the network node QQ300.

[0496] While the computing devices (e.g., UEs and network nodes) described herein may include the hardware component combinations shown, other embodiments may include computing devices with different component combinations. It will be understood that these computing devices may include any suitable hardware and / or software combination 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, which may process information by, for example, converting acquired information into other information, comparing the acquired or converted information with information stored in the network node, and / or performing one or more operations based on the acquired or converted information, and making determinations based on the results of said processing.

[0497] Furthermore, while components are depicted as single boxes situated within larger boxes or nested within multiple boxes, in practice, computing devices may include multiple distinct physical components constituting a single illustrated component, and functionality may be partitioned among the 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 functionality of any such component may be implemented in software or firmware, while the computationally intensive functionality may be implemented in hardware.

[0498] In some embodiments, some or all of the functionality described herein may be provided by processing circuitry that executes instructions stored on 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 functionality may be provided by processing circuitry without executing instructions stored on, for example, a separate or discrete device-readable storage medium in a hardwired manner. In any of these particular embodiments, the processing circuitry may be configured to perform the described functionality regardless of whether instructions stored on a non-transitory computer-readable storage medium are executed. The benefits provided by such functionality are not limited to processing circuitry alone or to other components of a computing device, but can generally be enjoyed by the entire computing device and / or end users and wireless networks.

[0499] Furthermore, it should be recognized that "network nodes" can be implemented in virtualized processing environments, such as cloud data centers. For example, in a CU / DU separation environment, at least the CU can be implemented using virtualized processing, memory, and interface resources in the data center computing environment.

Claims

1. A method performed by a user equipment (UE) configured to operate with respect to a telecommunications network, the method comprising: When the UE is connected to the telecommunications network, it receives information from the telecommunications network indicating a lower-layer triggered mobility LTM configuration for the UE's LTM-based mobility. Receive additional information from the telecommunications network, the additional information indicating that the UE is about to suspend the connection with the telecommunications network; as well as Release the LTM configuration.

2. The method according to claim 1, wherein, The additional information is a release message.

3. The method according to claim 2, wherein, The release message includes an indication that the LTM configuration should be released, and the step of the UE releasing the LTM configuration is performed in response to the indication.

4. The method according to claim 3, wherein, The instruction is implicit.

5. The method according to claim 3, wherein, The instruction is explicit.

6. The method according to any one of claims 1-5, wherein, The method further includes: The UE receives a recovery message from the telecommunications network, wherein the recovery message indicates a new LTM configuration, which the UE will use for LTM-related mobility with respect to the recovered connection; and Based on the new LTM configuration, begin LTM-related operations for the restored connection.

7. The method according to any one of claims 1-6, wherein, The method further includes the UE: Enter the inactive state associated with the suspended connection and release the LTM configuration; When in the inactive state, a request is sent to restore the connection; Receive a response to the request, restore the connection, and indicate a new LTM configuration to be used by the UE for LTM-related mobility; as well as Enter the active state and use the new LTM configuration in the active state.

8. The method according to any one of claims 1-6, wherein, The telecommunications network includes the 3GPP (Third Generation Partnership Project) wireless communication network.

9. The method according to claim 8, wherein, The 3GPP wireless communication network includes the fifth-generation 5G cellular network.

10. The method according to any one of claims 1-9, wherein, The LTM configuration includes a first set of one or more LTM-related configurations.

11. The method according to any one of claims 1-10, wherein, The LTM configuration includes any one or more of the following: One or more lower-level channel state information (CSI) measurement configurations for LTM; One or more uplink UL pre-synchronization configurations; One or more downlink DL pre-synchronization configurations; One or more LTM candidate cells are configured; One or more complete LTM candidate configurations are generated when the UE is configured with LTM; or LTM Reference Configuration.

12. A method performed by a network node in a telecommunications network, the method comprising: Send a lower-layer triggered mobility LTM configuration to a user equipment (UE) connected to the telecommunications network; as well as Additional information is sent to the UE, indicating that the UE is about to suspend the connection with the telecommunications network, thereby releasing the LTM configuration of the UE.

13. The method according to claim 12, wherein, Sending the additional information includes sending a release message to the UE, the release message indicating that the UE should release the LTM configuration.

14. The method according to claim 13, wherein, The instruction is an explicit instruction.

15. The method according to claim 13, wherein, The instruction is an implicit instruction.

16. The method according to claim 13, wherein, The release message is an RRC release message, and the indication is an information element in the RRC release message.

17. The method according to any one of claims 10-16, wherein, The method further includes: the network node then sends a recovery message to the UE for restoring the connection, and the recovery message includes a new LTM configuration that the UE will use for LTM-related mobility with respect to the restored connection.

18. A user equipment (UE) configured to operate in a telecommunications network, the UE comprising: A communication interface configured to communicate with network nodes of the telecommunications network; as well as Processing circuit, the processing circuit being configured to: When the UE is connected to the telecommunications network, it receives information from the telecommunications network via the communication interface, the information indicating a lower-layer triggered mobility LTM configuration for the UE's LTM-based mobility; Additional information is received from the telecommunications network via the communication interface, the additional information indicating that the UE is about to suspend the connection with the telecommunications network; as well as Release the LTM configuration.

19. The UE according to claim 18, wherein, The processing circuit is configured to control the UE to perform the method according to any one of claims 2-11.

20. A network node configured to operate in a telecommunications network, the network node comprising: A communication interface configured to communicate directly or indirectly with a user equipment (UE), the UE having a connection to the telecommunications network; as well as Processing circuit, the processing circuit being configured to: Send the lower-layer triggered mobility LTM configuration to the UE via the communication interface; as well as Additional information is sent to the UE via the communication interface, indicating that the UE is about to suspend the connection with the telecommunications network, thereby releasing the LTM configuration of the UE.

21. The network node according to claim 20, wherein, The processing circuit is configured to control the network node to perform the method according to any one of claims 13-17.

Images