Methods and apparatuses for managing ltm related configurations for resumption of suspended connections

Abstract

Disclosed methods and apparatuses provide for management of L1 / L2 Triggered Mobility (LTM) configuration information between a user equipment (UE) and a telecommunications network, particularly in cases involving suspension of a connection between the UE and the telecommunications network. According to techniques disclosed herein, LTM configuration used by the network and the UE remains "aligned" with respect to suspension of a connected UE and subsequent resumption of the connection.

Description

[0001] METHODS AND APPARATUSES FOR MANAGING LTM RELATED CONFIGURATIONS FOR RESUMPTION OF SUSPENDED CONNECTIONS

[0002] TECHNICAL FIELD

[0003] Disclosed methods and apparatuses relate to wireless communication networks and resumption of suspended connections between such networks and User Equipments (UEs) and corresponding management of Layer 1 / Layer 2 Triggered Mobility (LTM) related configurations.

[0004] BACKGROUND

[0005] Until Release 17 of the Third Generation Partnership Project (3GPP) Technical Specifications (TSs), serving cell changes for a User Equipment (UE) were triggered based on Layer 3 (L3) measurements and carried out via 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 the lower layers, e.g., Medium Access Control (MAC) and / or Physical (PHY) layers. Refer, for example, to Section 4.4 of 3GPP TS 38.300 V17.5.0, illustrating layers of the radio protocol architecture used in New Radio (NR) Fifth Generation (5G) networks.

[0006] Release 17 introduced L1 / L2 triggered mobility, also referred to as “Lower-layer Triggered Mobility” or LTM. LTM offers a mechanism for retaining the upper-layer configuration and minimizing changes to the lower-layer configuration. An example controlplane protocol stack includes the RRC layer, with a PDCP layer below it, a RLC layer below the PDCP layer, a MAC layer below the RLC layer, and a PHY layer below the MAC layer. In this context, the PHY layer is Layer 1 (LI), while Layer 2 (L2) includes the MAC, RLC, and PDCP layers, and Layer 3 (L3) includes the RRC layer.

[0007] A basic principle with LTM is that the UE is configured by the network with an RRC configuration per LTM candidate cell, sometimes also known as a LTM candidate cell configuration. Such a LTM candidate cell configuration may be in the form of an RRCReconfiguration message or one or more Information Elements (IES), or fields or parameters, such as CellGroupConfig.

[0008] The UE performs measurements on these LTM candidate cells and transmits corresponding measurement reports to the network. The network then triggers the execution of a LTM cell switch procedure in the UE by transmitting a lower layer signal to the UE, such as a MAC Control Element (CE) or Downlink Control Information (DCI). This lower-layer signal may be referred to as a LTM cell switch command, and the UE responds by connecting to the target cell and switching to a corresponding LTM candidate cell configuration. Certain challenge(s) regarding LTM exist. Consider, for example, so called “suspend” and “resume” procedures, which involve releasing a UE from an active, connected state to an inactive state, followed by a subsequent attempt by the UE 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, RRCJNACTIVE, and RRC_CONNECTED.

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

[0010] Consequently, LTM related configuration mismatches between the context information held in the network for the UE and that held in the UE arise, with such mismatches leading to reconfiguration failures when the UE tries to resume its connection. Such failures trigger reestablishment procedures or a transition to RRC_IDLE, which results in increased network signaling and UE power consumption. In addition, if the UE decides to release its LTM related configurations while the network keeps them, holding such information in the network during suspended operation of the UE would have been a waste of network resources.

[0011] SUMMARY

[0012] Disclosed methods and apparatuses provide for management of LI / L2 Triggered Mobility (LTM) configuration information between a user equipment (UE) and a telecommunications network, particularly in cases involving suspension of a connection between the UE and the telecommunications network. According to techniques disclosed herein, LTM configuration used by the network and the UE remains “aligned” with respect to suspension of a connected UE and subsequent resumption of the connection.

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

[0014] Another embodiment comprises a method performed by a network node in a telecommunications network. The method includes the network node transmitting a LTM configuration to a UE that is connected to the telecommunications network. Further, the method includes the network node sending additional information to the UE, the additional information indicating that the UE is to suspend the connection to the telecommunications network, whereby the UE releases the LTM configuration.

[0015] A further embodiment comprises a UE. The UE includes a communication interface configured for communicating with a network node of a telecommunications network, and further includes processing circuitry. The processing circuitry is configured to receive, via the communication interface, information from the telecommunications network while the UE is connected to the telecommunications network. The information indicates a LTM configuration, for use in LTM-based mobility of the UE. Further, the processing circuitry is configured to receive, via the communication interface, additional information indicating that the UE is to suspend the connection to the telecommunications network, and the processing circuitry is configured to release the LTM configuration.

[0016] Yet another embodiment comprises a network node configured for operation in a telecommunications network. The network node includes a communication interface configured for communicating directly or indirectly with a UE having a connection to the telecommunications network. Further, the network node includes processing circuitry that is configured to transmit, via the communication interface, a LTM configuration to the UE for use in LTM-based mobility of the UE. Still further, the processing circuitry is configured to transmit, via the communication interface, additional information to the UE, indicating that the UE is to suspend the connection to the telecommunications network, whereby the UE releases the LTM configuration.

[0017] Of course, the present invention is not limited to the above features and advantages. Indeed, those skilled in the art will recognize additional features and advantages upon reading the following detailed description, and upon viewing the accompanying drawings.

[0018] BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 is a block diagram of a telecommunications network and an associated user equipment (UE), according to an example embodiment. Figure 2 is a signal flow diagram illustrating signaling and corresponding operations for release of a first set of one or more LI / L2 Triggered Mobility (LTM) related configurations for a UE in association with suspension of the UE, according to an example embodiment.

[0020] Figure 3 is a signal flow diagram illustrating signaling and corresponding operations for release of a first set of one or more LTM related configurations for a UE in association with resumption of a suspended connection, according to an example embodiment.

[0021] Figure 4 is a signal flow diagram illustrating signaling and corresponding operations for providing a second set of one or more LTM related configurations for a UE in association with resumption of a suspended connection, according to an example embodiment.

[0022] Figure 5 is a signal flow diagram illustrating signaling and corresponding operations for release of a first set of one or more LTM related configurations for a UE at one or more candidate Distributed Units (DUs) in association with resumption of a suspended connection, according to an example embodiment.

[0023] Figure 6 is a signal flow diagram illustrating signaling and corresponding operations for restoration of a first set of one or more LTM related configurations for a UE at one or more candidate Distributed Units (DUs) in association with resumption of a suspended connection, according to an example embodiment.

[0024] Figure 7 is a signal flow diagram illustrating signaling and corresponding operations for releasing a first set of one or more LTM related configurations for a UE at one or more candidate Distributed Units (DUs) in association with resumption of a suspended connection, according to an example embodiment.

[0025] Figure 8 is a logic flow diagram of an example method of operation at a UE, according to an example embodiment.

[0026] Figure 9 is a logic flow diagram of an example method of operation at a network node, according to an example embodiment.

[0027] Figure 10 is a block diagram of a telecommunication system, according to an example embodiment.

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

[0029] Figure 12 is a block diagram of a network node, according to an example embodiment.

[0030] DETAILED DESCRIPTION

[0031] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art. The text refers to the term “LTM” to denote L1 / L2 triggered mobility and the term is interchangeable with “L1 / L2 based inter-cell mobility” as used in the Work Item Description in 3GPP, and the terms L1 / L2 mobility, Ll-mobility, LI based mobility, Ll / L2-centric inter-cell mobility, and L1 / L2 inter-cell mobility.

[0032] The basic principle of LTM is that a User Equipment (UE) receives lower layer signaling from the network, such as a MAC Control Element (MAC CE), indicating to the UE a change (or switch or activation) of its serving cell. The change may be from source Primary Cell (PCell) to a target PCell. A PCell change may also lead to a change in the Secondary Cell(s) (SCells) for the same cell group. For example, the LTM switch command may trigger the UE to change to another cell group configuration of the same type, e.g., another Master Cell Group (MCG) configuration.

[0033] Before the UE receives the LTM cell switch command, the UE is configured by the involved wireless communication network with one or more LTM candidate cell configurations. For example, a gNB or other network node transmits a Radio Resource Configuration (RRC) Reconfiguration message that indicates at least one LTM candidate cell configuration. A LTM candidate cell configuration includes, for example, parameters in the Information Element (IE) CellGroupConfig per candidate cell and / or an embedded RRC Reconfiguration per LTM candidate cell.

[0034] The term LTM cell switch procedure refers to the process of a UE switching or changing 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 neighbor cell. In the context of this disclosure, a UE switching to a LTM candidate cell configuration comprises the UE considering that an LTM candidate cell becomes its new Special cell (SpCell), e.g. a new PCell, in case of LTM being configured for a MCG and / or PSCell in case of LTM being configured for a Secondary Cell Group (SCG), or changing its SpCell from the current PCell to an LTM candidate cell. Broadly, when referring to a change of cells, it should be understood that a change may involve cell group configurations, which may include a change in SpCell, e.g., a change of PCell or a change of PSCell, along with a change in SCells of the cell group. SCell changes include any one or more of addition, modification, or release of one or more SCells.

[0035] A LTM cell switch procedure may be triggered in the UE by reception of a LTM cell switch command, or alternatively, triggered by some other event, such as a satisfaction of a triggering condition used for conditional configuration, such as a conditional handover being fulfilled as a result of recovery from radio link failure or handover failure.

[0036] In this disclosure a “LTM candidate cell” is a cell that a UE can move to in a LTM cell switch procedure, upon reception of a LTM cell switch command. The UE is provided with a corresponding LTE candidate cell configuration. LTE candidate cells may also be referred to simply as candidate cell(s), candidates, mobility candidates, non-serving cells, additional cells, target candidate cell, target candidate, etc.

[0037] A UE performs measurements on LTM candidate cells, such as Channel State Information (CSI) measurements, and reports the measurements to the network. The network uses the reported measurements to make an educated decision on which beam, e.g., Transmission Configuration Indicator (TCI), and / or cell, to which the UE is to be switched. A LTM candidate cell may be a target PCell or PSCell, or an SCell of a cell group (e.g., a MCG SCell). In the case of a LTM fast recovery, when a failure is detected, the UE selects a cell and when the cell is a LTM candidate cell the UE does not have to perform re-establishment, but instead performs a LTM cell switch towards the selected LTM candidate cell, e.g. by applying the LTM candidate cell configuration associated with the selected LTM candidate cell.

[0038] This disclosure refers to a UE having received at least one LTM candidate cell configuration, which may be an RRC configuration, such as encapsulated in an RRC Reconfiguration message that the UE receives when being configured with LTM. A LTM candidate cell configuration comprises the configuration which the UE needs to start operation when it performs a LTM cell switch procedure to that LTM candidate cell.

[0039] The LTM candidate cell configuration comprises parameters of a serving cell, or multiple serving cells, such as a cell group, and includes comprising one or more of the groups of parameters. Example LTM candidate cell configuration parameters include RRC Reconfiguration message IES, such as CellGroupConfig or a SpCellConfig, or SCellConfig in the case of a SCell. Particularly, a LTM candidate cell configuration in one example comprises one or more of: i) the PCell configuration and one or more SCell configuration(s) of a MCG; or ii) the PSCell configuration and one or more SCell configuration(s) of a SCG. The terms LTM candidate configuration, LTM configuration, LTM candidate target cell configuration, and LTM target candidate cell configuration are all interchangeable with “LTM candidate cell configuration”.

[0040] Each LTM candidate cell configuration is associated with an identifier, and the signaling sent from the network to the UE uses such identifiers to refer to specific LTM candidate cell configuration. For example, the UE receives a LTM candidate cell configuration having a corresponding identifier and, later, when the UE receives a LTM cell switch command, the network signals the identifier of the LTM candidate cell. Such an identifier is sometimes referred to as a LTM candidate cell configuration identity or LTM candidate configuration index.

[0041] The actual LTM candidate cell configuration and its exact content and / or structure of this IE and / or embedded message may be called an RRC model for the candidate configuration, or simply RRC model. A LTM candidate cell configuration comprises the configuration the UE needs to operate accordingly when it performs or executes L1 / L2 based inter-cell mobility to the corresponding LTM candidate cell.

[0042] A UE may be configured with multiple LTM candidate cell configurations. Also, LTM candidate cell configurations signaled to the UE may be indicated using “delta signaling”, which refers to signaling changes to be applied on top of a reference configuration. With delta signaling, the actual LTM candidate cell configuration comprises the default configuration as modified according to the delta signaling. The reference configuration may be signaled separately by the network to the UE.

[0043] The term “beam” may correspond to a spatial direction in which a signal is transmitted (e.g. by a network node) or received (e.g. by the UE), or a spatial filter applied to a signal which is transmitted or received. Thus, transmitting signals different beams could correspond to transmitting signals in different spatial directions. When the text refers to a “beam which is selected” it may refer to a beam index and / or a Reference Signal (RS) index or identifier, such as a Synchronization Signal block (SSB) index, or a CSLRS resource identifier. Thus, selecting a beam may correspond to selecting an SSB, associated to an SSB index. Or, selecting a beam may correspond to selecting a CSLRS, associated to a CSLRS resource identifier.

[0044] Example UE-related embodiments for the suspend operation include a first method at a UE for deleting LTM related configurations. The example method includes the UE: receiving a first set of one or more LTM related configuration(s), e.g., while connected to the network in an active state; receiving a message from the network to suspend 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 the message from the network to suspend the connection, or (ii) during an initiation of a resume procedure.

