WO2020117118A1

WO2020117118A1 - A wireless device and method performed by the wireless device when accessing a cell

Info

Publication number: WO2020117118A1
Application number: PCT/SE2019/051230
Authority: WO
Inventors: Icaro L. J. Da Silva; Patrik Rugeland
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2018-12-07
Filing date: 2019-12-05
Publication date: 2020-06-11
Also published as: EP3892031A1

Abstract

A method and a wireless device (100) in connected mode when accessing a cell and operating in a wireless communications network (102) and having a set of stored configurations for at least one target cell X (106A-106C). The wireless device (100) updates one or more stored configurations comprised in the set of stored configurations upon access of the cell. When the accessed cell is one of the target cell(s), the wireless device (100) applies one out of the one or more stored configurations comprised in the set of stored configurations to access the one of the at least one target cell X. When the accessed cell is different from the target cell(s), the wireless device (100) applies a received configuration to access the cell.

Description

A WIRELESS DEVICE AND METHOD PERFORMED BY THE WIRELESS DEVICE WHEN ACCESSING A CELL

Technical field

The present disclosure relates generally to a wireless device and a method performed by the wireless device when accessing a cell.

Background

In this disclosure, the term“wireless device” is used to represent any

communication entity capable of radio communication with a wireless network by sending and receiving radio signals, such as e.g. mobile telephones, tablets, laptop computers and Machine-to-Machine, M2M, devices, also known as Machine Type Communication, MTC, devices. Another common generic term in this field is“User Equipment, UE” which is frequently used herein as a synonym for wireless device. This disclosure is thus not limited to any particular wireless device or UE, as long as it is capable of radio communication and of executing a handover from one access point to another.

Further, the term“network node”, is used herein to represent any node or access point of a wireless network that is operative to communicate radio signals with wireless devices. For example, the wireless network may be operating according to Long Term Evolution LTE or according to 5G, also referred to as“New Radio” NR, both being defined by the third Generation Partnership Project, 3GPP. The network nodes herein may refer to base stations, eNBs, gNBs, ng-eNBs, access points, etc., depending on the terminology used, although this disclosure is not limited to these examples. The node ng-eNB is defined for 5G in the 3GPP document TS38.300 section 3.

A protocol known as Radio Resource Control, RRC, defined by 3GPP is used on the air interface between a wireless device and a wireless network, e.g. operating according to the Universal Mobile Telecommunications System, UMTS, or Long Term Evolution, LTE. Among other things, RRC is used to control handover and cell selection procedures, including when a wireless device switches its network connection from a current cell, referred to as“source” cell, to a new cell, referred to as“target” cell.

A considerable amount of signaling is normally required between the wireless device and the wireless network for cell attachment, and it may sometimes be problematic that this signaling causes delays so that the cell attachment may not have time to be completed before the wireless device loses contact with the source cell, e.g. due to rapidly worsening radio conditions. Another potential problem associated with cell attachment is that the wireless device may have stored a set of configurations related to target cells but does not know how to handle these configurations upon access of the cell. It also follows that the network is not aware of how the device handles its stored cell configurations after a cell has been accessed. As a result, the network has no knowledge of whether the device can use any stored configuration or not upon its next access to a cell.

In this description, communicating data and messages with a source or target “cell” is to be understood as communication with a network node that provides radio coverage in that cell. The term radio conditions basically refers to quality and strength of received radio signals and also the amount of interference from other transmissions.

Summary

It is an object of embodiments described herein to address at least some of the problems and issues discussed herein. It is possible to achieve this object and others by using a method and a wireless device as defined in the attached independent claims.

According to one aspect, a method is performed by a wireless device in connected mode when accessing a cell. The wireless device is operating in a wireless communications network and has a set of stored configurations for at least one target cell X. In this method, the wireless device updates one or more stored configurations comprised in the set of stored configurations upon access of the cell. When the accessed cell is one out of the at least one target cell, the wireless device applies one out of the one or more stored configurations comprised in the set of stored configurations to access the one of the at least one target cell X. When the accessed cell is different from one of the at least one target cell, the wireless device applies a received configuration to access the cell.

According to another aspect, a wireless device is arranged or configured to operate in a wireless communications network and having a set of stored configurations for at least one target cell X. When in connected mode and accessing a cell, the wireless device is configured to update one or more stored configurations comprised in the set of stored configurations upon access of the cell. This operation may be performed by means of an updating module in the wireless device.

When the cell is one out of the at least one target cell, the wireless device is configured to apply one out of the one or more stored configurations comprised in the set of stored configurations to access the one of the at least one target cell X. On the other hand, when the cell is different from one of the at least one target cell, the wireless device is configured to apply a received configuration to access the cell.

When using either of the above method and wireless device, it is an advantage that the amount of signaling over the air can be greatly reduced when the device selects a target cell with a configuration that has already been obtained and stored by the device, and this configuration is thus not necessary to be obtained, e.g. in an RRC re-establishment procedure, upon the cell selection. It is also an advantage that the network can be aware of how the device will handle its stored configurations by updating one or more stored configurations in the set of stored configurations upon access of the cell, which is useful knowledge e.g. enabling efficient communication with the device when it next accesses a cell.

The above method and wireless device may be configured and implemented according to different optional embodiments to accomplish further features and benefits, to be described below. A computer program is also provided comprising instructions which, when executed on at least one processor in the above wireless device, cause the at least one processor to carry out the method described above. A carrier is also provided which contains the above computer program, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium.

Brief description of drawings

The solution will now be described in more detail by means of exemplary embodiments and with reference to the accompanying drawings, in which: Fig. 1 illustrates a communication scenario involving a wireless device in a wireless network, where the examples and embodiments described herein may be used.

Fig. 2 is a flow chart illustrating a procedure in a wireless device, according to some example embodiments. Fig. 3 is a block diagram illustrating how a wireless device may be structured, according to further example embodiments.

Figs 4A-C is a signaling diagram illustrating a conventional handover procedure for a wireless device from a source gNB to a target gNB.

Fig. 5 is a signaling diagram illustrating a conventional handover from a serving gNB to a target gNB when conditional handover is employed.

Figs 6A-B is a signaling diagram illustrating an example of how a handover procedure can be executed with substantially reduced signaling as compared to conventional procedures.

Figs 7A-B is a signaling diagram illustrating another example of how a handover procedure can be executed with substantially reduced signaling as compared to conventional procedures. Figs 8A-B is a signaling diagram illustrating another example of how a handover procedure can be executed with substantially reduced signaling as compared to conventional procedures.

Figs 10-15 illustrate further scenarios, structures and procedures that may be employed when the solution is used, according to further possible embodiments.

Detailed Description

The solution will now be described and explained in terms of functionality in a wireless device which is operable in a wireless network for accessing a cell. It is assumed that the accessed cell is served by a network node. In this disclosure, the terms target cell, candidate and candidate cell are used interchangeably. Further, when it is mentioned herein that a cell performs some activity or operation, it means that it is a network node of the cell that actually performs the activity or operation. Further, when it is mentioned herein that the network is involved in some activity or operation, it should be understood that this activity or operation involves functionality in at least one suitable node of the network, typically a network node that provides radio coverage of a cell.

Fig. 1 illustrates a communication scenario where the examples and

embodiments described herein may be used. A wireless device 100 is shown to operate in a wireless network 102, and communicates currently with a serving network node covering a serving cell 104, also referred to as a source cell which term will be used herein. Some other nearby cells likewise covered and served by network nodes are also shown in the figure, denoted 106A-C, which can be seen as potential candidates, i.e. target cells, for handover of the device 100. In this description, the term cell should be understood broadly as a radio coverage area covered and served by a network node which thus can provide

communication services to wireless devices located in the cell. The cells in this figure are schematically indicated by dashed lines which in reality may have any forms and shapes such as circles, sectors and beams. According to conventional procedures, the wireless device 100 performs measurements on signals transmitted from the cells 104, 106A-C and reports the measurements to the serving node of cell 104 which node then may decide that the wireless device should be handed over to a target cell that can provide better reception of signals than the source cell 104. In order to execute such a commanded access to a target cell, e.g. one of cells 106A-C, the wireless device needs to obtain various configuration information that should be used for accessing the target cell. Such configuration information related to the target cell, also sometimes herein referred to as Radio Resource Control (RRC)

configuration, is usually transmitted from the source cell 104 in an RRC command to the device 100, i.e. after the reported measurements have been evaluated and the access decision has been taken.

In some of the examples and embodiments herein, so-called Radio Link Failure, RLF, is used as an example of communication failure which implies that the radio link in the serving cell 104 is not good enough to be used for the communication between the device 100 and the network 102, commonly also referred to as “bad” radio conditions. However, the examples and embodiments herein are not limited to the occurrence of RLF but could be employed also at other types of communication failure such as, e.g., handover failure and failure to comply with a configuration for accessing the wireless network.

In order to execute a commanded handover or re-establishment to a target cell, e.g. to one of cells 106A-C, the wireless device 100 needs to obtain various configuration information that should be used for accessing the target cell. Such configuration information related to the target cell, which may comprise an RRC configuration, is in the case of handover transmitted from the source cell 104, e.g. in a handover command to the device 100, which may be sent from the source cell 104 to the device after the reported measurements have been evaluated and a handover decision has been taken. In the case of re

establishment, configuration information related to the target cell is sent by the target cell in a re-establishment command to the device, after said device has selected that cell in a cell selection procedure. However, it may happen that the current connection to the source cell 104 is rapidly deteriorated so much that the wireless device 100 is not able to properly receive and detect the configuration information transmitted from the source cell 104, e g. in the RRC command. As a result, the device 100 is not able to access the target cell in time and a handover thus fails. This can be solved by utilizing a configuration, e.g. an RRC configuration, for at least one target cell X which has been obtained and stored in advance by the device 100, e.g. when transmitted from the source cell 104, well before any RRC procedure has been decided and initiated.

Thereby, the wireless device 100 can opportunistically select one of the candidate or target cells X for which a configuration has already been stored, and access the selected target cell using the stored configuration without having to receive the configuration in a command from the network, e.g. through the source cell 104. Changing connection using stored configurations without a command from the network when to change the connection may be called an opportunistic handover. In other words, the wireless device 100 may receive a conditional handover command, but the wireless device 100 is not instructed when to use the configurations.

