WO2025172019A1

WO2025172019A1 - Conditional handover (cho) with lower layer triggered mobility (ltm)

Info

Publication number: WO2025172019A1
Application number: PCT/EP2025/051726
Authority: WO
Inventors: Hans Thomas HÖHNE; Endrit DOSTI; Panagiotis SPAPIS; Prasna Kumar SAHU; Jedrzej STANCZAK
Original assignee: Nokia Technologies Oy
Current assignee: Nokia Technologies Oy
Priority date: 2024-02-16
Filing date: 2025-01-24
Publication date: 2025-08-21
Anticipated expiration: 2026-08-16

Abstract

An apparatus comprising means for: receiving a conditional handover configuration comprising an execution condition for conditional handover; AND a conditional handover configuration identifier, and an associated conditional handover configuration identifier of a previously received conditional handover configuration for accessing a lower layer triggered mobility (LTM) configuration.

Description

TITLE

Conditional Handover (CHO) with Lower layer Triggered Mobility (LTM)

TECHNOLOGICAL FIELD

Examples of the disclosure relate to configuring conditional Handover (CHO) and Lower layer Triggered Mobility (LTM)

BACKGROUND

Lower layer Triggered Mobility (LTM) allows the trigger connection establishment with a new cell using signal at layers below layer 3. A serving distributed unit (DU) asks (considering Layer 1 measurements) a user equipment (UE) to perform timing advance (TA) acquisition for a specific target cell. The UE can maintain LTM configurations of target cells.

Conditional Handover (CHO) ensures robustness of a handover procedure. The serving cell prepares multiple target cells, and the related conditional reconfigurations along with CHO execution conditions are provided beforehand to the UE. The UE evaluates the CHO execution conditions and initiates the handover to a specific target cell once its corresponding CHO execution condition is met.

Improvements in LTM and CHO configuration are desired.

BRIEF SUMMARY

According to various, but not necessarily all, examples there is provided examples as claimed.

According to various, but not necessarily all, embodiments there is provided an apparatus comprising means for performing at least part of one or more methods described herein. The description of a function and/or action should additionally be considered to also disclose any means suitable for performing that function and/or action. Functions and/or actions described herein can be performed in any suitable way using any suitable method. According to various, but not necessarily all, embodiments there is provided examples as claimed in the appended claims.

According to various examples, an apparatus is configured to receive a first conditional handover configuration comprising: an execution condition for conditional handover; a conditional handover configuration identifier; information to enable a multi-cell operation comprising a conditional handover configuration identifier of a previously received conditional handover configuration for accessing a lower layer triggered mobility (LTM) configuration.

According to various examples, an apparatus is configured to: receive a first conditional handover configuration; receive a second conditional handover configuration; in response to satisfaction of an execution condition for conditional handover comprised in the first conditional handover configuration, applying the first conditional handover configuration to enable handover to a cell and flushing the second conditional handover configuration; store information comprised in the second conditional handover configuration before flushing the second conditional handover configuration.

According to various examples, an apparatus is configured to: receive a first conditional handover configuration comprising lower layer triggered mobility (LTM) configuration information to enable lower layer triggered connection establishment; receive a second conditional handover configuration comprising lower layer triggered mobility (LTM) configuration information to enable lower layer triggered connection establishment; in response to satisfaction of an execution condition for conditional handover comprised in the first conditional handover configuration, applying the first conditional handover configuration to enable handover and flushing the second conditional handover configuration; before flushing the second conditional handover configuration, storing lower layer triggered mobility (LTM) configuration information comprised in the second conditional handover configuration or information linked via the lower layer triggered mobility (LTM) configuration information comprised in the second conditional handover configuration

While the above examples of the disclosure and optional features are described separately, it is to be understood that their provision in all possible combinations and permutations is contained within the disclosure. It is to be understood that various examples of the disclosure can comprise any or all the features described in respect of other examples of the disclosure, and vice versa. Also, it is to be appreciated that any one or more or all the features, in any combination, may be implemented by/comprised in/performable by an apparatus, a method, and/or computer program instructions as desired, and as appropriate. The description of a function should additionally be considered to also disclose any means suitable for performing that function

BRIEF DESCRIPTION

Some examples will now be described with reference to the accompanying drawings in which:

FIGs. 1 to 16 show examples of the subject matter described herein.

The figures are not necessarily to scale. Certain features and views of the figures can be shown schematically or exaggerated in scale in the interest of clarity and conciseness. For example, the dimensions of some elements in the figures can be exaggerated relative to other elements to aid explication. Similar reference numerals are used in the figures to designate similar features. For clarity, all reference numerals are not necessarily displayed in all figures.

DETAILED DESCRIPTION

FIG 1 and FIG 2 illustrate lower layer triggered mobility (LTM) configuration information 216.

A lower layer triggered mobility (LTM) configuration is a configuration for user equipment that enables base station triggering of a cell change using signaling at a layer lower than layer 3 (Radio Resource Control). In FIG. 1, the lower layer triggered mobility (LTM) configuration information 216 comprises a lower layer triggered mobility (LTM) configuration 220 that enables triggering of a cell change using signaling at a layer lower than layer 3

In FIG. 2, the lower layer triggered mobility (LTM) configuration information 216 comprises a link 202 to a lower layer triggered mobility (LTM) configuration 220 that enables triggering of a cell change using signaling at a layer lower than layer 3.

The lower layer triggered mobility (LTM) configuration can be defined using absolute values specified for a target cell or can be defined using relative values specified for a target cell, as deltas, that are relative to shared reference values.

FIG. 3 illustrates a conditional handover configuration 210 supporting lower layer triggered mobility (LTM). The conditional handover configuration 210 comprises: an execution condition 212 for conditional handover; a conditional handover configuration identifier 214_1 , and lower layer triggered mobility (LTM) configuration information 216 to enable lower layer triggered connection establishment.

The lower layer triggered mobility (LTM) configuration information 216 can comprise a lower layer triggered mobility (LTM) configuration 220 that enables triggering of a cell change using signaling at a layer lower than layer 3 (FIG. 1) or can comprise a link 202 to a lower layer triggered mobility (LTM) configuration that enables triggering of a cell change using signaling at a layer lower than layer 3.

The link 202 can be also signaled outside the LTM-Config Info as part of the CHO Config 210.

FIG. 4 illustrates an example, where a lower layer triggered mobility (LTM) configuration 220 is stored in a memory.

The user equipment receives from a base station a conditional handover configuration 210_1 comprising: an execution condition 212_1 for conditional handover; a conditional handover configuration identifier 214_1 ; and lower layer triggered mobility (LTM) configuration information 216_1 to enable lower layer triggered connection establishment comprising a lower layer triggered mobility (LTM) configuration 220_1.

The user equipment stores the lower layer triggered mobility (LTM) configuration 220_1 for access via a value of the conditional handover configuration identifier 214_1.

In this example, the lower layer triggered mobility (LTM) configuration 220_1 from the conditional handover configuration 210_1 is associated with the value of the conditional handover configuration identifier 214_1 from the same conditional handover configuration 210_1. That value of the conditional handover configuration identifier 214_1 can be used as an index in future to access (retrieve) that the conditional handover configuration 210_1 .

The conditional handover configuration 210_1 is also stored to memory. The procedure for conditional handover defines conditions when the stored conditional handover configuration 210_1 is flushed (removed) from the memory.

The storage of the lower layer triggered mobility (LTM) configuration 220_1 i the memory 204 in association with the value of the conditional handover configuration identifier 214_1 occurs before the stored conditional handover configuration 210_1 is flushed (removed) from the memory. The storage can, for example, occur early, at or just after reception of the conditional handover configuration 210_1. The storage can, for example, occur late, just before the flushing of the conditional handover configuration 210_1 from the memory.

