WO2025005852A1

WO2025005852A1 - Configurations for determining when to generate reports

Info

Publication number: WO2025005852A1
Application number: PCT/SE2024/050618
Authority: WO
Inventors: Ali PARICHEHREHTEROUJENI; Marco BELLESCHI; Pradeepa Ramachandra; Sakib BIN REDHWAN
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2023-06-28
Filing date: 2024-06-24
Publication date: 2025-01-02
Anticipated expiration: 2025-12-28

Abstract

There is provided a method performed by a user equipment, UE. The UE has a first Successful Primary Secondary Cell Group Cell (PSCell) Report (SPR) configuration and a second SPR configuration for determining when to generate SPRs. The method comprises, based on the occurrence of an event or procedure, releasing (301) at least part of the first SPR configuration and/or releasing at least part of the second SPR configuration.

Description

CONFIGURATIONS FOR DETERMINING WHEN TO GENERATE REPORTS

Technical Field

This disclosure relates to reporting configurations that are used for determining when to generate reports.

Background

Overall Architecture of NG-RAN

The current 5^th Generation (5G) Radio Access Network (RAN) (NG-RAN) architecture is depicted and described in the 3^rd Generation Partnership Project (3GPP) Technical Standard (TS) 38.401 V17.2.0 as shown in Fig. 1.

The NG-RAN consists of a set of gNBs connected to the 5G Core (5GC) through the Next Generation (NG) interface.

As specified in 3GPP TS 38.300 v17.4.0, NG-RAN could also consist of a set of ng-eNBs, where an ng-eNB may consist of an ng-eNB-Central Unit (CU, eNB-CU) and one or more ng- eNB-Distributed Unit(s) (DU(s), eNB-DU(s)). An ng-eNB-CU and an ng-eNB-DU is connected via W1 interface. The general principle described in this clause also applies to ng-eNB and W1 interface, if not explicitly specified otherwise.

• An gNB can support Frequency Division Duplex (FDD) mode, Time Division Duplex (TDD) mode or dual mode operation.

• gNBs can be interconnected through the Xn interface.

• A gNB may consist of a gNB-CU and one or more gNB-DU(s). A gNB-CU and a gNB-DU is connected via F1 interface.

• One gNB-DU is connected to only one gNB-CU.

• NG, Xn and F1 are logical interfaces.

For NG-RAN, the NG and Xn-C interfaces for a gNB consist of a gNB-CU and gNB-DUs, terminate in the gNB-CU. For E-UTRAN (Evolved-UTRA (UMTS Terrestrial Radio Access) Network) New Radio - Dual Connectivity (EN-DC), the S1-U and X2-C interfaces for a gNB consist of a gNB-CU and gNB-DUs terminating in the gNB-CU. The gNB-CU and connected gNB-DUs are only visible to other gNBs and the 5GC as a gNB.

The node hosting the user plane (UP) part of New Radio (NR) Packet Data Convergence Protocol (PDCP) (e.g. gNB-CU, gNB-CU-UP, and for EN-DC, Master eNB (MeNB) or Secondary gNB (SgNB) depending on the bearer split) shall perform user inactivity monitoring and further informs its inactivity or (re)activation to the node having control plane (CP) connection towards the core network (e.g. over E1 , X2). The node hosting NR Radio Link Control (RLC) (e.g. gNB- DU) may perform user inactivity monitoring and further inform its inactivity or (re)activation to the node hosting control plane, e.g. gNB-CU or gNB-CU-CP.

Uplink (UL) PDCP configuration (i.e. how the UE uses the UL at the assisting node) is indicated via X2-C (for EN-DC), Xn-C (for NG-RAN) and F1-C. Radio Link Outage/Resume for Downlink (DL) and/or UL is indicated via X2-U (for EN-DC), Xn-U (for NG-RAN) and F1-U.

The NG-RAN is layered into a Radio Network Layer (RNL) and a Transport Network Layer (TNL).

The NG-RAN architecture, i.e. the NG-RAN logical nodes and interfaces between them, is defined as part of the RNL. For each NG-RAN interface (NG, Xn, F1) the related TNL protocol and the functionality are specified. The TNL provides services for user plane transport, signalling transport.

The architecture shown above is that defined by 3GPP for 5G. Other standardisation groups, such as Open RAN (ORAN), have further extended the architecture above and have, for example, split the gNB-DU into two further nodes connected by a fronthaul interface. The lower node of the split gNB-DU would contain the Physical (PHY) protocol and the Radio Frequency (RF) parts, the upper node of the split gNB-DU would host the RLC and Medium Access Control (MAC). In ORAN the upper node is called ORAN Distributed Unit (O-DU), while the lower node is called ORAN-Radio Unit (O-RU).

At current state-of-art, the coordination across RAN and Transport domains is typically managed in a non-real-time mode (e.g. pre-planning and provisioning the Transport domain) with the alternative to coordinate Radio and Transport domains at Service Orchestration level, even though no products are yet available on the market.

Self-Organising Networks (SON) in 3GPP

A Self-Organising Network (SON) is an automation technology designed to make the planning, configuration, management, optimisation and healing of mobile radio access networks simpler and faster. SON functionality and behaviour has been defined and specified in generally accepted mobile industry recommendations produced by organisations such as 3GPP and the NGMN (Next Generation Mobile Networks).

In 3GPP, the processes within the SON area are classified into a Self-configuration process and a Self-optimisation process. The Self-configuration process is the process where newly deployed nodes are configured by automatic installation procedures to get the necessary basic configuration for system operation.

This process works in a pre-operational state. A pre-operational state is understood as the state from when the eNB is powered up and has backbone connectivity until the RF transmitter is switched on.

Fig. 2 illustrates some of the ramifications of Self-Configuration/Self-Optimisation functionality. Fig. 2 corresponds to Figure 22.1-1 in 3GPP TS 36.300 v17.4.0. As illustrated in Fig. 2, functions handled in the pre-operational state like:

• Basic Setup; and

• Initial Radio Configuration. are covered by the Self Configuration process.

The self-optimisation process is defined as the process where the User Equipment (UE) and access node measurements and performance measurements are used to auto-tune the network.

This process works in the operational state. The operational state is understood as the state where the RF interface is additionally switched on.

As described in Fig. 2Error! Reference source not found., functions handled in the operational state like Optimisation/Adaptation are covered by the Self Optimisation process.

In Long Term Evolution (LTE), support for Self-Configuration and Self-Optimisation is specified, as described in 3GPP TS 36.300 v17.4.0 section 22.2, including features such as Dynamic configuration, Automatic Neighbour Relation (ANR), Mobility load balancing, Mobility Robustness Optimisation (MRO), Random Access Channel (RACH) optimisation and support for energy saving.