However, in some scenarios such as upon reconfiguration, e.g. handover, conditional handover or opportunistic handover, or upon communication failure such as RLF, integrity protection failure or reconfiguration failure, it is not specified what the wireless device should do with its stored configurations upon access of a cell. As a result, the network cannot foresee how the device will handle its stored cell configurations and has thus no knowledge of whether the device can use any stored configuration or not upon its next access to a cell. This may be an issue when multiple cells may be configured for access and the wireless device has stored configurations for one or more of these multiple cells.

It should be understood that a conditional handover could be handled as an opportunistic handover. At least some of the embodiments disclosed herein relate to handling of stored configurations of cells that are not yet accessed by the wireless device.

An example of how the solution may be employed in terms of actions performed by a wireless device such as the wireless device 100, is illustrated by the flow chart in Fig. 2 which will now be described with further reference to Fig. 1 , although this procedure is not limited to the example of Fig. 1. Fig. 2 thus illustrates a procedure performed by the wireless device 100 in connected mode when accessing a cell and when operating in a wireless communications network 102 and having a set of stored configurations for at least one target cell X 106A- 106C.

Action 200 illustrates that the wireless device 100, upon access of the cell, updates one or more stored configurations comprised in the set of stored configurations. Thereby, the device 100 knows how to handle its stored

configurations upon access of the cell, and the network is further able to know which configurations are currently stored in the device by knowing how the one or more stored configurations were updated in action 200. Some examples of how the stored configuration(s) can be updated as of action 200 will be described later below with reference to some possible example embodiments.

Some non-limiting example embodiments that may be employed in the above procedure in Fig. 2 will now be described.

In some embodiments, the accessed cell may be one out of the at least one target cell 106A-106C. In such embodiments, the wireless device 100 may apply one out of the one or more stored configurations comprised in the set of stored

configurations to access the one of the at least one target cell X 106A-106C. In some alternative embodiments, the accessed cell may be different from one of the at least one target cell 106A-106C. In such embodiments, the wireless device 100 may apply a received configuration to access the cell.

The wireless device 100 may update the one or more stored configurations being different from a configuration to access the cell. In some embodiments, the wireless device 100 may perform the updating of the set of stored configurations in action 200 by performing one or more out of:

- discarding or removing one or more out of the stored configurations from the set;

- maintaining one or more configurations in the set of stored

configurations;

- stopping a timer relating to one or more out of the stored configurations of the set and updating the one or more out of the stored configurations of the set accordingly;

- stopping monitoring triggering conditions;

- removing a measurement result from one or more out of the stored configurations of the set;

- releasing any configured measurement gaps associated with the access of the cell;

- releasing an identity of the one or more stored configurations; and

- performing one or more measurement relating actions upon triggering of the access of the cell.

For example, if the wireless device 100 is configured with configurations for the cells 106A, 106B and 106C and accesses the cell 106A, then the stored configurations will only contain the configurations for the cells 106B and 106C, i.e. the set of stored configurations are modified, but the actual configurations are not changed.

In some further embodiments, the wireless device 100 accesses the cell by performing a handover procedure, a conditional handover procedure or a re establishment procedure.

The wireless device 100 may receive from the network an indication to perform the updating of the one or more stored configurations after the access of the cell. The indication may be received from a source cell 104, or from one of the at least one target cell X 106A-106C, or from another cell. It should be understood that the indication may be part of the stored configuration. For example, the indication may be that the wireless device 100 for the cell 106A and the cell 106B shall release any stored configurations after access of any one of these cells 106A, 106B, but when accessing the cell 106C the configurations should be kept.

Each stored configuration may be an RRC configuration, such as an RRC

Reconfiguration, a handover configuration, a conditional handover configuration, inter-RAT handover configuration, or inter-system handover configuration, just to give some examples. For example, the configuration may be provided by the network as an inter-RAT handover message (which is called

MobilityFromEUTRACommand or MobilityFromNRCommand), or a corresponding LTE message, i.e. RRCConnectionReconfiguration. All these messages may be considered as handover configurations. The term RAT used above denotes Radio Access Technology.

In some further embodiments, the wireless device 100 may perform the updating of the one or more stored configurations in action 200 upon a re-establishment procedure, or upon detecting a communication failure, or upon a conditional handover execution, or upon a handover execution. Thus, in some embodiments, the updating could be triggered by a re-establishment procedure, a handover execution or a conditional handover execution.

Some examples of a communication failure could be a handover failure, a radio link failure (RLF), integrity protection failure, and a failure to comply with a configuration for accessing the wireless network.

The block diagram in Fig. 3 illustrates a detailed but non-limiting example of how a wireless device 300 may be structured to bring about the above-described solution and embodiments thereof. In this figure, the wireless device 300 may be configured to operate according to any of the examples and embodiments of employing the solution as described herein, where appropriate, e.g. in the manner described for the wireless device 100. The wireless device 300 is shown to a processor“P”, a memory“M” and a communication circuit“C” with suitable equipment for transmitting and receiving information and messages in the manner described herein. The communication circuit C in the wireless device 300 thus comprises equipment configured for communication using a suitable protocol for the communication depending on the implementation. The solution is however not limited to any specific types of messages or protocols. The wireless device 300 is, e g. by means of units, modules or the like, configured or arranged to perform at least some of the actions of the flow chart in Fig. 2 and as follows. The wireless device 300 may further correspond to the above- described wireless device 100 of Fig. 1 .

It is assumed that the wireless device 300 at some point has been configured with a set of configurations for at least one target cell X 106A-106C which are stored in the device 300.

The wireless device 300 is capable of operating in connected mode.

The wireless device 300 is configured to operate in a wireless communications network and having a set of stored configurations for at least one target cell X. When in connected mode and accessing a cell, the wireless device 300 is configured to update one or more stored configurations in the set of stored configurations upon access of the cell. This operation may be performed by an updating module 300A in the wireless device 300, as also illustrated in action 200.

It should be noted that Fig. 3 illustrates various functional modules in the wireless device 300 and the skilled person is able to implement these functional modules in practice using suitable software and hardware equipment. Thus, the solution is generally not limited to the shown structure of the wireless device 300, and the functional modules therein may be configured to operate according to any of the features, examples and embodiments described in this disclosure, where appropriate.

The functional module 300A described above may be implemented in the wireless device 300 by means of program modules of a computer program comprising code means which, when run by the processor P causes the wireless device 300 to perform the above-described actions and procedures. The processor P may comprise a single Central Processing Unit (CPU), or could comprise two or more processing units. For example, the processor P may include a general purpose microprocessor, an instruction set processor and/or related chips sets and/or a special purpose microprocessor such as an Application Specific Integrated Circuit (ASIC). The processor P may also comprise a storage for caching purposes.

The computer program may be carried by a computer program product in the wireless device 300 in the form of a memory having a computer readable medium and being connected to the processor P. The computer program product or memory M in the wireless device 300 thus comprises a computer readable medium on which the computer program is stored e.g. in the form of computer program modules or the like. For example, the memory M may be a flash memory, a Random-Access Memory (RAM), a Read-Only Memory (ROM) or an Electrically Erasable Programmable ROM (EEPROM), and the program modules could in alternative embodiments be distributed on different computer program products in the form of memories within the wireless device 300.

The solution described herein may be implemented in the wireless device 300 by a computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the actions according to any of the above embodiments and examples, where appropriate. The solution may also be implemented at the wireless device 300 in a carrier containing the above computer program, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

While the solution has been described with reference to specific exemplifying embodiments, the description is generally only intended to illustrate the inventive concept and should not be taken as limiting the scope of the solution. For example, the terms“wireless device”,“network node”,“conditional handover”, “configuration”,“communication failure”,“target cell”,“cell selection” and“RRC re establishment procedure” have been used throughout this disclosure, although any other corresponding entities, functions, and/or parameters could also be used having the features and characteristics described here. The solution may for example be defined by the appended claims. The above mentioned problem of not knowing how to handle stored configurations upon access of a cell will now be described in more detail. Some currently available procedures will also be described. In the following, the above wireless device 100 or 300 will frequently be referred to as a user equipment or UE for short. Further, handover is often referred to as HO for short.

Mobility in a so-called RRC_CONNECTED state according to LTE and NR, which corresponds to the term connected mode used above, will now be described.

A connected wireless device, such as an RRC_CONNECTED UE in LTE (also called Evolved Universal Terrestrial Radio Access, E-UTRA) or an

RRC_CONNECTED UE in NR, can thus be configured by the network to perform measurements and use triggers for transmitting measurement reports to the network. Upon reception of the measurement reports, the network may send a handover command to the device/UE. In LTE the handover command may be a message called RRConnectionReconfiguration provided with a field called mobilityControllnfo, and in NR the handover command may be a message called RRCReconfiguration provided with a field called reconfigurationWithSync.

These reconfigurations are prepared by the target cell upon an inter-node request from the source node, e.g. over an X2 interface in case of E-UTRA/ Evolved Packet Core, EPC, or over an Xn interface in case of E-UTRA/5GC or NR, and takes into account the existing RRC configuration the device/UE has with the source cell (which are provided in the inter-node request). Among other parameters, the reconfiguration provided by the target node contains all information the UE needs to access the target cell, e.g. including random access configuration, a new Cell Radio Network Temporary Identifier, (C-RNTI) assigned by the target cell and security parameters enabling the UE to calculate new security keys associated to the target cell so the UE can send a handover complete message on a Signaling Radio Bearer called SRB1 (encrypted and integrity protected) based on new security keys upon accessing the target cell.

Figs 4A-C illustrate a conventional signaling procedure involving a UE, a source node, here denoted source gNB, and a target node, here denoted target gNB, during a handover procedure. In the terminology used throughout this

description, the terms source node and target node are more or less

interchangeable with the terms source cell and target cell, respectively. In more detail, Fig. 4A illustrates a handover preparation phase, Fig. 4B illustrates a handover execution phase following Fig. 4A, and Fig. 4C illustrates a handover completion phase following Fig. 4B.