The memory 204 therefore stores a previously received lower layer triggered mobility (LTM) configuration 220_1 in association with a previously received conditional handover configuration identifier 214_1. The value of the conditional handover configuration identifier 214_1 of the previously received conditional handover configuration 210_1 can be used for accessing the associated lower layer triggered mobility (LTM) configuration 220_1.

FIG. 5 illustrates an example, where a lower layer triggered mobility (LTM) configuration 220 is retrieved from a memory where it has been stored. The user equipment receives from a base station a conditional handover configuration 210_2 comprising: an execution condition 212_2 for conditional handover; a conditional handover configuration identifier 214_2.

The user equipment also receives a conditional handover configuration identifier 214_1 of a previously received conditional handover configuration 210_1 for accessing a stored lower layer triggered mobility (LTM) configuration 220_1.

The value of the conditional handover configuration identifier 214_1 of a previously received conditional handover configuration 210_1 is used for accessing the stored a lower layer triggered mobility (LTM) configuration 220_1.

The lower layer triggered mobility (LTM) configuration 220_1 is a previously received and stored lower layer triggered mobility (LTM) configuration 220_1 that is being reused

The conditional handover configuration identifier 214_2 of the previously received conditional handover configuration 210_1 is an index for accessing the stored lower layer triggered mobility (LTM) configuration 220_1.

The allocation and use of the index is tracked and controlled by the base station.

In some examples, the conditional handover configuration identifier 214_1 of the previously received conditional handover configuration 210_1 for accessing a stored lower layer triggered mobility (LTM) configuration 220_1 is received within the a conditional handover configuration 210_2.

The user equipment receives from a base station a conditional handover configuration 210_2 comprising: an execution condition 212_2 for conditional handover; a conditional handover configuration identifier 214_2; and lower layer triggered mobility (LTM) configuration information 216_2 to enable lower layer triggered connection establishment comprising the conditional handover configuration identifier 214_1 of the previously received conditional handover configuration 210_1 for accessing a lower layer triggered mobility (LTM) configuration 220_1. In some examples, an information element 230 (not illustrated) comprises the conditional handover configuration 210_2 and comprises, inside the conditional handover configuration 210_2, the (value of) the conditional handover configuration identifier 214_1 of the previously received conditional handover configuration 210_1 for accessing a lower layer triggered mobility (LTM) configuration 220.

In some examples, an information element 230 (not illustrated) comprises the conditional handover configuration 210_2 and comprises, outside the conditional handover configuration 210_2, the (value of) the conditional handover configuration identifier 214_1 of the previously received conditional handover configuration 210_1 for accessing a lower layer triggered mobility (LTM) configuration 220.

It will be appreciated that the (value of the) previously received conditional handover configuration identifier 210_1 provides a link 202_2 for accessing at least a part of the lower layer triggered mobility (LTM) configuration 220_1. The link 220_2 can be inside the conditional handover configuration 210_2 as illustrated in FIG 5. Alternatively, the link 220_2 can be outside the conditional handover configuration 210_2 but inside the information element comprising the conditional handover configuration 210_2 (not illustrated).

The previously received conditional handover configuration identifier 220_1 is from the previously received, stored then flushed conditional handover configuration 210_1.

FIG. 6 illustrates an example, where lower layer triggered mobility (LTM) configurations 220 are stored in a memory.

The first conditional handover configuration 210_1A comprises: a first execution condition 212_1A for conditional handover; a first conditional handover configuration identifier 214_1 A; first lower layer triggered mobility (LTM) configuration information 216_1A to enable lower layer triggered connection establishment comprising a first lower layer triggered mobility (LTM) configuration 220_1A.

The second conditional handover configuration 210_1 B comprises: a second execution condition 212_1 B for conditional handover; a second conditional handover configuration identifier 214_1B; second lower layer triggered mobility (LTM) configuration information 216_1B to enable lower layer triggered connection establishment comprising a second lower layer triggered mobility (LTM) configuration 220_1B.

The user equipment receives from a base station the first conditional handover configuration 210_1A comprising the first lower layer triggered mobility (LTM) configuration information 216_1A to enable lower layer triggered connection establishment. The user equipment stores the first conditional handover configuration 210_1A. The user equipment stores the first lower layer triggered mobility (LTM) configuration 220_1 A in the memory for access via a value of the first conditional handover configuration identifier 214_1A.

The user equipment receives from the base station the second conditional handover configuration 210_1B comprising the second lower layer triggered mobility (LTM) configuration information 216_1B to enable lower layer triggered connection establishment. The user equipment stores the second conditional handover configuration 210_1 B. The user equipment stores the second lower layer triggered mobility (LTM) configuration 220_1 B in the memory for access via a value of the second conditional handover configuration identifier 214_1B.

In response to satisfaction of the first execution condition 212_1A for conditional handover comprised in the first conditional handover configuration 210_1A, the user equipment applies the first conditional handover configuration 210_1A to enable handover and flushes the stored second conditional handover configuration 210_1B. in response to satisfaction of the second execution condition 212_1B for conditional handover comprised in the second conditional handover configuration 210_1B, the user equipment applies the second conditional handover configuration 210_1B to enable handover and flushes the stored first conditional handover configuration 210_1A.

The process can therefore comprise, before flushing the second conditional handover configuration 210_1B, storing, for access via a value of the second conditional handover configuration identifier 214_1B comprised in the second conditional handover configuration 210_1 B, the first lower layer triggered mobility (LTM) configuration 220_1 A, comprised in the first lower layer triggered mobility (LTM) configuration information 216_1A.

The method can therefore comprise, before flushing the first conditional handover configuration 210_1A, storing, for access via a value of the first conditional handover configuration identifier 214_1 A comprised in the first conditional handover configuration 210_1A, the second lower layer triggered mobility (LTM) configuration 220_1 B, comprised in the second lower layer triggered mobility (LTM) configuration information 216_1B.

In some examples, it is desirable to provide duplication control at the user equipment. In this example, the user equipment is already storing the (values of the) a currently received lower layer triggered mobility (LTM) configuration 220_i for access via a value of a previously received conditional handover configuration identifier 214_1. The use equipment is configured to associate the already stored lower layer triggered mobility (LTM) configuration 220_i for access via a value of the conditional handover configuration identifier 214_2 the currently received conditional handover configuration 210_2. In some examples, the user equipment receives a duplication indicator in association with the currently received conditional handover configuration 210_2 that controls storage.

In some examples, the user equipment receives an expiry indicator in association with the currently received conditional handover configuration 210_2 that controls expiry of storage.

FIG. 7A and 7B are similar to FIG 5, and illustrate retrieval of the lower layer triggered mobility (LTM) configuration 220 stored in FIG 6.

Referring to FIG 7A, the user equipment receives from a base station a conditional handover configuration 210_2A comprising: an execution condition 212_2A for conditional handover; a conditional handover configuration identifier 214_2A and also receives a conditional handover configuration identifier 214_1A of a previously received conditional handover configuration 210_1A for accessing a stored lower layer triggered mobility (LTM) configuration 220_1A. The value of the conditional handover configuration identifier 214_1 A of a previously received conditional handover configuration 210_1A is used for accessing the stored a lower layer triggered mobility (LTM) configuration 220_1A.

Referring to FIG 7B, the user equipment receives from a base station a conditional handover configuration 210_2B comprising: an execution condition 212_2B for conditional handover; a conditional handover configuration identifier 214_2B and also a conditional handover configuration identifier 214_1B of a previously received conditional handover configuration 210_1 B for accessing a stored lower layer triggered mobility (LTM) configuration 220_1B.