In NR, support for Self-Configuration and Self-Optimisation is specified as well, starting with Self-Configuration features such as Dynamic configuration, Automatic Neighbour Relation (ANR) in Release 15 (Rel-15), as described in 3GPP TS 38.300 V15.14.0 section 15. In NR Release 16 (Rel-16), more SON features are being specified, including Self-Optimisation features such as Mobility Robustness Optimisation (MRO).

Mobility Robustness Optimisation (MRO) in 3GPP

Seamless handovers are a key feature of 3GPP technologies. Successful handovers ensure that the UE moves around in the coverage area of different cells without causing too many interruptions in the data transmission. However, there will be scenarios when the network fails to handover the UE to the ‘correct’ neighbour cell in time, and in such scenarios the UE will declare a radio link failure (RLF) or Handover Failure (HOF).

Upon HOF and/or RLF, the UE may take autonomous actions, i.e. trying to select a cell and initiate re-establishment procedure to make sure the UE is trying to get back as soon as it can, so that it can be reachable by the network again. The RLF will cause a poor user experience as the RLF is declared by the UE only when it realises that there is no reliable communication channel (radio link) available between itself and the network. Also, re-establishing the connection requires signalling with the newly selected cell (random access procedure, Radio Resource Control (RRC) Reestablishment Request, RRC Reestablishment RRC Reestablishment Complete, RRC Reconfiguration and RRC Reconfiguration Complete) and adds some latency, until the UE can exchange data with the network again.

According to the specifications (3GPP TS 36.331 v17.4.0), the possible causes forthe radio link failure could be one of the following:

1) Expiry of the radio link monitoring related timer T310;

2) Expiry of the measurement reporting associated timer T312 (not receiving the handover command from the network within this timer’s duration despite sending the measurement report when T310 was running);

3) Upon reaching the maximum number of RLC retransmissions;

4) Upon receiving random access problem indication from the MAC entity.

As RLF leads to re-establishment which degrades performance and user experience, it is in the interest of the network to understand the reasons for RLF and try to optimise mobility related parameters (e.g. trigger conditions of measurement reports) to avoid later RLFs. Before the standardisation of MRO-related report handling in the network, only the UE was aware of some information associated with the radio quality at the time of RLF, the actual reason for declaring RLF etc. Forthe network to identify the reason for the RLF, the network needs more information, both from the UE and also from the neighbouring base stations.

Based on the RLF report from the UE and the knowledge about which cell the UE reestablished itself with, the original source cell can deduce whether the RLF was caused due to a coverage hole or due to handover-associated parameter configurations. If the RLF was deemed to be due to handover-associated parameter configurations, the original serving cell can further classify the handover-related failure as too early, too late or handover to wrong cell classes. Based on this classification, the original serving cell can properly tune handover parameters and initiate certain measurement reports to avoid/limit the occurrences of RLF/HOF.

As an enhancement to MRO in Rel.17 3GPP introduced the Successful HO Report (SHR). Unlike the RLF report as described above which is used to report the RLF or Handover Failure experienced by the UE, the SHR is used by the UE to report various information associated to a successful HO. The successful HO will not be reported always at every HO, but only when certain triggering conditions are fulfilled. For example, if while doing HO, the T310/T312/T304 timers exceed a certain threshold, then the UE shall store information associated to this HO. Similarly, in case the HO was a Dual Active Protocol Stack (DAPS) HO, and the UE succeeded with it but an RLF was experienced in the source cell while doing the DAPS HO, then the UE stores information associated to this DAPS HO. When storing the successful handover report, the UE may include various information to aid the network to optimise the handover, such as measurements of the neighbouring cells, the fulfilled condition that triggered the successful handover report (e.g. threshold on T310 exceeded, specific RLF issue in the source while doing DAPS HO), etc.

The SHR is configured by the gNB, and when triggering conditions for SHR logging are fulfilled, the UE stores this information until the network (NW) requests it. In particular, the UE may indicate availability of SHR information in certain RRC message, such as RRCReconfigurationComplete, RRCReestablishmentComplete, RRCSetupComplete, RRCResumeComplete, and the network may request such information via the UElnformationRequest message, upon which the UE transmits the stored SHR in the UElnformationResponse message. Once the HO is successfully performed, the SHR configuration received before the successful execution is released.

In particular, the SHR can be configured both by the source Primary Cell (PCell) and target PCell. The source PCell can configure the threshold on the T310/T312 timers and the triggering condition on RLF in source cell during DAPS HO, whereas the target PCell can configure the threshold on the T304 timer. The SHR configuration are conveyed in the otherConfig information element and for the case of T304 that can be provided by the target PCell as part of the HO command.

Currently the SHR can be applicable to any type of standardised HO affecting the PCell, i.e. the ordinary HO, the DAPS HO, the Conditional Handover (CHO).

Conditional Primary Secondary Cell Group (SCG) Cell (PSCell) Chanqe/Addition (CPC/CPA)

Besides the CHO, i.e. the conditional HO from a source PCell to a target PCell, in Rel.18 a conditional PSCell change (CPC) was defined. The CPC defines a framework for the conditional change of the PSCell. The PSCell change is executed by the UE when the execution condition(s) for a PSCell change is met. The UE starts evaluating the execution condition(s) upon receiving the CPC configuration and stops evaluating the execution condition(s) once PSCell change is triggered. Intra-Secondary Node (SN) CPC without Master Node (MN) involvement, and inter- SN CPC initiated by either MN or SN are supported.

Similarly, conditional PSCell addition (CPA) is supported initiated by MN only.

Successful PSCell change report (SPR)

As previously described, 3GPP Rel.17 introduced the SHR for the HO from a source PCell to a target PCell. In Rel-18, the SHR will be extended to allow the logging of a successful PSCell change/addition report (SPR). Similar to the use case of SHR, the objective of SPR is to capture those events in which the PSCell change/addition procedure was successful, but it was close to failure, e.g. the time spent for the PSCell change/addition procedure was close to the T304 timer expiry. This new report would allow the network to optimise the settings of network procedures for the execution of PSCell change/addition procedure, or in case of CPC, the settings of the CPC configuration. As for the SHR, the SPR configuration will consist of certain triggering conditions for the UE to generate the SPR. Amongst the possible triggering conditions for SPR generation, the following are listed:

1) T310 timer related threshold, i.e. elapsed value of T310 above a configured threshold;

2) T312 timer related threshold, i.e. elapsed value of T312 above a configured threshold;

3) T304 timer related threshold, i.e. elapsed value of T304 above a configured threshold.

Thus, during a PSCell change, if SPR is configured, the UE would monitor if the timer values exceeded the configured thresholds and log SPR. Some of the above triggering conditions (e.g. T310/T312) may be provided by the PCell and/or source PSCell, whereas some others (e.g. the threshold on the T304) may be provided by the target PSCell.

The SPR should be applicable to any type of PSCell change/addition, like ordinary PSCell change/addition or CPC/CPA.

Summary