Both in LTE and NR, some principles are used for handovers, commonly referred to as“mobility in RRC_CONNECTED, as follows:

Mobility in RRC_CONNECTED is Network-based as the network has access to information regarding the current situation in the network, such as load conditions in cells, resources in different nodes, available frequencies, etc. The network can also take into account the situation of many UEs in the network, for a resource allocation perspective.

The network, e.g. a source node or another network node, prepares a node of a target cell before the UE accesses that cell. The source node provides the UE with the RRC configuration to be used in the target cell, including SRB1 configuration to send HO complete.

The UE is provided by the target node with a target C-RNTI, i.e. the target node identifies the UE from a transmitted message MSG.3 on MAC level for the HO complete message. Hence, there is no context fetching performed, unless a failure occurs.

To speed up the handover, the network, e.g. the source node or another network node, provides to the UE needed information on how to access the target cell, e.g. Random Access Channel (RACH) configuration, so the UE does not have to acquire system information prior to the handover which otherwise would take some time to do.

The UE may be provided with Contention-Free Random Access (CFRA) resources, i.e. in that case the target node identifies the UE from a preamble MSG.1 transmitted by the UE. The principle behind this is that the procedure can always be optimized with dedicated resources. In Conditional Handover (CHO), that might be somewhat difficult as there is uncertainty about the final target cell but also about the timing of HO operations.

Security is prepared before the UE accesses the target cell, e.g. keys for encryption need to be refreshed before sending the RRC Connection

Reconfiguration Complete message, based on new keys and encrypted and integrity protected so that the UE can be verified in the target cell.

Both full reconfiguration and delta reconfiguration are supported so that the size of the handover command can be minimized. Work Items to achieve mobility robustness in release 16 (Rel-16) for LTE and NR and Conditional Handover, will now be described.

Two new work items for mobility enhancements in LTE and NR have started in 3GPP in release 16. The main objectives of the work items are to improve the robustness at handover and to decrease the interruption time at handover. One potential problem related to robustness at handover is that the handover command, herein referred to as HO Command, e.g. the above-mentioned RRCConnectionReconfiguration message with the mobilityControllnfo field and the RRCReconfiguration message with the reconfiguration With Sync field, is normally sent when the radio conditions for the UE are already quite bad, as also explained above. As a result, the HO Command may not reach the UE in time, particularly if the message is segmented and/or there are retransmissions resulting in added delays.

In LTE and NR, different solutions to increase mobility robustness have been discussed in the past. One solution discussed in NR is called“conditional handover” or“early handover command”. In order to avoid the undesired dependence on the serving radio link (and current radio conditions) at the time when the UE should execute the handover, the possibility to provide RRC signaling for the handover to the UE earlier should be provided. To achieve this, it should be possible to associate the HO command with a condition e.g. based on radio conditions possibly similar to the ones associated to a so-called A3 event, where signals from a given neighbor becomes‘X’ dB better than serving cell. The A3 event and other events that trigger measurement reports are defined by 3GPP, see for example 3GPP document TS 38.331 version 15.3.0, Release 15. As soon as the condition in the HO command is fulfilled, the UE executes the handover in accordance with the provided handover command.

Such a condition could e.g. be that the quality of the target cell or beam becomes Ύ dB stronger than the serving cell. The threshold X used in a preceding measurement reporting event should then be chosen lower than the threshold in the handover execution condition. This allows the serving cell to prepare the handover upon reception of an early measurement report and to provide the RRCConnectionReconfiguration message with the mobilityControllnfo field, or the RRCReconfiguration message with the ReconfigurationWithSync field, at a time when the radio link between the source cell and the UE is still stable. The execution of the handover can then be done at a later point in time, e.g. at a different signal threshold, which time is considered optimal for the handover execution.

Fig. 5 depicts an example of a signaling procedure between a UE, a serving cell i.e. a serving gNB, and a single target cell, i.e. a target gNB. The UE reports signal measurements, e.g. so-called Radio Resource Management, RRM,

measurements, to its serving gNB as a basis for handover decision. In practice there may often be several cells or beams that the UE reports as possible candidates for handover, based on its preceding RRM measurements. The network, e.g. by means of the source node or another network node, should then have the freedom to issue conditional handover commands for several of those candidates. The message RRCConnectionReconfiguration (or the message RRCReconfiguration in NR) for each of those candidates may differ e.g. in terms of the HO execution condition with respect to Reference signals to measure and a threshold to exceed, as well as in terms of a Random Access (RA) preamble to be sent from the UE when a certain condition is met. While the UE evaluates the condition in the conditional HO command, it should continue operating per its current RRC configuration, i.e. , without applying the conditional HO command. When the UE determines that the condition is fulfilled, it disconnects from the serving cell, applies the conditional HO command and connects to the target cell. These operations are equivalent to the current, instantaneous handover execution.

Opportunistic handover upon failure, such as any of the above-described communication failures, will now be described.

In opportunistic handover upon failure, the UE may be allowed to maintain a set of configurations which may only be applied in case the UE experiences a

communication failure. These configurations could e.g. be provided in conjunction with a handover, where the UE had some backup options in case the handover to a target cell failed. The configurations could also be provided at any other time, e.g. if the network expected the UE to experience a sudden failure where a backup configuration would be desirable, such as when the network would not be able to trigger a handover in time.

In RAN2#104 in Spokane in November 2018, the following has been agreed concerning conditional handover for LTE, where FFS denotes For Further Study:

=> FFS on the exact details of the procedures

=> FFS how many candidate cells (UE and network impacts should be clarified).

A significant aspect to be highlighted here is that the network may configure one or more candidate cells for conditional handover (CHO). One possible solution in CHO may be that the UE receives a message similar to

RRCConditionalReconfiguration that may contain an RRCReconfiguration with a reconfigurationWithSync prepared by each candidate. Hence, if the source cell decides to configure the UE with more than one candidate cell, the UE receives more than one RRCReconfiguration message with reconfigurationWithSync field, including one message for each potential target candidate. It may be assumed for example that the UE has received a conditional handover associated to target cells A, B and C i.e. under the assumption that all these three cells are prepared for a UE handover execution. When it comes to the triggering condition there may be a single triggering condition for multiple cells or each target candidate cell may have its own triggering condition.

It should be noted that the previous terminology corresponds to the NR

terminology in the afore-mentioned 3GPP document TS 38.331. In LTE, the equivalent solution would work with the message RRCConnectionReconfiguration with the mobilityControllnfo field.

In either conditional handover, or opportunistic handover upon failure, it is not specified how the UE should handle its stored configurations upon successful conditional handover. This may be an issue when multiple cells may be configured for conditional handover, or for any form of conditional mobility, in general.

Unless it is clearly specified how to handle stored configurations, it will be left to UE implementation basically beyond the network’s knowledge, and some UEs may retain the configurations and act upon the conditions, whereas other UEs may discard the configurations and act as if they had never received them. In either case, the network will not be aware of whether the UE will conduct another conditional handover, that is if certain conditions are fulfilled, or if the network must provide the conditional configurations once again to the UE.

In essence, some embodiments disclosed herein relate to how a UE in connected mode should handle one or more stored configuration(s) of cells, e.g. candidate cells, that are not the target cell upon the triggering or completion of an access to a cell, e.g. upon triggering or completion of a handover procedure, a conditional handover procedure or a re-establishment procedure.

Some embodiments and examples disclosed herein are also related to the handling on the network side of these multiple configurations, possibly associated to multiple cells from the same or different nodes.

It is thus described herein, e.g. with reference to Figs 1-3, functionality in a UE or wireless device for the handling of stored configuration(s) of cells, e.g. candidate cells, which are not the target cell upon the triggering of conditional handover or completion of handover.

Some embodiments and examples disclosed herein also refer to the handling on the network side of these multiple configurations, possibly associated to multiple cells from the same or different nodes. By the expression“network side” when used herein is meant a network node, such as the source node, the target node, and other core network nodes. Further, it may relate to the communication between such network nodes.

Some of the embodiments and examples herein relate to one or more of the following possible options:

Firstly, the UE discards at least some of the stored conditional handover related configurations upon triggering and/or completion of the conditional handover or handover towards a target cell.

Secondly, the UE performs some clean up actions associated to conditional handover such as stopping of related timers, removal of measurements, etc. Thirdly, the UE maintains at least some of the stored conditional configurations after successfully completing a normal or conditional handover, and the UE acts upon the configurations once the corresponding conditions are fulfilled, e.g. by resuming the monitoring of triggering conditions. Fourthly, when configuring conditional configurations the network indicates whether the UE should maintain these configurations upon successfully completing a conditional handover.

Some advantages with at least some of the embodiments disclosed herein will now be described. Firstly, some advantages that may be achieved with some embodiments of discarding conditional handover configurations upon completion of conditional handover are:

- No coordination is required on the network side to ensure that the conditional handover configurations stored in the UE are valid and up to date once the UE has connected to the target node.

- In addition, any kind of ambiguity can be avoided on the UE side and on the network side regarding what the existing UE stored configurations are, so that potential state mismatches between the UE and the network may be avoided.

Secondly, some advantages that may be achieved with some embodiments of maintaining conditional configurations after completion of handover are:

- Since the provided conditional handover configurations may still be valid and relevant after the completion of the handover, the UE would need to be provided again with the full set of conditional handovers if it needs them. If the changes to the conditional handover configurations are small, it would have been beneficial to provide delta configurations, i.e. only the difference between new and old configurations, instead of always providing full configurations after the handover. As some of the embodiments involve both providing a backup configuration to be used in case of communication failure and a conditional handover configuration to be used for handovers, the benefits could be slightly different, as outlined below in two examples A and B.

A) Maintaining an unused backup configuration through handovers: This could e.g. be for a UE using indoor high frequency NR performing occasional handovers between different indoor nodes, such as when the UE is moving in an indoor area with many small cells. Whenever the NR frequency is lost, e.g. due to blockage or bad radio conditions, or when leaving the indoor area, the UE applies a backup configuration for a wide area LTE frequency. If this conditional backup configuration would be released at every handover, the UE would need to be reconfigured with the conditional backup configuration after every handover, i.e. multiple times.