[0045] In a particular example, a UE connected to the network receives information indicating a LTM configuration, for use in LTM-related mobility of the UE. Subsequently, the UE receives additional information indicating that the UE is to suspend the connection with the network and the UE releases the LTM configuration. In at least one such embodiment, the additional information, which may be a release message or may be sent in association with a release message, includes an implicit or an explicit indication to the UE to release the LTM configuration.

[0046] Here, “releasing” refers to deleting, discarding, or otherwise removing the LTM configuration. Correspondingly, the LTM configuration received and then subsequently released by the UE may comprise a first set of one or more LTM related configurations including, for example, any one or more of: (a) Lower layer (CSI) measurement configuration(s) for LTM; (b) Time Alignment (TA) acquisition (also called UL pre-sync configuration); (c) TCI state configuration(s) for pre-sync (also called DL pre-sync configuration); (d) LTM Reference configuration(s); (e) LTM Candidate Cell Configuration(s); or (f) Complete LTM candidate configuration(s) generated when the UE is configured with LTM.

[0047] The above example method of UE operation in at least one embodiment further includes the UE initiating a resume procedure, transmitting a RRC Resume Request message, and receiving a RRC Resume message including a new LTM configuration, e.g., a second set of one or more LTM related configuration(s). Thus, the method in one or more embodiments comprises the UE using new or updated LTM related configuration information when resuming its connection to the network, rather than earlier LTM configuration information released by the UE in association with suspension of the connection.

[0048] The second set of one or more LTM related configuration(s) may be the same or different than the first set of one or more LTM related parameters. Correspondingly 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 configuration(s). In at least one embodiment or in at least one operational 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 for the Master Cell Group (MCG) or the Secondary Cell Group (SCG).

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

[0050] In at least one embodiment, the method further includes initiating a resume procedure, transmitting a RRC Resume Request message and receiving a RRC Resume message including a first indication (e.g., a restoreLTM field) and, in response to the first indication, restoring the first set of stored LTM related configuration(s). In at least one embodiment, the method includes initiating a resume procedure, transmitting a RRC Resume Request message, receiving a RRC Resume message and upon determining that a first indication is absent, deleting the first set of LTM related configuration(s).

[0051] In at least one embodiment, the RRC Resume message further comprises a second set of one or more related LTM configuration(s), which is applied by the UE as part of the RRC resume procedure. The second set of one or more related LTM configuration(s) may be the same or different than the first set of one or more LTM related parameters. In one or more embodiments, the second set of one or more related LTM configuration(s) adds to, modifies, or releases the first set of LTM related configuration(s).

[0052] In at least one embodiment or in at least one operational scenario, the UE is in MR-DC or NR-DC and the first set of one or more LTM related configurations is for the MCG or the SCG. A RRC Resume message may include, as an example of the aforementioned first indication, a restoreSCG indication.

[0053] On the network side, one embodiment disclosed herein comprises a first method of operation by a network node of a wireless communications network. In at least one particular example, the network node is a serving Central Unit (CU) for a UE. For example CU details, see 3GPP TS 38.470 V17.5.0, describing the “Fl” interface for connecting a gNB-CU with a gNB- DU, where “DU” denotes “Distributed Unit”. Also, see 3GPP TS 38.300 V17.5.0 for gNB details and 3GPP TS 38.401 V17.5.0, for additional CU and DU details.

[0054] With the CU / DU arrangement, 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 on the air interface. In one or more embodiments, a serving CU performs a method that includes: transmitting to the UE a first set of one or more LTM related configuration(s); transmitting a message to the UE network to suspend the connection and to transition the UE to an inactive state (e.g., to move the UE from the RRC Connected state to the 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. Example defined events triggering the deleting of the first set of one or more LTM related configurations at the CU include: transmitting the message to the UE to transition the UE to the inactive state, or during an initiation of a resume procedure.

[0055] In one or more example embodiments, the network sends a LTM configuration to a UE having a connection with the network, for use in LTM-related mobility by the UE. Subsequently, the network sends additional information indicating that the connection is to be suspended, whereby the UE releases the LTM configuration. In at least one such embodiment, the additional information comprises a release message or is sent in association with a release message. Further, in at least one such embodiment, the additional information includes an implicit or explicit indication to prompt the UE to release the LTM configuration.

[0056] Such operations are performed by a serving node in the network for example, such as a serving CU. The serving node in at least one such embodiment further performs releasing, or initiates releasing, of the LTM configuration in the network, e.g., removal of the LTM information from UE context information held in the network for the UE. As noted, the LTM configuration may comprise a first set of one or more LTM related configurations and “releasing” the LTM configuration means deleting or otherwise removing the LTM configuration. Releasing the first set of one or more LTM related configurations comprises, for example, the serving CU transmitting a release message to at least one candidate DU for releasing the first set of LTM related configuration(s) at the at least one candidate DU. Here, the first set of LTM related configuration(s) is associated with a LTM candidate cell of the at least one candidate DU.

[0057] With respect to a resumption of the connection of the UE with the same serving CU, the method of operation by the serving CU includes, in one or more embodiments, the serving CU receiving from the UE an RRC Resume Request message and the serving CU transmitting an RRC Resume message in response. Here, the RRC Resume message includes a second set of one or more LTM related configuration(s), wherein the second set of one or more LTM related configuration(s) may be the same or different than the deleted first set of one or more LTM related parameters.

[0058] Another embodiment comprises a further or second method of operation by a network node, which is a serving CU in a specific example. The method includes the serving CU transmitting to the UE a first set of one or more LTM related configuration(s) and transmitting a message to the UE, to suspend the connection with the UE and to transition the UE to inactive state. The method further includes the serving CU storing the first set of one or more LTM related configurations in response to transmitting the message to the UE to transition the UE to Inactive state. Still further, the method includes the serving CU receiving from the UE a RRC Resume Request message and, correspondingly, transmitting a RRC Resume message for the UE.

[0059] If it is desired to have the UE resume the connection using the first set of one or more LTM related configurations sent to it before the suspension, the serving CU includes, for example, a first indication in the RRC Resume message, indicating that the UE should restore for use the first set of one or more LTE related configurations. An example indication is inclusion of a restoreLTM field in the RRC Resume message, which indicates to the UE that the UE shall restore the first set of stored LTM related configuration(s). On the other hand, omitting the indication from the RRC Resume message indicates to the UE that the UE should delete the previously stored first set of one or more LTM configurations — i.e., absence of the indication in the RRC Resume message serves as an indication to the UE that the UE should not use — should delete — the first set of one or more LTM related configurations the UE stored before or in conjunction with the prior suspension of its connection to the network. In one or more embodiments, the serving CU prompts the UE to delete the stored first set of one or more LTM related parameters by omitting from the Resume message an indication that they should be used in resuming the connection of the UE, and / or by including in the UE a second set of one or more LTM related configurations. As a particular example, omission of the indication tells the UE that it should not restore the stored first set of one or more LTM related parameters, and instead should use a second set of one or more LTM related parameters for resuming the connection, where the second set of one or more LTM related parameters is included in the RRC Resume message sent from the serving CU to the UE.

[0060] The second set may be the same or different than the first set. As a particular example, the second set may replace the first set. As a further example, the second set may modify the first set, e.g., the second set includes one or more values that replace or adjust one or more values in the first set. As a still further example, the second set supplements the first set.

[0061] In association with the serving CU releasing the UE to the inactive state — suspending the connection of the UE — the serving CU in one or more embodiments stores the first set of one or more LTM related configurations, and transmits a message to a Candidate DU associated with the first set of one or more LTM related configuration(s), to indicate that the first set of one or more LTM related configurations is suspended.

[0062] Consider another aspect of example operation at a CU. Assume that the CU provides a first set of one or more LTM related configurations to a UE being served by the CU. For example, the CU provides the first set of one or more LTM related configurations to the UE while the UE is in an active state and has a connection to the network via the serving CU. As a particular example, the CU provides the first set of one or more LTM related configurations to the UE in a RRC Connection Release message, and it stores the first set of one or more LTM related configurations as “suspended” configurations for the now suspended UE.

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

[0064] As one example technical advantage flowing from the disclosed techniques, there is no mismatch between a UE and a network when the UE transitions from RRC_INACTIVE to RRC_CONNECTED, for cases where the UE was configured with LTM related configuration(s) before being transitioned to RRC_INACTIVE. Preventing such mismatches prevents a reconfiguration failure every time a resume procedure is attempted by the UE. Such prevention avoids the need for triggering a re-establishment procedure or a transition to RRC _IDLE, and allows for successful resumption of the connection, thereby reducing network signaling and UE power consumption. As a further advantage, the disclosed techniques eliminate LTM configuration mismatches between, for example, a serving CU and one or more candidate DUs.

[0065] Figure 1 illustrates a wireless communication network 10 according to an example embodiment, wherein one or more nodes of the network 10 and the example User Equipment (UE) 12 are configured for management of LTM related configurations with respect to suspension and resumption of connections. Here, “connection” refers to the communication link between the UE 12 and the network 10, wherein the network 10 and the UE 12 are operative to suspend and resume the connection. For example, the UE 12 operates in a RRC_ACTIVE state, which includes having an active connection with the network 10, and is then released to a RRC_IN ACTIVE state in which the connection is suspended. The UE 12 has one or more LTM related configurations stored in it at the time of suspension, as does its serving network node in the network 10.

[0066] In at least one embodiment, the UE 12 releases the one or more LTM related configurations in association with suspension of the connection, so that the UE does not attempt to reuse one or more LTM related configurations upon later resumption of the connection. In one or more other embodiments, the UE retains the one or more LTM related configurations and one or more of the techniques disclosed herein provide mechanisms for controlling whether the retained LTM configuration(s) are reused or released in association with resumption of the connection, to prevent a mismatch between the network 10 and the UE 12.

[0067] The UE 12 is a wireless terminal, such as a cellular smartphone, and may be sometimes connected to a first network node 14 over a wireless interface 16 and may, such as a result of a mobility procedure, subsequently be connected to a second network node 18 via a wireless interface 20.

[0068] The first network node 14, controls a first cell 22 (sometimes called serving cell, Special Cell (SpCell), or Primary Cell, PCell. The second network node 18 controls a second cell 24, which, for purposes of this example, is configured as a LTM candidate cell or target cell for the UE 12.

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

[0070] The first network node 14 and the second network node 18 are connected to a third network node 26, sometimes also referred to as serving network node. The third network node 26 may, e.g. in case of a distributed CU / DU RAN architecture, be a central unit, CU, sometimes referred to as the serving CU, known as either a gNB-CU, CU, gNB-CU-CP or gNB-CU-UP, or a core network node such as a User Plane Function (UPF) or an Access and Mobility management Function (AMF). Thus, in an example scenario, the first network node 14 is a first DU, the second network node 18 is a second DU, and the third network node 26 is a CU commonly associated with the first and second DUs 14 and 18.

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

[0072] Further, the first cell 22 may in these cases belong to the Master Cell Group (MCG) and a 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 serving cell, Special Cell (SpCell), or Primary SCG Cell, PSCell. In this example context, the third cell 32 is a LTM candidate cell or target cell for the UE 12. To support such connectivity arrangements, the fourth network node 30 is connected with the third network node 26 over an interface 34 which may be an Xn type of interface. The first network node 14 and the second network node 18 have like interfaces 36 and 38, communicatively coupling them to the third network node 26.

[0073] With respect to LTM related configuration(s), techniques disclosed herein involve respective or complementary methods of operation by a UE and a network node, for so-called LTM related configuration(s). Such method include various operations or steps, including storing, removing, or deleting sets of one or more LTM related configurations.

[0074] As an example of a LTM related configuration, also more simply referred to as a LTM configuration, the network 10 provides the UE 12 with one or more lower layer measurement configurations to be used or adopted by the UE 12 for performing measurements on respective cells identified as LTM candidate cells for the UE 12. Example measurements include measurements made by the UE 12 on Synchronization Signal Bursts (SSBs) transmitted in a LTM candidate cell and / or Channel State Information Reference Signal (CSI-RS) transmissions in a LTM candidate cell. Reporting of these measurements by the UE 12 to the network 10 assists the network 10 in performing LTM switch decisions. Examples of reported measurements include Synchronization Signal Reference Signal Received Power (SS-RSRP), Ll-RSRP, SS Reference Signal Received Quality (RSRQ) or Ll-RSRQ, SS Signal-to-interference-and-noise ratio (SINR), or Ll-SINR.

[0075] In one option, the lower layer measurement configuration comprises one or more reporting configuration(s) included in a serving cell configuration (e.g. ServingCellConfig, as part of a CSI measurement configuration, or LTM measurement configuration) of a serving cell (e.g. PCell or an MCG SCell) in which lower layer measurement reports for LTM are to be reported. The reporting configuration(s) may include one or more parameters indicating how the UE 12 is meant to perform the reporting e.g. periodic, aperiodic, semi-persistently, etc. An instance of a reporting configuration may be defined in the IE CSI-ReportConfig, or a new IE referred to herein as LTM-CSLReportConfig.

[0076] When the UE 12 removes lower layer measurement configuration(s), the UE 12 also removes the LTM related reporting configuration(s) from each serving cell configuration (e.g. CSI measurement configuration on each SCell configuration and CSI measurement configuration on the SpCell configuration)

[0077] In one option, a reporting configuration indicates which LTM candidate cell(s) are to be reported according to that reporting configuration.

[0078] In one option, the lower layer measurement configuration comprises one or more resource configuration(s) e.g. indicating what was to be measured by the UE 12, such as one or more LTM candidate cell(s) and / or one or more RSs of an LTM candidate cell (e.g. SSB(s) and / or CSI-RS resource(s)).

[0079] In one sub-option, a resource configuration is included within each LTM candidate cell configuration, e.g., in the lower layer measurement configuration.

[0080] In another sub-option, a resource configuration is included within the overall LTM candidate cell which the UE receives when the UE is configured with LTM e.g. an instance of the IE LTM-CSI-ResourceConfig, included within the IE LTM-Config. In such cases, a resource configuration may refer to one or more LTM candidate cells, e.g., by referring to one or more LTM candidate identifier (s).

[0081] In one option, the lower layer measurement configuration further includes one or more of: indication of the frequency of the SS / PBCH block associated to an LTM-Candidate; subcarrier spacing of SSB; periodicity of the SS / PBCH block given in subframe number; indication of the time domain positions of the transmitted SS-blocks in a half frame with SS / PBCH blocks; average EPRE of the resources elements that carry secondary synchronization signals in dBm that the NW used for SSB transmission of the LTM-Candidate; Physical Cell Identifier (PCI) of a LTM-Candidate; list of LTM-CSLResourceConfig(s); list of LTM- CSIResourceConfig to be released; a group of one or more LTM-CSI-SSB-ResourceSets; a SS / PBCH block resource set from one or more candidate cells; identification of an SS / PBCH block resource set; indication of SS / PBCH block resources from one or more candidate cells; or indication of the PCIs of the SSBs in the LTM-CSI-SSB-Resourcelist.

[0082] As noted, one advantage of the techniques disclosed herein is the prevention of mismatches between a UE 12 and a network 10 with respect to LTM related configurations, particularly in the context of resuming a suspended connection. That is, the UE 12 and the network 10 are aligned in terms of whether the UE 12 needs to perform lower layer measurements or not, with further alignment regarding the LTM configurations to be used with respect to such measurements. Mismatch prevention saves UE power, and prevents UL interference on the network side, which may degrade performance of the UE 12 and other UEs operating in the network 10. For example, a mismatch in LTM related configurations may result in the UE 12 unnecessarily performing lower layer measurements after resumption of its previously suspended connection, thus wasting UE power.

[0083] In addition to power wastage, the UE 12 may try to report lower layer measurements over an UL channel of a serving cell after resumption of its connection, while the network 10 is not prepared to receive such measurements. That circumstance may lead to UL interference as mentioned above and corresponding performance degradation. Conversely, a mismatch between the LTM related configuration(s) stored at the UE 12 and those expected by the network 10 may result in the UE 12 failing to perform lower layer measurements that are expected by the network 10. Such a situation results in wasted UL resources allocated by the network 10 for reporting by the UE 12.

[0084] Several example options regarding Time Alignment (TA) acquisition configurations, also referred to as UL pre-sync configurations. A TA acquisition configuration provides a UE 12 with the necessary information needed for transmitting an UL message to a LTM candidate cell. A random access preamble on a Physical Random Access CHannel (PRACH) time / frequency resource stands as one example of such an UL message. In other words, the network 10 calculates a TA value for use by the UE 12 with respect to a LTM candidate cell, such that the UE 12 will be in UL synchronization with the candidate LTM candidate cell, and provides the TA value to the UE 12 in a corresponding TA acquisition configuration.

[0085] 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-sync configuration) provided to the UE 12 comprises one or more random access related parameters such as: one or more indication(s) of one or more preamble (e.g. per beam(s) and / or SSB(s)), e.g. random access preamble indices; one or more indication(s) of random access occasions with the associated SSB indices configured for each candidate cell; or one or more parameters associated with power ramping for preamble transmission / re-transmission.

[0086] In one option, the TA acquisition configuration, which may be conveyed as an IE EarlyUL-SyncConfig, is included within a configuration per LTM candidate cell. For example, each LTM candidate cell is represented in an IE LTM-Candidate provided to the UE 12, with the IE LTM-Candidate conveying an IE EarlyUL-SyncConfig, which indicates the TA value to be used by the UE 12 for UL synchronization with the LTM candidate cell.

[0087] These aspects of the broader techniques disclosed herein have the advantage of ensuring that the UE 12 and the network 10 are aligned on whether the UE is configured for TA acquisition or not. A mismatch in this case could be the UE having random access related configurations for TA acquisition and possibly getting prepared in case the network 10 sends a Physical Downlink Dedicated Channel (PDDCH) order triggering a preamble transmission, but, due to a mismatch, the network 10 does not send the PDDCH order, based on a mistaken understanding by the network 10 that the UE 12 does not have the corresponding TA acquisition configuration stored.

[0088] Thus, an aligned state or understanding of TA acquisition configurations between the network 10 and the UE 12 prevents wasted UE actions. Further prevented is a circumstance where the network 10 sends a PDDCH order to trigger preamble transmission by the UE 12 for a LTM candidate cell for which the UE lacks a corresponding TA acquisition configuration. Receiving a PDDCH order intended for a given RRC configuration which the UE 12 does not have available causes, for example, a RRC Reconfiguration failure or other error.

[0089] Regarding Downlink (DL) synchronization, LTM relies on the use of TCI state configuration(s) for DL pre-sync, and such configuration are also referred to as DL pre-sync configurations. A TCI configuration for DL pre-sync comprises the necessary configuration(s) for the UE 12 to obtain DL pre-sync with a LTM candidate cell. Example configuration information includes one or more indications of reference signals, e.g., SSB indexes or CSI-RS resource identifiers and associated configuration(s).

[0090] In one option, TCI configurations for DL pre-sync are received by the UE 12 per LTM candidate cell. For example, the IE LTM-Candidate sent to the UE 12 for a LTM candidate cell includes the corresponding TCI configuration for that LTM candidate cell. In an example embodiment, the TCI configuration for a LTM candidate cell includes one or more TCI state configuration(s), e.g., LTM-CandidateTCI-States-ToAddModList-rl8 of IE(s) CandidateTCI- StatesT o AddModList-r 18.

[0091] In one option, a TCI configuration for DL pre-sync comprises one or more of: a list of TCI states indicating a transmission configuration which includes Quasi-Co-Location (QCL)- relationships between the DL RSs (e.g. SSB indices and / or CSI-RS resource identifiers and / or TRS identifiers) in one RS set and the Physical Downlink Shared Chanel (PDSCH) Demodulation Reference Signal (DMRS) ports; a list of UL TCI states for an LTM candidate cell; the unified TCI state type the UE is configured for an LTM candidate cell; or the association between one or two DL reference signals with a corresponding quasi-colocation (QCL) type.

[0092] Preventing LTM related configuration mismatches between a UE 12 and a network 10, e.g., with respect to suspension and resumption of the connection between the UE 12 and the network 10 provides numerous advantages, as noted throughout. In the context of TCI configuration for pre-sync, one advantage is preventing the UE 12 from performing DL pre-sync operation(s), such as measurements on SSB and / or CSLRS resources of a LTM candidate cell, while the network 10 never transmits a LTM cell switch command that would benefit from such measurements. Foregoing such measurements saves UE power and, another problem prevented is the UE 12 not receiving a DL pre-sync command from the network 10 without the UE 12 having a corresponding DL pre-sync acquisition configuration. A DL pre-sync command may be sent as a MAC CE before the UE receives a LTM cell switch command and not having the corresponding TCI configuration for pre-sync for the LTM candidate cell the UE 12 is being switched to may cause RRC reconfiguration failures or other errors.

[0093] In the context of this disclosure, the reference configuration or LTM Reference Configuration comprises a configuration provided by a network 10 to a UE 12. The configuration is common to multiple configured LTM candidate cells and it is used by the UE 12 to generate a complete LTM candidate cell configuration, i.e., based on the UE 12 applying a LTM candidate cell configuration on top of the LTM reference configuration.

[0094] In one option, the LTM reference configuration is configured as a RRC Reconfiguration message, e.g. within the IE LTM-Config as shown in the following Abstract Syntax Notation 1 (ASN.l) code:

[0095] LTM-Config-rl8 ::= SEQUENCE {

[0096] [■ ■ .]

[0097] Itm-ReferenceConfiguration-r 18 OCTET STRING (CONTAINING

[0098] RRCReconfiguration), OPTIONAL, — Cond FirstLTM-Candidate

[0099] [■ ■ .] }

[0100] In one or more embodiments herein, the LTM candidate cell configuration is a configuration associated with a LTM candidate cell. A LTM candidate cell configuration can be a complete LTM candidate cell configuration or a delta (difference) configuration with respect to a LTM reference configuration. In one option, the LTM candidate configuration is configured as a list of RRC reconfiguration messages, e.g. as shown in the following ASN.l example:

[0101] LTM-CandidateToAddModList-rl8 ::= SEQUENCE (SIZE (l..maxNrofCellsLTM-rl8)) OF LTM-Candidate-rl8

[0102] LTM-Candidate-rl8 ::= SEQUENCE }