There currently exist certain challenge(s). In particular, the SHR configuration which is applicable to the HO from a source PCell to a target PCell is released by the UE once the HO is successfully performed, or as a result of a radio link failure or UE entering RRCJDLE. On the other hand, a PSCell change/addition procedure can be initiated by both the MN/PCell and/or the SN/PSCell. Moreover, both MN, source SN/PSCell and target SN/PSCell can configure the UE with their respective SPR configurations, e.g. different triggering conditions for the generation of the SPR, and the UE may need to store all of them and possibly apply one or more of them, e.g. depending on which node initiated the PSCell change/addition procedure. When the UE would release the SPR configuration and which of the potentially multiple SPR configurations would need to be released, is not currently captured in specification procedures.

Certain aspects of the disclosure and their embodiments may provide solutions to these or other challenges, and in particular relate to the retention or release of a Successful PSCell Report (SPR) configuration at a User Equipment (UE). In particular, a method performed in a User Equipment (UE) is proposed in which the UE receives (or is configured with) Successful PSCell Report (SPR) configuration(s) from network nodes, and upon performing certain RRC procedures, the UE evaluates/determines whether the SPR configurations should be kept/retained or released/discarded.

Embodiments of the disclosure provide for a UE to evaluate whether the UE is required to keep/retain or release/discard the SPR configuration(s) on the occurrence of one or more RRC events or RRC procedures. The events/procedures can include any one or more of: a. upon receiving SPR configuration from the PCell and/or source PSCell and/or target PSCell; b. upon successfully performing a PSCell change/addition procedure using a PSCell change/addition configuration provided by the PCell or PSCell; c. upon performing a Multi-Radio Dual Connectivity (MR-DC) release procedure; d. upon successfully performing a PCell handover, where: i. the UE may perform a simultaneous PCell handover and PSCell change/addition; or ii. the UE may perform a PCell handover without PSCell change/addition; e. upon performing reestablishment procedure following an experienced RLF/HOF in the PCell; f. upon performing a RRC resume procedure, or more specifically: i. upon performing RRC resume without Secondary Cell Group (SCG) restoration; ii. upon performing RRC resume with SCG restoration; g. upon experiencing RLF or HOF in the PSCell; h. upon performing fast Master Cell Group (MCG) link recovery following an experienced RLF in the PCell;

Depending on the embodiment, the evaluation can result in: a. the UE keeps only the PCell configured SPR configuration, and releases the SPR configuration configured by the source PSCell; b. the UE keeps only the source PSCell configured SPR configuration, and releases the SPR configuration configured by the PCell; c. the UE keeps only the target PSCell configured SPR configuration, and releases the SPR configuration configured by the PCell and source PSCell; d. the UE releases all the configured SPR configurations.

Thus, this disclosure defines a decision process in the UE as to whether the UE should delete SPR configuration(s) upon performing certain RRC procedures/events. The solution outlines different scenarios and their implication on UE behaviour. In particular embodiments, a method in the UE can comprise:

• receiving one or more SPR configurations from different cells, which may be hosted by different network nodes, e.g. a PCell (served by the MN), a source PSCell (served by the source SN), a target PSCell (served by the target SN);

• performing any of the following RRC-related procedures: o successfully performing a PSCell change/addition procedure using a PSCell change/addition configuration provided by the PCell or PSCell; o failing to perform a PSCell change/addition procedure using a PSCell change/addition configuration provided by the PCell or PSCell; o performing a MR-DC release procedure; o successfully performing a PCell handover; o performing a re-establishment procedure following an experienced RLF/HOF in the PCell; o RLF/HOF in the PCell; o an RRC resume procedure; o RLF in the PSCell; or o fast MCG link recovery following an experienced RLF in the PCell.

• depending on the specific RRC procedure above, performing one or more of the following actions: o keeping/retaining the SPR configuration provided by the PCell; o keeping/retaining the SPR configuration provided by the source PSCell; o keeping/retaining the SPR configuration provided by the target PSCell; o releasing/discarding the SPR configuration provided by the PCell; o releasing/discarding the SPR configuration provided by the source PSCell; o releasing/discarding the SPR configuration provided by the target PSCell.

According to a first aspect, there is provided a method performed by a UE. The UE has a first SPR configuration and a second SPR configuration for determining when to generate SPRs, and the method comprises: based on the occurrence of an event or procedure, releasing at least part of the first SPR configuration and/or releasing at least part of the second SPR configuration.

According to a second aspect, there is provided a computer program product comprising a computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform the method according to the first aspect or any embodiment thereof. According to a third aspect, there is provided a user equipment, UE, configured to perform the method according to the first aspect or any embodiment thereof.

According to a fourth aspect, there is provided a user equipment, UE, comprising a processor and a memory, said memory containing instructions executable by said processor whereby said UE is operative to perform the method according to the first aspect or any embodiment thereof.

Certain embodiments may provide one or more of the following technical advantage(s). The advantage of the solutions disclosed herein is to standardise UE behaviour regarding storage or deletion of SPR configuration(s) upon performing certain RRC procedures or certain RRC events occurring. The solution facilitates less collaboration overhead between the network nodes and ensures deterministic UE operation. In addition, the solution limits the air interface overhead by providing a new SPR configuration only when it is needed. Further, the solution also means that the UE does not generate an unexpected SPR based on an SPR configuration that should have been released.

Brief Description of the Drawings

Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings, in which:

Fig. 1 is a block diagram of a NG-RAN architecture;

Fig. 2 illustrates ramifications of Self-Configuration/Self-Optimisation functionality;

Fig. 3 is a flow chart illustrating a method performed by a user equipment in accordance with some embodiments;

Fig. 4 shows an example of a communication system in accordance with some embodiments; and

Fig. 5 shows a UE in accordance with some embodiments.

Detailed Description

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.

In this disclosure, the terms User Equipment (UE) and Wireless Access User refer to a generic set of devices capable of communicating over the cellular network.

The network encompasses any possible wireless network, some examples being LTE, NR, and any possible future technologies. The term network node identifies any wireless network node, such as an eNB or gNB. The SPR configurations described herein are used by the UEto determine when to generate an SPR. A SPR configuration comprises one or more parameters/triggering conditions/criteria, any one or more of which should typically be fulfilled for the UE to generate an SPR. These parameters/triggering conditions/criteria can be configured (i.e. set or determined) by the network node that provides the SPR configuration to the UE. In some embodiments the triggering conditions for the UE to generate the SPR are, or include, timer thresholds. In some embodiments, the SPR configuration comprises other triggering conditions/criteria/parameters in addition to one or more timer thresholds, or instead of timer thresholds. The Timer thresholds may be any of: a T310 timer related threshold, i.e. elapsed value of T310 above a configured threshold; a T312 timer related threshold, i.e. elapsed value of T312 above a configured threshold; and/or a T304 timer related threshold, i.e. elapsed value of T304 above a configured threshold.