B) Maintaining an unused conditional handover configuration through handovers: This could e.g. be for a UE moving in a predictable mobility pattern with expected frequent handovers, for instance when the UE is on a high speed train or in a car traveling fast on a highway. The UE would be configured with staggered configurations applicable to subsequent cells along the traveled path. If the UE would release the unused conditional configurations after each handover, the UE would need to be frequently reconfigured.

Thirdly, an advantage with embodiments wherein the network indicates which conditional configurations should be maintained through handovers is:

- These embodiments could provide the benefit of both the above firstly and secondly described advantages, where the network only needs to provide delta configurations for the configurations the UE shall keep, but the network is able to release the configurations where network coordination is undesirable. A more detailed description of some further example embodiments will now follow.

A UE configured with a set of conditional RRCReconfiguration will execute a handover when the condition for the handover is fulfilled. In opportunistic handover upon failure, the UE would be configured with a set of configurations to be applied in the event of communication failure, e.g. handover, conditional handover, radio link, or reconfiguration failure. In both of these scenarios, the UE can be configured with a multitude of configurations each with their own set of conditions when to apply the configurations. By necessity, it may be only possible to apply just one of the configurations at the time, but it is not detailed what the UE should do with the extraneous or non-used configurations after one of the conditional configurations have been applied.

Under the assumption that upon the triggering of conditional handover the UE executes a handover like procedure towards a single cell triggering the condition, during this procedure the UE may still have stored configuration(s) as described above. These conditional handover related configuration(s) may be for:

- Cell(s) that have also triggered the condition for conditional handover, but were not selected to be the target cell e.g. due to some prioritization rule that the UE applies;

- Cell(s) that have not triggered the condition for conditional handover, but for which the UE has stored a configuration;

- Measurement object(s) / frequencies that have also triggered the condition for conditional handover, but were not selected to be the target cell e.g. due to some prioritization rule that the UE applies;

- Measurement object(s) / frequencies that have not triggered the condition for conditional handover, but for which the UE has stored a configuration;

In the context of the embodiments herein, the“conditional handover related configuration(s)” for a certain cell could comprise at least the following:

- An RRCReconfiguration like message (or any message with equivalent content), possibly containing a reconfigurationWithSync using NR terminology (defined by 3GPP in TS 38.331 specifications); Or, using the LTE terminology, an RRCConnectionReconfiguration with mobilityControllnfo in the LTE terminology (defined by 3GPP in TS 36.331 specifications); - Triggering condition(s) configuration e.g. something like A1 -A6 triggering events (as defined by 3GPP in TS 38.331 / TS 36.331 in reportConfig) where instead of triggering a measurement report it would trigger a conditional handover;

- Other conditional handover controlling parameters e.g. timer defining the validity of target candidate resources, etc.

Some further aspects and details of this description will now be discussed. First, some of the terminology used herein will be explained

In this disclosure the term handover or reconfiguration with sync is used with a similar meaning. Hence, a conditional handover may also be called a conditional reconfiguration with sync. In NR terminology, the handover configurations are typically called an RRCReconfiguration with a reconfigurationWithSync field containing configuration necessary to execute a handover. In LTE terminology, the handover configurations are typically called an RRCConnectionReconfiguration with a mobilityControllnfo field containing configuration necessary to execute a handover.

Most of the UE (and network) actions defined in this disclosure are described as being performed in NR or LTE. In other words, the configuration of a conditional HO received in NR for NR cells, conditional handover (CHO) executed in NR. However, the procedures and features described herein are also applicable when any of the described steps and operations occurs in different RATs, for example:

The UE is configured with a conditional HO in NR (for candidate NR and LTE cells), then the condition is triggered for an NR cell and UE executes the HO in NR;

The UE is configured with a conditional HO in LTE (for candidate NR and LTE cells), then the condition is triggered for an LTE cell and UE executes the HO in LTE; The UE is configured with a conditional HO in NR (for candidate NR and LTE cells), then the condition is triggered for an LTE cell and UE executes the HO in LTE;

The UE is configured with a conditional HO in LTE (for candidate NR and LTE cells), then the condition is triggered for an NR cell and UE executes the HO in NR;

Or, in more general terms, the UE is configured with a condition HO in RAT- 1 for cells in RAT-1 or RAT-2, then the condition is triggered, and UE executes the HO in RAT-2.

Some embodiments are described in the context of conditional handover, which should not be seen as a limiting factor. Some embodiments may also be applicable for handovers triggered by the reception of the RRCReconfiguration message with the reconfigurationWithSync field without any condition associated, or the RRCConnectionReconfiguration message with the mobilityControllnfo field. Then, upon the execution of a handover for a given target cell X, the UE may have stored a configuration of multiple cells provided to the UE.

Some embodiments may also be applicable in case of application of stored configurations during recovery of a connection with the network, e.g. due to radio link or handover failure. These stored configurations may comprise a

RRCReconfiguration like message, where the UE performs a handover upon failure, or the stored configurations may comprise e.g. system information or random access configurations applicable to the target cell to reduce the time for recovery. Then upon successful or unsuccessful completion of the recovery, the UE may still have stored configurations of multiple cells provided to the UE.

Below a more detail description of some of the above-mentioned different alternatives for performing action 200 in Fig. 2 will follow:

The UE discards/releases at least some of its stored conditional handover related configurations upon completion of the handover, the conditional handover or of the re-establishment towards a target cell; The UE may further perform some associated clean up actions, e.g. stopping of related timers, removal of stored measurements, etc.

The UE maintains at least some of the stored conditional configurations after successfully completing a (normal or conditional) handover and acts upon the configurations once the corresponding conditions are fulfilled, e g. by resuming the monitoring of triggering conditions.

The network indicates when configuring conditional configurations whether the UE should maintain these upon successfully completing a conditional handover.

It will now be described in more detail how at least some conditional handover related configurations can be released upon successfully completing a handover.

In some embodiments, the UE discards stored conditional configuration(s), e.g. stored RRCReconfiguration possibly with reconfigurationWithSync and configured triggering conditions, after it has triggered a conditional handover and started to perform a reconfiguration towards a target cell, e.g. a handover, a conditional handover, or an opportunistic handover upon failure. In this context, the stored conditional configurations to be released may or may not exclude the

configurations for the target cell that has triggered the condition for conditional handover.

Some possible examples of the stored conditional configurations that may be discarded, e.g. parts or combinations of these, are listed below:

- Stored RRCReconfiguration(s) for non-triggered cells; and/or

- Stored RRCReconfiguration(s) for triggered cells that were not selected as the target cell; and/or

- Stored triggering conditions for non-triggered cells that were not selected as the target cell; and/or - Stored triggering conditions for triggered cells that were not selected as the target cell;

- Stored control configurations related to conditional handover such as timers for controlling the resources for target candidate cells. The term“release” in this context may also be interpreted as discarding a stored configuration for a target cell candidate. As indicated above, a candidate for a target cell is sometimes referred to herein as a candidate cell.

Some embodiments may also involve a set of so-called“clean up” UE actions that could be performed upon releasing/discarding the CHO related configuration such as:

- Stopping CHO related timers, like any timer associated to the validity of CHO resources for target cell candidates;

- Stopping the monitoring of triggering condition(s);

- Stopping of measurements associated to CHO;

- Release any configured measurement gaps associated to the CHO;

- Releasing the identity of the conditional handover, e.g. a condHO-Objectld (similar to the measObjectld used for measurements);

Performing specific measurement related actions upon the triggering of a HO. Some examples of how the network may act when the embodiments herein are used, will now be described.

On the network side, before configuring the UE to perform CHO, the source node may prepare a set of potential target candidates. Then, each target candidate receives the UE’s current configuration used in source cell so that each target node is able to build an RRCReconfiguration like message with a

reconfigurationWithSync field. In this solution, upon receiving a handover complete from a UE, e.g. RRCReconfigurationComplete according to the target’s prepared configuration, that executes a handover e.g. due to the triggering of the CHO condition, the target node knows that the UE has released all CHO related configurations, so that if the target node wants to configure that UE with CHO, the target node knows it has to configure the UE“from scratch”, i.e. by signaling the complete CHO related configurations to the UE without performing any delta signaling, thus assuming that the UE does not have any CHO related

configuration.

On the network side, one possible variant may be that the UE discards the RRCReconfiguration like message with a reconfigurationWithSync for non-target cells, but maintains the triggering condition configurations, e.g. indicating which triggering event(s) and threshold(s) should be associated to which cell. In that case, the source node may provide the triggering condition configuration in a preparation message towards each target candidate as that condition is actually decided by the source node. And, as the source node knows in advance what the condition will be, i.e. before it receives confirmation from other target candidates.

In the embodiments herein, there will be no ambiguity in the network as to which configurations the UE has stored. A consequence is that the network would have prepared resources and configurations in multiple nodes, which need to be released upon the completion of the handover.

In one example, all candidate target nodes are informed of the other candidates configured for the UE and upon completion of the conditional handover to one of the target nodes, this target node informs all other candidate targets to release the UE context with the conditional configurations. In another example, the discarding operation described herein is only performed for a subset of target node candidates e.g. the cells apart from the same node as the target cell. In another example, the discarding operation described herein is only performed for a subset of target node candidates e.g. the cells apart from the same node as the source cell.

In another example, the UE is configured to perform the described discarding actions for specific cells only e.g. the cells apart from the same node as the source cell.