[0103] Itm-Candidateld-rl 8 LTM-Candidateld-rl 8, ltm-CandidateConfig-rl8 OCTET STRING (CONTAINING RRCReconfiguration), OPTIONAL, — Need M

[0104] [■ ■ .]

[0105] }

[0106] With the above in mind, a LTM candidate configuration(s) comprises the complete LTM candidate configuration for each LTM candidate cell, and, therefore, may also be referred to as a Complete LTM Candidate Cell Configuration. This configuration is defined the configuration that contains all the necessary fields needed for the UE 12 to perform a LTM cell switch procedure. The complete configuration may be a LTM candidate cell configuration itself or may be generated by applying a LTM candidate cell configuration on top of a LTM reference configuration. That is, a Complete LTM Candidate Cell Configuration in one or more embodiments or in one or more operating scenarios generated by the UE 12 applying a LTM candidate cell configuration on top of the LTM Reference configuration, wherein the applying comprises the UE 12 performing one or more of the following steps:

[0107] 1> if there is no entry in ue-ltm-ConfigCandidateList within VarLTM-UE-Config with Itm-Candidateld value set to the value of Itm-Candidateld included in the LTM- Candidate:

[0108] 2> create an entry in ue-ltm-ConfigCandidateList within VarLTM-UE-Config with value Itm-Candidateld;

[0109] 2> set to the value of Itm-Candidateld in that entry to the value included in the LTM- Candidate;l> in the entry of ue-ltm-ConfigCandidateList within VarLTM-UE-Config with Itm-Candidateld set to the value of Itm-Candidateld value included in the LTM- Candidate:

[0110] 2> if the LTM-Candidate includes Itm-ConfigComplete;

[0111] 3> consider the received Itm-CandidateConfig within Itm-Candidate as a complete LTM candidate cell configuration;

[0112] 3> if ue-LTM-config is present within VarLTM-UE-Config: 4> replace ue-LTM-Config with the Itm-CandidateConfig included in the LTM-Config ;

[0113] 3> else:

[0114] 4> store in ue-LTM-Config the Itm-CandidateConfig included in the LTM-Config;

[0115] 2> else:

[0116] 3> generate a complete LTM candidate cell configuration by applying Itm- CandidateConfig on top of Itm-referenceConfiguration, according to clause 5.3.5.x.5.3> ue-LTM-config is present within VarLTM-UE-Config :

[0117] 4> replace ue-LTM-Config with the generated complete LTM candidate cell configuration;

[0118] 3> else:

[0119] 4> store in ue-LTM-Config the generated complete LTM candidate cell configuration.

[0120] Other LTM related configurations may be involved. For example, configuration(s) indicating whether the UE performs a Layer 2 reset or not, when LTM cell switch is to be performed from cell A to a cell B. This configuration may be specified using the field Itm- ServingCellNoResetID-rl8 of IE INTEGER (L. maxNrofCellsLTM-rl8-plus-l).

[0121] Another example LTM related configuration is an indication of whether LTM fast recovery is to be performed or not, e.g., attempt-LTM which may be set to ‘TRUE’. When such indication is included, it indicates to the UE 12 that LTM fast recovery is to be performed by the UE 12 when a failure is triggered, e.g., the UE 12 performs a LTM cell switch when, while timer T311 is running, a selected cell is a LTM candidate cell.