The SPR configurations addressed in this disclosure can be provided by any of the PCell, the source PSCell, and the target PSCell. The PCell and source/target PSCells can be hosted by different network nodes, i.e. a MN for the PCell, a source SN for the PSCell, and/or a target SN for the target PSCell.

The MN and SN are network nodes, e.g. gNBs, and may take different role for different UEs. Thus, a particular node may act as MN to a first UE and act as a SN to another UE.

With reference to the SPR configurations, the terms “keep”, “retain” and “store” are used interchangeably herein, and refer to the SPR configuration continuing to be used/monitored by the UE after the relevant RRC event/procedure.

Also with reference to the SPR configurations, the terms “release”, “discard” and “delete” are used interchangeably herein, and refer to part or all of the SPR configuration no longer being stored, used and/or monitored by the UE after the relevant RRC event/procedure.

In the following, the release of the target PSCell SPR configuration may only imply the release of certain parameters conveyed in the SPR configuration provided by the target PSCell in some embodiments. However, in other embodiments, the release of the target PSCell SPR configuration may imply the release of the entire SPR configuration provided by the target PSCell. For example, after a successful PSCell change to the target PSCell, the UE may only release the T304 threshold configuration included in the SPR configuration provided by the said target PSCell. In another example, after an RLF in the PCell or RLF/HOF experienced in the PSCell, the UE may release the entire SPR configuration provided by the target PSCell, if configured.

As noted above, the techniques described herein enable a UE configured with one or more SPR configurations from different cells (possibly hosted by different network nodes), i.e. PCell (MN), source PSCell (source SN), target PSCell (target SN), to determine if and whether it should release one or more of the SPR configurations upon performing a certain RRC procedure.

RLF or HOF in the PCell

The following embodiments relate to evaluations in the event of a RLF or HOF in the PCell.

In one embodiment, upon RLF or HOF in the PCell, the UE can release both a PCell configured SPR configuration and a source PSCell configured SPR configuration. In a further embodiment, the UE can also release a target PSCell configured SPR configuration. The UE may execute this method if no suitable cell is found during a re-establishment procedure after declaring RLF/HOF. Alternatively, the UE may execute this method irrespective of whether a suitable cell is found after RLF/HOF or a successful RRC Reestablishment is performed. In some cases, in the event of PCell HOF, the UE can release both the source PCell configured SPR configuration and the target PCell configured SPR configuration.

In another embodiment, if upon RLF/HOF a successful RRC Reestablishment occurs in the same PCell in which the RLF was experienced, or in the same source PCell in case of HOF, the UE can keep/retain the PCell configured SPR configuration and release the source PSCell configured SPR configuration. In another embodiment, the UE can release also the target PSCell configured SPR configuration.

In another embodiment, if upon RLF/HOF a successful RRC Reestablishment occurs in the same PSCell to which the UE was connected at the time of RLF/HOF, the UE can keep the PSCell configured SPR configuration and release the PCell configured SPR configuration. In some embodiments, the UE can replace the PCell configured SPR configuration contents with the source PSCell configured SPR configuration. In another embodiment, the UE can release also the target PSCell configured SPR configuration.

In another embodiment, if upon RLF/HOF a successful RRC Reestablishment occurs in the target PSCell towards which the UE was performing PSCell change/addition at the time of RLF/HOF, the UE can keep the target PSCell configured SPR configuration and release the PCell and source PSCell configured configuration.

Performing a RRC resume procedure

The following embodiments relate to evaluations in the event of performing a RRC resume procedure.

In some embodiments, the UE can release both PCell and source PSCell configured SPR configurations from the UE Inactive Access Stratum (AS) context, if stored. For example, this method can be adopted if the UE resumes in a cell different from the PCell or PSCell to which the UE was connected at the time of entering RRCJNACTIVE state. Alternatively, this method can be adopted if the UE does not support maintaining SCG configuration upon connection resumption. In a further embodiment, the UE can also release the target PSCell configured SPR configuration from the UE Inactive AS context, if stored.

In other embodiments, if the RRC resume occurs in the same PCell in which the UE transited to RRCJNACTIVE mode, the UE may keep any configured SPR configuration, e.g. the PCell SPR configuration, the source PSCell, the target PSCell configuration. For example, this method can be performed if the UE supports maintaining SCG configuration upon connection resumption.

In other embodiments, if the RRC resume occurs in the same PCell in which the UE transited to RRCJNACTIVE mode, the UE can keep the PCell SPR configuration and release the source PSCell SPR configuration. In further embodiments, the UE may also keep the source PSCell configured SPR configuration only if the SCG is restored at the RRC resume. In a further embodiment, the UE can release the target PSCell configured SPR configuration.

In other embodiments, if the RRC resume occurs in the same PSCell to which the UE was connected when it transited to RRCJNACTIVE mode, the UE can keep the PSCell SPR configuration and release the PCell SPR configuration. In a further embodiment, the UE can also release the target PSCell configured SPR configuration.

Successfully performed PCell handover

The following embodiments relate to evaluations in the event of the UE successfully performing PCell handover.

In some embodiments, the UE can release the source PCell configured SPR configuration. Further, if the target PCell had configured a new SPR configuration during the handover procedure, then the UE can apply such a SPR configuration upon successfully completing the PCell handover.

In other embodiments, the UE can release, if configured, PCell and source PSCell SPR configuration. In a further embodiment, the UE can also release the target PSCell configured SPR configuration.

In other embodiments, if the UE performs PCell handover without PSCell change, the UE can release the PCell configured SPR configuration, if configured, and keep the source PSCell configured SPR configuration. In further embodiments, the UE may also keep the target PSCell configured SPR configuration, if configured.

In other embodiments, if the UE performs PCell handover without PSCell change, the UE can keep the PCell configured SPR configuration, even after connecting to the target PCell. This embodiment implies that the source PCell informs the target PCell (e.g. as part of the HO request message) about the configured SPR configuration.

If the UE performs simultaneous PCell handover and PSCell change, the UE can release both the PCell and source PSCell configured SPR configuration. Further, the UE may also release the target PSCell configured SPR configuration, if configured.

Successfully performed PSCell change

The following embodiments relate to evaluations in the event the UE successfully performs PSCell change:

In some embodiments, the UE can release both PCell configured and source PSCell configured SPR configuration. In a further embodiment, the UE can also release the target PSCell configured SPR configuration, if configured.

In other embodiments, if the UE performs PSCell change, without changing the PCell, the UE can release the source PSCell configured SPR configuration and keep the PCell configured SPR configuration. In a further embodiment, the UE can also release the target PSCell configured SPR configuration, if configured.

In other embodiments, if the UE performs MN initiated PSCell change, it can release only the source PSCell configured SPR configuration and target PSCell configured SPR configuration, whereas it can keep the PCell configured SPR configuration.