Figs 6A-B schematically illustrate an example of a signaling procedure for conditional handover of a UE currently served by a source gNB, where the target node, e.g. the candidate gNB B, releases conditional UE contexts in other candidate targets, e.g. the source gNB, the candidate gNB A, and the candidate gNB C. In more detail, Fig. 6A illustrates a first part of the signaling procedure and Fig. 6B illustrates a second part of the signaling procedure following Fig. 6A. In Fig. 6A, the UE sends a conditional handover request to each candidate gNB A, B and C in steps 3a, 3b and 3c, respectively. The candidate gNBs A-C then perform admission control for the UE in steps 4a, 4b and 4c, respectively, and sends a conditional handover response to the source gNB in steps 5a, 5b and 5c, respectively. Eventually, the source gNB sends configurations containing handover conditions of the candidate gNBs A-C to the UE in the message RRCConditionalReconfiguration as of step 7. In Fig. 6B, the UE accordingly evaluates the received handover conditions so that a conditional handover is triggered for gNB B in step 8a. The UE then applies the RRCReconfiguration associated to gNB B in step 8b, and releases the RRCReconfiguration associated to other cells A and C than cell B in step 8c. As a result, the UE sends a RRCReconfigurationComplete to gNB B in step 9, and so forth.

Some embodiments that can be implemented in a UE will now be described in more detail.

A suitable UE behavior when the embodiments herein are used may be

implemented in the NR RRC specifications in different manners e.g. depending how the conditional handover is configured to the UE including how the UE is configured with: i) the triggering condition for cell candidates and ii) the

configuration to be used in a potential target cell if that triggers the condition, e.g. an RRCReconfiguration with reconfigurationWithSync to be applied. In the following implementation examples, denoted as Alternatives 1 and 2 below, it is assumed that conditional handover is configured:

Alternative 1/ The UE is configured with CHO by the reception of one message RRCReconfiguration with reconfigurationWithSync field for each target cell candidate; The triggering condition is also configured in the same message, either implicit, e.g. by indicating an event/measurement linked to the triggering condition, or explicit, where the triggering condition as such is also included in the message. The condition configuration is an indication that this RRCReconfiguration shall not be executed/applied until the condition is triggered. Upon receiving each message, the UE shall start monitoring the triggering condition. Alternative 21 The UE is configured with CHO by the reception of a new message possibly called RRCConditionalReconfiguration, or any message configuring conditional handover for one or multiple cells, the received message containing for each possible target candidate a triggering condition configuration which could be implicit or explicit as described for alternative 1 , and an RRCReconfiguration with reconfigurationWithSync.

These two alternatives are described below in further detail with examples to illustrate the implementation of some embodiments.

Alternative 1

- RRCReconfiguration The RRCReconfiguration message is the command to modify an RRC connection. It may convey information for measurement configuration, mobility control, radio resource configuration (including Radio Bearers (RBs), MAC main configuration and physical channel configuration) and security configuration. Signalling radio bearer: SRB1 or SRB3 RLC-SAP: AM Logical channel: DCCH Direction: Network to UE The RRCReconfiguration message may be as follows with some relevant parts underlined.

— ASMiST I

— TAS-SSCRECONFIGOSATIOH-START

sacsecoafiguratiaa : := SEQUENCE i

rrc-Iras3actic5l!iestifiar SSC-Iraa3acticaIdeatifiar,