[0122] As noted, the actual or complete LTM candidate cell configuration may be indicated using delta signaling based on a reference configuration, e.g., signaled using the Itm- CandidateConfig-rl8 OCTET STRING (CONTAINING RRCReconfiguration within the IE LTM-Candidate.

[0123] Multiple steps are taken by a UE 12 and a network 10 according to a first method of releasing LTM related configurations to maintain alignment between the network 10 and the UE 12, e.g., with respect to suspension and resumption of the connection between the UE 12 and the network 10. In at least one embodiment, the UE 12 receives a LTM configuration, such as in a RRC Reconfiguration message. The UE 12 receives the message, for example, when it transitions to RRC_CONNECTED, e.g., from RRC_IDLE, or during a handover, or during a reconfiguration with sync, or from its serving cell for intra-cell reconfiguration. In one option the LTM configuration is received by the UE 12 when the UE 12 is capable of handling one or more of the LTM related configuration(s). For example, the UE 12 receives as the LTM configuration, one or more UL pre-sync configuration(s), based on the UE 12 being capable of performing UL pre-sync for LTM.

[0124] UE operations in the context of the first method further include the UE 12 receiving a message from the network to suspend the connection, with the UE 12 correspondingly transitioning to an inactive state, e.g., RRC_INACTIVE. For example, the UE 12 receives a RRC Release message that includes a suspend configuration (suspendConfig).

[0125] In at least one embodiment, as part of UE operations in the first method, the UE 12 deletes the LTM configuration in response to receiving the RRC Release message with suspendConfig. An example RRC modeling may be included in the RRC specifications, with new or modified specification details shown in bold italics:

[0126] 5.3.8.3 Reception of the RRCRelease by the UE

[0127] The UE shall:

[0128] [■ ■ .]

[0129] 1> if the RRCRelease includes suspendConfig:

[0130] [■ ■ .]

[0131] 2> remove all entries within the MCG VarLTM-UE-Config, if any;

[0132] 2> remove all entries within the MCG VarLTM-Config, if any;

[0133] 2> remove LTM-Config for LTM on the MCG, if any;

[0134] 2> remove the Itm-CSI-ReportConfigToAddModList instances for all MCG Serving cells;

[0135] 2> if the RRCRelease message with suspendConfig was received in response to an RRCResumeRequest or an RRCResumeRequestl:

[0136] [■ ■ .]

[0137] 2> else:

[0138] 3> store in the UE Inactive AS Context the nextHopChainingCount received in the RRCRelease message, the current KgNB and KRRCint keys, the ROHC state, the EHC context(s), the stored QoS flow to DRB mapping rules, the C-RNTI used in the source PCell, the cellldentity and the physical cell identity of the source PCell, the spCellConfigCommon within ReconfigurationWithSync of the NR PSCell (if configured) and all other parameters configured except for: parameters within ReconfigurationWithSync of the PCell; parameters within ReconfigurationWithSync of the NR PSCell, if configured; parameters within MobilityControlInfoSCG of the E-UTRA PSCell, if configured; servingCellConfigCommonSIB ;

[0139] LTM-Config and other LTM related configuration(s);

[0140] [■ ■ .]

[0141] 2> enter RRC_INACTIVE and perform cell selection as specified in TS 38.304

[0020] ;

[0142] 1> else

[0143] 2> perform the actions upon going to RRC_IDLE as specified in 5.3.11 , with the release cause 'other'.

[0144] In other embodiments or under other operating scenarios, the UE 12 deletes the first set of one or more LTM related configurations stored in the UE 12 during initiation of a resume procedure. This approach is modeled as follows in the RRC specifications (no exception added for storing in the UE Inactive AS Context, and removal is done in resume initiation) as follows:

[0145] 5.3.13 RRC connection resume

[0146] [■ ■ .]

[0147] 5.3.13.2 Initiation

[0148] [■ ■ .]

[0149] Upon initiation of the procedure, the UE shall:

[0150] [■ ■ .]

[0151] 1> if the UE is in NE-DC or NR-DC:

[0152] 2> if the UE does not support maintaining SCG configuration upon connection resumption:

[0153] 3> release the MR-DC related configurations (i.e., as specified in 5.3.5.10) from the UE Inactive AS context, if stored;

[0154] 1> if the UE is configured with LTM related configuration(s):

[0155] 2> if the UE does not support maintaining LTM related configurations upon connection resumption:

[0156] 3> release the LTM related configuration(s) from the UE Inactive AS context, if stored: 4> remove all entries within the MCG VarLTM-UE-

[0157] Config, if any;

[0158] 4> remove all entries within the MCG VarLTM-Config, if any;

[0159] 4> remove LTM-Config for LTM on the MCG, if any;

[0160] 4> remove the Itm-CSI-ReportConfigToAddModList instances for all MCG Serving cells;

[0161] [■ ■ .]

[0162] 5.3.5.4 Secondary cell group release

[0163] The UE shall:

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

[0165] 2> reset SCG MAC, if configured;

[0166] 2> for each RLC bearer that is part of the SCG configuration:

[0167] 3> perform RLC bearer release procedure as specified in 5.3.5.5.3;

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

[0169] 3> perform BH RLC channel release procedure as specified in 5.3.5.5.10;

[0170] 2> release the SCG configuration;

[0171] 2> remove all the entries within the SCG VarConditionalReconfig, if any;

[0172] 2> remove all entries within the SCG VarLTM-UE-Config, if any;

[0173] 2> remove all entries within the SCG VarLTM-Config, if any;

[0174] 2> remove LTM-Config for LTM on the SCG, if any;

[0175] 2> remove the Itm-CSI-ReportConfigToAddModList instances for all SCG Serving cells;

[0176] 2> if SCG release was triggered by NR (i.e. NR-DC case):

[0177] 3> remove all the entries within the MCG VarConditionalReconfig for which the RRCReconfiguration within condRRCReconfig does not include the masterCellGroup with reconfigurationWithSync, if any;

[0178] 2> else (i.e. EN-DC case):

[0179] 3> perform VarConditionalReconfiguration CPC removal as specified in TS 36.331

[0010] clause 5.3.5.9.7;

[0180] 2> stop timer T310 for the corresponding SpCell, if running;

[0181] 2> stop timer T312 for the corresponding SpCell, if running; 2> stop timer T304 for the corresponding SpCell, if running.

[0182] NOTE: Release of cell group means only release of the lower layer configuration of the cell group but the RadioBearerConfig may not be released.

[0183] Another possibility to model this in RRC is to define a function for releasing LTM related configuration(s), as follows (where “x” and “y” denote numbering to be determined):

[0184] 5.3.5.x. y Release LTM related configuration

[0185] The UE shall: l> as a result of the release of LTM related configurations:

[0186] 2> remove all entries within the MCG VarLTM-UE-Config, if any;

[0187] 2> remove all entries within the MCG VarLTM-Config, if any;

[0188] 2> remove LTM-Config for LTM on the MCG, if any;

[0189] 2> remove the Itm-CSI-ReportConfigToAddModList instances for all MCG Serving cells;

[0190] 5.3.13 RRC connection resume

[0191] [■ ■ . ]

[0192] 5.3.13.2 Initiation

[0193] [■ ■ . ]

[0194] Upon initiation of the procedure, the UE shall:

[0195] [■ ■ . ]

[0196] 1> if the UE is in NE-DC or NR-DC:

[0197] 2> if the UE does not support maintaining SCG configuration upon connection resumption:

[0198] 3> release the MR-DC related configurations (i.e., as specified in 5.3.5.10) from the UE Inactive AS context, if stored;

[0199] 1> if the UE is configured with LTM related configuration(s):

[0200] 2> if the UE does not support maintaining LTM related configurations upon connection resumption:

[0201] 3> release the MCG LTM related configuration(s) (i.e., as specified in 5.3.5.x.y)from the UE Inactive AS context, if stored:

[0202] 3> release the SCG LTM related configuration(s) from the UE

[0203] Inactive AS context, if stored:

[0204] 4> remove all entries within the SCG VarLTM-UE-Config, if any; 4> remove all entries within the SCG VarLTM-Config, if any;

[0205] 4> remove LTM-Config for LTM on the SCG, if any;

[0206] 4> remove the Itm-CSI-ReportConfigToAddModList instances for all SCG Serving cells;

[0207] [■ ■ .]

[0208] One example approach to the UE 12 removing a previously configured first set of one or more LTE related configurations comprises the UE removing entries of one or more UE variables in which the first set of LTM related configuration(s) have been configured. Such an approach is shown in the above example, where the UE 12 removes all entries within the MCG or SCG VarLTM-UE-Config, if any, and when the UE 12 removes all entries within the MCG or SCG VarLTM-Config, if any.

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

[0210] An ASN.l example for VarLTM-Config is as follows:

[0211] - ASN1 START

[0212] - TAG-VARLTM-CONFIG-START

[0213] VarLTM-Config-rl8-IEs ::= SEQUENCE { ltm-ReferenceConfiguration-rl8 OCTET STRING (CONTAINING RRCReconfiguration) , Itm-CandidateList-r 18 LTM-CandidateList-r 18

[0214] }

[0215] LTM-CandidateList-r 18 ::= SEQUENCE (SIZE (L.maxNrofCellsLTM-rl8)) OF LTM-

[0216] Candidate-rl8

[0217] - TAG-VARLTM-CONFIG-STOP

[0218] - ASN1STOP

[0219] An ASN.l example for VarLTM-UE-Config is as follows:

[0220] - ASN1 START

[0221] - TAG-VARLTM-CONFIG-START

[0222] VarLTM-UE-Config-rl8-IEs ::= SEQUENCE { ue-ltm-ConfigCandidateList-r 18 UE-LTM-ConfigCandidateList-r 18

[0223] } UE-LTM-ConfigCandidateList-rl8 ::= SEQUENCE (SIZE (l..maxNrofCellsLTM-rl8)) OF UE-LTM-Candidate-rl8 UE-LTM-Candidate-rl8 ::= SEQUENCE { Itm-Candidateld-rl 8 LTM-Candidateld-rl 8, ue-LTM-Config-r 18 OCTET STRING (CONTAINING RRCReconfiguration) }

[0224] - TAG-VARLTM-CONFIG-STOP

[0225] - ASN1STOP

[0226] According to the foregoing variable example, a UE 12 removing a first set of one or more LTM related configuration(s) upon resume initiation or during transition to RRC_INACTIVE comprises the UE 12 removing all entries within the VarLTM-UE-Config, if any, and removing all entries within the VarLTM-Config, if any.

[0227] In at least one embodiment, the UE 12 removes a first set of LTM related configuration(s) which were previously configured in the UE 12, by removing the IE including the LTM related configuration (e.g. IE LTM-Config, and the IES within), which is part of its UE current configuration.

[0228] An ASN1.1 example for the LTM-Config IE is as follows:

[0229] - ASN1 START

[0230] - TAG-LTM-CONFIG-START

[0231] LTM-Config-rl8 ::= SEQUENCE {

[0232] Itm-ReferenceConfiguration-r 18 OCTET STRING (CONTAINING

[0233] RRCReconfiguration) , OPTIONAL, - Cond FirstLTM-Candidate

[0234] Itm-CandidateToReleaseList-r 18 LTM-CandidateToReleaseList-r 18

[0235] OPTIONAL, - Need N Itm-CandidateToAddModList-r 18 LTM-CandidateToAddModList-r 18

[0236] OPTIONAL, - Need N ltm-ServingCellNoResetID-rl8 INTEGER (L. maxNrofCellsLTM-rl8- plus-1) OPTIONAL, - Cond FirstLTM-Only ltm-CSI-ResourceConfigToAddModList-rl8 SEQUENCE (SIZE (1..maxNrofCSI- Resourceconfigurations)) OF LTM-CSI-ResourceConfig OPTIONAL, - Need N ltm-CSI-ResourceConfigToReleaseList-rl8 SEQUENCE (SIZE (1..maxNrofCSI- Resourceconfigurations)) OF LTM-CSI-ResourceConfigld OPTIONAL, - Need N }

[0237] Editor’s Note: FFS on whether the ETM-CandidateNoResetE2-Eist field should include separate reset flags for REC and PDCP recovery.

[0238] LTM-CandidateToReleaseList-rl8 ::= SEQUENCE (SIZE (E.maxNrofCellsLTM-rl8))

[0239] OF LTM-CandidateId-rl8 OPTIONAL - Need N

[0240] - TAG-LTM-CONFIG-STOP

[0241] - ASN1STOP

[0242] The first set of one or more LTM related configurations may correspond to one or more of the following: (i) lower layer measurement configuration(s) for LTM; (ii) TA acquisition (also called UL pre-sync configuration); (iii) TCI state configuration(s) for pre-sync (also called DL pre-sync configuration); (iv) LTM Reference configuration(s); (v) LTM Candidate Cell Configuration(s); (vi) complete LTM candidate cell configuration(s) generated when the UE is configured with LTM; or (vii) other LTM related configuration(s).

[0243] In a set of embodiments, a UE 12, which has deleted a (previously stored) first set of one or more LTM related configurations, initiates a resume procedure, transmits a RRC Resume Request message (e.g., RRCResumeRequest, or RRCResumeRequestl) and receives in response a RRC Resume message (RRCResume). The RRCResume message includes a second set of one or more LTM related configuration(s), to be used by the UE 12 rather than the first set.

[0244] In one option, the second set of one or more LTM related configuration(s) is comprised within the IE LTM-Config as shown below, with modified or added content shown in bold italics:

[0245] RRCResume-vl8xy-Ies ::= SEQUENCE {

[0246] Itm-Config-rl 8 SetupRelease {LTM-Config-rl8} OPTIONAL, — NeedM nonCriticalExtension SEQUENCE {}

[0247] OPTIONAL

[0248] }

[0249] LTM-Config information element

[0250] - ASN1 START

[0251] - TAG-LTM-CONFIG-START

[0252] LTM-Config-rl8 ::= SEQUENCE { Itm-ReferenceConfiguration-r 18 OCTET STRING (CONTAINING RRCReconfiguration) , OPTIONAL, - Cond FirstLTM-Candidate Itm-CandidateToReleaseList-r 18 LTM-CandidateToReleaseList-r 18 OPTIONAL, - Need N Itm-CandidateToAddModList-r 18 LTM-CandidateToAddModList-r 18 OPTIONAL, - Need N Itm-ServingCellNoResetID-r 18 INTEGER (L. maxNrofCellsLTM-rl8- plus-1) OPTIONAL, - Cond FirstLTM-Only ltm-CSI-ResourceConfigToAddModList-rl8 SEQUENCE (SIZE (L.maxNrofCSI-ResourceConfigurations)) OF LTM-CSI-ResourceConfig OPTIONAL, - Need N ltm-CSI-ResourceConfigToReleaseList-rl8 SEQUENCE (SIZE (L.maxNrofCSI-ResourceConfigurations)) OF LTM-CSI-ResourceConfigld OPTIONAL, - Need N Editor’s Note: FFS on whether the ETM-CandidateNoResetE2-Eist field should include separate reset flags for REC, and PDCP recovery.

[0253] LTM-CandidateToReleaseList-rl8 ::= SEQUENCE (SIZE (E.maxNrofCellsLTM-rl8)) OF LTM-CandidateId-rl8 OPTIONAL - Need N

[0254] - TAG-LTM-CONFIG-STOP

[0255] - ASN1STOP

[0256] The below example depicts procedure text in RRC, according to one embodiment, where the new or modified content as compared to the existing specification text appears in bold italics:

[0257] 5.3.13.4 Reception of the RRCResume by the UE

[0258] The UE shall:

[0259] [■ ■ .]

[0260] 1> if the RRCResume message includes the Itm-Config:

[0261] 2> if the Itm-Config is set as setup:

[0262] 3> perform the LTM configuration procedure as specified in 5.3.5.x;

[0263] 2> else: 3> release the LTM configuration;

[0264] 1> set the content of the RRCResumeComplete message as follows:

[0265] [■ ■ .]

[0266] In an example case where the connection of a UE 12 is suspended and the UE 12 stores, or previously stored a first set of one or more LTM related configurations, the disclosed techniques provide mechanisms to ensure that the LTM related configuration(s) used by the UE 12 matches what the network 10 expects, with respect to operation of the UE 12 in association with resumption of the connection. That is, while the UE 12 may store a first set of one or more LTM related configurations, it may, in association with resumption of the suspended connection, be provided with a second set of one or more LTM related configurations. The second set of one or more LTM related configuration(s) may be the same or different than the first set of one or more LTM related configurations.

[0267] In one or more embodiments, a first network node of the network 10 operates as a Central CU serving a UE 12 and performs a method of operation.

[0268] The method includes the serving CU transmitting to the UE 12 a first set of one or more LTM related configuration(s). In at least one embodiment, the first set of one or more LTM related configuration(s) is received by the UE 12 in a message which corresponds to an RRC Reconfiguration message, which the UE 12 may receive in different manners, such as when it transitions to RRC_CONNECTED (e.g., from RRC_IDLE), or during a handover, or during a reconfiguration with sync, or from the serving cell for intra-cell reconfiguration.

[0269] In at least one embodiment, the first set of one or more LTM related configuration(s) is received when the UE 12 is capable of handling one or more of the LTM related configuration(s). For example, the UE receives in the first set an UL pre-sync configuration(s) when the UE is capable of performing UL pre-sync for LTM.

[0270] In at least one embodiment, the message from the network to suspend the connection and transition to Inactive state corresponds to a RRC Release message that includes a suspend configuration (suspendConfig). Further, in at least one such embodiment, the message from the first network node, e.g., CU-Control Plane (CP) is transmitted to another network node, e.g., CU-User Plane (UP), with one indication of suspending connection for the bearer(s) established for LTM operation, for example, in the E1AP BEARER CONTEXT MODIFICATION REQUEST message.

[0271] Further operations at the serving CU according to the example method include the serving CU deleting the first set of one or more LTM related configurations as stored in the network 10 for the UE 12, in response to one or more triggering events. For example, the serving CU performs the deletion responsive to transmitting a RRCRelease message to the UE 12, to transition the UE 12 to Inactive state.

[0272] For example, the RRCRelease message is included within a UE CONTEXT RELEASE COMMAND (sent over F1AP signaling), which is transmitted to a serving DU. Here, the serving DU forwards the RRCRelease message, including the suspendConfig, to the UE 12. Correspondingly, the serving DU transmits to the serving CU a UE CONTEXT RELEASE COMPLETE message (sent over F1AP signaling). When that message is received at the serving CU, the serving CU transmits another UE CONTEXT RELEASE COMMAND, this time to one or more candidate DU(s) associated with the first set of LTM related configuration(s). Doing so prompts the candidate DU(s) to release the first set of LTM configuration(s), and respond with a UE CONTEXT RELEASE COMPLETE message.

[0273] In at least one such embodiment, when the serving DU receives the UE CONTEXT RELEASE COMMAND from the serving CU, the serving DU releases the UE context in the serving DU and sends the UE CONTEXT RELEASE COMPLETE message to the serving CU. Thus, if or when the UE 12 tries to resume its connection with the same serving DU, a UE CONTEXT SETUP procedure is needed and the signaling flow depicted in Figure 2 illustrates corresponding steps.

[0274] In Figure 2, “S-DU” denotes a serving DU, “S-CU” denotes a serving CU, and “C-DU” denotes a candidate DU, i.e., a DU associated with one of the one or more candidate LTM cells involved in the first set of one or more LTM related configurations being deleted.

[0275] In one or more other embodiments, the message is included within a UE CONTEXT MODIFICATION REQUEST message (sent over F1AP signaling), which includes an indication of suspension of lower layer and is transmitted to a serving DU. Here, the serving DU forwards the RRCRelease message, which includes suspendConfig, to the UE 12. Correspondingly, the serving DU transmits to the serving CU a UE CONTEXT MODIFICATION RESPONSE message (over F1AP signaling). When that response message is received at the serving CU, the serving CU transmits another UE CONTEXT RELEASE COMMAND, this time to one or more candidate DU(s) associated with the first set of LTM related configuration(s). Doing so prompts each of the candidate DUs to release the first set of LTM configuration(s), and respond to the serving CU with a UE CONTEXT RELEASE COMPLETE.

[0276] In at least one such embodiment, when the UE CONTEXT MODIFICATION REQUEST message (over F1AP signaling), which includes an indication of suspension of lower layer, is received by the serving DU, the serving DU keeps all lower layer configuration(s) for the UE 12 and does not transmit or receive data from the UE. If later the UE tries to resume its connection with the same serving DU, a UE CONTEXT MODIFICATION REQUEST message, is sent with the Lower Layer presence status change IE set to "resume lower layers" and, as a result, the gNB-DU shall use the previously stored lower layer configuration for the UE.

[0277] In one or more embodiments or in one or more operational scenarios, the deletion of an (outdated or stale) first set of one or more LTM related configurations held in the network 10 for a UE 12 having a suspended connection and operating in the RRC_IN ACTIVE state occurs during initiation of a resume procedure for the UE 12.

[0278] For example, when the serving CU receives a RRC Resume Request, the serving CU recognizes that the UE 12 is releasing the first set of LTM related configurations, as stored in the UE 12. Thus, the serving CU responds by transmitting a UE CONTEXT RELEASE COMMAND to the one or more candidate DU(s) associated with the first set of LTM related configuration(s), thereby prompting the one or more candidate DUs to release the first set of LTM configurations, as stored in the candidate DUs for the UE 12. Each candidate DU responds to the serving CU with a UE CONTEXT RELEASE COMPLETE.

[0279] As a particular example in this context, when the UE CONTEXT in the serving DU has been suspended instead of released, the serving DU sends a UE CONTEXT MODIFICATION REQUEST for resuming the UE CONTEXT, before it sends the RRC Resume message to the UE 12.

[0280] As a further particular example, the serving CU-CP sends to another network node or logical entity, e.g., to a serving CU-UP, with one indication of resuming connection for the bearer(s) established for LTM operation, for example, in the E1AP BEARER CONTEXT MODIFICATION RESPONSE message. See the signaling steps shown in Figure 3, which can be understood as illustrating an example release of LTM related configurations when a UE 12 tries to resume its connection.

[0281] In one or more embodiments, a serving CU receives from a UE 12 a RRC Resume Request message (e.g. RRCResumeRequest or RRCResumeRequestl message) and determines to configure the UE 12 with a second set of one or more LTM related configurations. Here, it will be understood that “second” serves as a label for distinguishing the second set from a first set of one or more LTM related configurations previously determined for the UE 12. For example, it may be assumed that the network 10 previously determined the first set, with corresponding configuration information stored in the UE 12 and in the candidate DU(s) implicated in the first set.

[0282] Thus, by these actions, the network 10 and the UE 12 will operate in alignment, i.e., both the network 10 and the UE 12 will operate according to the second set of one or more LTM related configurations. In association with determining the second set of one or more LTM related configurations for the UE 12, the serving CU requests at least one candidate DU to configure LTM for the UE 12, which may be incoming to a cell of the candidate DU. For example, the serving CU transmits a UE CONTEXT SETUP REQUEST to the candidate DU. Subsequently, the serving CU receives from the candidate DU a UE CONTEXT SETUP RESPONSE, which includes at least one configuration from the second set of the one more LTM related configurations, e.g., configuration per LTM candidate cell, UL pre-sync configuration, DL presync configuration, and / or other LTM related configurations.

[0283] The serving CU then includes the second set of LTM related configuration(s) in a RRC Resume message to be transmitted to the UE 12. Therefore, even in cases where the UE 12 stores a first set of one or more LTM related configurations when its connection was suspended, the network 10 may update the UE 12 with a second set of one or more LTM related configurations in the RRC Resume message. In this manner, the UE 12 resumes operations using LTM related configuration(s) aligned with the network 10.

[0284] Figure 4 illustrates example signaling for including a second set of one or more LTM related configurations in a RRCResume message sent to a UE 12.

[0285] With respect to example steps for a UE 12 and a network 10 to store / restore LTM related configurations, consider example operations at a UE 12. The example operations include the UE 12 receiving a first set of one or more LTM related configuration(s). For example, the UE 12 receives a RRC Reconfiguration message when it transitions to RRC_CONNECTED state from the RRC_IDLE state, with that message indicating the first set of one or more LTM related configurations. Other examples include the UE 12 receiving the first set during handover or during a reconfiguration sync or from a serving cell for intracell reconfiguration. Yet another example is the UE 12 receiving the first set of one or more LTM related configuration(s) when the UE 12 is capable of handling one or more of the LTM related configuration(s). For example, the UE 12 receives in the first set an UL pre-sync configuration(s) when the UE is capable of performing UL pre-sync for LTM.

[0286] UE operations further include the UE 12 subsequently receiving a message from the network 10, to suspend its connection to the network 10 and transition to an inactive state, e.g. RRC_INACTIVE. This message includes, for example, a suspend configuration (suspendConfig) element and, in response to that inclusion, the UE 12 stores the first set of one or more LTM related configurations.

[0287] Such operations are modeled in the RRC specifications according to the below example, where new or modified text is shown in bold italics. 5.3.8.3 Reception of the RRCRelease by the UE

[0288] The UE shall:

[0289] [■ ■ .]

[0290] 1> if the RRCRelease includes suspendConfig:

[0291] [■ ■ .]

[0292] 2> if the RRCRelease message with suspendConfig was received in response to an RRCResumeRequest or an RRCResumeRequestl:

[0293] [■ ■ .]

[0294] 2> else:

[0295] 3> store in the UE Inactive AS Context the nextHopChainingCount received in the RRCRelease message, the current KgNB and KRRCint keys, the ROHC state, the EHC context(s), the stored QoS flow to DRB mapping rules, the C-RNTI used in the source PCell, the cellidentity and the physical cell identity of the source PCell, the spCellConfigCommon within ReconfigurationWithSync of the NR PSCell (if configured) and all other parameters (including LTM related parameters) configured except for:

[0296] - parameters within ReconfigurationWithSync of the PCell;

[0297] - parameters within ReconfigurationWithSync of the NR PSCell, if configured;

[0298] - parameters within MobilityControlInfoSCG of the E-UTRA PSCell, if configured;

[0299] - servingCellConfigCommonSIB;

[0300] NOTE: The LTM related parameters include all entries within the MCG and

[0301] SCG VarLTM-UE-Config, entries within the MCG and SCG VarLTM-Config, the IE LTM-Config, and the Itm-CSI-ReportConfigToAddModList instances for all Serving cells.

[0302] [■ ■ .]

[0303] 2> enter RRC_INACTIVE and perform cell selection as specified in TS 38.304

[0020] ;

[0304] 1> else

[0305] 2> perform the actions upon going to RRC_IDLE as specified in 5.3.11 , with the release cause 'other'. In one or more embodiments, a UE 12 stores a first set of LTM related configuration(s), configured for the UE 12 by a network 10, based on the UE 12 storing entries in one or more UE variables. Such an example is shown above, with reference to the VarLTM-Config and VarLTM- UE-Config variables. Also, note that in one or more embodiments, the UE 12 stores LTM related configurations separately, for MCG and SCG. In one or more embodiments, the network 10 uses a RRC Resume message to control whether a UE 12 resuming its connection restores LTM related configurations that were stored in the UE 12 at or before the prior suspension of the connection. That is, LTM related configuration(s) stored in a UE 12 that is returning to the active state — resuming a suspended connection — may or may not be appropriate for use by the UE 12, and the network 10 controls whether that previously stored configuration information is used by the UE 12 when returning to the active state, or replaced with updated LTM related configuration information.

[0306] As one example, the UE 12 initiates a resume procedure and transmits a RRC Resume Request message to a target CU — i.e., the CU associated with the DU providing the network cell where the UE 12 is attempting to resume its connection. Assuming that the CU is LTM capable, the CU then decides whether the UE 12 should use its previously stored LTM related configurations or should use new or otherwise updated LTM related configurations. The CU indicates the decision to the UE 12 using the RRC Resume message. In particular, in at least one embodiment, the RRC Resume message includes or does not include an indication. Inclusion of the indication, e.g., a restoreLTM field, serves as a signal to the UE 12 that it should restore its stored LTM related configurations. Absence of the indication from the RRC Resume message serves as a signal to the UE 12 that it should delete (remove) its previously stored LTM related configurations.

[0307] The foregoing logic also has the advantage of ensuring proper behavior in the UE 12 in cases where the target CU is not LTM capable. Namely, if the target CU is not LTM capable, the RRCResume message sent to the UE 12 does not include an indication that the UE 12 should restore its previously stored LTM related configuration(s) in association with the resumed connection. Consequently, the UE 12 “views” the absence of the indication as a signal to delete its previously stored LTM related configuration(s) and, therefore, the UE 12 resumes its connection without use of outdated / stale LTM related configuration(s).

[0308] With respect to a MCG and a SCG, in one or more embodiments, the RRCResume message may include or omit two separate indications, independently. That is, inclusion or omission of a first indication in the RRCResume message controls whether the UE 12 restores previously stored LTM related configurations for the MCG. Separately, inclusion or omission of a second indication in the RRCResume message controls whether the UE restores previously stored LTM related configurations for the SCG. As an alternative, restoration by the UE 12 of the previously stored LTM related configurations for the SCG requires the presence of both the first and the second indications — i.e., the UE 12 does not restore the SCG-related information unless it also restores the MCG-related information.

[0309] The foregoing logic may be stipulated in the RRC specifications as shown in the following example. Again, text that is new or modified as compared to the existing specification text appears in bold italics.

[0310] 5.3.13.4 Reception of the RRCResume by the UE

[0311] The UE shall:

[0312] [■ ■ .]

[0313] 1> if the RRCResume includes the fullConfig:

[0314] 2> perform the full configuration procedure as specified in 5.3.5.11 ;

[0315] 1> else:

[0316] [■ ■ .]

[0317] 2> if the RRCResume does not include the restoreSCG:

[0318] 3> release the MR-DC related configurations (i.e., as specified in 5.3.5.10) from the UE Inactive AS context, if stored;

[0319] 2> if the RRCResume does not include the restoreLTM:

[0320] 3> release the LTM related configurations (i.e., as specified in 5.3.5.x) from the UE Inactive AS context, if stored;

[0321] Editor’s Note: FFS define the procedure for releasing LTM related configuration 5.3.5.x when IES and LI parameters are stable.

[0322] 2> restore the masterCellGroup, mrdc-SecondaryCellGroup, if stored, LTM related configurations, if stored, and pdcp-Config from the UE Inactive AS context;

[0323] [■ ■ .]

[0324] 1> discard the UE Inactive AS context;

[0325] [■ ■ .]

[0326] 5.3.5.10 MR-DC release

[0327] The UE shall:

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

[0329] 2> release SRB3, if established, as specified in 5.3.5.6.2;

[0330] 2> release measConfig associated with SCG;

[0331] 2> if the UE is configured with NR SCG:

[0332] 3> release the SCG configuration as specified in clause 5.3.5.4; 3> release otherConfig associated with the SCG, if configured;

[0333] 3> stop timers T346a, T346b, T346c, T346d, T346e, T346j and T346k associated with the SCG, if running;

[0334] 3> release bap-Config associated with the SCG, if configured;

[0335] 3> release the BAP entity as specified in TS 38.340

[0047] , if there is no configured bap-Config;

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

[0337] 2> else if the UE is configured with E-UTRA SCG:

[0338] 3> release the SCG configuration as specified in TS 36.331

[0010] , clause 5.3.10.19 to release the E-UTRA SCG;

[0339] [■ ■ .]

[0340] 5.3.5.4 Secondary cell group release

[0341] The UE shall:

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

[0343] 2> reset SCG MAC, if configured;

[0344] 2> for each RLC bearer that is part of the SCG configuration:

[0345] 3> perform RLC bearer release procedure as specified in 5.3.5.5.3;

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

[0347] 3> perform BH RLC channel release procedure as specified in 5.3.5.5.10;

[0348] 2> release the SCG configuration;

[0349] 2> remove all the entries within the SCG VarConditionalReconfig, if any;

[0350] 2> remove all entries within the SCG VarLTM-UE-Config, if any;

[0351] 2> remove all entries within the SCG VarLTM-Config, if any;

[0352] 2> remove LTM-Config for LTM on the SCG, if any;

[0353] 2> remove the Itm-CSI-ReportConfigToAddModList instances for all SCG Serving cells;

[0354] 2> if SCG release was triggered by NR (i.e. NR-DC case):

[0355] 3> remove all the entries within the MCG VarConditionalReconfig for which the RRCReconfiguration within condRRCReconfig does not include the masterCellGroup with reconfigurationWithSync, if any;

[0356] 2> else (i.e. EN-DC case):

[0357] 3> perform VarConditionalReconfiguration CPC removal as specified in TS 36.331

[0010] clause 5.3.5.9.7;

[0358] 2> stop timer T310 for the corresponding SpCell, if running; 2> stop timer T312 for the corresponding SpCell, if running;

[0359] 2> stop timer T304 for the corresponding SpCell, if running.

[0360] NOTE: Release of cell group means only release of the lower layer configuration of the cell group but the RadioBearerConfig may not be released.

[0361] [■ ■ .]

[0362] RRCResume-vl8xy-Ies ::= SEQUENCE { restoreLTM-rl8 ENUMERATED {true}

[0363] OPTIONAL, - Need N nonCriticalExtension SEQUENCE {}

[0364] OPTIONAL

[0365] } restoreLTM

[0366] Indicates that the UE shall restore the LTM related configurations from the UE Inactive AS Context, if stored.

[0367] Consider a further example taken in the context of a UE 12 that stored a first set of LTM related configurations when its connection to the network 10 was suspended, and then later transmits a RRC Resume Request message (e.g. RRCResumeRequest, or RRCResumeRequestl). The network 10 sends a RRC Resume message (RRCResume) to the UE 12 in response to the request, and includes in the RRC Resume message a second set of one or more LTM related configurations. Inclusion of the second set of one or more LTM related configurations in the RRC Resume message may serve as a signal to the UE 12 not to restore the previously stored first set of one or more LTM related configurations for resumption of the connection and to, instead, use the second set of one or more LTM related configurations. The second set may be a complete replacement for the first set, or the second set may supplement or otherwise modify the first set — e.g., add, delete, or change one or more items in the first set. In at least one embodiment, when the network 10 wants the UE 12 to delete the previously stored first set of one or more LTM related parameters and instead use a second set of one or more LTM related parameters in association with the resumed connection, the restoreLTM indication is omitted from the RRC Resume message, and the second set of one or more LTM related configurations is included in the message. An example of including a second set of one or more LTM related configuration(s) in the earlier-described IE LTM-Config appears below.

[0368] RRCResume-vl8xy-Ies ::= SEQUENCE { ltm-Config-rl8 SetupRelease {LTM-Config-rl8}

[0369] OPTIONAL, — NeedM nonCriticalExtension SEQUENCE {}

[0370] OPTIONAL } [■ ■ .]

[0371] LTM-Config information element

[0372] - ASN1 START

[0373] - TAG-LTM-CONFIG-START

[0374] LTM-Config-rl8 ::= SEQUENCE {

[0375] Itm-ReferenceConfiguration-r 18 OCTET STRING (CONTAINING

[0376] RRCReconfiguration) , OPTIONAL, - Cond FirstLTM-Candidate

[0377] Itm-CandidateToReleaseList-r 18 LTM-CandidateToReleaseList-r 18

[0378] OPTIONAL, - Need N

[0379] Itm-CandidateToAddModList-r 18 LTM-CandidateToAddModList-r 18

[0380] OPTIONAL, - Need N

[0381] Itm-ServingCellNoResetID-r 18 INTEGER (1... maxNrofCellsLTM-rl8-plus-l)

[0382] OPTIONAL, - Cond FirstLTM-Only ltm-CSI-ResourceConfigToAddModList-rl8 SEQUENCE (SIZE

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

[0384] OPTIONAL, -

[0385] Need N ltm-CSI-ResourceConfigToReleaseList-rl8 SEQUENCE (SIZE

[0386] (1 . . .maxNrofCSI-ResourceConfigurations)) OF LTM-CSI-ResourceConfigld

[0387] OPTIONAL, -

[0388] Need N Editor’s Note: FFS on whether the ETM-CandidateNoResetE2-Eist field should include separate reset flags for REC, and PDCP recovery.

[0389] LTM-CandidateToReleaseList-rl8 ::= SEQUENCE (SIZE (E.maxNrofCellsLTM-rl8)) OF LTM-CandidateId-rl8 OPTIONAL - Need N

[0390] - TAG-LTM-CONFIG-STOP

[0391] - ASN1STOP

[0392] The RRC content shown below constitutes example procedure text.

[0393] 5.3.13.4 Reception of the RRCResume by the UE

[0394] The UE shall:

[0395] [■ ■ .]

[0396] 1> if the RRCResume message includes the Itm-Config:

[0397] 2> if the Itm-Config is set as setup:

[0398] 3> perform the LTM configuration procedure as specified in 5.3.5.x;

[0399] 2> else:

[0400] 3> release the LTM configuration; 1> set the content of the RRCResumeComplete message as follows:

[0401] [■ ■ .]

[0402] The second set of one or more LTM related configuration(s) may be the same or different than the first set of one or more LTM related parameters.

[0403] As a further example of operations in one or more embodiments, a UE 12 in the active state is suspended and in association with suspension of its connection to the network 10, the UE stores the then-current LTM related configuration(s) most recently provided to it by the network during active-state operation. The then-serving CU of the UE 12 also stores the then-current LTM related configuration(s) for the UE 12, e.g., in the UE Inactive AS Context. However, in association with suspension of the connection and transitioning the UE 12 to the inactive state, the then-serving CU releases the then-current LTM related configurations from the involved candidate DU(s). Removal of such information from the candidate DU(s) means that context setup will be triggered in resume operations. Alternatively, the serving CU suspends the LTM related configuration(s) in the candidate DU(s), rather than releasing the configuration(s), so that context modification is triggered in resume operations.

[0404] In more detail, consider a UE 12 operating in the active state and having an associated first set of one or more LTM related configurations. Thus, LTM related configuration information is held in the UE 12 and corresponding LTM related configuration information is held in the DU(s) that is / are identified to the UE 12 as LTM candidate cells. In association with the serving CU suspending the connection of the UE 12, with the UE 12 transitioning to the inactive state, the serving CU stores the first set of one or more LTM related configurations in the UE Inactive context at the network side. The serving CU also transmits a UE CONTEXT MODIFICATION REQUEST to each candidate DU implicated in the first set of one or more LTM related configurations. This request indicates suspension of lower layers, and each candidate DU responds by suspending the first set of one or more LTM configuration(s). Further, each candidate DU transmits a UE CONTEXT MODIFICATION RESPONSE back to the serving CU.

[0405] As compared to configuration release, in which released configuration information is discarded, “suspended” configurations are stored. Hence, in response to the UE CONTEXT MODIFICATION REQUEST sent by the serving CU to each candidate DU implicated in the first set of one or more LTM related configurations, each candidate DU stores the LTM related configuration(s) for the UE 12, for potential later reuse upon later connection resumption. Figure 5 illustrates example signaling embodying the steps carried out for such suspension at each candidate DU. Now consider the example case where the serving CU suspended the first set of one or more LTM related configurations of the UE 12 at each of the involved candidate DUs but, in association with the serving CU later receiving a RRC Resume Request message from the 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 transmits a message to each such candidate DU, prompting the candidate DU to delete the first set of LTM related configuration(s). As a specific example, the serving CU transmits a UE CONTEXT RELEASE COMMAND to each candidate DU. Each candidate DU responds to the UE CONTEXT RELEASE COMMAND by releasing the first set of LTM related configuration(s) or parts of it, as stored at the candidate DU. Releasing “parts” of the stored information refers to the example case where more than one candidate DU is implicated in the first set of one or more LTM related configurations, in which case each candidate DU deletes the information specific to it.

[0406] In the contrary case where the serving CU has suspended the first set of one or more LTM related configurations for the UE 12 in the candidate DU(s) and decides that that first set should be restored in association with resumption of the connection of the UE 12, the serving CU transmits, for example, a UE CONTEXT MODIFICATION REQUEST to each candidate DU. The request includes an indication that the candidate DU should restore the first set of one or more LTM related configurations for the UE 12. Each candidate DU responds by restoring — resuming use of — the first set of one or more LTM related configurations for the UE 12, or relevant parts thereof.

[0407] For the serving CU to cause the candidate DU(s) to resume their use of the first set of one or more LTM related configuration, the context information for the UE 12 (e.g. UE Inactive AS Context) needs to include information about the candidate DU(s), e.g., node identifiers, F1AP signaling association(s), tunnel identifiers, etc. One example for causing the resumption of the suspended LTM related configuration(s) for the UE 12 is shown in Figure 6.

[0408] Now consider example details for an embodiment or an operating scenario where a serving CU receives a RRC Resume Request from a UE 12 for which a first set of one or more LTM related configurations are stored in the UE 12, and the serving 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.

[0409] Before sending the RRC Resume message to the UE 12, the serving CU transmits a CONTEXT SETUP REQUEST to one or more candidate DUs, requesting that the candidate DU determine one or more LTM related configurations for the UE 12. Each candidate DU responds to the serving CU by sending a UE CONTEXT SETUP RESPONSE that includes one or more LTM related configurations determined by the candidate DU for the UE 12. The serving CU aggregates the LTM configuration(s) determined by the candidate DUs as a second set of one or more LTM related configurations to be used by the UE for replacing or modifying the first set of one or more LTM related configurations stored in the UE 12 before it was suspended. Example LTM related configurations included in this second set are per candidate DU determinations of UL and / or DL pre-sync configurations.

[0410] Now consider an example where a UE 12 attempts to resume its connection but has moved such that the CU in the network 10 that receives the RRC Resume Request is not the same CU that previously served the UE 12 and suspended the connection of the UE 12. In other words, this “second” CU receiving the resume request is not the “first” CU that previously served the UE 12. Here, it is assumed that a first set of one or more LTM related configurations was stored in the UE 12 and in the network 10, in association with suspending the connection of the UE 12.

[0411] When the UE 12 attempts to resume its connection, the first CU receives a message from the second CU, requesting UE Context for the UE 12. For example, the second CU sends a XnAP: RETRIEVE UE CONTEXT REQUEST to the first CU. The first CU responds by deleting the stored first set of LTM related configuration(s) from the UE Inactive AS Context it maintained for the UE 12 and it sends a UE Context response message (e.g., XnAP: RETRIEVE UE CONTEXT RESPONSE) to the second CU. This response message includes the UE Inactive AS Context (without the first set of LTM related configuration(s)). As part of these operations, the first CU also deletes the first set of LTM related configuration(s) from the candidate DU(s) involved in the first set of one or more LTM related configurations, by transmitting a UE CONTEXT RELEASE COMMAND to each such candidate DU.

[0412] A signaling flow embodying such operations appears in Figure 7. Although Figure 7 illustrates first (serving) and second (target) CUs and correspondingly associated candidate DUs, the operations can be understood broadly in the context of new and old gNBs or new and old radio base stations. That is, an “old” gNB that was the serving gNB for a UE 12 when it was released to the inactive state deletes LTM related configurations for the UE 12 from the context information stored for the UE 12, in association with determining that the UE 12 is resuming its suspended connection with a “new” gNB.

[0413] Figure 7 and the logic embodied in its depicted signaling flow accounts for cases where a UE 12 has LTM related configurations associated with it when it is released to the inactive state and the UE 12 moves around with cell reselection while inactive, and tries to resume its connection in a network cell that is not associated with the gNB / CU that released it. Such action triggers a release both in the network 10 and in the UE 12 of the stored LTM related configuration(s) associated with the UE 12. Advantageously, this behavior automatically accounts for a case where the new (target) gNB / CU does not support LTM. In such cases, the target gNB / CU does not receive any LTM related configuration in the UE Inactive AS context from the previously serving gNB / CU.

[0414] In association with the foregoing example, the following text is proposed for TS 38.473, with the newly proposed text shown in bold italics.

[0415] 8.3.4 UE Context Modification (gNB-CU initiated)

[0416] 8.3.4.1 General

[0417] The purpose of the UE Context Modification procedure is to modify the established UE Context, e.g., establishing, modifying and releasing radio resources or sidelink resources. This procedure is also used to command the gNB-DU to stop data transmission for the UE for mobility (see TS 38.401 [4]). The procedure uses UE-associated signaling.

[0418] Omit text

[0419] If the LTM presence status change IE set to "suspend LTM" is included in the UE CONTEXT MODIFICATION REQUEST, the gNB-DU shall keep all lower layer including LTM configuration for UEs, and not transmit or receive data from UE. If the LTM presence status change IE set to "resume LTM" is included in the UE CONTEXT MODIFICATION REQUEST message, the gNB-DU shall use the previously stored lower layer including LTM configuration for the UE.

[0420] Omit text

[0421] 9.2.2.7 UE CONTEXT MODIFICATION REQUEST

[0422] This message is sent by the gNB-CU to provide UE Context information changes to the gNB-DU.

[0423] Direction: gNB-CU gNB-DU

[0424] Omit text

[0425] 9.3.1.x LTM Presence Status Change 9.3.1.x LTM Presence Status Change

[0426] This IE indicates lower layer including LTM configuration presence status shall be changed. Figure 8 illustrates a method 800 of operation by a UE 12 according to one or more embodiments. In particular, the method 800 is performed by a UE 12 configured for operation with respect to a telecommunications network, and it includes the UE 12: receiving (Block 802) information from the telecommunications network while the UE 12 is connected to the telecommunications network, the information indicating a lower-layer triggered mobility (LTM) configuration, for use in LTM-based mobility of the UE 12; receiving (Block 804) additional information indicating that the UE 12 is to suspend the connection with the telecommunications network; and releasing (Block 806) the LTM configuration.

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

[0428] Figure 9 illustrates a method 900 performed by a network node in a telecommunications network. For example, a gNB or gNB-CU performs the method 900 with respect to a UE 12 that is connected. The method 900 includes the network node: transmitting (Block 902) information to the UE 12, the information indicating a LTM configuration to be used by the UE for LTM- related mobility; and transmitting (Block 904) additional information to the UE that indicates that the UE is to suspend the connection with the network, whereby the UE releases the LTM configuration.

[0429] The transmission of the additional information occurs, for example, some indeterminate time after the transmission of the information indicating the LTM configuration. That is, the UE 12 and the network 10 may operate for some time while the UE 12 is connected, using the LTM configuration. Further, in at least one implementation of the method 900, the additional information is sent in a release message, indicating suspension of the connection and release of the UE 12. For example, the release message includes an implicit or explicit indication that the UE 12 is to release the LTM configuration in association with suspension of the connection. Further, in one or more embodiments, the method 900 includes the serving node and / or any other involved nodes in the network 10 releasing the LTM configuration, so that it is not reused with respect to a subsequent resumption of the connection.

[0430] Figure 10 shows an example of a communication system QQ100 in accordance with some embodiments. The communication system QQ100 is a more detailed example of the network 10, for example. The communication system QQ100 shall be understood as being configured according to the techniques described above, to maintain alignment of LTM related configuration information between UEs and the network, particularly in the context of a UE resuming its suspended connection where one or more LTM related configuration(s) are already stored for the UE, e.g., as previously determined for the UE before its suspension.

[0431] In the example, the communication system QQ100 includes a telecommunications network QQ102 that includes an access network QQ104, such as a radio access network (RAN), and a core network QQ106, which includes one or more core network nodes QQ108. The access network QQ104 includes one or more access network nodes, such as network nodes QQ110a and QQ110b (one or more of which may be generally referred to as network nodes QQ110), or any other similar 3rd Generation Partnership Project (3GPP) access nodes or non-3GPP access points. These “network nodes” may be configured as described above in the example gNB-CU / gNB-DU examples, for maintaining alignment of LTM related information for UEs resuming suspended connections.

[0432] Moreover, as will be appreciated by those of skill in the art, a network node is not necessarily limited to an implementation in which a radio portion and a baseband portion are supplied and integrated by a single vendor. Thus, it will be understood that network nodes include disaggregated implementations or portions thereof. 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 an ORAN specification (e.g., a specification published by the O-RAN Alliance, or any similar organization) and may operate alone or together with other nodes to implement one or more functionalities of any node in the telecommunications network QQ102, including one or more network nodes QQ110 and / or core network nodes QQ108.

[0433] Examples of an ORAN network node include an open radio unit (O-RU), an open distributed unit (O-DU), an open central unit (O-CU), including an O-CU control plane (O-CU- CP) or an O-CU user plane (O-CU-UP), a RAN intelligent controller (near-real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time control application (e.g., rApp), or any combination thereof (the adjective “open” designating support of an ORAN specification). The network node may support a specification by, for example, supporting an interface defined by the ORAN specification, such as an Al, Fl, Wl, El, E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an ORAN access node may be a logical node in a physical node. Furthermore, an ORAN network node may be implemented in a virtualization environment (described further below) in which one or more network functions are virtualized. For example, the virtualization environment may include an O-Cloud computing platform orchestrated by a Service Management and Orchestration Framework via an 0-2 interface defined by the O-RAN Alliance or comparable technologies. The network nodes QQ110 facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs QQ112a, QQ112b, QQ112c, and QQ112d (one or more of which may be generally referred to as UEs QQ112) to the core network QQ106 over one or more wireless connections. One or more of these UEs QQ112 shall be understood as being configured like the aforementioned UE 12, with respect to managing / handling stored LTM related configurations in the context of resuming a suspended connection.

[0434] Example wireless communications over a wireless connection include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, 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 may facilitate or participate in the communication of data and / or signals whether via wired or wireless connections. The communication system QQ100 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system.

[0435] The UEs QQ112 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and / or operable to communicate wirelessly with the network nodes QQ110 and other communication devices. Similarly, the network nodes QQ110 are arranged, capable, configured, and / or operable to communicate directly or indirectly with the UEs QQ112 and / or with other network nodes or equipment in the telecommunications network QQ102 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in the telecommunications network QQ102.

[0436] In the depicted example, the core network QQ106 connects the network nodes QQ110 to one or more hosts, such as host QQ116. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network QQ106 includes one more core network nodes (e.g., core network node QQ108) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and / or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node QQ108. Example core network nodes include functions of one or more of a 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 De-concealing function (SIDE), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and / or a User Plane Function (UPF).

[0437] The host QQ116 may be under the ownership or control of a service provider other than an operator or provider of the access network QQ104 and / or the telecommunications network QQ102, and may be operated by the service provider or on behalf of the service provider. The host QQ116 may host a variety of applications to provide one or more service. Examples of such applications include live and pre-recorded audio / video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server.

[0438] As a whole, the communication system QQ100 of Figure 10 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are 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 standards (WiFi); and / or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (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.

[0439] In some examples, the telecommunications network QQ102 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunications network QQ102 may support network slicing to provide different logical networks to different devices that are connected to the telecommunications network QQ102. For example, the telecommunications network QQ102 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and / or Massive Machine Type Communication (mMTC) / Massive loT services to yet further UEs.

[0440] In some examples, the UEs QQ112 are configured to transmit and / or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network QQ104 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network QQ104. Additionally, a UE may be configured for operating in single- or multi-RAT or multi-standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio - Dual Connectivity (EN-DC).

[0441] In the example, the hub QQ114 communicates with the 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, the hub QQ114 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub QQ114 may be a broadband router enabling access to the core network QQ106 for the UEs. As another example, the hub QQ114 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes QQ110, or by executable code, script, process, or other instructions in the hub QQ114. As another example, the hub QQ114 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub QQ114 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, the hub QQ114 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub QQ114 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In still another example, the hub QQ114 acts as a proxy server or orchestrator for the UEs, in particular if one or more of the UEs are low energy loT devices.

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

[0443] The communication system QQ100 may be configured in accordance with the techniques disclosed herein, e.g., one or more of the UEs QQ112 are configured to perform the conditional restore / delete operations described herein for LTM related configurations in the context of connection suspension / resumption. Correspondingly, one or more of the network nodes QQ110 are configured as CU / DU systems, with at least one such CU configured to perform the serving CU operations described herein. The same applies with respect to the subsequent figures, such as Figure 11.

[0444] Figure 11 shows a UE QQ200 in accordance with some embodiments. As used herein, a UE refers to a device capable, configured, arranged and / or operable to communicate wirelessly with network nodes and / or other UEs. Examples of a UE include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), wireless cameras, gaming console or device, music storage device, playback appliance, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), smart device, wireless customer-premise equipment (CPE), vehicle, vehicle-mounted or vehicle embedded / integrated wireless device, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including a narrow band internet of things (NB-IoT) UE, a machine type communication (MTC) UE, and / or an enhanced MTC (eMTC) UE.

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

[0446] The UE QQ200 includes processing circuitry QQ202 that is operatively coupled via a bus QQ204 to an input / output interface QQ206, a power source QQ208, a memory QQ210, a communication interface QQ212, and / or any other component, or any combination thereof. Certain UEs may utilize all or a subset of the components shown in Figure 11. The level of integration between the components may vary from one UE to another UE. Further, certain UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

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

[0448] In the example, the input / output interface QQ206 may be configured to provide an interface or interfaces to an input device, output device, or one or more input and / or output devices. Examples of an output device include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smartcard, another output device, or any combination thereof. An input device may allow a user to capture information into the UE QQ200. Examples of an input device include a touch- sensitive or presence- sensitive display, a camera (e.g., a digital camera, a digital video camera, a web camera, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smartcard, and the like. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. A sensor may be, for instance, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as an input device. For example, a Universal Serial Bus (USB) port may be used to provide an input device and an output device.

[0449] In some embodiments, the power source QQ208 is structured as a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet), photovoltaic device, or power cell, may be used. The power source QQ208 may further include power circuitry for delivering power from the power source QQ208 itself, and / or an external power source, to the various parts of the UE QQ200 via input circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging of the power source QQ208. Power circuitry may perform any formatting, converting, or other modification to the power from the power source QQ208 to make the power suitable for the respective components of the UE QQ200 to which power is supplied.

[0450] The memory QQ210 may be or be configured to include memory such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable readonly memory (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, the memory QQ210 includes one or more application programs QQ214, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data QQ216. The memory QQ210 may store, for use by the UE QQ200, any of a variety of various operating systems or combinations of operating systems.

[0451] The memory QQ210 may be configured to include a number of physical drive units, such as redundant array of independent disks (RAID), flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, high-density digital versatile disc (HD-DVD) optical disc drive, internal hard disk drive, Blu-Ray optical disc drive, holographic digital data storage (HDDS) optical disc drive, external mini-dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro-DIMM SDRAM, smartcard memory such as tamper resistant module in the form of a universal integrated circuit card (UICC) including one or more subscriber identity modules (SIMs), such as a USIM and / or ISIM, other memory, or any combination thereof. The UICC may for example be an embedded UICC (eUICC), integrated UICC (iUICC) or a removable UICC commonly known as ‘SIM card.’ The memory QQ210 may allow the UE QQ200 to access instructions, application programs and the like, stored on transitory or non-transitory memory media, to off-load data, or to upload data. An article of manufacture, such as one utilizing a communication system may be tangibly embodied as or in the memory QQ210, which may be or comprise a device -readable storage medium.

[0452] The processing circuitry QQ202 may be configured to communicate with an access network or other network using the communication interface QQ212. The communication interface QQ212 may comprise 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 used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or a network node in an access network). Each transceiver may include a transmitter QQ218 and / or a receiver QQ220 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth). Moreover, the transmitter QQ218 and receiver QQ220 may be coupled to one or more antennas (e.g., antenna QQ222) and may share circuit components, software or firmware, or alternatively be implemented separately.

[0453] In the illustrated embodiment, communication functions of the communication interface QQ212 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communications such as Bluetooth, near-field communication, location-based communication such as the use of the global positioning system (GPS) to determine a location, another like communication function, or any combination thereof. Communications may be implemented in according to one or more communication protocols and / or standards, such as IEEE 802.11, Code Division Multiplexing Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, transmission control protocol / internet protocol (TCP / IP), synchronous optical networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), and so forth.

[0454] Regardless of the type of sensor, a UE may provide an output of data captured by its sensors, through its communication interface QQ212, via a wireless connection to a network node. Data captured by sensors of a UE can be communicated through a wireless connection to a network node via another UE. The output may be periodic (e.g., once every 15 minutes if it reports the sensed temperature), random (e.g., to even out the load from reporting from several sensors), in response to a triggering event (e.g., when moisture is detected, an alert is sent), in response to a request (e.g., a user initiated request), or a continuous stream (e.g., a live video feed of a patient).

[0455] As another example, a UE comprises an actuator, a motor, or a switch, related to a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input the states of the actuator, the motor, or the switch may change. For example, the UE may comprise a motor that adjusts the control surfaces or rotors of a drone in flight according to the received input or to a robotic arm performing a medical procedure according to the received input.

[0456] A UE, when in the form of an Internet of Things (loT) device, may be a device for use in one or more application domains, these domains comprising, but not limited to, city wearable technology, extended industrial application and healthcare. Non-limiting examples of such an loT device are a device which is or which is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door / window sensor, a flood / moisture sensor, an electrical door lock, a connected doorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a head-mounted display for Augmented Reality (AR) or Virtual Reality (VR), a wearable for tactile augmentation or sensory enhancement, a water sprinkler, an animal- or item-tracking device, a sensor for monitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV), and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. A UE in the form of an loT device comprises circuitry and / or software in dependence of the intended application of the loT device in addition to other components as described in relation to the UE QQ200 shown in Figure 11.

[0457] As yet another specific example, in an loT scenario, a UE may represent a machine or other device that performs monitoring and / or measurements, and transmits the results of such monitoring and / or measurements to another UE and / or a network node. The UE may in this case be an M2M device, which may in a 3GPP context be referred to as an MTC device. As one particular example, the UE may implement the 3GPP NB-IoT standard. In other scenarios, a UE may represent a vehicle, such as a car, a bus, a truck, a ship and an airplane, or other equipment that is capable of monitoring and / or reporting on its operational status or other functions associated with its operation. In practice, any number of UEs may be used together with respect to a single use case. For example, a first UE might be or be integrated in a drone and provide the drone’s speed information (obtained through a speed sensor) to a second UE that is a remote controller operating the drone. When the user makes changes from the remote controller, the first UE may adjust the throttle on the drone (e.g. by controlling an actuator) to increase or decrease the drone’s speed. The first and / or the second UE can also include more than one of the functionalities described above. For example, a UE might comprise the sensor and the actuator, and handle communication of data for both the speed sensor and the actuators.

[0458] Figure 12 shows a network node QQ300 in accordance with some embodiments. As used herein, network node refers to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or equipment, 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 NodeBs (gNBs)), O-RAN nodes or components of an O-RAN node (e.g., O-RU, O-DU, O-CU).