In other embodiments, if the UE performs MN initiated PSCell change, it can release source PSCell configured SPR configuration and target PSCell configured SPR configuration, and the PCell configured SPR configuration.

In other embodiments, if the UE performs SN initiated PSCell change, it can release only the source PSCell configured SPR configuration, and the target PSCell configured SPR configuration, whereas it can keep the PCell configured SPR configuration.

In other embodiments, if the UE performs SN initiated PSCell change, it can release the PCell, source PSCell and target PSCell configured SPR configurations.

In the above embodiments, the release of the target PSCell configured SPR configuration may imply only the release of some parameters configured in the target PSCell configured SPR configuration. For example, after the successful PSCell change to the target PSCell, the UE may only release the T304 threshold configuration included in the SPR configuration provided by the said target PSCell, and keep the configuration of T310/T312 thresholds.

Successfully performed PSCell addition

The following embodiments relate to evaluations in the event the UE successfully performs PSCell addition. In some embodiments, the UE can release the PCell configured SPR configuration and the target PSCell configured SPR configuration (in this case there is no source PSCell configured SPR configuration, since the UE performs a PSCell addition).

In other embodiments, if the UE performs PSCell addition without changing the PCell, the UE can release the target PSCell configured SPR configuration, and it can keep the PCell configured SPR configuration.

In the above embodiments, the release of the target PSCell configured SPR configuration may imply only the release of some parameters configured in the target PSCell configured SPR configuration. For example, after the successful PSCell change to the target PSCell, the UE may only release the T304 threshold configuration included in the SPR configuration provided by the said target PSCell, and the UE keeps the configuration of T310/T312 thresholds.

Failed PSCell change

The following embodiments relate to evaluations in the event the UE fails to perform a PSCell change.

In some embodiments, the UE can release both the PCell configured SPR configuration and the source PSCell configured SPR configuration. In a further embodiment, the UE can also release the target PSCell configured SPR configuration, if configured.

In other embodiments, if the UE fails in the PSCell change procedure without changing the PCell, the UE can release the source PSCell configured SPR configuration and the target PSCell configured SPR configuration, and keep the PCell configured SPR configuration.

In other embodiments, if the UE fails in the PSCell change procedure without changing the PCell, the UE can keep the PCell configured SPR configuration, and also keep the source PSCell configured SPR configuration if the MN, after the failed PSCell change, configures as PSCell the same PSCell which was the source PSCell at the time of the failed PSCell change. In a further embodiment, the UE can also release the target PSCell configured SPR configuration, if configured.

Failed PSCell addition

The following embodiments relate to evaluations in the event the UE fails to perform a PSCell addition.

In some embodiments, the UE can release both PCell configured SPR configuration and target PSCell configured SPR configuration (in this case there is no source PSCell configured SPR configuration, since the UE performs a PSCell addition).

In other embodiments, if the UE fails with the PSCell addition without changing the PCell, the UE can release the target PSCell configured SPR configuration, and keep the PCell configured SPR configuration.

UE experiencing a failure in the SCG

The following embodiments relate to evaluations in the event the UE experiences a failure, i.e. RLF, in the SCG.

In some embodiments, the UE can release both PCell configured SPR configuration and source PSCell configured SPR configuration. In a further embodiment, the UE can also release the target PSCell configured SPR configuration, if configured.

In other embodiments, if the UE experiences the RLF in the SCG while the UE continues to be connected to the same PCell, the UE can release the source PSCell configured SPR configuration, whereas it can keep the PCell configured SPR configuration. In a further embodiment, the UE may also release the target PSCell configured SPR configuration, if configured.

In other embodiments, if the UE experiences the RLF in the SCG while continuing to be connected to the same PCell, the UE can keep the PCell configured SPR configuration and the source PSCell configured SPR configuration if the MN, after the experienced RLF in the SCG, configures as PSCell the same PSCell in which the UE experienced the RLF. In a further embodiment, the UE can also release the target PSCell configured SPR configuration, if configured.

Fast MCG link recovery

The following embodiments relate to evaluations in the event the UE performs fast MCG link recovery following an experienced RLF in the PCell.

In some embodiments, the UE can release both PCell configured SPR configuration and source PSCell SPR configuration. In a further embodiment, the UE can also release the target PSCell configured SPR configuration, if configured.

In other embodiments, the UE can release the PCell configured SPR configuration, whereas it keeps the source PSCell configured SPR configuration. In a further embodiment, the UE can also keep the target PSCell configured SPR configuration, if configured.

In other embodiments, the UE can keep the source PSCell configured SPR configuration and the PCell configured SPR configuration if the SN configures the same PCell in which the UE experienced the RLF as PCell after the fast MCG link recovery. Here, the SN is the SN towards which the UE performed the fast MCG link recovery (i.e., towards which the UE sent the MCG Failureinformation message). In a further embodiment, the UE may also keep the target PSCell configured SPR configuration, if configured.

MR-DC release procedure

The following embodiments relate to evaluations in the event the UE performs an MR-DC release procedure.

In other embodiments, if the network releases the MR-DC configuration without changing the PCell, the UE can release the source PSCell configured SPR configuration and keep the PCell configured SPR configuration. In a further embodiment, the UE can also release the target PSCell configured SPR configuration, if configured.

In other embodiments, the UE can release/delete the SPR configuration configured as part of otherConfig of the MCG. This is because the UE already released otherConfig (including the SPR configuration) associated to the MCG. The UE can keep the SPR configuration of the target PSCell received as part of otherConfig of the target PSCell’s conditional reconfiguration.

SPR configuration for more cell groups

The SPR configuration can be conveyed in the OtherConfig provided by the PCell, i.e. by the MCG, and/or in the OtherConfig provided by the source PSCell, i.e. by the source SCG, and/or in the OtherConfig provided by the target PSCell, i.e. by the target SCG.

In other embodiments, the SPR configuration configured by a certain cell group is to report the SPR to the said cell group, if the SPR triggering conditions indicated in the said SPR configuration are fulfilled for the PSCell change/addition.

Fig. 3 is a flow chart illustrating a method performed by a UE in accordance with some embodiments. The UE may perform the method in response to executing suitably formulated computer readable code. The computer readable code may be embodied or stored on a computer readable medium, such as a memory chip, optical disc, or other storage medium. The computer readable medium may be part of a computer program product. The UE may be the UE 412 or UE 500 as described later with reference to Figs. 4 and 5 respectively.

The UE has a first Successful PSCell Report (SPR) configuration and a second SPR configuration for determining when to generate SPRs.

In step 301 , based on the occurrence of an event or procedure, the UE releases at least part of the first SPR configuration and/or releases at least part of the second SPR configuration. That is, on the occurrence of the event or procedure, the UE evaluates which of the first SPR configuration and the second SPR configuration (or both) is to be released partly, or in full.