The value of the conditional handover configuration identifier 214_1 B of the previously received conditional handover configuration 210_1B is used for accessing the stored a lower layer triggered mobility (LTM) configuration 220_1B.

FIG 8 maps the components of the conditional handover configuration 210 comprising lower layer triggered mobility (LTM) configuration information 216 that comprises a link 202 to a lower layer triggered mobility (LTM) configuration 220 to features of the current 2GPP specifications.

FIG 9A maps the components of the conditional handover configuration 210 comprising lower layer triggered mobility (LTM) configuration information 216 that comprises a lower layer triggered mobility (LTM) configuration 220 to features of the current 2GPP specifications.

The ConditionalReconfiguration Information element 230 comprises a CondReconfigToAddMod information element 210, comprising: cond Reconfig Id 214 an execution condition 212 (e.g. condExecutionCond) for conditional handover a RRCReconfiguration information element (condRRCReconfig) 216 comprising: a LTM configuration 220 (LTM-Config) or a link 202 (CondReconfigld) for accessing a LTM Configuration. In FIG 9B, the CondReconfigToAddMod information element 210 (not the RRCReconfiguration information element 216) comprises: a link 202 (CondReconfigld) for accessing a LTM Configuration 220.

Therefore the message element CondReconfigToAddMod can contain an element condRRCReconfig. condRRCReconfig is of type RRCReconfiguration. RRCReconfiguration is a top-level configuration message to setup a connection between UE 110 and base station 120. It is included in the condRRCReconfig to be applied when the UE has made the cell handover decision. It may include also LTM- Config. The element condRRCReconfig can contain Itm-Config (FIGs 8, 9A). Itm- Config is of type LTM-Config (FIG 8) or Itm-Config is of type CondReconfld (FIG 9A).The message element CondReconfigToAddMod can contain Itm-Config (FIG 9B). Itm-Config can be of type LTM-Config or of type CondReconfld.

In FIGs 8, 9A, 9B, the conditional handover configuration 210 (CondReconfigToAddMod) contains LTM configuration information 216 (condRRCReconfig, Itm-Configld). The LTM configuration information 216 can be or contain a link 202 to a LTM configuration 220. The LTM configuration information 216 can be or contain LTM configuration 220

The conditional handover configuration 210 is provided by the CondReconfigToAddMod information element. The conditional handover configuration identifier 214 is provided by condReconfigld. The lower layer triggered mobility (LTM) configuration information 216 is provided by the RRCReconfiguration information element (condRRCReconfig).

FIG 10 illustrates a storage method 100.

At block 102, the method 100 takes the first conditional handover configuration 210 (CondReconfigToAddMod IE)

At block 104, the method 100 determines whether or not the conditional handover configuration 210 comprises LTM configuration information 216 comprising a LTM Configuration 220. That is whether or not the current CondReconfigToAddMod IE contains Itm-Config of type LTM-Config.

At block 106, the method 100 stores the LTM Configuration 220. It stores Itm-Config to varStoreLTM.

The blocks 108, 110, 112 control cycling the same method through the available conditional handover configurations 210 (CondReconfigToAddMod lEs)

FIG 11 illustrates a storage method 120. It continues at block 122 from the block 112 of the method 100 illustrated in FIG 10.

At block 124, the method 120 takes the first conditional handover configuration 210 (CondReconfigToAddMod IE)

At block 126, the method 120 determines whether or not the conditional handover configuration 210 comprises LTM configuration information 216 comprising a link 202 to a LTM Configuration.

That is whether or not the current CondReconfigToAddMod IE contains Itm-Config of type CondReconfigld. In another embodiment where the link 202 is placed inside CHO Config 210, the block 126 checks for the presence of 202 in 210.

At block 128, the method 120 uses the link 202 to obtain a LTM Configuration 220 and replaces the link 202 with the retrieved LTM Configuration 220.. In another embodiment where 202 is contained in 210, the method 120 uses link 202 to obtain a LTM configuration 220 and create/copy it to the -Itm config info 216 for further processing in block 130.

At block 130, further processing is carried not specific to this description..

The blocks 132, 136, 134control cycling the same method through the available conditional handover configurations 210 (CondReconfigToAddMod lEs)

Lower layer Triggered Mobility (LTM), according to the latest 3GPP agreements is split in four phases:

Preparation: during which a serving central unit (CU) identifies the potential targets based on the Layer 3 measurement reports, prepares the target cells, and shares the target cell configurations with the user equipment (UE).

Early Synchronization: during which the serving distributed unit (DU) asks (considering Layer 1 measurements) the UE to perform timing advance (TA) acquisition for a specific target cell. Execution: during which the serving DU decides (considering Layer 1 measurements) on the target cell and asks the UE to switch to that. The latter switches to that cell and starts receiving data from it.

Completion: during which the UE context is released from the prepared cells. This is optional and the UE context may be kept in case of Dynamic Switching. It is up to the CU on how long the UE context will be maintained.

In case the UE maintains the configurations of the target cell it is allowed to perform multiple/subsequent LTM operations. This is called subsequent LTM.

Conditional Handover (CHO) ensures robustness of a handover procedure. In brief, in CHO the serving cell prepares multiple target cells and the related conditional reconfigurations along with CHO execution conditions are provided beforehand to the UE, so as to ensure that the radio conditions are still adequate for the UE to receive the reconfiguration. Then the UE evaluates the CHO execution conditions and initiates the handover to a specific target cell once its corresponding CHO execution condition is met.

Initially a configured event triggers the UE to send a measurement report. Based on this report, the source node prepares one or more target cells for the handover (CHO Request + CHO Request Acknowledge) and then sends an RRC Reconfiguration (CHO command) to the UE. The UE evaluates the CHO execution conditions and accesses the target cell once one of the conditions is met. The CHO preparation and execution phases are decoupled.

Once the UE completes the handover execution to the target cell (e.g., UE has sent RRC Reconfiguration Complete), the target cell sends to the source node “Handover Success” indication. Then, the source node stops transmissions to the UE and starts data forwarding the user plane packets to target cell. The source may release the CHO preparations in other target nodes/cells (which are no longer needed) when it receives “HO Success” indication.

LTM targets intra CU mobility. Layer 3 mobility can deal with both intra and inter CU mobility. However, nothing prevents the base station (gNB) configuring both of them at the same time. Additionally, nothing prevents the target gNB configuring LTM at the time of Layer 3 mobility configuration.

Let cells 1.1 and 1.2 belong to DU1 and are controlled by Source CU. Let target cells 2.1 and 2.2 belong to Du 2, controlled by Target DU. Let target cells 3.1 and 3.2 belong to Du 3, controlled by Target DU.