[0459] Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and so, depending on the provided amount of coverage, may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node controlling a relay. A network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units, distributed units (e.g., in an O-RAN access node) and / or remote radio units (RRUs), sometimes referred to as Remote Radio Heads (RRHs). Such remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS).

[0460] Other examples of network nodes include multiple transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi-cell / multicast coordination entities (MCEs), Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes, Self- Organizing Network (SON) nodes, positioning nodes (e.g., Evolved Serving Mobile Location Centers (E-SMLCs)), and / or Minimization of Drive Tests (MDTs).

[0461] The network node QQ300 includes a processing circuitry QQ302, a memory QQ304, a communication interface QQ306, and a power source QQ308. The network node QQ300 may be composed of multiple physically separate components (e.g., a NodeB component and a RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components. In certain scenarios in which the network node QQ300 comprises multiple separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, the network node QQ300 may 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., a same antenna QQ310 may be shared by different RATs). The network node QQ300 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node QQ300, for example 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 chip or set of chips and other components within network node QQ300.

[0462] The processing circuitry QQ302 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application- specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and / or encoded logic operable to provide, either alone or in conjunction with other network node QQ300 components, such as the memory QQ304, to provide network node QQ300 functionality.

[0463] In some embodiments, the processing circuitry QQ302 includes a system on a chip (SOC). In some embodiments, the processing circuitry QQ302 includes one or more of radio frequency (RF) transceiver circuitry QQ312 and baseband processing circuitry QQ314. In some embodiments, the radio frequency (RF) transceiver circuitry QQ312 and the baseband processing circuitry QQ314 may be on separate chips (or sets of chips), boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry QQ312 and baseband processing circuitry QQ314 may be on the same chip or set of chips, boards, or units.