In some cases, step 301 can result in the UE releasing only a part of the first SPR configuration. This can mean that the other part of the first SPR configuration is kept (i.e. not released). In other cases, step 301 can result in the UE releasing the first SPR configuration in full.

Either or both of the SPR configurations can comprise a plurality of timer thresholds, e.g. any one or more of T304, T310 and T312 thresholds.

In some cases, step 301 can result in the UE not releasing (i.e. keeping) the first SPR configuration and releasing the second SPR configuration. In other cases, step 301 can result in the UE not releasing (i.e. keeping) the first SPR configuration and releasing a part of the second SPR configuration. In other cases, step 301 can result in the UE releasing the first SPR configuration and releasing a part of the second SPR configuration. In other cases, step 301 can result in the UE releasing a part of the first SPR configuration and releasing a part of the second SPR configuration. In other cases, step 301 can result in the UE releasing the first SPR configuration and releasing the second SPR configuration.

The first SPR configuration may have been received from, or configured by, a PCell, a source PSCell or a target PSCell. Where the first SPR configuration was received from, or configured by, one of a PCell, a source PSCell or a target PSCell, the second SPR configuration can be received from, or configured by, a different one of the PCell, source PSCell and target PSCell. The UE may have a third SPR configuration that was received from, or configured by, the remaining one of the PCell, source PSCell and target PSCell. In this case, in step 301 the UE may not release (i.e. keep) one of the SPR configurations, and release at least part or all of the other two SPR configurations. Alternatively, in step 301 the UE may not release (i.e. keep) two of the SPR configurations and release at least part of the other SPR configuration. As another alternative, in step 301 the UE may release all three SPR configurations.

The event or procedure that triggers or initiates step 301 can be a RRC event or procedure. The event or procedure can be any of:

• receiving the SPR configuration from a PCell and/or source PSCell, and/or target PSCell;

• successfully performing a PSCell change/addition procedure using a PSCell change/addition configuration provided by the PCell or PSCell;

• failure of a PSCell change/addition procedure using a PSCell change/addition configuration provided by the PCell or PSCell;

• performing a MR-DC release procedure; • successfully performing a PCell handover;

• successfully performing a simultaneous PCell handover and PSCell change/addition;

• successfully performing a PCell handover without PSCell change/addition;

• performing a re-establishment procedure following a RLF or HOF in the PCell;

• performing a RRC resume procedure;

• performing RRC resume with or without SCG restoration;

• RLF in the PCell or PSCell;

• HOF in the PCell or PSCell; or

• performing fast MCG link recovery following RLF in the PCell.

Implementation examples

The following section provides an exemplary implementation of the techniques described herein in the 3GPP technical specifications. In particular, the following implementation is set out for 3GPP TS 38.331 v17.4.0.

Upon successful PSCell change, the aforementioned embodiments can be represented in the technical specification as follows (with the new content indicated in bold and underline), whereby the SPR configuration provided by the source PSCell and the T304 threshold configuration provided in the SPR configuration of the target PSCell are released, but the UE keeps the SPR configuration provided by the PCell:

Upon successful PCell change, i.e. ordinary HO with no PSCell change, the aforementioned embodiments can be represented in the technical specification as follows (with the new content indicated in bold and underline), whereby the SPR configuration provided by the source PCell is released, but the UE keeps the SPR configuration provided by the PSCell:

Upon MR-DC release, the aforementioned embodiments can be represented in the technical specification as follows (with the new content indicated in bold and underline), whereby the SPR configuration provided by the PCell and PSCell are both released:

Upon performing RRC resume, the aforementioned embodiments can be represented in the technical specification as follows (with the new content indicated in bold and underline), wherein the SPR configuration provided by the PCell and PSCell are both released, i.e. any SPR configuration configured by any cell group is released:

The SPR configuration can be conveyed in the OtherConfig provided by the PCell, i.e. by the MCG, and/or in the OtherConfig provided by the source PSCell, i.e. by the source SCG, and/or in the OtherConfig provided by the target PSCell, i.e. by the target SCG. The technical specification impact can be as follows (with the new content indicated in bold and underline):