criticaiExtaBsioa3 CHOICE {

rrcSeeotfigaratiat; SSCSecaafigaration-ISs,

critica!SjcteasiossFatare SEQUENCE {;

asCRscosiigaratios-IEs ::= SEQUENE t

radiaBaarerCoafig Radi Eec. eΪCcr.fIg

OPTIONAL, — Seed M

secoiidaryCeiiGrotsp OCTET STRING {COSTHKIBS CeliSraapCoEfig) OPTIONAL, — Seed M

nsasCoitfig MeasCsafig

OPTIONAL, — Seed M

lateKoaCriticalExtessioa OCTET SIRING

OPTIONAL,

naaCriticaiExtensica i®CRecoafigaratioa-viS30-ISs

OPTIONAL

SSSRecoafigaratioa-YlSSS-ISs : := SEQUENCE i

EasterCeilSrosp OCTET STRING (CONTAINING CenGreapCoafigj OPTIONAL, — Seed M

fslICoBfig ENUMERATES {trae}

OPTIONAL, — Coad FailCsafig

dedieatedNAS-MessagsLiat SEQUENCE (SIZE (1..sasS S) ] CF DedicatedKAS-Hessage OETIOiSL, — Coad aosBO

ssasterKeyUpdste HasterXeyUpdata

OP IONAL, — Coad HasterKeyChaage

dedicatedSIBl-Baiivery OCTET STRING (CONTAINING SIB1)

OPTIONAL, — Seed S

dedieatedSystealaformatioaSeli ery OCTET STSIHS { MtJ m Systeslaferisatics) OPTIONAL, — Seed S

ct erCosfig OtherCaafig

OPTIONAL, — Seed N

RSCRecoafigaEatioa-vlS-IEs : := SEQUENCE ¾

coBdReccsfiggratios_ CoadSecoafigaratioB OPTI0i¾I,

sssterC ilSroup OCTET SUING {CONTAINING CeiiSroapCcsfig}

OPTIOB&L, — Need M

falLConfig ENUMERATED {tree}

OPTIONAL, — Ccnd FallCanfig

dedicatedBAS-Messageli st SEQUENCE [SIZE f i..aaxDRBj } OF Dedicated AS-Message OPTIONAL, — Coad nonHC

ssaster eyUpdate HasterKeyopdate

OPTIONAL, -- Coad MasterKeyChasge

dcdicatedSIBi-Ueiivery OCTET STRING {CONTAINING SIB1)

OPTTONAL , — See K

dedicatedSysteEsIiiforRaticinBeiivery OCTET STRING {CONTAINING SystessInfcrsiatiQaj OPTIONAL, — Used E

ot erCoafig Cthcr cnfig

OPTIONAL, — Need E

aosCriticallxteasioa SEQUENCE U

OPTIONAL

MasterKeyUpdste : := SEQUEN E i

keySetCfeangelBdicator BOOLEAN,

BentSopChaiaisgCoaat NeKtSopChaiaiagCoaat,

— TAG-RRCRECG FXGGSATION-SIOP

— ASHISTOP

_ ReportConfigNR

The IE ReportConfigNR specifies criteria for triggering of an NR measurement reporting event.

Measurement reporting events are based on cell measurement results, which can either be derived based on SS/PBCH block or CSI-RS. These events are labelled AN with N equal to 1, 2 and so on. Event A 1 : Serving becomes better than absolute threshold;

Event A2: Serving becomes worse than absolute threshold;

Event A3 : Neighbour becomes amount of offset better than PCell/PSCell;

Event A4: Neighbour becomes better than absolute threshold; Event A5 : PCell/PSCell becomes worse than absolute thresholdl AND Neighbour/SCell becomes better than another absolute threshold2.

Event A6: Neighbour becomes amount of offset better than SCell. The above-mentioned ReportConfigNR information element may be as follows.

hysteresis Hysteresis, tisieTalrigger TisteXcIrigger event&3

a3-Offset

reporiOnLeave

hysteresis Hysteresis,

h eveat.¾ SEQOISCE { a4-Ifcr=s olQ MeasiriggerQsastity, repertOsLeave BOGLEAS,

hysteresis Hysteresis,

tiseTelrigger Tisslelrigger, aseSbiteCellList BOSLI

h

eveat&S 3EG0SSCE ΐ

aS-Tbisshaldl Meas!riggerSpentity, aS-Threshoid2 lieasIriggerQssstity, rsp-.rtCr.Leave BOOLEAN,

hys eresis Hysteresis,

tiEeTalrigger !itsel lrigger, aseSbiteCeliList BOOLESK

h

eveat 3ES0ESCE {

a€-Cffset MeasiriggerQsastit Offset, rs oztO&LeaYe BOGLESK,

hysteresis Hysteresis,

reportyuantityasladexes MeasSeportQaant11y

OPTIOH5L, — S ed K

saxSrofSSIndexeslcfieport IMISSES {1..saxNrofIsdexesIoReport} OFTIC!&L, — Seed 8

isc1ndeBeasMeastresents BOOLEAN,

repor ddMeig fess EKSMERATES {setapj

OPTIGHSL, — Seed S

Periodical e pcrtConfig SEQUENCE

r sl pe NR-B.£-Iype ,

report-interval Report lute ryal ,

repctt&Bsaaat SraSR&ISS ill, å2, r4, rS, ri€, r32, r€4 , infisityj

report^asstitySsIsdexes Me asSepo rtSaastity

OPTIOIfil, — Seed R

rsaxRr c f Ss Indexe sic Repo r t ISIESSR 1 . . s&axNrof IndexssIoReport j OPTIONAL, — Seed R

i is c i¾de BeasMe as ar assEts BOOLEAN,

oseSs iteCeilList BOOLEAN,

M-RS-Type : := E ¾5E8AT£B issh, csi-i's ;

rsrg RSEQ-Rsnge,

sinr SIHS-Sasge

HeasTriggerOsaEtityOfiset : := CHOICE {

rsrp iSTSSER (-35. .30) ,

rsrq INTEGER I-30. .3S ) ,

s i nr INTEGER -30 , .35 ) easRepor tQi ar.ti tv : : IIQUEHCE ;

rsrp BOOLEAN,

rsrq BOOLESS,

sinr BOOLEAN

— IftS-REPORT-COSFIS-SIftRT

— ASHiSIOP

Below some examples of how the embodiments herein may be implemented in the RRC specifications, assuming alternative 1 and alternative 2, respectively, will be described. Some example procedures in TS 38.331 assuming alternative 1 for the CHO configuration, are outlined below with some relevant parts underlined. pCell denotes a primary cell.

5.3.5.5.2 Reconfiguration with sync

The UE shall perform the following actions to execute a reconfiguration with sync.

1> if the security is not activated, perform the actions upon going to RRC IDLE as specified in 5.3.11 with the release cause 'other' upon which the procedure ends;

1> stop timer T310 for the corresponding SpCell, if running;

1> start timer T304 for the corresponding SpCell with the timer value set to t304, as included in the reconfigurationWithSync,

1> if the frequencylnfoDL is included:

2> consider the target SpCell to be one on the SSB frequency indicated by the

frequencylnfoDL with a physical cell identity indicated by the physCellld;

1> else:

2> consider the target SpCell to be one on the SSB frequency of the source SpCell with a physical cell identity indicated by the physCellld,

1> start synchronising to the DL of the target SpCell;

apply the specified BCCH configuration defined in 9.1.1 1;

1> acquire the M/5, which is scheduled as specified in TS 38.213 [13];

1> perform the actions specified in section 5.2.2.4.1;

NOTE 1 : The UE should perform the reconfiguration with sync as soon as possible following the reception of the RRC message triggering the reconfiguration with sync, which could be before confirming successful reception (HARQ and ARQ) of this message.

NOTE 2: The UE may omit reading the M1B if the UE already has the required timing

information, or the timing information is not needed for random access.

1> reset the MAC entity of this cell group;

1> consider the SCell(s) of this cell group, if configured, to be in deactivated state;

1> if stored, discard the RRCRecon figuration messagefs) received for conditional handover;

1> apply the value of the new UE-ldentity as the C-RNTI for this cell group;

Editor's Note: Verify that this does not configure some common parameters which are later discarded due to e.g. SCell release or due to LCH release.

1> configure lower layers in accordance with the received s pCellConfigCommon;

1> configure lower layers in accordance with any additional fields, not covered in the previous, if included in the received reconfigurationWithSync. Alternative 2

- RRCConditionalReconfiguration

The RRCConditionalReconfiguration message is the command to modify an RRC connection upon the triggering of an associated condition. This message may convey information for measurement configuration, mobility control, radio resource configuration (including RBs, MAC main configuration and physical channel configuration) and security configuration.

Signalling radio bearer: SRB1 or SRB3 RLC-SAP: AM

Logical channel: DCCH Direction: Network to UE

The RRCConditionalReconfiguration message may be as follows with some relevant parts underlined.

ev¾at?r i gge rCHO RepprtCo&figN ,

1 iateUonCriticalExtessioT OCTET STAINS

OPTIONAL,

aonCriticalExteasion SRCSe coaf igssatioa-vl538-I Es

OPTIONAL

i

— IAS- SSCCOSDIIIONMSSCOEFISUSAIIOS -STOP

— ASNl STOP

Some example procedures in TS 38.331 assuming alternative 2 for the CHO configuration, are outlined below with some relevant parts underlined.

5.3.5.5.2. Reconfiguration with sync

1> stop timer T310 for the corresponding SpCell, if running;

1> start timer T304 for the corresponding SpCell with the timer value set to t304, as included in the reconflgurationWithSync 1> if the frequencylnfoDL is included:

2> consider the target SpCell to be one on the SSB frequency indicated by the

frequencylnfoDL with a physical cell identity indicated by the physCellld,

1> else:

2> consider the target SpCell to be one on the SSB frequency of the source SpCell with a physical cell identity indicated by the physCellld,·

1> start synchronising to the DL of the target SpCell;

1 > apply the specified BCCH configuration defined in 9.1.1.1 ;

1> acquire the MIB, which is scheduled as specified in TS 38.213 [13];

1> perform the actions specified in section 5.2.2.4.1;

information, or the timing information is not needed for random access.

1> reset the MAC entity of this cell group;

1> _ if stored, discard RRCConditionalReconfisuration message! si; apply the value of the new UE-Identity as the C-RNTI for this cell group;

1> configure lower layers in accordance with the received spCellConfigCommon;

1> configure lower layers in accordance with any additional fields, not covered in the previous, if included in the received reconfigurationWithSync.

Some further example procedures in TS 38.331 assuming alternative 2 for the CHO configuration (condition configuration is not discarded), are outlined below with some relevant parts underlined.

5.3.5.5.2 Reconfiguration with sync

1> stop timer T310 for the corresponding SpCell, if running; 1> start timer T304 for the corresponding SpCell with the timer value set to t304, as included in the reconflgurationWithSync

1> if the frequencylnfoDL is included:

2> consider the target SpCell to be one on the SSB frequency indicated by the

frequencylnfoDL with a physical cell identity indicated by the physCellld

1> else:

1> start synchronising to the DL of the target SpCell;

1 > apply the specified BCCH configuration defined in 9.1.1.1 ;

1> acquire the Mill which is scheduled as specified in TS 38.213 [13];

1> perform the actions specified in section 5.2.2.4.1;

information, or the timing information is not needed for random access.

1> reset the MAC entity of this cell group;

1> if stored, discard the RRCRecon figuration message(s) configured by

RRCConditionalReconfisuration message;

1> apply the value of the new UE-ldentity as the C-RNTI for this cell group;

Editor's Note: Verify that this does not configure some common parameters which are later discarded due to e.g. SCell release or due to LCH release. l>configure lower layers in accordance with the received s pCellConfigCommon; l>configure lower layers in accordance with any additional fields, not covered in the previous, if included in the received reconfiguration WithSync.

Some examples of advantages that may be achieved when the embodiments herein are employed will now be described.

An advantage of the embodiments where the UE discards at least part of the configuration associated to conditional mobility (e.g. conditional handover) could be that there would be no ambiguities regarding UE behaviour to the network. When the embodiments herein are employed, the network, in particular the target cell/node receiving the incoming UE, knows exactly what is deleted and what is stored by the UE in terms of configuration, so that there is no risk of state mismatch between the UE and the network.

Further, the solution reduces the need for inter-node signalling of the alternative where each target candidate needs to know the CHO configuration the UE has stored for all potential target candidates. Thus, after the handover execution (e.g. due to CHO) the target node can apply delta signalling to the UE and/or assume that the UE continues the monitoring and possible triggering process after the handover. In the last example, assuming the above alternative 2 is used, the condition configuration is not discarded. The reason for that is that inter-node signalling would not be required as that can be provided in the conditional handover / handover preparation phase as the handover is decided by the source node, and this preparation phase may be the same for any target cell candidate. Hence, the example implements one of the embodiments where only the

RRCReconfiguration(s) are discarded, but not the conditions.

Some further embodiments and examples will now be described where stored but unused conditional configurations are maintained by the UE upon handover.

In some other embodiments, the UE maintains stored conditional reconfigurations even after a handover, conditional handover, or re-establishment with conditional configurations (e.g. RRCReconfiguration possibly with reconfigurationWithSync for cells that are not the target cell). In other words, the UE considers the conditional mobility related as part of its stored RRC configuration i.e. subjected to delta signaling.

For example, a UE is connected to cell A and is configured with conditional handovers to cell B and cell C. After some time, the condition for handover to cell B is fulfilled which triggers the UE to handover to cell B. However, upon

completion of the handover to cell B, the UE still have the configurations for conditional handover to cell C. These configurations are considered as any other configurations the UE has applied, i.e. it may be considered as part of the current UE’s RRC configuration. Then, upon the triggering of conditional handover towards cell-X, the UE does not discard but keeps the stored CHO configurations and apply the configuration (e.g. RRCReconfiguration) for cell-X on top of the currently used RRCReconfiguration i.e. the one used in source cell. When handover is being executed, the UE suspends the monitoring of the triggering conditions and, upon connecting to target the UE resumes the monitoring of the triggering conditions.

On the network side, there may be different ways of enabling the UE to maintain the CHO configuration after the triggering of CHO.

In one embodiment, the source node, after having received the

RRCReconfiguration with reconfigurationWithSync from each target candidate in the preparation phase, provides to each target candidate the set of

RRCReconfiguration with reconfigurationWithSync messages so that each target is aware of the UE’s stored RRC configuration, including the stored CHO related configuration (which possibly includes the reconfiguration message and triggering condition configuration(s)). Figs 7A-B illustrate a signaling procedure where the configuration is conveyed from the source node to the candidate nodes e.g. in a new message called CONDITIONAL HANDOVER INFORMATION. In more detail, Fig. 7A illustrates a first part of the signaling procedure and Fig. 7B illustrates a second part of the signaling procedure following Fig. 7A, involving a UE, a source gNB and three candidate gNBs A,B,C. The CONDITIONAL HANDOVER

INFORMATION message is conveyed from the source gNB to the candidate gNBs A,B,C in steps 6a, 6b and 6c, respectively.

When the UE has handed over to a target candidate cell, the target can decide which conditional handover configurations and triggering conditions should be maintained, modified or released. For instance, the conditional configurations which should be maintained doesn’t need any processing as the UE has kept the configurations, whereas the ones which should be added, modified or released need to be coordinated in the network. After the new target node have decided and coordinated with the new set of candidate cells, it needs to provide the candidate cells with information about the updated list of candidate cells. Figs 7A- B thus show an example signaling diagram, where the source gNB decides to configure the UE with candidate cells in gNB A, B and C. The UE then triggers the conditional handover to a cell in gNB B in step 8a and transmits the

RRCReconfigurationComplete message to that cell in step 9.

The target cell’s gNB B may send a message to the source cell in step 13 to release the source UE context. After the conditional handover, the target gNB B decides that the UE should be configured with conditional handovers to the previous source cell and the cell in gNB C. However, the cell in gNB A should no longer be valid. The cell of gNB B is now the serving cell for the UE and gNB B then performs the following:

- requests the previous source gNB to create a new conditional configuration, and - requests gNB A to release the conditional UE context.

The cell in gNB C is already configured in the UE and gNB B does not need to modify the conditional configurations. However, gNB B will inform all the new candidate target nodes which other conditional configurations that the UE has been configured with. In the signaling procedure for conditional handover shown in Figs 7A-B, the target node, e.g. the candidate gNB B, is aware of all other conditional configurations and may maintain, modify, or release the conditional configurations after the handover.

In another embodiment, the source node, during the preparation message to request the conditional HO for each target candidate includes the triggering condition configuration so that each target candidate is aware of the UEs stored triggering condition configuration for CHO. The procedures in this embodiment will be similar to those in Figs 7A-B, but the message CONDITIONAL HANDOVER INFORMATION will only contain the triggering conditions for the conditional configurations.

In another embodiment, when the target node requests to release the UE context in the source node, the source node responds with the conditional configurations and triggering conditions which the UE was configured with. The target node may then decide whether the UE should maintain, reconfigure or release these configurations.

Figs 8A-B schematically illustrate another example of a signaling procedure for conditional handover where the target node, e.g. the candidate gNB B, is informed of all other conditional configurations upon completion of handover and may maintain, modify or release the conditional configurations after the handover. As similar to Figs 7A-B, Fig. 8A illustrates a first part of the signaling procedure and Fig. 8B illustrates a second part of the signaling procedure following Fig. 8A, again involving a UE, a source gNB and three candidate gNBs A,B,C. The main difference for the procedure in Figs 8A-B compared to Figs 7A-B is that the target cell is only informed of the other candidate targets after the successful completion of the handover. This will significantly reduce the number of inter-node messages as it is only the actual target node which is informed of the other candidate cell configurations. In another embodiment, the network maintains a coordinated set of conditional configurations, where each candidate node is aware of a default configuration to be used in all other candidate nodes. Thus, the UE can be configured with this set of configurations with e.g. a RRCConditionalReconfiguration message. When the UE executes a conditional handover towards any of these candidate targets, the target node is already aware of the default configurations to configure for all other candidates. Thus, the new target only needs to add conditional configurations if a cell doesn’t belong to this preconfigured set of cells.

It is also possible that the embodiments herein can be applied when a Central Unit (CU)/ Distributed Unit (DU) architecture split is employed in the network, where a protocol such as RRC or Packet Data Convergence Protocol (PDCP), for example, could be implemented in the CU while lower layers are implemented in the DU(s) connected to the same CU. If the UE is connected to a CU-DU split gNB, the network may configure the UE with conditional configurations for one or many different DUs belonging to the same CU. This is because when the UE performs an intra-gNB-CU handover, the termination point (and location of the RRC entity) remains the same.

Thus, the CU would be able to reuse the previous conditional configurations for the candidate DUs which were not triggered. Thus, it would be beneficial if the UE maintain the conditional configurations unless the network instructs it otherwise.

It will now be described how stored configurations can be managed upon Re establishment.

If a UE is configured with conditional handover configurations, or handover configurations in general, or an RRCReconfiguration like message, for one or several cells and the UE experiences a connection failure (e.g. RLF, handover failure, integrity protection failure, etc.), the UE will perform a cell search and initiate a re-establishment procedure.

This is done by the UE transmitting a RRCReestablishmentRequest like message to the cell in the target node it has selected and including in that message a UE identity (e.g. PCI + C-RNTI) and a security token to verify the UE identity. The target node receiving the RRCReestablishmentRequest message will attempt to locate the old UE context based on the UE identity. If the UE context is located in the target node which the UE attempts to re-establish in the network can respond with a RRCReestablishment message followed by an RRCReconfiguration. If the UE context is located in a different node (last serving node), but the target node can identify this node based on the UE identity, the target node can request to retrieve the UE context from the last serving node. Once the UE context is fetched to the target node, the target node can send the RRCReestablishment message to the UE followed by an RRCReconfiguration. However, if the target node is unable to retrieve the old UE context, e.g. because it cannot identify the last serving node from the UE identity, e.g. when the last serving node have deleted the UE context, or for some other reason, the target node will not be able to retrieve the UE context and will therefore transmit a RRCSetup to the UE. This will cause the UE to go to RRCJDLE and establish a new connection from scratch.

If the UE receives the RRCReestablishment message from the UE which has stored configurations, ,e.g. conditional handover or handover configurations for other cells, it is unclear what the UE shall do with these configurations according to prior conventional behavior. In the procedure shown in Fig. 2 and elsewhere, these configurations are updated by the UE e.g. upon a failure declaration as of action 200 in Fig. 2, which may be followed by a re-establishment attempt.

In some embodiments, upon trying to re-establish while having stored

configurations for one or multiple cells (e.g. conditional configurations or handover configurations or RRCReconfiguration(s)), the UE releases (i.e. discards) the mentioned stored configuration received prior to the failure.

In the particular case the re-establishment occurs after the UE failed a handover or a conditional handover, the UE might have already applied one of the

configurations prepared by one of the target candidates. Then, upon that failure, the UE shall revert its configuration to the configuration the UE had in source prior to the failure, but also prior to the application of the RRCReconfiguration prepared by a target candidate. And, upon reverting the configuration to the source’s configuration, the UE shall also delete/discard the conditional handover

configuration(s). Hence, one could say that upon the failure detection e.g. T304 expiry or equivalent failure, the UE shall revert back to the UE configuration used in the source PCell, except the stored conditional handover or handover configurations for other target candidate cells (i.e. not including these as part of the PCell configuration).

In some embodiments, when the UE reverts its configuration to the configuration used in the PCell including the conditional handover configurations (or handover configuration(s) in more general terms) i.e. the UE maintains all stored

configurations it had prior to the failure, and once it receives the

RRCReestablishment message, it will again consider the stored configurations for handover. Alternatively, the UE awaits the reception of the first

RRCReconfiguration message after the Re-establishment.

These reverting actions may also be performed upon the failure detection e.g.

T304 expiry, non-compliance with the RRCReconfiguration, etc.

If the UE re-establishes in the same node (same cell or different cell) as it was connected to prior to the failure, the stored configurations may likely still be relevant, and the UE should maintain them. As the network may reconfigure or release these configuration in the first reconfiguration message after the re establishment it is beneficial to maintain them. If the UE re-establishes in a different node than the last serving node, the target node can decide whether the conditional configurations are relevant or not, and release, maintain, or reconfigure the stored configurations in the first reconfiguration message after the re establishment.

Figs 9A-B schematically illustrate another example of a signaling procedure for RRC Re-establishment. As similar to Figs 7A-B and Figs 8A-B, Fig. 9A illustrates a first part of the signaling procedure and Fig. 9B illustrates a second part of the signaling procedure following Fig. 9A, again involving a UE, a source gNB and three candidate gNBs A,B,C.

Some further extensions and variations will now be described with reference to Figs 10-15.

With reference to Fig. 10, in accordance with an embodiment, a

communication system includes a telecommunication network 102, 3210 e.g. a WLAN, such as a 3GPP-type cellular network, which comprises an access network 321 1 , such as a radio access network, and a core network 3214. The access network 321 1 comprises a plurality of base stations 3212a, 3212b, 3212c, such as access nodes, AP STAs NBs, eNBs, gNBs or other types of wireless access points, each defining a corresponding coverage area 104, 106A-106C, 3213a, 3213b, 3213c. Each base station 3212a, 3212b, 3212c is connectable to the core network 3214 over a wired or wireless connection 3215. A first user equipment (UE), e.g. UE 100, such as a Non-AP STA 3291 located in coverage area 3213c is configured to wirelessly connect to, or be paged by, the

corresponding base station 3212c. A second UE 3292 such as a Non-AP STA in coverage area 3213a is wirelessly connectable to the corresponding base station 3212a. While a plurality of UEs 3291 , 3292 are illustrated in this example, the disclosed embodiments are equally applicable to a situation where a sole UE is in the coverage area or where a sole UE is connecting to the corresponding base station 3212.

The telecommunication network 3210 is itself connected to a host computer 3230, which may be embodied in the hardware and/or software of a standalone server, a cloud-implemented server, a distributed server or as processing resources in a server farm. The host computer 3230 may be under the ownership or control of a service provider, or may be operated by the service provider or on behalf of the service provider. The connections 3221 , 3222 between the telecommunication network 3210 and the host computer 3230 may extend directly from the core network 3214 to the host computer 3230 or may go via an optional intermediate network 3220. The intermediate network 3220 may be one of, or a combination of more than one of, a public, private or hosted network; the intermediate network 3220, if any, may be a backbone network or the Internet; in particular, the intermediate network 3220 may comprise two or more sub-networks (not shown).

The communication system of Fig. 10 as a whole enables connectivity between one of the connected UEs 3291 , 3292 and the host computer 3230. The connectivity may be described as an over-the-top (OTT) connection 3250. The host computer 3230 and the connected UEs 3291 , 3292 are configured to communicate data and/or signaling via the OTT connection 3250, using the access network 321 1 , the core network 3214, any intermediate network 3220 and possible further infrastructure (not shown) as intermediaries. The OTT connection 3250 may be transparent in the sense that the participating communication devices through which the OTT connection 3250 passes are unaware of routing of uplink and downlink communications. For example, a base station 3212 may not or need not be informed about the past routing of an incoming downlink communication with data originating from a host computer 3230 to be forwarded (e.g., handed over) to a connected UE 3291. Similarly, the base station 3212 need not be aware of the future routing of an outgoing uplink communication originating from the UE 3291 towards the host computer 3230.

Example implementations, in accordance with an embodiment, of the UE, base station and host computer discussed in the preceding paragraphs will now be described with reference to Fig. 11 In a communication system 3300, a host computer 3310 comprises hardware 3315 including a communication interface 3316 configured to set up and maintain a wired or wireless connection with an interface of a different communication device of the communication system 3300. The host computer 3310 further comprises processing circuitry 3318, which may have storage and/or processing capabilities. In particular, the processing circuitry 3318 may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The host computer 3310 further comprises software 331 1 , which is stored in or accessible by the host computer 3310 and executable by the processing circuitry 3318. The software 331 1 includes a host application 3312. The host application 3312 may be operable to provide a service to a remote user, such as a UE 3330 connecting via an OTT connection 3350 terminating at the UE 3330 and the host computer 3310. In providing the service to the remote user, the host application 3312 may provide user data which is transmitted using the OTT connection 3350.

The communication system 3300 further includes a base station 3320 provided in a telecommunication system and comprising hardware 3325 enabling it to communicate with the host computer 3310 and with the UE 3330. The hardware 3325 may include a communication interface 3326 for setting up and maintaining a wired or wireless connection with an interface of a different communication device of the communication system 3300, as well as a radio interface 3327 for setting up and maintaining at least a wireless connection 3370 with a UE 3330 located in a coverage area (not shown in Fig. 11 ) served by the base station 3320. The communication interface 3326 may be configured to facilitate a connection 3360 to the host computer 3310. The connection 3360 may be direct or it may pass through a core network (not shown in Fig. 11 ) of the telecommunication system and/or through one or more intermediate networks outside the telecommunication system. In the embodiment shown, the hardware 3325 of the base station 3320 further includes processing circuitry 3328, which may comprise one or more programmable processors, application-specific integrated circuits, field

programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The base station 3320 further has software 3321 stored internally or accessible via an external connection.

The communication system 3300 further includes the UE 3330 already referred to. Its hardware 3335 may include a radio interface 3337 configured to set up and maintain a wireless connection 3370 with a base station serving a coverage area in which the UE 3330 is currently located. The hardware 3335 of the UE 3330 further includes processing circuitry 3338, which may comprise one or more programmable processors, application-specific integrated circuits, field

programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The UE 3330 further comprises software 3331 , which is stored in or accessible by the UE 3330 and executable by the processing circuitry 3338. The software 3331 includes a client application 3332. The client application 3332 may be operable to provide a service to a human or non-human user via the UE 3330, with the support of the host computer 3310. In the host computer 3310, an executing host application 3312 may communicate with the executing client application 3332 via the OTT connection 3350 terminating at the UE 3330 and the host computer 3310. In providing the service to the user, the client application 3332 may receive request data from the host application 3312 and provide user data in response to the request data. The OTT connection 3350 may transfer both the request data and the user data. The client application 3332 may interact with the user to generate the user data that it provides.

It is noted that the host computer 3310, base station 3320 and UE 3330 illustrated in Fig. 1 1 may be identical to the host computer 3230, one of the base stations 3212a, 3212b, 3212c and one of the UEs 3291 , 3292 of Fig. 10, respectively. This is to say, the inner workings of these entities may be as shown in Fig. 1 1 and independently, the surrounding network topology may be that of Fig. 10.

In Fig. 1 1 , the OTT connection 3350 has been drawn abstractly to illustrate the communication between the host computer 3310 and the user equipment 3330 via the base station 3320, without explicit reference to any intermediary devices and the precise routing of messages via these devices. Network infrastructure may determine the routing, which it may be configured to hide from the UE 3330 or from the service provider operating the host computer 3310, or both. While the OTT connection 3350 is active, the network infrastructure may further take decisions by which it dynamically changes the routing (e.g., on the basis of load balancing consideration or reconfiguration of the network).

The wireless connection 3370 between the UE 3330 and the base station 3320 is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to the UE 3330 using the OTT connection 3350, in which the wireless connection 3370 forms the last segment. More precisely, the teachings of these embodiments may improve the efficiency in communication and thereby provide benefits such as better utilization of resources in the network.

A measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection 3350 between the host computer 3310 and UE 3330, in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring the OTT connection 3350 may be implemented in the software 331 1 of the host computer 3310 or in the software 3331 of the UE 3330, or both. In some embodiments, sensors (not shown) may be deployed in or in association with communication devices through which the OTT connection 3350 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software 331 1 , 3331 may compute or estimate the monitored quantities. The reconfiguring of the OTT connection 3350 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not affect the base station 3320, and it may be unknown or imperceptible to the base station 3320. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling facilitating the host computer’s 3310 measurements of throughput, propagation times, latency and the like. The measurements may be implemented in that the software 331 1 , 3331 causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection 3350 while it monitors propagation times, errors etc.

Fig. 12 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station such as a AP STA, and a UE such as a Non-AP STA which may be those described with reference to Figs 10 and 1 1. For simplicity of the present disclosure, only drawing references to Fig. 12 will be included in this section. In a first action 3410 of the method, the host computer provides user data. In an optional subaction 341 1 of the first action 3410, the host computer provides the user data by executing a host application. In a second action 3420, the host computer initiates a transmission carrying the user data to the UE. In an optional third action 3430, the base station transmits to the UE the user data which was carried in the transmission that the host computer initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In an optional fourth action 3440, the UE executes a client application associated with the host application executed by the host computer.

Fig. 13 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station such as a AP STA, and a UE such as a Non-AP STA which may be those described with reference to Figs 10 and 1 1. For simplicity of the present disclosure, only drawing references to Fig. 13 will be included in this section. In a first action 3510 of the method, the host computer provides user data. In an optional subaction (not shown) the host computer provides the user data by executing a host application. In a second action 3520, the host computer initiates a transmission carrying the user data to the UE. The transmission may pass via the base station, in accordance with the teachings of the embodiments described throughout this disclosure. In an optional third action 3530, the UE receives the user data carried in the transmission.

Fig. 14 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station such as a AP STA, and a UE such as a Non-AP STA which may be those described with reference to Figs 10 and 1 1. For simplicity of the present disclosure, only drawing references to Fig. 14 will be included in this section. In an optional first action 3610 of the method, the UE receives input data provided by the host computer. Additionally or alternatively, in an optional second action 3620, the UE provides user data. In an optional subaction 3621 of the second action 3620, the UE provides the user data by executing a client application. In a further optional subaction 361 1 of the first action 3610, the UE executes a client application which provides the user data in reaction to the received input data provided by the host computer. In providing the user data, the executed client application may further consider user input received from the user. Regardless of the specific manner in which the user data was provided, the UE initiates, in an optional third subaction 3630, transmission of the user data to the host computer. In a fourth action 3640 of the method, the host computer receives the user data transmitted from the UE, in accordance with the teachings of the embodiments described throughout this disclosure.

Fig. 15 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station such as a AP STA, and a UE such as a Non-AP STA which may be those described with reference to Figs 10 and 1 1. For simplicity of the present disclosure, only drawing references to Fig. 15 will be included in this section. In an optional first action 3710 of the method, in accordance with the teachings of the embodiments described throughout this disclosure, the base station receives user data from the UE. In an optional second action 3720, the base station initiates transmission of the received user data to the host computer. In a third action 3730, the host computer receives the user data carried in the transmission initiated by the base station.

Claims

1. A method performed by a wireless device (100,300) in connected mode when accessing a cell, wherein the wireless device (100,300) operates in a wireless communications network (102) and has a set of stored

configurations for at least one target cell X (106A-106C), and wherein the method comprises:

- updating (200) one or more stored configurations comprised in the set of stored configurations upon access of the cell.

2. The method of claim 1 , wherein the accessed cell is one out of the at least one target cell (106A-106C) and wherein the method further comprises:

- applying one out of the one or more stored configurations comprised in the set of stored configurations to access the one of the at least one target cell X (106A-106C).

3. The method of claim 1 , wherein the accessed cell is different from one of the at least one target cell (106A-106C) and wherein the method further comprises:

- applying a received configuration to access the cell.

4. The method of any one of claims 1 -3, wherein the updating (200) of the one or more stored configurations comprised in the set of stored

configurations comprises:

- updating the one or more stored configurations being different from a configuration to access the cell.

5. The method of any one of claims 1 -4, further comprising:

- accessing the cell by performing a handover procedure, a conditional handover procedure or a re-establishment procedure.

6. The method of any one of claims 1 -5, wherein the updating (200) of the set of stored configurations comprises one or more out of:

- maintaining one or more configurations in the set of stored

configurations;

- stopping monitoring triggering conditions;

- releasing an identity of the one or more stored configurations;

7. The method of any one of claims 1 -6, further comprising:

- receiving an indication to perform the updating (200) of the one or more stored configurations after the access of the cell, wherein the indication is received from a source cell (104), one of the at least one target cell X (106A-106C) or from another cell.

8. The method of any one of claims 1 -7, wherein each stored configuration is an RRC configuration, such as an RRC Reconfiguration, a handover configuration or a conditional handover configuration.

9. The method of any one of claims 1 -8, wherein the updating (200) of the one or more stored configurations is performed upon a re-establishment procedure, upon detecting a communication failure, upon a conditional handover execution or upon a handover execution.

10. The method of claim 9, wherein the communication failure comprises any of: a handover failure, a radio link failure, an integrity protection failure, and a failure to comply with a configuration for accessing the wireless network.

1 1. A wireless device (100,300) configured to operate in a wireless communications network (102) and having a set of stored configurations for at least one target cell X (106A-106C), and when in connected mode and accessing a cell, the wireless device (100,300) is configured to:

- update one or more stored configurations comprised in the set of stored configurations upon access of the cell.

12. The wireless device (100,300) of claim 1 1 , wherein the accessed cell is one out of the at least one target cell (106A-106C) and wherein the wireless device (100,300) further is configured to:

- apply one out of the one or more stored configurations comprised in the set of stored configurations to access the one of the at least one target cell X (106A-106C).

13. The wireless device (100,300) of claim 1 1 , wherein the accessed cell is different from one of the at least one target cell (106A-106C) and wherein the wireless device (100,300) further is configured to:

- apply a received configuration to access the cell.

14. The wireless device (100,300) of any one of claims 1 1 -13, wherein the wireless device (100,300) is configured to update the one or more stored configurations comprised in the set of stored configurations by further being configured to:

- update the one or more stored configurations being different from a configuration to access the cell.

15. The wireless device (100,300) of any one of claims 1 1 -14, further being configured to:

- access the cell by performing a handover procedure, a conditional handover procedure or a re-establishment procedure.

16. The wireless device (100,300) of any one of claims 1 1 -15, wherein the wireless device (100,300) is configured to update the set of stored configurations by being configured to perform one or more out of: - discarding or removing one or more out of the stored configurations from the set;

- maintaining one or more configurations in the set of stored

configurations;

- stopping monitoring triggering conditions;

- releasing an identity of the one or more stored configurations;

17. The wireless device (100,300) of any one of claims 1 1 -16, further being configured to:

- receive an indication to perform the updating (200) of the one or more stored configurations after the access of the cell, wherein the indication is received from a source cell (104), one of the at least one target cell X (106A-106C) or from another cell.

18. The wireless device (100,300) of any one of claims 1 1 -17, wherein each stored configuration is an RRC configuration, such as an RRC

Reconfiguration, a handover configuration or a conditional handover configuration.

19. The wireless device (100,300) of any one of claims 1 1 -18, wherein the wireless device (100,300) is configured to update the one or more stored configurations upon a re-establishment procedure, upon detecting a communication failure, upon a conditional handover execution or upon a handover execution.

20. The wireless device (100,300) of claim 19, wherein the communication failure comprises any of: a handover failure, a radio link failure, an integrity protection failure, and a failure to comply with a configuration for accessing the wireless network.

21. A computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to any one of claims 1 -10.

22. A carrier containing the computer program of claim 21 , wherein the

carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.