[0464] The memory QQ304 may comprise any form of volatile or non-volatile computer- readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory devices that store information, data, and / or instructions that may be used by the processing circuitry QQ302. The memory QQ304 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and / or other instructions capable of being executed by the processing circuitry QQ302 and utilized by the network node QQ300. The memory QQ304 may be used to store any calculations made by the processing circuitry QQ302 and / or any data received via the communication interface QQ306. In some embodiments, the processing circuitry QQ302 and memory QQ304 is integrated.

[0465] The communication interface QQ306 is used in wired or wireless communication of signaling and / or data between a network node, access network, and / or UE. As illustrated, the communication interface QQ306 comprises port(s) / terminal(s) QQ316 to send and receive data, for example to and from a network over a wired connection. The communication interface QQ306 also includes radio front-end circuitry QQ318 that may be coupled to, or in certain embodiments a part of, the antenna QQ310. Radio front-end circuitry QQ318 comprises filters QQ320 and amplifiers QQ322. The radio front-end circuitry QQ318 may be connected to an antenna QQ310 and processing circuitry QQ302. The radio front-end circuitry may be configured to condition signals communicated between antenna QQ310 and processing circuitry QQ302. The radio front-end circuitry QQ318 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. The radio front-end circuitry QQ318 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters QQ320 and / or amplifiers QQ322. The radio signal may then be transmitted via the antenna QQ310. Similarly, when receiving data, the antenna QQ310 may collect radio signals which are then converted into digital data by the radio front-end circuitry QQ318. The digital data may be passed to the processing circuitry QQ302. In other embodiments, the communication interface may comprise different components and / or different combinations of components.

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