Fig. 4 shows an example of a communication system 400 in accordance with some embodiments. In the example, the communication system 400 includes a telecommunication network 402 that includes an access network 404, such as a radio access network (RAN), and a core network 406, which includes one or more core network nodes 408. The access network 404 includes one or more access network nodes, such as access network nodes 410a and 410b (which are interchangeably referred to as RAN network nodes 410 herein), or any other similar 3^rd Generation Partnership Project (3GPP) access node or non-3GPP access point (AP). Moreover, as will be appreciated by those of skill in the art, a RAN 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 telecommunication network 402 includes one or more Open-RAN (ORAN) network nodes. An ORAN network node is a node in the telecommunication network 402 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 telecommunication network 402, including one or more network nodes 410 and/or core network nodes 408.

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 (RIC) (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 A1 , F1 , W1 , E1 , 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 access network nodes 410 facilitate direct or indirect connection of wireless devices (also referred to interchangeably herein as user equipment (UE)), such as by connecting UEs 412a, 412b, 412c, and 412d (one or more of which may be generally referred to as UEs 412) to the core network 406 over one or more wireless connections. The access network nodes 410 may be, for example, access points (APs) (e.g. radio access points), base stations (BSs) (e.g. radio base stations, Node Bs, evolved Node Bs (eNBs) and New Radio (NR) NodeBs (gNBs)).

Unless otherwise indicated, the general term ‘network node’ as used herein refers to access network nodes 410 and core network nodes 408.

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 400 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 400 may include and/or interface with any type of communication, telecommunication, data, cellular, radio network, and/or other similar type of system.

The wireless devices/UEs 412 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 410 and other communication devices. Similarly, the access network nodes 410 are arranged, capable, configured, and/or operable to communicate directly or indirectly with the UEs 412 and/or with other network nodes or equipment in the telecommunication network 402 to enable and/or provide network access, such as wireless network access, and/or to perform other functions, such as administration in the telecommunication network 402.

In the depicted example, the core network 406 connects the access network nodes 410 to one or more hosts, such as host 416. 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 406 includes one more core network nodes (e.g. core network node 408) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the wireless devices/UEs, access network nodes, and/or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 408. Example core network nodes include functions of one or more of a Mobile Switching Center (M SC), 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 (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and/or a User Plane Function (UPF).

The host 416 may be under the ownership or control of a service provider other than an operator or provider of the access network 404 and/or the telecommunication network 402, and may be operated by the service provider or on behalf of the service provider. The host 416 may host a variety of applications to provide one or more services. Examples of such applications include the provision of live and/or pre-recorded audio/video content, data collection services, for example, 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.

As a whole, the communication system 400 of Fig. 4 enables connectivity between the wireless devices/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 2^nd Generation (2G), 3^rd Generation (3G), 4^th Generation (4G), 5^th Generation (5G) standards, or any applicable future generation standard (e.g. 6^th Generation (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.

In some examples, the telecommunication network 402 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunications network 402 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 402. For example, the telecommunications network 402 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)ZMassive Internet of Things (loT) services to yet further UEs.

In some examples, the UEs 412 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 404 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 404. Additionally, a UE may be configured for operating in single- or multi-radio access technology (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- UTRA (UMTS Terrestrial Radio Access) Network) New Radio - Dual Connectivity (EN-DC).

In the example illustrated in Fig. 4, the hub 414 communicates with the access network 404 to facilitate indirect communication between one or more UEs (e.g. UE 412c and/or 412d) and access network nodes (e.g. access network node 410b). In some examples, the hub 414 may be a controller, router, a content source and analytics node, or any of the other communication devices described herein regarding UEs. For example, the hub 414 may be a broadband router enabling access to the core network 406 for the UEs. As another example, the hub 414 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 410, or by executable code, script, process, or other instructions in the hub 414. As another example, the hub 414 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 414 may be a content source. For example, for a UE that is a Virtual Reality VR headset, display, loudspeaker or other media delivery device, the hub 414 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 414 then provides to the UE either directly, after performing local processing, and/or after adding additional local content. In still another example, the hub 414 acts as a proxy server or orchestrator for the UEs, in particular if one or more of the UEs are low energy Internet of Things (loT) devices.

The hub 414 may have a constant/persistent or intermittent connection to the network node 410b. The hub 414 may also allow for a different communication scheme and/or schedule between the hub 414 and UEs (e.g. UE 412c and/or 412d), and between the hub 414 and the core network 406. In other examples, the hub 414 is connected to the core network 406 and/or one or more UEs via a wired connection. Moreover, the hub 414 may be configured to connect to a Machine-to-Machine (M2M) service provider over the access network 404 and/or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes 410 while still connected via the hub 414 via a wired or wireless connection. In some embodiments, the hub 414 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 410b. In other embodiments, the hub 414 may be a non-dedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node 410b, but which is additionally capable of operating as a communication start and/or end point for certain data channels.

Fig. 5 shows a wireless device or UE 500 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 wireless device/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 camera, 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, vehiclemounted 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-loT) UE, a machine type communication (MTC) UE, and/or an enhanced MTC (eMTC) UE.

A wireless device/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).

The UE 500 includes processing circuitry 502 that is operatively coupled via a bus 504 to an input/output interface 506, a power source 508, a memory 510, a communication interface 512, and/or any other component, or any combination thereof. Certain UEs may utilize all or a subset of the components shown in Fig. 5. 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.

The processing circuitry 502 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 510. The processing circuitry 502 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 502 may include multiple central processing units (CPUs). The processing circuitry 502 may be operable to provide, either alone or in conjunction with other UE 500 components, such as the memory 510, to provide UE 500 functionality. For example, the processing circuitry 502 may be configured to cause the UE 502 to perform the methods according to any of the embodiments described herein.

In the example, the input/output interface 506 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 500. 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.

In some embodiments, the power source 508 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 508 may further include power circuitry for delivering power from the power source 508 itself, and/or an external power source, to the various parts of the UE 500 via input circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging of the power source 508. Power circuitry may perform any formatting, converting, or other modification to the power from the power source 508 to make the power suitable for the respective components of the UE 500 to which power is supplied.

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

The memory 510 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 Universal Subscriber Identity Module (USIM) and/or integrated SIM (ISIM), other memory, or any combination thereof. The UICC may for example be an embedded UICC (eUlCC), integrated UICC (iUICC) or a removable UICC commonly known as ‘SIM card.’ The memory 510 may allow the UE 500 to access instructions, application programs and the like, stored on transitory or non-transitory memory media, to offload 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 510, which may be or comprise a device- readable storage medium.

The processing circuitry 502 may be configured to communicate with an access network or other network using the communication interface 512. The communication interface 512 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna 522. The communication interface 512 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 518 and/or a receiver 520 appropriate to provide network communications (e.g. optical, electrical, frequency allocations, and so forth). Moreover, the transmitter 518 and receiver 520 may be coupled to one or more antennas (e.g. antenna 522) and may share circuit components, software or firmware, or alternatively be implemented separately.

In some embodiments, communication functions of the communication interface 512 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) or other Global Navigation Satellite System (GNSS) 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, 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.

Regardless of the type of sensor, a UE may provide an output of data captured by its sensors, through its communication interface 512, 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).

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 controls a robotic arm performing a medical procedure according to the received input.

A UE, when in the form of an 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 devices which are or which are 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 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 on the intended application of the loT device in addition to other components as described in relation to the UE 500 shown in Fig. 5.

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-loT 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.

Although the computing devices described herein (e.g. UEs, RAN network nodes, core network node, hosts) 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. 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.

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.

The foregoing merely illustrates the principles of the disclosure. Various modifications and alterations to the described embodiments will be apparent to those skilled in the art in view of the teachings herein. It will thus be appreciated that those skilled in the art will be able to devise numerous systems, arrangements, and procedures that, although not explicitly shown or described herein, embody the principles of the disclosure and can be thus within the scope of the disclosure. Various exemplary embodiments can be used together with one another, as well as interchangeably therewith, as should be understood by those having ordinary skill in the art. EMBODIMENTS

Group A Embodiments

1. A method performed by a user equipment, UE, wherein the UE has a first Successful Primary Secondary Cell Group Cell, PSCell, Report, SPR, configuration for determining when to generate SPRs, the method comprising: on or following the occurrence of an event or procedure, evaluating whether the UE is to keep or release the first SPR configuration; and based on the result of the evaluation, keeping the first SPR configuration or releasing at least part of the first SPR configuration.

2. The method of Embodiment 1 , wherein the result of the evaluation is to release only a part of the first SPR configuration.

3. The method of Embodiment 2, wherein the other part of the first SPR configuration is kept.

4. The method of any of Embodiments 1-3, wherein the first SPR configuration comprises a plurality of timer thresholds, and wherein the result of the evaluation is to release only some of the plurality of timer thresholds.

5. The method of Embodiment 1 , wherein the result of the evaluation is to release the first SPR configuration in full.

6. The method of Embodiment 5, wherein the first SPR configuration comprises a plurality of timer thresholds.

7. The method of any of Embodiments 1-5, wherein the first SPR configuration was received from, or configured by, a Primary Cell, PCell, a source PSCell or a target PSCell.

8. The method of any of Embodiments 1-7, wherein the UE has at least a second SPR configuration.

9. The method of any of Embodiments 1-8, wherein the first SPR configuration was received from, or configured by, a Primary Cell, PCell, a source PSCell or a target PSCell, and wherein the UE has a second SPR configuration that was received from, or configured by, a different one of the PCell, source PSCell and target PSCell.