A UE is configured with LTM in cells 1.1 and 1.2 which belong to DU1 , controlled by Source CU. Based on the UE measurements Source CU configures L3 mobility (Baseline HO or CHO) for target CU (which controls DU2 (with cells 2.1 and 2.2) and DU3 (with cells 3.1 and 3.2). In this scenario, Target DU has two options, either to configure L3 mobility for the UE to go to cell 2.1 (based on the UE L3 measurements) and then configure (if it wishes to do so) LTM for the intra CU cells (i.e., cells 2.1 , 2.2, 3.1 , 3.1) or configure at the same time both L3 mobility and LTM, and have in the target cell configuration of the L3 handover command (RRC Configuration) the LTM configuration of these cells belonging to Target CU.

Further, the target CU may split the LTM cell groups to two different LTM configurations, one for cells 2.1 and 2.2, and one for 3.1 and 3.2. The rational can be easier management inside one DU, or the number of cells that are within one group (that is if there are not only cells 2.1 , 2.2, but also 2.3.. 2.8 and 3.1..3.8).

We provide this explanation using the CU-DU split to motivate the usage of configurations. However, the scenario is also applicable to architectures supporting LTM and CHO.

Following this approach, the UE will switch to the target CU and upon connected to cell 2.1 it will be able to operate with LTM in cells 2.1 , 2.2, 3.1 and 3.2 (including subsequent LTM).

The RRC Configuration provided to a UE for LTM comprises a LTM Configuration IE.

This can contain: a reference configuration which is common for all target cells a list of delta configurations (one for each target cell), which contains the delta (cellspecific) configuration of each target cell with regards to the reference. Note that the delta combined with the reference will comprise a complete configuration, which when the UE applies will be able to access the target cell.

A CSI resource config IE which contains the target cells beam configuration

The UE will apply the target cell delta configuration on top of the reference configuration, and it will create a configuration comprising all protocol configurations for the LTM candidate cell. It is up to the UE implementation when to apply the target cell configurations on top of the reference.

When a UE has executed a CHO condition, it is required to flush all other CHO conditions that did not get executed. Further, if a UE performs fast recovery using CHO conditions, it is required to flush all other CHO conditions. This is needed because all CHO candidate configs are given as deltas over the serving cell config. If the serving cell changes, then the delta configs that were given become obsolete.

However, this is different in case of LTM, because the candidate configs are given as deltas over a reference configuration, which is set up by the NW.

Flushing CHO conditions, flushes the LTM-Config that were not executed.

The network cannot configure new CHO conditions for the UE, involving a flushed the LTM-Config.

The examples described propose enhancements in the RRC Reconfiguration message structure, in order to reduce the flushing and re-signaling of LTM-Config information elements when the UE is configured at the same time with LTM and L3 mobility (CHO).

The solution is applicable to the currently standardized CHO+LTM configuration structure.

The UE-side solution steps are described as follows:

• UE receives and RRC Configuration containing one or more CHO configurations with the respective CHO conditions

• UE stores the LTM configurations contained within the CHO configuration conditions to a new UE variable (e.g. varStoreLTMConfig)

• Optional: UE receives from NW a list of LTM reference configurations and stores those in new UE variable varStoreLTMConfig • UE stores the CHO configuration and CHO conditions to VarConditional Reconfig, as specified in R16.

• In case the CHO conditions contain links to LTM-Configs, UE may process the link now or at a later time.

• UE carries out CHO,

• UE applies contents of VarConditional Reconfig:

• In case the CHO condition contained in RRCReconfig contains links UE dereferences the pointers using the varStoreLTMConfig.

• UE flushes other CHO conditions (as in R16).

• if the UE has not yet stored the LTM-Configs of the CHO conditions it saves them into the UE variable varStoreLTMConfig, before the flush

• The network side solution steps are described as follows:

• Optional: NW provides LTM reference config

• NW configured CHO cond contains pointer to LTM reference config

• NW may reference the UE saved reference LTM-Config when configuring a new CHO to the UE

• NW managing duplicate LTM-Configs:

• If there are multiple CHO conditions using the same LTM-Config, during UE flush operation UE would not need to store duplicate LTM-Configs

• NW may indicate that LTM-Config does not need saving (Boolean in CHO condition)

• NW keeps track what is stored at the UE

• The condition for the NW to reference one of several reference configurations stored in the UE is that UE and NW have same understanding what the UE has stored.

If UE uses the network provided CondReconfigID to store, then there will be no ambiguity. FIG 12 illustrates a method 140 as a signaling flow diagram, for the case where normal configuration signaling is used, without the signaling optimizations. The method illustrates UE storing an LTM-Config and then later accessing it.

At Step 1 : the network configures a CHO to the containing multiple CHO conditions. The structure of the configuration may be as already existing definitions , or may include the optional field indicating CHO conditions containing duplicate LTM configurations.

Step 2 : the UE saves the NW configuration.

Step 2.1 : the UE stores the CHO configuration to the UE’s varConditionalReconfig.

Step 2.2: Additionally, it stores the LTM-Config contained within a CHO condition to a separate new UE variable varStoreLTMConfig, see FIG. 13. The saving to that variable uses the condReconfigID of the CHO condition to index the LTM Config inside the variable. The saving to that variable may be conditioned to the presence of a duplicate flag. A time stamp may be associated with a stored configuration to facilitate erasing the variable without network signaling.

The step 2.2 can be alternatively executed alongside step 4 of UE flushing nonexecuted CHO conditions. In that case the UE should store to the varStoreLTMConfig not only the flushed configurations, but also the applied LTM- Config, as it might be referenced for future CHO conditions by the network.

In case the LTM config contains a Reference Config then the UE can apply the target cell delta on top of the reference and create a complete configuration, to ensure that only one Reference configuration is maintained in the UE.

Step 3: One of the CHO conditions is fulfilled, and the UE executes it. The UE applies the target cell condRRCReconfig which contains also an LTM-Config. LTM- config is applied as well.

At the end of the CHO execution the UE will send as usual a RRCReconfigurationComplete to the network.

Step 4: Step 4 may be happening before the UE sends RRCReconfigurationComplete. The UE flushes the CHO conditions which were not executed. If step 2.2 was not carried out after 2.1 it can be carried out now.

Step 5: CHO conditions were flushed, but the LTM configurations have been saved to the local UE variable varStoreLTMConfig Some time may pass. Step 6: the NW decides to configure a new CHO with several CHO conditions to the UE. At this point, the network knows that the UE has stored not only the active LTM- Config B, but also the LTM-Config A. Therefore, the CHO conditions only need to contain a pointer to the LTM-Config which are stored in the UE.

Step 7: The UE saves the configuration received by the network. In more detail: Approach 1 : “de-reference at application time” .

Step 7: UE stores the CHO configuration and the links to LTM configurations contained within in the varConditionalReconfig.

Approach 2: “de-reference at storing time”.

Step 7: de-reference links to LTM-Config before saving them to varConditionalReconfig

Step 8: UE stores the LTM config of the CHO conditions as described in step 2.2 to varStoreLTMConfig. It will overwrite existing entries for the respective condReconfigID.

Step 9: Again a CHO condition is met, this time one that contains the LTM-Config B. Approach 1 : before applying the CHO configuration the link contained within is replaced by the contents of the UE local variable.

Approach 2: apply CHO configuration normally

Step 10: further CHO steps outside the scope of the proposed method

FIG 1 is a graphical presentation of a CHO configuration comprising a LTM-Config and storing it to a local UE variable.

The following provides details how the configuration messages and procedures to process them can be designed.

For the signaling optimization, the CHO configuration

Conditional Reconfiguration ->condReconfigToAddModList->condReconfigToAddMod -^condRRCReconfig -^LTM-Config should be able to include an LTM-Config via pointer.

Therefore, the condRRCReconfig which is an RRCReconfiguration IE should include the LTM-Config as a choice of [LTM-Config, pointer].

The pointer is implemented as an ID, pointing to a stored LTM-Config that belonged to a condReconfig which was flushed.

When the network signals the CHO configuration, it may include a list of LTM-Config that will be used inside the CHO condReconfigToAddMod . We may label those LTM- Configs as condReferenceLTMConfig and include them to ConditionalReconfiguratiorr.

Multiple CHO conditions may hold the same LTM-Config. In case of flushing of CHO conditions which have same LTM-Config, it would not be necessary to store each of them. One can use a binary tag to indicate “storing needed”. Thus, a duplicate LTM-

Config will not be stored during a flush operation.

Approach 1 : configs processed at application time

When the UE receives ConditionalReconfiguration, it will store the contents of condReferenceLTMConfig to varStoreLTMConfig. replace condReconfigld and LTM-Config within the VarStoreLTMConfig with the respective values of condReferenceLTMConfig

Further, the UE as usual stores the contained condRRCReconfig in the existing UE variable VarConditional Reconfig. If the condRRCReconfig contains and LTM-Config which is a pointer, it will store the pointer as-is.

2> if the entry in condReconfigToAddModList includes an condRRCReconfig-, 3> replace condRRCReconfig within the VarConditional Reconfig with the value received for this condReconfigld',

When the UE applies a CHO condition and it contains an LTM-Config pointer P, the UE retrieves the corresponding LTM-Config from the VarStoreLTMConfig

1 > for each condReconfigld within the VarConditional Reconfig:

2> if the RRCReconfiguration within condRRCReconfig includes a pointer P to an LTM-Config

3> apply the contents of VarStoreLtmConfig[P] No further actions required, as the LTM-Configs are already in VarStoreLTMConfig

Approach 2: configs processed at reception time

Upon UE receiving ConditionReconfiguration:

UE will store any received condRRCReconfig->LTM-Config to VarStoreLTMConfig.

Further it as usual stores the contained condRRCReconfig in the existing UE variable VarConditionalReconfig .

If the condRRCReconfig contains and LTM-Config which is a pointer P, the UE will store not the pointer, but store the contents of varStoreLTMConfig^LTMConfigList Pj.

2> if the entry in condReconfigToAddModList includes an condRRCReconfig-, 3> replace condRRCReconfig within the VarConditional Reconfig with the value received for this condReconfigld;

3> if the condRRCReconfig contains an LTM-Config which is a pointer P, replace the pointer with the contents of varStoreLTMConfig->LTM-ConfigList[P]; replace respective values in VarConditionalReconfig ...

UE application remains unchanged from existing procedure.

1 > for each condReconfigld within the VarConditionalReconfig

2> if the RRCReconfiguration within condRRCReconfig includes ...

If the UE has not saved LTM-Configs contained in the CHO conditions at CHO configuration reception time, it shall do at point of flush operation as follows: During the procedure where the UE flushes condReconfigToAddMod which has condReconfigld which did not become serving cell during CHO HO or serving cell as part of CHO fast recovery:

If the flag CondReconfigToAddMod condSaveThisLTMConfig is set to True, the UE variable VarStoreLTMConfig[condReconfigld]wi\\ be replaced with the contents of condReconfigToAddMod -^LTM-Config

Further, UE shall also save the serving LTM-Config to VarStoreLTMConfig, using the condReconfigld which is being activated. Embodiment: storing Itm-ReferenceConfiguration .

Including Itm-ReferenceConfiguration a CHO via pointer

Instead of saving LTM-Config to varStoreLTMConfig, one can save LTM- Config->ltm-ReferenceConfiguration. This allows to balance storage and signaling. Further, in the set of CHO conditions (conditionalReconfiguration->condReconfigToAddModl_ist), Itm- ReferenceConfiguration will be less diverse compared to LTM-Config, as it does not contain Itm-Candidate configurations. The method is applicable to NW with monolithic gNB and to NW with CU-Dll split gNB.

Example implementation without optimized signaling

FIG. 14 illustrates a method 160 that is similar to the method 140 illustrated in FIG

12. It is an example implementation without optimized signaling.

It follows approach 2, and uses Itm-ReferenceConfiguration (instead of LTM-Config), without optimized signaling

/

The UE can implement a new variable containing a list of Itm-

ReferenceConfiguration:

NW signaling: Including LTM ReferenceConfig in a CHO via pointer

For the signaling optimization, the CHO configuration

Conditional Reconfiguration ->condReconfigToAddModList->condReconfigToAddMod ->condRRCReconfig->LTM-Config->ltm-ReferenceConfiguration should be able to include an Itm-ReferenceConfiguration via pointer. Therefore, the LTM-Config should include the Itm-ReferenceConfiguration as a choice of [Referenceconfiguration, pointer].

The pointer is implemented as an ID, pointing to a Itm-ReferenceConfiguration stored in the VarStoreLTMConfig, that belonged to a condReconfig which was flushed.

In this embodiment, the network will not provide a list of Itm-ReferenceConfiguration outside the CHO conditions, but it will rely on what the UE has stored locally. The pointer LTM-Config->ltm-ReferenceConfiguration==CondReconfigld may have a different value than condReconfigToAddMod->condRRCReconfig ->condReconfigld because different condRRCReconfig may include the same Itm- ReferenceConfiguration. Multiple CHO conditions may hold the same LTM-Config. In case of flushing of CHO conditions which have same LTM-Config, it would not be necessary to store each of them. The NW is aware of duplicate entries and can use a binary tag to indicate “storing needed”. Thus, storing a duplicate LTM-Config can be avoided during a flush operation.

When the UE receives the ConditionalReconfiguration, it as usual stores the contained condRRCReconfig in the existing UE variable VarConditional Reconfig. If the condRRCReconfig contains and LTM-Config->ltm-ReferenceConfiguration which is a pointer P, the UE will store not the pointer, but store the contents of the UE variable varStoreLTMConfig ->LTMConfigList [PJ.

2> if the entry in condReconfigToAddModList includes an condRRCReconfig-,

3> replace condRRCReconfig within the VarConditional Reconfig with the value received for this condReconfigld;

3> if the condRRCReconfig contains an LTM-Config->ltm-ReferenceConfiguration which is a pointer of value P, replace the pointer with the contents of varStoreLTMConfig->LTM-ConfigList[P] ; replace corresponding values within VarConditionalReconfig ..

UE application remains unchanged from existing procedure. 1 > for each condReconfigld within the VarConditional Reconfig:

2> if the RRCReconfiguration within condRRCReconfig includes ... flush operation: As the UE already has saved all LTM reference configurations to varStoreLTMConfig at ConditionalReconfiguration reception, no modifications to the flush operations are needed.

In a simple embodiment, LTM-Configs are stored, duplicate storing is avoided, no signaling of reference configurations is performed, signaling of references to stored LTM-Configs is performed.

One variant procedural implementation is shown as below:

“Conditional reconfiguration addition/modification” capture the storing of LTM configurations contained within a ConditionalReconfiguration to VarStoreLTMConfig and referencing contents of VarStoreLTMConfig in signaling of ConditionalReconfiguration. The structure of the procedure is that upon reception of ConditionalReconfiguration as a first step to store all non-pointer LTM-Config contained in the individual CHO conditions, before any further processing happens. This avoids ambiguity in the de-referencing of pointers when the contents are stored in VarConditional Reconfig:

<38.331 modification start - modified parts are highlighted in yellow>

For each condReconfigld received in the condReconfigToAddModList IE the UE shall:

1> if the entry in condReconfigToAddModList includes an condRRCReconfig-, 2> if the condRRCReconfig contains an LTM-Config which is not a pointer 3> If the if the entry condReconfigToAddMod contains condSaveThisLtmConfig and it is set to True:

4> replace the contents of VarStoreLTMConfig ->LTM- ConfigList[condReconfigld] with the LTM-Config

For each condReconfigld received in the condReconfigToAddModList IE the UE shall: > if an entry with the matching condReconfigld exists in the condReconfigToAddModList within the VarConditionalReconfig: 2> if the entry in condReconfigToAddModList includes a condRRCReconfig which includes an LTM-Config which is a pointer P

3> replace the pointer (that is LTM-Config) with the contents of VarStoreLTMConfig ->LTM-Config List[P] and continue with further steps | and replace the corresponding value in VarConditional Reconfig] > if the entry in condReconfigToAddModList includes an condExecutionCond, condExecutionCondSCG, or condExecutionCondPSCell: > replace condExecutionCond, condExecutionCondSCG, or condExecutionCondPSCell within the VarConditional Reconfig with the value received for this condReconfigld', > if the entry in condReconfigToAddModList includes subsequentCondReconfig co nta i n i ng condExecutionCondToA dd Mod Li st: > for each condReconfigld received in condExecutionCondToAddModList > if an entry with the matching condReconfigld exists in the condExecutionCondToAddModList withi n VarConditionalReconfig-, > replace the entry in condExecutionCondToAddModList within

VarConditional Reconfig with the value received for this condReconfigld', >else: >add a new entry in condExecutionCondToAddModList within VarConditionalReconfig with the value received for this condReconfigld',2> if the entry in condReconfigToAddModList includes subsequentCondReconfig containing condExecution CondT oReleaseList: > for each condReconfigld received in condExecutionCondToReleaseList that is part of current stored condExecutionCondToAddModList within VarConditionalReconfig : > remove the entry in condExecutionCondToAddModList within

VarConditionalReconfig with the value received for this condReconfigld', > if the entry in condReconfigToAddModList includes an securityCellSetld', > replace securityCellSetld within the VarConditionalReconfig with the value received for this condReconfigld',

NOTE X: The UE should release the entry within VarServingSecurityCellSetID in case all the subsequent CPAC configurations are released. > if the entry in condReconfigToAddModList includes an condRRCReconfig-, > replace condRRCReconfig within the VarConditional Reconfig with the value received for this condReconfigld', >else:

2> add a new entry for this condReconfigld within the VarConditional Reconfig-, 2> if the entry in condReconfigToAddModList includes a condRRCReconfig which includes an LTM-Config which is a pointer P

3> replace the pointer (that is LTM-Config) with the contents of VarStoreLTMConfig LTM-Config List[P] and replace the corresponding value in VarConditional Reconfig

<38.331 modification end>

In the following example, link 202 is defined in the conditional handover configuration 210. A suitable UE variable for storing LTM configurations is:

An LTM configuration can be signalled as a pointer (to a UE variable). The LTM configuration is contained in the condReconfigToAddMod under

ConditionalReconfiguration IE 230:

LTM configurations contained within a ConditionalReconfiguration are stored to VarStoreLTMConfig. Contents of VarStoreLTMConfig are referenced in signaling of ConditionalReconfiguration.

The structure of the modification for the standard procedural text is that upon reception of ConditionalReconfiguration as a first step to store all non-pointer LTM- Config contained in the individual CHO conditions, before any further processing happens. This avoids ambiguity in the replacing of indices when the contents are stored in VarConditional Reconfig. In the second step, potentially contained pointers will lead to pulling what is in the UE variable to the message for further processing. We additionally provide the procedural text in form of pseudo-code, to avoid confusion in the procedural text: Variant

The LTM config 220 can be setup or released by the network and for that purpose the network may use a SetupRelease{LTM-Config} wrapper which allows to signal a binary value associated to the LTM-Config, “setup” or “release”. In the context of the disclosed solution, in the first part of procedure, 100, the SetupRelease wrapper applied to the LTM Config 220 may mean with “Setup” to store the contents 220 to the UE variable 214 or "Release” mean not storing. In the second part of the procedure, 120, the retrieved contents of the UE variable 214 may be further wrapped with a “Setup” before create/copy it to the LTM config info 216 for further processing in block 130. This is captured in below in pseudo-code as follows. Fig 15 illustrates an example of a controller 400 suitable for use in an apparatus 10, 20. Implementation of a controller 400 may be as controller circuitry. The controller 400 may be implemented in hardware alone, have certain aspects in software including firmware alone or can be a combination of hardware and software (including firmware).

As illustrated in Fig 15 the controller 400 may be implemented using instructions that enable hardware functionality, for example, by using executable instructions 406 in a general-purpose or special-purpose processor 402 that may be stored on a machine readable storage medium (disk, memory etc.) to be executed by such a processor 402.

The processor 402 is configured to read from and write to the memory 404. The processor 402 may also comprise an output interface via which data and/or commands are output by the processor 402 and an input interface via which data and/or commands are input to the processor 402.

The memory 404 stores instructions, program, or code 406 that controls the operation of the apparatus 10, 20 when loaded into the processor 402. The computer program instructions, program or code am 406, provide the logic and routines that enables the apparatus 10, 20 to perform the methods illustrated in the accompanying FIGs. The processor 402 by reading the memory 404 is configured to load and execute the instructions, program, or code 406.

The apparatus 10, 20 comprises: at least one processor 402; and at least one memory 404 storing instructions that, when executed by the at least one processor 402, cause the apparatus at least to: receive a first conditional handover configuration comprising first lower layer triggered mobility (LTM) configuration information to enable lower layer triggered connection establishment; store, for later access via a value of a first conditional handover configuration identifier of the first conditional handover configuration, a first lower layer triggered mobility (LTM) configuration, comprised in the first lower layer triggered mobility (LTM) configuration information; receive a second conditional handover configuration comprising second lower layer triggered mobility (LTM) configuration information to enable lower layer triggered connection establishment; store, for access via a value of a second conditional handover configuration identifier of the second conditional handover configuration, a second lower layer triggered mobility (LTM) configuration comprised in the second lower layer triggered mobility (LTM) configuration information; in response to satisfaction of an execution condition for conditional handover comprised in the first conditional handover configuration, applying the first conditional handover configuration to enable handover and flushing the second conditional handover configuration; receiving a third conditional handover configuration comprising third lower layer triggered mobility (LTM) configuration information to enable lower layer triggered connection establishment comprising the first conditional handover configuration identifier for accessing the first lower layer triggered mobility (LTM) configuration.

In addition, the apparatus is configured to access the first lower layer triggered mobility (LTM) configuration via the value of the first conditional handover configuration identifier to store the first lower layer triggered mobility (LTM) configuration within the third conditional handover configuration in place of the first conditional handover configuration identifier.

In addition, the apparatus is configured to store the third conditional handover configuration with the first conditional handover configuration identifier, without accessing the first lower layer triggered mobility (LTM) configuration via a value of the first conditional handover configuration identifier.

As illustrated in Fig 16, the instructions, program, or code 406 may arrive at the apparatus 10, 20 via any suitable delivery mechanism 408. The delivery mechanism 408 may be, for example, a machine readable medium, a computer-readable medium, a non-transitory computer-readable storage medium, a computer program product, a memory device, a record medium such as a Compact Disc Read-Only Memory (CD-ROM) or a Digital Versatile Disc (DVD) or a solid-state memory, an article of manufacture that comprises or tangibly embodies the computer program 406. The delivery mechanism may be a signal configured to reliably transfer the computer program 406. The apparatus 10, 20 may propagate or transmit the computer program 406 as a computer data signal.

The term “non-transitory” as used herein, is a limitation of the medium itself (i.e., tangible, not a signal ) as opposed to a limitation on data storage persistency (e.g., RAM vs. ROM).

Computer program instructions for causing an apparatus to perform at least the following or for performing at least the following: receive a first conditional handover configuration comprising first lower layer triggered mobility (LTM) configuration information to enable lower layer triggered connection establishment; store, for later access via a value of a first conditional handover configuration identifier of the first conditional handover configuration, a first lower layer triggered mobility (LTM) configuration, comprised in the first lower layer triggered mobility (LTM) configuration information; receive a second conditional handover configuration comprising second lower layer triggered mobility (LTM) configuration information to enable lower layer triggered connection establishment; store, for access via a value of a second conditional handover configuration identifier of the second conditional handover configuration, a second lower layer triggered mobility (LTM) configuration comprised in the second lower layer triggered mobility (LTM) configuration information; in response to satisfaction of an execution condition for conditional handover comprised in the first conditional handover configuration, applying the first conditional handover configuration to enable handover and flushing the second conditional handover configuration; receiving a third conditional handover configuration comprising third lower layer triggered mobility (LTM) configuration information to enable lower layer triggered connection establishment comprising the first conditional handover configuration identifier for accessing the first lower layer triggered mobility (LTM) configuration.

The computer program instructions may be comprised in a computer program, a non- transitory computer readable medium, a computer program product, a machine readable medium. In some but not necessarily all examples, the computer program instructions may be distributed over more than one computer program.

Although the memory 404 is illustrated as a single component/circuitry it may be implemented as one or more separate components/circuitry some or all of which may be integrated/removable and/or may provide permanent/semi-permanent/ dynamic/cached storage.

Although the processor 402 is illustrated as a single component/circuitry it may be implemented as one or more separate components/circuitry some or all of which may be integrated/removable. The processor 402 may be a single core or multi-core processor.

References to ‘computer-readable storage medium’, ‘computer program product’, ‘tangibly embodied computer program’ etc. or a ‘controller’, ‘computer’, ‘processor’ etc. should be understood to encompass not only computers having different architectures such as single /multi- processor architectures and sequential (Von Neumann)/parallel architectures but also specialized circuits such as field- programmable gate arrays (FPGA), application specific circuits (ASIC), signal processing devices and other processing circuitry. References to computer program, instructions, code etc. should be understood to encompass software for a programmable processor or firmware such as, for example, the programmable content of a hardware device whether instructions for a processor, or configuration settings for a fixed-function device, gate array or programmable logic device etc.

As used in this application, the term ‘circuitry’ may refer to one or more or all the following:

(a) hardware-only circuitry implementations (such as implementations in only analog and/or digital circuitry) and (b) combinations of hardware circuits and software, such as (as applicable): i. a combination of analog and/or digital hardware circuit(s) with software/firmware and ii. any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory or memories that work together to cause an apparatus, such as a mobile phone or server, to perform various functions and

(c) hardware circuit(s) and or processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (for example, firmware) for operation, but the software may not be present when it is not needed for operation.

This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor and its (or their) accompanying software and/or firmware. The term circuitry also covers, for example and if applicable to the claim element, a baseband integrated circuit for a mobile device or a similar integrated circuit in a server, a cellular network device, or other computing or network device.

The blocks illustrated in the accompanying Figs may represent steps in a method and/or sections of code in the computer program 406. The illustration of a particular order to the blocks does not necessarily imply that there is a required or preferred order for the blocks and the order and arrangement of the block may be varied. Furthermore, it may be possible for some blocks to be omitted.

As used here ‘module’ refers to a unit or apparatus that excludes certain parts/components that would be added by an end manufacturer or a user. The apparatus 10, 20 can, for example be a module. A controller 400 of the apparatus 10, 20 can, for example be a module.

Where a structural feature has been described, it may be replaced by means for performing one or more of the functions of the structural feature whether that function or those functions are explicitly or implicitly described. The apparatus can be provided in an electronic device, for example, a mobile terminal, according to an example of the present disclosure. It should be understood, however, that a mobile terminal is merely illustrative of an electronic device that would benefit from examples of implementations of the present disclosure and, therefore, should not be taken to limit the scope of the present disclosure to the same. While in certain implementation examples, the apparatus can be provided in a mobile terminal, other types of electronic devices, such as, but not limited to: mobile communication devices, hand portable electronic devices, wearable computing devices, portable digital assistants (PDAs), pagers, mobile computers, desktop computers, televisions, gaming devices, laptop computers, cameras, video recorders, GPS devices and other types of electronic systems, can readily employ examples of the present disclosure. Furthermore, devices can readily employ examples of the present disclosure regardless of their intent to provide mobility.

The term ‘comprise’ is used in this document with an inclusive not an exclusive meaning. That is any reference to X comprising Y indicates that X may comprise only one Y or may comprise more than one Y. If it is intended to use ‘comprise’ with an exclusive meaning then it will be made clear in the context by referring to ‘comprising only one...’ or by using ‘consisting.’

In this description, the wording ‘connect’, ‘couple’ and ‘communication’ and their derivatives mean operationally connected/coupled/in communication. It should be appreciated that any number or combination of intervening components can exist (including no intervening components), i.e. , to provide direct or indirect connection/coupling/communication. Any such intervening components can include hardware and/or software components.

As used herein, the term "determine/determining" (and grammatical variants thereof) can include, not least: calculating, computing, processing, deriving, measuring, investigating, identifying, looking up (for example, looking up in a table, a database, or another data structure), ascertaining and the like. Also, "determining" can include receiving (for example, receiving information), accessing (for example, accessing data in a memory), obtaining and the like. Also, " determine/determining" can include resolving, selecting, choosing, establishing, and the like. In this description, reference has been made to various examples. The description of features or functions in relation to an example indicates that those features or functions are present in that example. The use of the term ‘example’ or ‘for example’ or ‘can’ or ‘may’ in the text denotes, whether explicitly stated or not, that such features or functions are present in at least the described example, whether described as an example or not, and that they can be, but are not necessarily, present in some of or all other examples. Thus ‘example’, ‘for example’, ‘can’, or ‘may’ refers to a particular instance in a class of examples. A property of the instance can be a property of only that instance or a property of the class or a property of a sub-class of the class that includes some but not all the instances in the class. It is therefore implicitly disclosed that a feature described with reference to one example but not with reference to another example, can where possible be used in that other example as part of a working combination but does not necessarily have to be used in that other example.

As used herein, “at least one of the following: ” and “at least one of ” and similar wording, where the list of two or more elements are joined by “and” or “or” mean at least any one of the elements, or at least any two or more of the elements, or at least all the elements.

Although examples have been described in the preceding paragraphs with reference to various examples, it should be appreciated that modifications to the examples given can be made without departing from the scope of the claims.

Features described in the preceding description may be used in combinations other than the combinations explicitly described above.

Although functions have been described with reference to certain features, those functions may be performable by other features whether described or not.

The description of a feature, such as an apparatus or a component of an apparatus, configured to perform a function, or for performing a function, should additionally be considered to also disclose a method of performing that function. For example, description of an apparatus configured to perform one or more actions, or for performing one or more actions, should additionally be considered to disclose a method of performing those one or more actions with or without the apparatus.

Although features have been described with reference to certain examples, those features may also be present in other examples whether described or not.

The term ‘a’, ‘an’ or ‘the’ is used in this document with an inclusive not an exclusive meaning. That is any reference to X comprising a/an/the Y indicates that X may comprise only one Y or may comprise more than one Y unless the context clearly indicates the contrary. If it is intended to use ‘a’, ‘an’ or ‘the’ with an exclusive meaning then it will be made clear in the context. In some circumstances the use of ‘at least one’ or ‘one or more’ may be used to emphasis an inclusive meaning but the absence of these terms should not be taken to infer any exclusive meaning.

The presence of a feature (or combination of features) in a claim is a reference to that feature or (combination of features) itself and to features that achieve substantially the same technical effect (equivalent features). The equivalent features include, for example, features that are variants and achieve substantially the same result in substantially the same way. The equivalent features include, for example, features that perform substantially the same function, in substantially the same way to achieve substantially the same result.

In this description, reference has been made to various examples using adjectives or adjectival phrases to describe characteristics of the examples. Such a description of a characteristic in relation to an example indicates that the characteristic is present in some examples exactly as described and is present in other examples substantially as described.

The above description describes some examples of the present disclosure however those of ordinary skill in the art will be aware of possible alternative structures and method features which offer equivalent functionality to the specific examples of such structures and features described herein above and which for the sake of brevity and clarity have been omitted from the above description. Nonetheless, the above description should be read as implicitly including reference to such alternative structures and method features which provide equivalent functionality unless such alternative structures or method features are explicitly excluded in the above description of the examples of the present disclosure. Whilst endeavoring in the foregoing specification to draw attention to those features believed to be of importance the Applicant may seek protection via the claims in respect of any patentable feature or combination of features hereinbefore referred to and/or shown in the drawings whether or not emphasis has been placed thereon. l/we claim:

Claims

1. An apparatus comprising means for: receiving a conditional handover configuration comprising: an execution condition for conditional handover; and a conditional handover configuration identifier, and an associated conditional handover configuration identifier of a previously received conditional handover configuration for accessing a lower layer triggered mobility (LTM) configuration.

2. An apparatus as claimed in claim 1, wherein the conditional handover configuration identifier of a previously received conditional handover configuration is an index for accessing a stored lower layer triggered mobility (LTM) configuration.

3. An apparatus as claimed in claim 1 or 2, comprising means for: receiving a conditional handover configuration comprising: an execution condition for conditional handover; a conditional handover configuration identifier; lower layer triggered mobility (LTM) configuration information to enable lower layer triggered connection establishment comprising: a conditional handover configuration identifier of a previously received conditional handover configuration for accessing a lower layer triggered mobility (LTM) configuration.

4. An apparatus as claimed in any preceding claim, wherein an information element comprises the conditional handover configuration and comprises, inside the conditional handover configuration, the conditional handover configuration identifier of a previously received conditional handover configuration for accessing a lower layer triggered mobility (LTM) configuration.

5. An apparatus as claimed in any preceding claim, wherein an information element comprises the conditional handover configuration and comprises, outside the conditional handover configuration, the conditional handover configuration identifier of a previously received conditional handover configuration for accessing a lower layer triggered mobility (LTM) configuration.

6. An apparatus as claimed in any preceding claim, wherein the conditional handover configuration identifier provides a link for accessing at least a part of a lower layer triggered mobility (LTM) configuration.

7. An apparatus as claimed in any preceding claim, wherein the conditional handover configuration identifier is from a previously received and flushed conditional handover configuration.

8. An apparatus as claimed in any preceding claim, comprising means for: receiving a conditional handover configuration comprising: an execution condition for conditional handover; a conditional handover configuration identifier; lower layer triggered mobility (LTM) configuration information to enable lower layer triggered connection establishment comprising: a lower layer triggered mobility (LTM) configuration; and storing the lower layer triggered mobility (LTM) configuration for access via a value of the conditional handover configuration identifier.

9. An apparatus as claimed in any preceding claim, wherein the lower layer triggered mobility (LTM) configuration enables triggering of a cell change using signaling at a layer lower than layer 3.

10. An apparatus as claimed in any preceding claim, comprising means configured to: receive a first conditional handover configuration comprising first lower layer triggered mobility (LTM) configuration information to enable lower layer triggered connection establishment; receive a second conditional handover configuration comprising second lower layer triggered mobility (LTM) configuration information to enable lower layer triggered connection establishment; in response to satisfaction of an execution condition for conditional handover comprised in the first conditional handover configuration, applying the first conditional handover configuration to enable handover and flushing the second conditional handover configuration; before flushing the second conditional handover configuration, storing, for access via a value of a conditional handover configuration identifier comprised in the second conditional handover configuration, a lower layer triggered mobility (LTM) configuration, comprised in the lower layer triggered mobility (LTM) configuration information.

11. An apparatus as claimed in claim 10, comprising means configured to: before flushing the second conditional handover configuration, storing, for access via a value of a conditional handover configuration identifier comprised in the second conditional handover configuration, a lower layer triggered mobility (LTM) configuration linked via the lower layer triggered mobility (LTM) configuration information comprised in the second conditional handover configuration.

12. An apparatus as claimed in claim 10 or 11 , comprising means configured to: receive a duplication indicator in association with the second conditional handover configuration that controls storage.

13. An apparatus as claimed in claim 10, 11 or 12, comprising means configured to receive an expiry indicator in association with the second conditional handover configuration that controls expiry of storage.

14. An apparatus as claimed in claim 10, 11 or 12, comprising means for: receiving the conditional handover configuration via an information element comprising:

ConditionalReconfiguration Information element comprising

CondReconfigToAddMod information element, comprising: condReconfigld execution condition for conditional handover an index for accessing a LTM Configuration RRCReconfiguration information element comprising: a LTM configuration wherein the conditional handover configuration is provided by the CondReconfigToAddMod information element, the conditional handover configuration identifier is provided by condReconfigld the lower layer triggered mobility (LTM) configuration information is provided by the RRCReconfiguration information element.

15. An apparatus as claimed in claim 10, 11 or 12, comprising means for: receiving the conditional handover configuration via an information element comprising:

ConditionalReconfiguration Information element comprising

CondReconfigToAddMod information element, comprising: condReconfigld execution condition for conditional handover RRCReconfiguration information element comprising: a LTM configuration or an index for accessing a LTM Configuration wherein the conditional handover configuration is provided by the CondReconfigToAddMod information element, the conditional handover configuration identifier is provided by condReconfigld the lower layer triggered mobility (LTM) configuration information is provided by the RRCReconfiguration information element.

16. A method comprising: receiving a first conditional handover configuration comprising first lower layer triggered mobility (LTM) configuration information to enable lower layer triggered connection establishment; storing, for later access via a value of a first conditional handover configuration identifier of the first conditional handover configuration, a first lower layer triggered mobility (LTM) configuration, comprised in the first lower layer triggered mobility (LTM) configuration information; receiving a second conditional handover configuration comprising second lower layer triggered mobility (LTM) configuration information to enable lower layer triggered connection establishment; storing, for access via a value of a second conditional handover configuration identifier of the second conditional handover configuration, a second lower layer triggered mobility (LTM) configuration comprised in the second lower layer triggered mobility (LTM) configuration information; in response to satisfaction of an execution condition for conditional handover comprised in the first conditional handover configuration, applying the first conditional handover configuration to enable handover and flushing the second conditional handover configuration; receiving a third conditional handover configuration comprising third lower layer triggered mobility (LTM) configuration information to enable lower layer triggered connection establishment comprising the first conditional handover configuration identifier for accessing the first lower layer triggered mobility (LTM) configuration.

17. A method as claimed in claim 16 comprising: accessing the first lower layer triggered mobility (LTM) configuration via the value of the first conditional handover configuration identifier to store the first lower layer triggered mobility (LTM) configuration within the third conditional handover configuration in place of the first conditional handover configuration identifier.

18. A method as claimed in claim 16 or 17 comprising: storing the third conditional handover configuration with the first conditional handover configuration identifier, without accessing the first lower layer triggered mobility (LTM) configuration via a value of the first conditional handover configuration identifier.

19. A computer program that when executed by one or more processors of an apparatus cause the apparatus to perform: receiving a conditional handover configuration comprising: an execution condition for conditional handover, and a conditional handover configuration identifier, and an associated conditional handover configuration identifier of a previously received conditional handover configuration for accessing a lower layer triggered mobility (LTM) configuration.

20. An apparatus comprising means for: transmitting a conditional handover configuration comprising an execution condition for conditional handover; and a conditional handover configuration identifier, and an associated conditional handover configuration identifier of a previously received conditional handover configuration for accessing a lower layer triggered mobility (LTM) configuration.