[0467] The antenna QQ310 may include one or more antennas, or antenna arrays, configured to send and / or receive wireless signals. The antenna QQ310 may be coupled to the radio front-end circuitry QQ318 and may be any type of antenna capable of transmitting and receiving data and / or signals wirelessly. In certain embodiments, the antenna QQ310 is separate from the network node QQ300 and connectable to the network node QQ300 through an interface or port.

[0468] The antenna QQ310, communication interface QQ306, and / or the processing circuitry QQ302 may be configured to perform any receiving operations and / or certain obtaining operations described herein as being performed by the network node. Any information, data and / or signals may be received from a UE, another network node and / or any other network equipment. Similarly, the antenna QQ310, the communication interface QQ306, and / or the processing circuitry QQ302 may be configured to perform any transmitting operations described herein as being performed by the network node. Any information, data and / or signals may be transmitted to a UE, another network node and / or any other network equipment.

[0469] The power source QQ308 provides power to the various components of network node QQ300 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). The power source QQ308 may further comprise, or be coupled to, power management circuitry to supply the components of the network node QQ300 with power for performing the functionality described herein. For example, the network node QQ300 may be connectable to an external power source (e.g., the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source QQ308. As a further example, the power source QQ308 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail.

[0470] Embodiments of the network node QQ300 may include additional components beyond those shown in Figure 12 for providing certain aspects of the network node’s functionality, including any of the functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, the network node QQ300 may include user interface equipment to allow input of information into the network node QQ300 and to allow output of information from the network node QQ300. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node QQ300.

[0471] Although the computing devices described herein (e.g., UEs, and network nodes) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and / or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and / or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination.

[0472] Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

[0473] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain 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 the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer- readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally.

[0474] Further, it should be appreciated that a “network node” may be implemented in a virtualized processing environment, such as in cloud data center. For example, in a CU / DU split environment, at least the CU may be implemented using virtualized processing, memory, and interface resources in a data-center computing environment.

Claims

CLAIMSWhat is claimed is:

1. A method performed by a user equipment (UE) configured for operation with respect to a telecommunications network, the method comprising: receiving information from the telecommunications network while the UE is connected to the telecommunications network, the information indicating a lower-layer triggered mobility (LTM) configuration, for use in LTM-based mobility of the UE; receiving additional information from the telecommunications network, the additional information indicating the UE is to suspend the connection to the telecommunications network; and releasing the LTM configuration.

2. The method of claim 1, wherein the additional information is a release message.

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

4. The method of claim 3, wherein the indication is implicit.

5. The method of claim 3, wherein the indication is explicit.

6. The method of any one of claims 1-5, wherein the method further includes: the UE receiving a resume message from the telecommunications network, where the resume message indicates a new LTM configuration to be used by the UE for LTM-related mobility with respect to the resumed connection; and beginning LTM-related operations with respect to the resumed connection, in accordance with the new LTM configuration.

7. The method of any one of claims 1-6, wherein the method further includes the UE: entering an inactive state in association with the connection being suspended and releasing the LTM configuration; while in the inactive state, transmitting a request to resume the connection;receiving a response to the request, resuming the connection and indicating a new LTM configuration to be used by the UE for LTM-related mobility; and entering an active state and using the new LTM configuration in the active state.

8. The method of any one of claims 1-6, wherein the telecommunications network comprises a Third Generation Partnership Project (3GPP) wireless communications network.

9. The method of claim 8, wherein the 3GPP wireless communications network comprises a Fifth Generation (5G) cellular network.

10. The method of any one of claims 1-9, wherein the LTM configuration comprises a first set of LTM related configuration(s).

11. The method according to any one of claims 1-10, wherein the LTM configuration comprises any one or more of: one or more lower layer Channel State Information (CSI) measurement configurations for LTM; one or more Uplink (UL) pre-sync configurations; one or more Downlink (DL) pre- sync configurations; one or more LTM candidate cell configurations; one or more complete LTM candidate configurations generated when the UE is configured with LTM; or a LTM reference configuration.

12. A method performed by a network node in a telecommunications network, the method comprising: transmitting a lower-layer triggered mobility (LTM) configuration to a user equipment (UE) that is connected to the telecommunications network; and transmitting additional information to the UE, the additional information indicating that the UE is to suspend the connection to the telecommunications network, whereby the UE releases the LTM configuration.

13. The method of claim 12, wherein transmitting the additional information comprises transmitting a release message to the UE, where the release message indicates that the UE should release the LTM configuration.

14. The method of claim 13, wherein the indication is an explicit indication.

15. The method of claim 13, wherein the indication is an implicit indication.

16. The method of claim 13, wherein the release message is a RRC Release message and the indication is an information element in the RRC release message.

17. The method of any of claims 10-16, wherein the method further includes the network node subsequently sending a resume message to the UE for resumption of the connection and including in the resume message a new LTM configuration to be used by the UE for LTM- related mobility with respect to the resumed connection.

18. A user equipment (UE) configured for operation in a telecommunications network, the UE comprising: a communication interface configured for communicating with a network node of the telecommunications network; and processing circuitry configured to: receive, via the communication interface, information from the telecommunications network while the UE is connected to the telecommunications network, the information indicating a lower-layer triggered mobility (LTM) configuration, for use in LTM-based mobility of the UE; receive, via the communication interface, additional information from the telecommunications network, the additional information indicating that the UE is to suspend the connection with the telecommunications network; and release the LTM configuration.

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

20. A network node configured for operation in a telecommunications network, the network node comprising:a communication interface configured for communicating directly or indirectly with a user equipment (UE) having a connection to the telecommunications network; and processing circuitry configured to: transmit, via the communication interface, a lower-layer triggered mobility (LTM) configuration to the UE; and transmit, via the communication interface, additional information indicating that the UE is to suspend the connection to the telecommunications network, whereby the UE releases the LTM configuration.

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

Images