10. The method of Embodiment 8 or 9, wherein the result of the evaluation is to keep the first SPR configuration and to release the second SPR configuration.

11. The method of Embodiment 8 or 9, wherein the result of the evaluation is to keep the first SPR configuration and to release a part of the second SPR configuration.

12. The method of Embodiment 8 or 9, wherein the result of the evaluation is to release the first SPR configuration and to release at least a part of the second SPR configuration.

13. The method of Embodiment 9, wherein the UE has a third SPR configuration that was received from, or configured by, the remaining one of the PCell, source PSCell and target PSCell.

14. The method of Embodiment 13, wherein the result of the evaluation is to keep the first SPR configuration, the second SPR configuration and the third SPR configuration.

15. The method of Embodiment 13, wherein the result of the evaluation is to keep one of the SPR configurations and to release at least part of all of the other two SPR configurations.

16. The method of Embodiment 13, wherein the result of the evaluation is to keep two of the SPR configurations and to release at least part of the other SPR configuration.

17. The method of Embodiment 13, wherein the result of the evaluation is to release the first SPR configuration, the second SPR configuration and the third SPR configuration.

18. The method of any of Embodiments 1-17, wherein the event or procedure is a Radio Resource Control, RRC, event or procedure.

19. The method of any of Embodiments 1-18, wherein the event or procedure is one of:

• receiving the SPR configuration from a Primary Cell, PCell, and/or source PSCell, and/or target PSCell;

• successfully performing a PSCell change/addition procedure using a PSCell change/addition configuration provided by the PCell or PSCell; • failure of a PSCell change/addition procedure using a PSCell change/addition configuration provided by the PCell or PSCell;

• performing a Multi-Radio Dual Connectivity, MR-DC, release procedure;

• successfully performing a PCell handover;

• successfully performing a PCell handover without PSCell change/addition;

• performing a re-establishment procedure following a Radio Link Failure in the PCell;

• performing a re-establishment procedure following a Handover Failure, HOF, in the PCell;

• performing a Radio Resource Control, RRC, resume procedure;

• performing RRC resume without Secondary Cell Group, SCG, restoration;

• performing RRC resume with SCG restoration;

• RLF in the PCell;

• HOF in the PCell;

• RLF in the PSCell;

• HOF in the PSCell; or

• performing fast Master Cell Group, MCG, link recovery following RLF in the PCell.

Group C Embodiments

20. A computer program product comprising a computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform the method of any of the Group A embodiments.

21. A user equipment, UE, configured to perform the method of any of the Group A embodiments.

22. A user equipment, UE, comprising a processor and a memory, said memory containing instructions executable by said processor whereby said UE is operative to perform the method of any of the Group A embodiments.

23. A user equipment, UE, comprising: processing circuitry configured to cause the user equipment to perform any of the steps of any of the Group A embodiments; and power supply circuitry configured to supply power to the processing circuitry. 24. A user equipment, UE, the UE comprising: an antenna configured to send and receive wireless signals; radio front-end circuitry connected to the antenna and to processing circuitry, and configured to condition signals communicated between the antenna and the processing circuitry; the processing circuitry being configured to perform any of the steps of any of the Group A embodiments; an input interface connected to the processing circuitry and configured to allow input of information into the UE to be processed by the processing circuitry; an output interface connected to the processing circuitry and configured to output information from the UE that has been processed by the processing circuitry; and a battery connected to the processing circuitry and configured to supply power to the UE.

Claims

1. A method performed by a user equipment, UE, wherein the UE has a first Successful Primary Secondary Cell Group Cell, PSCell, Report, SPR, configuration and a second SPR configuration for determining when to generate SPRs, the method comprising: based on the occurrence of an event or procedure, releasing (301) at least part of the first SPR configuration and/or releasing at least part of the second SPR configuration.

2. The method of Claim 1 , wherein, based on the occurrence of the event or procedure, releasing only a part of the first SPR configuration.

3. The method of Claim 2, wherein the other part of the first SPR configuration is kept.

4. The method of Claim 1 , wherein, based on the occurrence of the event or procedure, releasing the first SPR configuration in full.

5. The method of any of Claims 1-4, wherein the first SPR configuration and/or the second SPR configuration comprises a plurality of timer thresholds.

6. The method of any of claims 1-5, wherein, based on the occurrence of the event or procedure, not releasing the first SPR configuration and releasing the second SPR configuration.

7. The method of any of claims 1-5, wherein, based on the occurrence of the event or procedure, not releasing the first SPR configuration and releasing a part of the second SPR configuration.

8. The method of any of claims 1-5, wherein, based on the occurrence of the event or procedure, releasing the first SPR configuration and releasing a part of the second SPR configuration.

9. The method of any of claims 1-5, wherein, based on the occurrence of the event or procedure, releasing the first SPR configuration and releasing the second SPR configuration.

10. The method of any of Claims 1-9, wherein the first SPR configuration was received from, or configured by, a Primary Cell, PCell, a source PSCell or a target PSCell.

11. The method of any of Claims 1-9, wherein the first SPR configuration was received from, or configured by, a Primary Cell, PCell, a source PSCell or a target PSCell, and the second SPR configuration was received from, or configured by, a different one of the PCell, source PSCell and target PSCell.

12. The method of claim 11 , wherein the UE has a third SPR configuration that was received from, or configured by, the remaining one of the PCell, source PSCell and target PSCell.

13. The method of Claim 12, wherein, based on the occurrence of the event or procedure, not releasing one of the SPR configurations and releasing at least part or all of the other two SPR configurations.

14. The method of Claim 12, wherein, based on the occurrence of the event or procedure, not releasing two of the SPR configurations and releasing at least part of the othSPRSPR configuration.

15. The method of Claim 12, wherein, based on the occurrence of the event or procedure, releasing the first SPR configuration, the second SPR configuration and the third SPR configuration.

16. The method of any of Claims 1-15, wherein the event or procedure is a Radio Resource Control, RRC, event or procedure.

17. The method of any of Claims 1-16, wherein the event or procedure is one of:

• performing a Multi-Radio Dual Connectivity, MR-DC, release procedure;

• successfully performing a PCell handover;

• successfully performing a PCell handover without PSCell change/addition; • performing a re-establishment procedure following a Radio Link Failure in the PCell;

• performing a Radio Resource Control, RRC, resume procedure;

• performing RRC resume without Secondary Cell Group, SCG, restoration;

• performing RRC resume with SCG restoration;

• RLF in the PCell;

• HOF in the PCell;

• RLF in the PSCell;

• HOF in the PSCell; or

18. A computer program product comprising a computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform the method of any of claims 1-17.

19. A user equipment, UE, configured to perform the method of any of claims 1-17.

20. A user equipment, UE, comprising a processor and a memory, said memory containing instructions executable by said processor whereby said UE is operative to perform the method of any of claim 1-17.