WO2024035286A1

WO2024035286A1 - Improving an ongoing communication after a planned outage

Info

Publication number: WO2024035286A1
Application number: PCT/SE2022/050746
Authority: WO
Inventors: Badawi YAMINE; Henrik RYDÉN
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2022-08-08
Filing date: 2022-08-08
Publication date: 2024-02-15

Abstract

The present invention describes methods and devices for improving wireless communication after a planned cell outage in a wireless network comprising a serving Radio Node, RN, a neighboring RN, a first cell belonging to the serving RN that is serving the User Equipment, UE, and a second cell belonging to the serving RN or the neighboring RN. According to a first embodiment the object is achieved by a method performed by a User equipment (UE). The action for improving wireless communication after a planned cell outage can be taken by the UE or by serving RN or cell. FIG 1

Description

IMPROVING AN ONGOING COMMUNICATION AFTER A PLANNED OUTAGE

TECHNICAL FIELD

The presented invention generally relates to wireless communications field, and more particularly relates to improving communication sessions after a planned outage occurs in the serving cell.

BACKGROUND

In every wireless mobile network at any moment one or more cells or even a Radio Node (RN) could experience outage. It is known as cell or RN outage when a cell or RN becomes disabled for a period and then comes back into service, this results in losing radio coverage for User Equipment (UE) under these cells or RN until there are back into service.

Cell outages can be classified in expected or unexpected outages. Unexpected outages represent outages that occur unexpectedly due to the equipment’s software and/or hardware failing suddenly, whereas expected outages, also known as planned outages, represent outages that occurs in an intentional way to allow implementation of some type of software and/or hardware maintenance, upgrade, testing, etc.

In particular expected cell outage, also known as planned cell outage, could be arranged for many reasons such as: new software release of the cell or the RN, a value changes of radio parameters of the cell that will not take effect until the cell is lock/unlock, a software bug that requires restarting the cell, introducing a new cell Radio Access Technology (RAT), e.g. 5G, on existing RN that contains already 4G cells or the operator has locked the cell for testing procedures.

Currently the principal approach for handling cell or RN outage is based on 3rd Generation Partnership Project (3GPP) standards, for example 3GPP TS 38.331v16.7, and it is a general procedure that applies to any UE that losses coverage for any reason; it can be summarized as follows. When a UE in communication with a serving cell (such a 4G or 5G cell) loses its radio coverage from the serving cell, a timer (such a T311) is started at both the cell and at UE side. While the timer is running the UE tries to find the most suitable cell that can be the previous serving cell or a neighboring cell.

Moreover, based on the 3GPP standards, a UE must be served by the best cell available otherwise a connecting procedure is triggered towards the best new cell available. This handover procedure results in one or more signaling procedures depending on the Radio Access Technology (RAT) type of the cells (such as 3G, 4G or 5G), or on the location area such as Tracking Area Code (TAC) of the involved cells. Additionally, this signaling procedures also it depends on the state of UE for example: UE in RRC_CONNECTED state (when the UE is in a call), UE in RRCJDLE state (when the UE is not performing any call activity) or UE in RRC_IN ACTIVE state (when the UE is not exchanging any data with the RN, but its UE context is still stored at the UE and at the network).

It is also known patent applications that try to handle outage outside the standards specifications. For example, US20110028181 describes a method for configuring and optimizing an Automatic Neighbor Relation (ANR) consisting of making a differentiation, based on UE measurement reports, whether a newly added neighbor cell is an overlay neighbor cell (ON) or whether it is a horizontal neighbor cell. This document uses overlay cells in the network for load balancing and cell outage compensation. However, it just describes moving all the UE being served by the cell to other neighboring cells. So, the UE ended up behaving as indicated by the standards and most the UE will go to the neighbor cell and shortly back to the last serving cell once it is back to service.

It is known that patent application WO2021029796A1 address the problem of the availability of the UE context after unexpected outage as follows. When a Radio Unit (RU), or a cell, goes down the RN of WO2021029796A1 instead of clearing all UE context, it will forward, as well it stores in its memory, the UE context of all UEs that were being served by cell to neighboring RN of with new serving cell. As a result, when UE wants to connect to the new serving cell after the last serving cell outage it could because the new serving cell of the neighboring RN has already the UE context of UE and hence the call reestablishment of UE on new cell is successful.

Finally, it is also known EP2580931A1 that describes how to improve handover (HO) procedures and signaling for planned cell outage in wireless cellular networks. This method pretends to control HO of the UE before the outage occurs by selecting a part of the signal bandwidth or time-frequency resource of a neighbor cell, which does not overlap with that to be used by the serving cell during the handover; and designating the selected part for use by the UE to be handed over from the first cell unit.

SUMMARY

As part of the description of embodiments herein, one or more problems with the existing technology will first be identified and discussed.

Cell outage both planned and unexpected are particularly problematic because the coverage of the area provided by the outage cell needs to be provided by other neighboring cell of during the downtime to avoid interruption of the service. Currently the principal approach for handling cell or Radio Node (RN) outage is based on 3rd Generation Partnership Project (3GPP) standards as mentioned in more details above. This approach requires that a User Equipment (UE) must be served by the best cell available otherwise a handover procedure is triggered towards the best new cell available. This condition generates the following behavior when an outage occurs: all the UEs have to move to a neighboring cell during an outage and most of those UEs that moved to the neighboring cell will come back to the previous serving cell after the outage. This situation generates a lot of signaling procedures of UEs going forward to another cell and then back to the previous cell. This can include multiple signaling such a location update and call setup required in both ways to the neighbor cell and back to the last serving cell resulting in a waste of signaling resources as well as an additional energy consumption for both the cell or RN and the UE. This problem is defined as ping pong problem because the UEs are moving to the neighboring cell just to go back to the serving cell.

The ping pong problem becomes more relevant when thousands of UEs might be camped (RRCJDLE state) on the serving cell before the serving cell outage and that all these UE might trigger their signaling procedure simultaneously as they all will detect loss of radio coverage of serving cell (after serving cell outage) and they will again detect radio coverage from the last serving cell and trigger signaling procedure simultaneously again to connect back to the last serving cell.

Another problem of the actual 3GPP approach is that when the serving cell goes down due to the outage it clears all UEs contexts and the neighboring cell when request a UE context to the serving cell will not be able to get it.

Furthermore, the known prior art related to outage may try to improve handover procedures in different ways. However, the prior art is both mute about the ping pong problem and still affected by it.

According to the foregoing, it is an object of embodiments herein to improve the improving wireless communication after a planned cell outage in a wireless network

The embodiments of the invention have been divided in two groups and the objective of all the embodiments is improving wireless communication after a planned cell outage in a wireless network comprising a serving Radio Node, RN, a neighboring RN, a first cell belonging to the serving RN that is serving a User Equipment, UE, and a second cell belonging to the serving RN or the neighboring RN. The division between the embodiments is based on whether the UE or the RN is taking the decision to connect to the second cell, or to disconnect from the first cell during a period of outage (T) and reconnect to the first cell after the planned outage. First group of embodiments

According to a first embodiment the object is achieved by a method performed by a User equipment (UE). The method for improving wireless communication after a planned cell outage in a wireless network comprising a serving Radio Node, RN, a neighboring RN, a first cell belonging to the serving RN that is serving the User Equipment, UE, and a second cell belonging to the serving RN or the neighboring RN. The method is performed by the UE and comprises receiving a message from the first cell comprising a period of outage , and in response to a radio connection loss due to the planned cell outage, deciding, based on at least a UE condition, whether to connect to the second cell, or to disconnect from the first cell during the period of outage and reconnect to the first cell after the planned outage.

According to a second embodiment the object is achieved by a method performed by a serving Radio Node (RN). In particular, the method improves wireless communication after a planned cell outage in a wireless network comprising the serving Radio Node, RN, a neighboring RN, a first cell belonging to the serving RN that is serving a User Equipment, UE, and a second cell belonging to the serving RN or the neighboring RN. The method is performed by the serving RN and comprises in responsive to determining a planned cell outage of the first cell, holding a UE context of the UE, obtaining a period of outage , and sending a message to the UE comprising a period of outage .

According to a third embodiment the object is achieved by a User equipment (UE) The UE is configured for improving wireless communication after a planned cell outage in a wireless network comprising a serving Radio Node, RN, a neighboring RN, a first cell belonging to the serving RN that is serving the UE, and a second cell belonging to the serving RN or the neighboring RN. The UE comprises processing circuitry configured to perform the flowing steps: receiving a message from the first cell comprising a period of outage , and in response to a radio connection loss due to the planned cell outage, deciding, based on at least a UE condition, whether to connect to the second cell, or to disconnect from the first cell during the period of outage and reconnect to the first cell after the planned outage.

According to a fourth embodiment the object is achieved by a serving Radio Node (RN). In particular, the serving RN is configured for improving wireless communication after a planned cell outage in a wireless network comprising the serving Radio Node, RN, a neighboring RN, a first cell belonging to the serving RN that is serving a User Equipment, UE, and a second cell belonging to the serving RN or the neighboring RN. The RN is serving the UE before the outage and comprises processing circuitry configured to perform the flowing steps: in responsive to determining a planned cell outage of the first cell, holding a UE context of the UE, obtaining a period of outage , and sending a message to the UE comprising a period of outage .

Second group of embodiments

According to a fifth embodiment the object is achieved by a method performed by the serving Radio Node (RN). The method for improving wireless communication after a planned cell outage in a wireless network comprising the serving Radio Node, RN, a neighboring RN, a first cell belonging to the serving RN that is serving a User Equipment, UE, and a second cell belonging to the serving RN or the neighboring RN. The method is performed by the serving RN and in response to an incoming planned cell outage of the first cell, comprises: deciding, based on at least a UE condition, whether to trigger a handover procedure on the UE to connect to it the second cell before cell outage, or to disconnect the UE for a period of outage and reconnect it to the first cell after the planned outage.

According to a sixth embodiment the object is achieved by a method performed by the User equipment (UE). The method for improving wireless communication after a planned cell outage in a wireless network comprising a serving Radio Node, RN, a neighboring RN, a first cell belonging to the serving RN that is serving the UE, and a second cell belonging to the serving RN or the neighboring RN. The method is performed by the UE and in response to an incoming planned cell outage of the first cell, comprises: connecting from the first cell to the second cell by a handover procedure before cell outage, or disconnecting for a period of outage and reconnecting to the first cell after the planned outage.

According to a seventh embodiment the object is achieved by a serving Radio Node (RN). The serving RN is configured for improving wireless communication after a planned cell outage in a wireless network comprising the serving Radio Node, RN, a neighboring RN, a first cell belonging to the serving RN that is serving a User Equipment, UE, and a second cell belonging to the serving RN or the neighboring RN. The RN is serving the UE before the outage and comprises processing circuitry configured to perform the following steps in response to an incoming planned cell outage of the first cell: deciding, based on at least a UE condition, whether to trigger a handover procedure on the UE to connect to it the second cell before cell outage, or to disconnect the UE for a period of outage and reconnect it to the first cell after the planned outage.

According to an eight embodiment the object is achieved by a User equipment (UE) The UE is configured for improving wireless communication after a planned cell outage in a wireless network comprising a serving Radio Node, RN, a neighboring RN, a first cell belonging to the serving RN that is serving the UE and a second cell belonging to the serving RN or the neighboring RN. The UE comprises processing circuitry configured to perform the following steps in response to an incoming planned cell outage of the first cell: connecting from the first cell to the second cell by a handover procedure before cell outage or disconnecting for a period of outage and reconnecting to the first cell after the planned outage.

The present invention solves the ping pong problem and have the advantages to o reduce the amount of signaling when a planned cell outage occurs, which is increasingly important with a vast number of new UEs being deployed, such as Internet of Things (loT) devices. The reduced signaling overhead will lead to energy savings at both the network and UEs by for example mitigating an unnecessary RAN Notification Area (RNA) update.

Moreover, the present invention has the advantage of deciding based on the UE condition to re-connect to the last serving cell in order to avoid losing completely the running communication, such as the buffer of an application or a downloading video. This becomes critical when the application, or the video, is about a sensitive matter, e.g. a remote health operator or a video coming from an area of disaster etc.

Along this document the following terms are equivalent and interchangeable with each other. User equipment (UE) may include wireless communication devices, mobile stations, stations (STA) and/or wireless devices, communicate via a Radio Access Network (RAN) with one or more core networks (CN) and Radio network node may include Radio Nodes (RN) also referred as radio base station (RBS) such as NodeB, gNodeB, or eNodeB, and Wi-Fi access point. The term neighboring cell can be understood as target cell or new serving cell and serving cell is understood as the serving cell before the outage or last serving cell. Further examples of these terms are described in the detailed description.

BRIEF DESCRIPTION OF THE DRAWINGS

Examples of embodiments herein are described in more detail with reference to the accompanying drawings, and according to the following description.

Figure 1 is a block diagram in accordance with a first group of embodiments of the present invention.

Figure 2 is a block diagram in accordance with a second group of embodiments of the present invention.

Figure 3 shows an example of a communication system 300 in accordance with some embodiments. Figure 4 shows a UE 400 in accordance with some embodiments.

Figure 5 shows a network node 500 in accordance with some embodiments.

Figure 6 is a block diagram of a host 600, which may be an embodiment of the host 316 of Figure 3, in accordance with some embodiments.

Figure 7 is a block diagram illustrating a virtualization environment 700 in which functions implemented by some embodiments may be virtualized.

Figure 8 shows a communication diagram of a host 802 communicating via a network node 804 with a UE 806 over a partially wireless connection in accordance with some embodiments.

DETAILED DESCRIPTION

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

Certain aspects of the present disclosure and their embodiments may provide solutions to the challenges discussed in the Summary section or other challenges. There are, proposed herein, various embodiments which address one or more of the issues disclosed herein.

As part of the detailed description herein, the User Equipment (UE) behaviour under 3GPP for example TS 38.331v16.7, for an outage situation will first be identified and discussed.

Note that the following terms celU refers to serving cell is understood as the serving cell before the outage or last serving cell and cell2 refers to neighboring cell can be understood as target cell or new serving cell. Also, along the description the term network (NW), Radio Node, cell, cell with some tools on Operation Support Systems (OSS), or RN with some tools on OSS are interchangeable.

When a UE in RRC_CONNECTED state or in INACTIVE state, which is in communication with a 5G serving cell loses its radio coverage from the serving cell -due to for example cell outage-, the call is dropped and the timer T311 is started at the cell and at UE side and while the T311 is running: the call contexts of UE are held at cell and at UE, and the UE tries to find a suitable cell resulting in the following 3 scenarios.

Scenario 1 : If neighbor cell is running on a different RAT than the one running on serving cell the UEwill then drop its call on the serving cell and trigger a new call on neighbor cell which should include a location update, e.g. Tracking Area Update (TAU) procedure, on neighbor cell, while the serving cell releases all its UE context. In other words, in this scenario two signaling procedures are triggered on neighbor cell: A location update procedure AND a new call setup.

Scenario 2: If neighbor cell is running on the same RAT as of serving cell but it is configured with a different location area, TAG, than the one used in serving cell the UE will trigger two signaling procedures on neighbor cell: A location update procedure AND a call reestablishment procedure which is possible only if before serving cell outage, RN of serving cell has, stored in its memory and forwarded to neighboring RN, the context of all UEs that were connected to serving cell

Scenario 3: If neighbor cell is running on the same RAT, RAT1 , as of serving cell but it is configured with the same location area, e.g. TAC1 , as the one used, TAC1 , in serving cell. In such scenario UE1 will trigger only one signaling procedures on neighbor cell: A call reestablishment procedure which is possible thanks only if before serving cell outage, RN of serving cell has, stored in its memory and forwarded to neighboring RN, the context of all UEs that were connected to serving cell.

For scenarios 1-3, if T311 expires before the UE finds a suitable cell, the UE will go into an RRCJDLE state, and it will result in that the UE is left without any radio coverage.

In scenarios 1- 3 is worth mentioning that the duration of such call setup procedure depends on which RAT, UE1 has triggered the call setup and that for all cases, whatever is the target RAT, the duration of the call setup is longer than the duration of the call reestablishment.

Additionally, in case of UE in RRC_CONNECTED state, as described below in order to avoid a drop call, there are features in prior art where the UE in RRC_CONNECTED state might be moved to neighboring cells before celU outage.

The behavior of the UE based on the RAT type and location area, e.g. TAG, of cell2 in comparison to the RAT and TAG on celU is the following.

Scenario 4: If cell2 is running on a different RAT, e.g. RAT2, than the one running on celU , RAT1 , then an inter RAT handover procedure is triggered from celU towards cell2. Once on cell2, in addition to the inter RAT handover procedure the UE has to trigger a location update procedure on cell2, e.g. Tracking Area Update (TAU) procedure. In other words, in this scenario two signaling procedures are triggered on cell2: A location update procedure AND a inter RAT handover procedure.

Scenario 5: If cel I2 is running on the same RAT, RAT 1 , as of celU but it is configured with a different location area, e.g. TAC2, then the one used, TAC1 , in celU . In such scenario UE1 will trigger two signaling procedures on cell2: A location update procedure, e.g. a TAU procedure AND an intra or inter frequency handover procedure. Scenario 6: If cel 12 is running on the same RAT, RAT 1 , as of celll but it is configured with the same location area, e.g. TAC1 , as the one used, TAC1 , in celll . In such scenario UE1 will trigger only one signaling procedures on cell2: An intra or inter frequency handover procedure.

In the case of UE in RRCJDLE state or in RRCJNACTIVE, no such features are used in prior art and hence each of such UEs will experience celll outage and its behavior will be as follows:

Scenario 7: The UE moves to cell2 running on a different RAT, e.g. RAT2, than of celll , e.g. RAT1. In case the UE is in RRCJDLE state, it will camp on cell2 and will trigger two signaling procedures: register on the new RAT, e.g. via attach procedure, and a location area update procedure on cell2. In case the UE is in RRC_IN ACTIVE state, the UE will release its UE context that were used on celll , then it will behave as of a UE in RRCJDLE state on cell2 that is by triggering the two mentioned signaling procedures on cell2, that are UE registration, and RNA update procedure according to for example 3GPP TS 38.300, V16.8.0.

Scenario 8: The UE moves to cell2 running on the same RAT, RAT1 , as of celll , but is configured with different location area (case of UE in RRCJDLE state) or with different RNA (case of UE in RRCJNACTIVE). In such scenario, for a UE in RRCJNACTIVE state as it moves from one RNA to another one, it will trigger a signaling RNA update procedure. Similarly, when a UE in RRCJDLE state moves from one location area, e.g, TAC1 , to another one, e.g. TAC2, it triggers a location update procedure according to for example 3GPP TS 23.502, V16.11.0.

Scenario 9: The UE moves to cell2 running on the same RAT, RAT 1 , as of celll , AND also cell2 is configured with the same location area (case of UE in RRCJDLE state) or with same RNA (case of UE in RRCJNACTIVE) as in celll , THEN no signaling procedure is triggered by the UE.

Thus, the behavior of the UE results in 9 different scenarios and scenarios 1-8 are affected by the ping pong problem described above.

The embodiments of the invention have been divided in two groups and the objective of all the embodiments is improving wireless communication after a planned cell outage (in any scenario) for a wireless network comprising a serving Radio Node, RN, a neighboring RN, a first cell belonging to the serving RN that is serving a User Equipment, UE, and a second cell belonging to the serving RN or the neighboring RN. The division between the embodiments is based on whether the UE or the RN is taking the decision to connect to the second cell, or to disconnect from the first cell during a period of outage (T) and reconnect to the first cell after the planned outage. All the decision are based on a UE condition comprising any item or factors described along the whole description that triggers the decision of the UE or the cell or RN.

First group of embodiments

In the first group of embodiments the decision, based on UE condition comprising different factors, about how to improve the wireless communication after the planned cell outage cells is taken at the UE side and it may comprise the following steps or states according to block diagram of figure 1 .

Step 100: The initial state may comprise of two prerequisites:

• A decision to trigger, at time t1 , an outage that affects call coverage on one cell, celU , of a Radio Node (RN), RN1 , of one RAT (Radio Access Technology), RAT1 , is to be taken either: o by an operator staff, e.g. for a planned outage, e.g. the operator wants to change some parameters on celU which require a cell lock/unlock or the operator wants to upgrade the version of the running software on celU , o or by the network, e.g. auto-healing tool or SON (Self-Organizing Networks) or others. For example, there was a software issue, e.g. an alarm caused by a radio equipment that is serving celU , and the auto-healing tool knows from past experience that a restart of the faulty equipment could restore the service of celU .

• The period of outage T for the cell is known to the network.

Note that the period of outage T this could be obtained by the operator, or the network as follows:

• for a cell it measures the time tjock when the cell goes into outage and time t_unlock when the cell broadcast radio coverage again. Then the value of T is equal to (t_unlock - tjock).

• for a Radio Node (RN) restart it measures the time t_restart when the cell of RN goes into outage and time t_restart_compleletd when the cell of that the restarted RN broadcast radio coverage again. Then the value of T is equal to (t_restart_compleletd - t_restart).

• Similarly, the operator could calculate the value of T for any procedure that could lead to cell outage. On the other hand, if a cell, e.g. celHOO, goes into a non-planned outage, e.g. a Radio Unit equipment powering celHOO goes faulty and the auto-healing could not restore celHOO, the value of T could not be calculated and in such scenario the present invention does not apply.

Step 110: explains the actions that may be taken by celU before it goes into a planned outage, and it may comprise the following:

• In prior art, if a UE, UE1 , is being served by a cell, celU , that goes into outage, then the UE context of UE1 are released and as a consequence when that cell is restored any call reestablishment by UE1 towards celU will fail. At step 110, all UEs context are not released rather they are held for a period T, at RN1 where celU is running or at a neighboring RN, e.g. RN2, so that when celU is restored all UEs that were being served by celU before the outage could reestablish successfully their call on celU .

• CelU broadcast to all UEs in celU , the period of outage T, via one SIB (System Information Block).

• Each UE, whatever is its status (UE in connected or RRCJDLE state, or UE in RRCJNACTIVE state) is requested by celU , or by any other mean, e.g. a new feature installed at the UE, to store its radio conditions, e.g. value of RSRP, before celU outage.

Step 111 : indicates actions that may be taken by the UE after cell 1 outage is triggered.

In particular, after a UE, UE1 , in call with serving celU of RAT1 loses its radio coverage due to celU outage & if best cell suitable cell, is cell2, THEN UE1 , whether it is in RRCJDLE state or in RRC_CONNECTED state will take best decision on whether:

• it moves directly to cell2 and trigger a signaling procedure on it or

• it camps on cell2 but does not trigger any signaling procedure on cell2 rather wait for a period > T and then reconnect to cell1 of RAT 1

Such decision may be based on the UE condition including different factors such as:

• In a first example the decision is based on the type of RAT and type of location area, e.g. TAC (Tracking area update), of cell2 in comparison to the RAT and location area in cell1.

• In a second example the decision is based on how distant is UE1 from the antennas of cell1.

• In a third example the decision is based on other factors, e.g. type of call service running on UE1 and others etc... When the decision to switch of UE1 to cell2 depends on RAT and location area at cell2 in comparison to the ones running on celll (first example), it may comprise the following:

• If cell2 is of different RAT than of celll (scenario 1) OR if cell2 is of the same RAT of celll but it is configured with a different location area, e.g. TAG (Tracking Area Code) than of celll (scenario 2), o THEN UE1 does not move directly to cell2 but rather wait for a period > T and then reconnect to celll of RAT 1.

• Else, if cell2 is of the same RAT of celll but it is configured with the same location area, e.g. TAC as of celll (scenario 3), o THEN UE1 might move to cell2.

When the decision to switch of UE1 to cell2 depends on how far UE1 is located from the antennas of celll (second example), it may comprise the following:

• If, at time t1 of triggering of celll outage, UE1 is at the edge of celll and is moving towards cell2 then even though UE1 has still better radio conditions from celll than from cell2, let UE1 moves to cell2 because by the time celll outage is ceased at time t2, it is most likely that the radio conditions of cell2 on UE1 might be better than the ones of celll .

At least the following two procedures are used to check whether UE1 is moving at the edge of celll towards cell2.

Procedure 1 : It consists in estimating the distance of UE1 from celll antennas based on UE radio conditions and it applies to any mode of the UE, e.g. UE in idle and in RRC_CONNECTED state. This done as shown in following two scenarios:

• Scenario A: If ((UE1 radio conditions of cell2 before outage) < (UE1 radio conditions of cell2 after outage) THEN it is most likely that UE1 is moving from celll towards cell2 and as a consequence UE1 decision is to connect immediately on cell2. This is done because after celll outage is completed, there is no fear that UE1 moves back to celll and hence ping pong problem described above is not valid.

• Scenario B: If (UE1 radio conditions of cell2 before outage > UE1 radio conditions of cell2 after outage) THEN it is most likely that UE1 has remained in its location during celll outage, or it has moved towards antennas of celll and as a consequence UE1 decision is NOT to connect immediately on cell2 after celll outage but rather wait for a period T and reselects celll . This is done in order to avoid UE1 moving temporary to cell2 then moving back to cell1.

• Note that for Scenario A and B we are referring to RSRP value that are negative values. For example: if before celll outage UE1 radio conditions based on RSRP, on cell2, are equal to -90 dbm then if after outage RSRP of UE1 on cell2 are: o -85 dbm (which is > -90 dbm) meaning that UE1 is moving towards cell2. o -94 dbm (which is < -90 dbm) meaning that UE1 is rather moving away from cell2

Procedure 2: it consists in estimating distance of UE1 from celll antennas is based on the Timing Advance (TA) and applies only for UE in RRC_CONNECTED state. Procedure 2 works as follows:

• If just before the occurrence of the outage and after its occurrence the TA of UE1 is increasing, within a predefined threshold, THEN it is most likely UE1 is moving away from celll and in such scenario, UE1 might switch to cell2.

• Otherwise, if just before the occurrence of the outage and after its occurrence the TA of UE1 is stable (UE1 is stationary) or decreasing (UE1 is moving towards the antennas of celll) THEN UE1 might not switch to cell2 but rather wait for period of outage T in order to reconnect to celll .

When the decision to switch of UE1 to cell2 depends on other factors, e.g. type of call (third example): the UE might not take only its radio condition as the only factor for it decision on whether to move directly to cell2 or wait for a period T and return to celll . Other factors might be taken into consideration as for example:

• The type of the communication running on the UE: whether it could support a short break (UE wait till return to celll) or needs continuity of call even if degraded (UE moves to cell2).

• UE traffic predictions: With a prediction model, one can estimate the probability of data arriving in the downlink/uplink

• UE battery level: The cost of potential ping-pong handover might be larger for a battery constrained UE.

• UE radio conditions predicted by the NW, the cell or the RN, and signaled to the RRC_CONNECTED state UE: Another method is for the NW, based on e.g. the observed radio measurements reported for the UE, to predict the RSRP in cell 1 and cell 2 after outage (t1+T). Such per-UE predictions cannot be broadcasted, but should be unicasted, for example via RRC signaling before the outage. The NW also have more information on the local environment and should be better to perform such radio condition prediction. Note that such forecasted RRC measurement value needs to be standardized, there is no such support in current NR standards.

Thus, based on the third example a UE1 does not have to connect immediately on cell2 but rather wait for a period T to return to celll under influence of other factors that might have a higher priority over UE1 radio conditions or distance between the antenna and the UE.

Second group of embodiments

In the second group of embodiments the decision, based on UE condition comprising different factors, about how to improve the wireless communication after the planned cell outage cells is taken at the network side and it may comprise the following steps or states according to block diagram of figure 2.

Step 200: The initial state may comprise of two prerequisites:

• A decision to trigger, at time t1 , an outage that affects call coverage on one cell, celll , of a Radio Node (RN), RN1 , of one RAT (Radio Access Technology), RAT1 , is to be taken either: o by an operator staff, e.g. for a planned outage, e.g. the operator wants to change some parameters on celll which require a cell lock/unlock or the operator wants to upgrade the version of the running software on celll , o or by the network, e.g. auto-healing tool or SON (Self-Organizing Networks) or others. For example, there was a software issue, e.g. an alarm caused by a radio equipment that is serving celll , and the auto-healing tool knows from past experience that a restart of the faulty equipment could restore the service of celll .

• The period of outage T for the cell is known to the network.

• for a cell it measures the time tjock when the cell goes into outage and time t_unlock when the cell broadcast radio coverage again. Then the value of T is equal to (t_unlock - tjock). • for a Radio Node (RN) restart it measures the time t_restart when the cell of RN goes into outage and time t_restart_compleletd when the cell of that the restarted RN broadcast radio coverage again. Then the value of T is equal to (t_restart_compleletd - t_restart).

• Similarly, the operator could calculate the value of T for any procedure that could lead to cell outage.

On the other hand, if a cell, e.g. celHOO, goes into a non-planned outage, e.g. a Radio Unit equipment powering celHOO goes faulty and the auto-healing could not restore celHOO, the value of T could not be calculated and in such scenario the present invention does not apply.

Step 210: explains the actions that may be taken by celU before it goes into a planned outage, and it may comprise the following:

• The contexts of all UEs being served by celU are stored at RN1 and/or forwarded to surrounding RNs, e.g. RN2. In prior art, when a cell goes into outage, all its UEs context are released. Here with this step, all UEs context are not released rather they are held for a period T so that when celU is restored all UEs that were being served by celU before the outage could reestablish successfully their call on celU .

• A request from celU to each UE that being served (UE in RRC_CONNECTED state) by celU to send a multiple RRC radio measurement report, e.g. value of RSRP. The request is done via a multicast (e.g. SIB) or unicast RRC message (each UE receives a dedicated signaling message).

This RRC radio measurement message may contain the value of UE radio conditions at time of sending the message, e.g. value RSRP1 at time t1 , multiple values of RSRP require the UE sending multiple RRC radio measurement with one value of RSRP in each message. The example of reports requested by the UE is RSRP the request but could be any other measurements performed by the UE, e.g. RSRQ or others.

The request of multiple reports could follow any format. In some embodiments, the requested report could be periodic, e.g. every interval equal to TJnterval, one report is to be sent for a predefined total duration, e.g. T1 . In other embodiments, the requested report could be a predefined number of reports to be sent, e.g. five reports and the UE could the interval of time between each report or could be one report when a certain threshold is reached. Additionally, the RRC radio measurement message may contain the forecasted value of UE radio conditions at time after outage, e.g. value RSRP1 at time t1+T. This would need standardization extensions to the current RRC measurement report. The forecasted value can also include an uncertainty measure of the forecast. For example, the RSRP is x +-B, where B is the standard deviation of the prediction uncertainty.

Step 221 : describes the procedure being used by the UE to send the result of the report to the cell.

Once the request of multiple reports is received by the UE, it will send multiple measurements reports, based on the receive format e.g. one report each interval TJnterval for a total duration equal to T1. For a UE in RRC_CONNECTED state each report is sent via one RRC measurement report.

Step 222: describes the actions taken by the network when it receives the multiple report from the UE.

When the NW receives, before celU outage, the multiple report, e.g. containing RSRP values, from each UE, e.g. UE1 , it could predict whether UE1 is:

• remaining at the same location or moving inside celU , then celU will not take any further action and in such case the UE will behave as described in the first group of embodiments, or

• moving outside celU , e.g. towards cell2, e.g. the value of RSRP1 of celU is decreasing whereas the value of RSRP2 of cell2 is increasing. In such case a normal handover is triggered.

In one example embodiment, suppose that, at time t1 , before the occurrence of the outage on celU , 1200 UEs are being served by celU and suppose that 200 of these 1200 UEs are moving outside celU towards neighboring cells, e.g. cell2, whereas the remaining 1000 UEs are either stationary UEs or they are moving inside celU . In such example, the second group of embodiments will move only 200 UEs from celU to cell2, by making celU trigger a handover procedure on each of these 200 UEs.

When the outage of celU occurs, then the remaining 1000 UEs will experience a call drop. After the outage is ceased on celU , e.g. at time t2, the 200 UEs that have moved at time t1 from celU to cell2 will unlikely be handed over from cell2 to celU as at time t2 we assume that a moving UE from celU towards cell2 will experience a better radio condition from cell2 than from celU . In this way the ping pong issue described above will not apply to these 200 UEs. For the 1000 UEs that have experienced a drop call after celll outage, will behave as described in the first group of embodiments. That is depending on the RAT and location area of cell2 (see scenario 1 , 2 and 3 above), the ping pong issue is avoided.

Step 223: describes other factors might be considered for cell switch.

After receiving multiple reports from the UE, other factors included in the UE condition might be taken into consideration for the decision of the NW such as the following:

• even though received radio measurements from a UE, e.g. UE2, say that UE2 is moving towards cell2 but cell2 is congested then NW will not ask UE2 to move to cel I2 & UE2 will wait for a period T in order to return to celll .

• even though received radio measurements from a UE, e.g. UE2, say that UE2 is NOT moving towards cell2 but rather is having good radio conditions from celll , AND if the NW predict or is aware about new data arriving to the UE then NW might ask the UE to move to cell2 so that it does not lose the data while waiting for a period T for celll return.

Figure 3 shows an example of a communication system 300 in accordance with some embodiments.

In the example, the communication system 300 includes a telecommunication network 302 that includes an access network 304, such as a radio access network (RAN), and a core network 306, which includes one or more core network nodes 308. The access network 304 includes one or more access network nodes, such as network nodes 310a and 310b (one or more of which may be generally referred to as network nodes 310), or any other similar 3rd Generation Partnership Project (3GPP) access nodes or non-3GPP access points. Moreover, as will be appreciated by those of skill in the art, a network node is not necessarily limited to an implementation in which a radio portion and a baseband portion are supplied and integrated by a single vendor. Thus, it will be understood that network nodes include disaggregated implementations or portions thereof. For example, in some embodiments, the telecommunication network 302 includes one or more Open-RAN (ORAN) network nodes. An ORAN network node is a node in the telecommunication network 302 that supports an ORAN specification (e.g., a specification published by the O- RAN Alliance, or any similar organization) and may operate alone or together with other nodes to implement one or more functionalities of any node in the telecommunication network 302, including one or more network nodes 310 and/or core network nodes 308. Examples of an ORAN network node include an open radio unit (0-Rll), an open distributed unit (0-Dll), an open central unit (O-CU), including an O-CU control plane (O- CLI-CP) or an O-CU user plane (O-CU-UP), a RAN intelligent controller (near-real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time control application (e.g., rApp), or any combination thereof (the adjective “open” designating support of an ORAN specification). The network node may support a specification by, for example, supporting an interface defined by the ORAN specification, such as an A1 , F1 , W1 , E1 , E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an ORAN access node may be a logical node in a physical node. Furthermore, an ORAN network node may be implemented in a virtualization environment (described further below) in which one or more network functions are virtualized. For example, the virtualization environment may include an O-Cloud computing platform orchestrated by a Service Management and Orchestration Framework via an 0-2 interface defined by the O- RAN Alliance or comparable technologies. The network nodes 310 facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs 312a, 312b, 312c, and 312d (one or more of which may be generally referred to as UEs 312) to the core network 306 over one or more wireless connections.

Example wireless communications over a wireless connection include transmitting and/or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and/or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, the communication system 300 may include any number of wired or wireless networks, network nodes, UEs, and/or any other components or systems that may facilitate or participate in the communication of data and/or signals whether via wired or wireless connections. The communication system 300 may include and/or interface with any type of communication, telecommunication, data, cellular, radio network, and/or other similar type of system.

The UEs 312 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and/or operable to communicate wirelessly with the network nodes 310 and other communication devices. Similarly, the network nodes 310 are arranged, capable, configured, and/or operable to communicate directly or indirectly with the UEs 312 and/or with other network nodes or equipment in the telecommunication network 302 to enable and/or provide network access, such as wireless network access, and/or to perform other functions, such as administration in the telecommunication network 302. In the depicted example, the core network 306 connects the network nodes 310 to one or more hosts, such as host 316. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network 306 includes one more core network nodes (e.g., core network node 308) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and/or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 308. Example core network nodes include functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (ALISF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and/or a User Plane Function (UPF).

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

As a whole, the communication system 300 of Figure 3 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and/or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and/or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and/or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox. In some examples, the telecommunication network 302 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunications network 302 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 302. For example, the telecommunications network 302 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and/or Massive Machine Type Communication (mMTC)/Massive loT services to yet further UEs.

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

In the example, the hub 314 communicates with the access network 304 to facilitate indirect communication between one or more UEs (e.g., UE 312c and/or 312d) and network nodes (e.g., network node 310b). In some examples, the hub 314 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub 314 may be a broadband router enabling access to the core network 306 for the UEs. As another example, the hub 314 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes 310, or by executable code, script, process, or other instructions in the hub 314. As another example, the hub 314 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub 314 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, the hub 314 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 314 then provides to the UE either directly, after performing local processing, and/or after adding additional local content. In still another example, the hub 314 acts as a proxy server or orchestrator for the UEs, in particular if one or more of the UEs are low energy loT devices. The hub 314 may have a constant/persistent or intermittent connection to the network node 310b. The hub 314 may also allow for a different communication scheme and/or schedule between the hub 314 and UEs (e.g., UE 312c and/or 312d) , and between the hub 314 and the core network 306. In other examples, the hub 314 is connected to the core network 306 and/or one or more UEs via a wired connection. Moreover, the hub 314 may be configured to connect to an M2M service provider over the access network 304 and/or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes 310 while still connected via the hub 314 via a wired or wireless connection. In some embodiments, the hub 314 may be a dedicated hub - that is, a hub whose primary function is to route communications to/from the UEs from/to the network node 310b. In other embodiments, the hub 314 may be a non-dedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node 310b, but which is additionally capable of operating as a communication start and/or end point for certain data channels.

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

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

The UE 400 includes processing circuitry 402 that is operatively coupled via a bus 404 to an input/output interface 406, a power source 408, a memory 410, a communication interface 412, and/or any other component, or any combination thereof. Certain UEs may utilize all or a subset of the components shown in Figure 4. The level of integration between the components may vary from one UE to another UE. Further, certain UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

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

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

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

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

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

The processing circuitry 402 may be configured to communicate with an access network or other network using the communication interface 412. The communication interface 412 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna 422. The communication interface 412 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or a network node in an access network). Each transceiver may include a transmitter 418 and/or a receiver 420 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth). Moreover, the transmitter 418 and receiver 420 may be coupled to one or more antennas (e.g., antenna 422) and may share circuit components, software or firmware, or alternatively be implemented separately.

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

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

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

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

As yet another specific example, in an loT scenario, a UE may represent a machine or other device that performs monitoring and/or measurements, and transmits the results of such monitoring and/or measurements to another UE and/or a network node. The UE may in this case be an M2M device, which may in a 3GPP context be referred to as an MTC device. As one particular example, the UE may implement the 3GPP NB-loT standard. In other scenarios, a UE may represent a vehicle, such as a car, a bus, a truck, a ship and an airplane, or other equipment that is capable of monitoring and/or reporting on its operational status or other functions associated with its operation.

In practice, any number of UEs may be used together with respect to a single use case. For example, a first UE might be or be integrated in a drone and provide the drone’s speed information (obtained through a speed sensor) to a second UE that is a remote controller operating the drone. When the user makes changes from the remote controller, the first UE may adjust the throttle on the drone (e.g. by controlling an actuator) to increase or decrease the drone’s speed. The first and/or the second UE can also include more than one of the functionalities described above. For example, a UE might comprise the sensor and the actuator, and handle communication of data for both the speed sensor and the actuators.

Figure 5 shows a network node 500 in accordance with some embodiments. As used herein, network node refers to equipment capable, configured, arranged and/or operable to communicate directly or indirectly with a UE and/or with other network nodes or equipment, in a telecommunication network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs) and NR NodeBs (gNBs)), O-RAN nodes or components of an O-RAN node (e.g., 0-Rll, 0-Dll, O-CU).

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

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

The network node 500 includes a processing circuitry 502, a memory 504, a communication interface 506, and a power source 508. The network node 500 may be composed of multiple physically separate components (e.g., a NodeB component and a RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components. In certain scenarios in which the network node 500 comprises multiple separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, the network node 500 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory 504 for different RATs) and some components may be reused (e.g., a same antenna 510 may be shared by different RATs). The network node 500 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 500, for example GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z- wave, LoRaWAN, Radio Frequency Identification (RFID) or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within network node 500.

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

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

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

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

In certain alternative embodiments, the network node 500 does not include separate radio front-end circuitry 518, instead, the processing circuitry 502 includes radio front-end circuitry and is connected to the antenna 510. Similarly, in some embodiments, all or some of the RF transceiver circuitry 512 is part of the communication interface 506. In still other embodiments, the communication interface 506 includes one or more ports or terminals 516, the radio front-end circuitry 518, and the RF transceiver circuitry 512, as part of a radio unit (not shown), and the communication interface 506 communicates with the baseband processing circuitry 514, which is part of a digital unit (not shown).

The antenna 510 may include one or more antennas, or antenna arrays, configured to send and/or receive wireless signals. The antenna 510 may be coupled to the radio frontend circuitry 518 and may be any type of antenna capable of transmitting and receiving data and/or signals wirelessly. In certain embodiments, the antenna 510 is separate from the network node 500 and connectable to the network node 500 through an interface or port.

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

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

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

Figure 6 is a block diagram of a host 600, which may be an embodiment of the host 316 of Figure 3, in accordance with various aspects described herein. As used herein, the host 600 may be or comprise various combinations hardware and/or software, including a standalone server, a blade server, a cloud-implemented server, a distributed server, a virtual machine, container, or processing resources in a server farm. The host 600 may provide one or more services to one or more UEs.

The host 600 includes processing circuitry 602 that is operatively coupled via a bus 604 to an input/output interface 606, a network interface 608, a power source 610, and a memory 612. Other components may be included in other embodiments. Features of these components may be substantially similar to those described with respect to the devices of previous figures, such as Figures 4 and 5, such that the descriptions thereof are generally applicable to the corresponding components of host 600. The memory 612 may include one or more computer programs including one or more host application programs 614 and data 616, which may include user data, e.g., data generated by a UE for the host 600 or data generated by the host 600 for a UE. Embodiments of the host 600 may utilize only a subset or all of the components shown. The host application programs 614 may be implemented in a container-based architecture and may provide support for video codecs (e.g., Versatile Video Coding (WC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), MPEG, VP9) and audio codecs (e.g., FLAG, Advanced Audio Coding (AAC), MPEG, G.711), including transcoding for multiple different classes, types, or implementations of UEs (e.g., handsets, desktop computers, wearable display systems, heads-up display systems). The host application programs 614 may also provide for user authentication and licensing checks and may periodically report health, routes, and content availability to a central node, such as a device in or on the edge of a core network. Accordingly, the host 600 may select and/or indicate a different host for over-the-top services for a UE. The host application programs 614 may support various protocols, such as the HTTP Live Streaming (HLS) protocol, Real-Time Messaging Protocol (RTMP), Real-Time Streaming Protocol (RTSP), Dynamic Adaptive Streaming over HTTP (MPEG-DASH), etc.

Figure 7 is a block diagram illustrating a virtualization environment 700 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 700 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized. In some embodiments, the virtualization environment 700 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated by a Service Management and Orchestration Framework via an O-2 interface.

Applications 702 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment Q400 to implement some of the features, functions, and/or benefits of some of the embodiments disclosed herein.

Hardware 704 includes processing circuitry, memory that stores software and/or instructions executable by hardware processing circuitry, and/or other hardware devices as described herein, such as a network interface, input/output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 706 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 708a and 708b (one or more of which may be generally referred to as VMs 708), and/or perform any of the functions, features and/or benefits described in relation with some embodiments described herein. The virtualization layer 706 may present a virtual operating platform that appears like networking hardware to the VMs 708.

The VMs 708 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 706. Different embodiments of the instance of a virtual appliance 702 may be implemented on one or more of VMs 708, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.

In the context of NFV, a VM 708 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs 708, and that part of hardware 704 that executes that VM, be it hardware dedicated to that VM and/or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 708 on top of the hardware 704 and corresponds to the application 702.

Hardware 704 may be implemented in a standalone network node with generic or specific components. Hardware 704 may implement some functions via virtualization. Alternatively, hardware 704 may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 710, which, among others, oversees lifecycle management of applications 702. In some embodiments, hardware 704 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of a control system 712 which may alternatively be used for communication between hardware nodes and radio units.

Figure 8 shows a communication diagram of a host 802 communicating via a network node 804 with a UE 806 over a partially wireless connection in accordance with some embodiments. Example implementations, in accordance with various embodiments, of the UE (such as a UE 312a of Figure 3 and/or UE 400 of Figure 4), network node (such as network node 310a of Figure 3 and/or network node 500 of Figure 5), and host (such as host 316 of Figure 3 and/or host 600 of Figure 6) discussed in the preceding paragraphs will now be described with reference to Figure 8.

Like host 600, embodiments of host 802 include hardware, such as a communication interface, processing circuitry, and memory. The host 802 also includes software, which is stored in or accessible by the host 802 and executable by the processing circuitry. The software includes a host application that may be operable to provide a service to a remote user, such as the UE 806 connecting via an over-the-top (OTT) connection 850 extending between the UE 806 and host 802. In providing the service to the remote user, a host application may provide user data which is transmitted using the OTT connection 850.

The network node 804 includes hardware enabling it to communicate with the host 802 and UE 806. The connection 860 may be direct or pass through a core network (like core network 306 of Figure 3) and/or one or more other intermediate networks, such as one or more public, private, or hosted networks. For example, an intermediate network may be a backbone network or the Internet.

The UE 806 includes hardware and software, which is stored in or accessible by UE 806 and executable by the UE’s processing circuitry. The software includes a client application, such as a web browser or operator-specific “app” that may be operable to provide a service to a human or non-human user via UE 806 with the support of the host 802. In the host 802, an executing host application may communicate with the executing client application via the OTT connection 850 terminating at the UE 806 and host 802. In providing the service to the user, the UE's client application may receive request data from the host's host application and provide user data in response to the request data. The OTT connection 850 may transfer both the request data and the user data. The UE's client application may interact with the user to generate the user data that it provides to the host application through the OTT connection 850. The OTT connection 850 may extend via a connection 860 between the host 802 and the network node 804 and via a wireless connection 870 between the network node 804 and the UE 806 to provide the connection between the host 802 and the UE 806. The connection 860 and wireless connection 870, over which the OTT connection 850 may be provided, have been drawn abstractly to illustrate the communication between the host 802 and the UE 806 via the network node 804, without explicit reference to any intermediary devices and the precise routing of messages via these devices.

As an example of transmitting data via the OTT connection 850, in step 808, the host 802 provides user data, which may be performed by executing a host application. In some embodiments, the user data is associated with a particular human user interacting with the UE 806. In other embodiments, the user data is associated with a UE 806 that shares data with the host 802 without explicit human interaction. In step 810, the host 802 initiates a transmission carrying the user data towards the UE 806. The host 802 may initiate the transmission responsive to a request transmitted by the UE 806. The request may be caused by human interaction with the UE 806 or by operation of the client application executing on the UE 806. The transmission may pass via the network node 804, in accordance with the teachings of the embodiments described throughout this disclosure. Accordingly, in step 812, the network node 804 transmits to the UE 806 the user data that was carried in the transmission that the host 802 initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In step 814, the UE 806 receives the user data carried in the transmission, which may be performed by a client application executed on the UE 806 associated with the host application executed by the host 802.

In some examples, the UE 806 executes a client application which provides user data to the host 802. The user data may be provided in reaction or response to the data received from the host 802. Accordingly, in step 816, the UE 806 may provide user data, which may be performed by executing the client application. In providing the user data, the client application may further consider user input received from the user via an input/output interface of the UE 806. Regardless of the specific manner in which the user data was provided, the UE 806 initiates, in step 818, transmission of the user data towards the host 802 via the network node 804. In step 820, in accordance with the teachings of the embodiments described throughout this disclosure, the network node 804 receives user data from the UE 806 and initiates transmission of the received user data towards the host 802. In step 822, the host 802 receives the user data carried in the transmission initiated by the UE 806. One or more of the various embodiments improve the performance of OTT services provided to the UE 806 using the OTT connection 850, in which the wireless connection 870 forms the last segment. More precisely, the teachings of these embodiments may improve the wireless communication after a planned cell outage and thereby provide benefits such as reducing the amount of signaling when a planned cell outage occurs leading to energy savings at both the network and UEs.

In an example scenario, factory status information may be collected and analyzed by the host 802. As another example, the host 802 may process audio and video data which may have been retrieved from a UE for use in creating maps. As another example, the host 802 may collect and analyze real-time data to assist in controlling vehicle congestion (e.g., controlling traffic lights). As another example, the host 802 may store surveillance video uploaded by a UE. As another example, the host 802 may store or control access to media content such as video, audio, VR or AR which it can broadcast, multicast or unicast to UEs. As other examples, the host 802 may be used for energy pricing, remote control of nontime critical electrical load to balance power generation needs, location services, presentation services (such as compiling diagrams etc. from data collected from remote devices), or any other function of collecting, retrieving, storing, analyzing and/or transmitting data.

In some examples, 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 850 between the host 802 and UE 806, in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring the OTT connection may be implemented in software and hardware of the host 802 and/or UE 806. In some embodiments, sensors (not shown) may be deployed in or in association with other devices through which the OTT connection 850 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 may compute or estimate the monitored quantities. The reconfiguring of the OTT connection 850 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not directly alter the operation of the network node 804. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling that facilitates measurements of throughput, propagation times, latency and the like, by the host 802. The measurements may be implemented in that software causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection 850 while monitoring propagation times, errors, etc.

Although the computing devices described herein (e.g., UEs, network nodes, hosts) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and/or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and/or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and/or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

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

Claims

1. A method for improving wireless communication after a planned cell outage in a wireless network comprising a serving Radio Node, RN, a neighboring RN, a first cell belonging to the serving RN that is serving a User Equipment, UE, and a second cell belonging to the serving RN or the neighboring RN; wherein the method is performed by the UE and comprises:

• receiving a message from the first cell comprising a period of outage, and

• in response to a radio connection loss due to the planned cell outage, deciding, based on at least a UE condition, whether to connect to the second cell, or to disconnect from the first cell during the period of outage and reconnect to the first cell after the planned outage.

2. The method of claim 1 , further comprises obtaining the UE condition from at least one of the following:

• the first cell before the planned cell outage,

• the second cell before the planned cell outage,

• the first cell after the planned cell outage,

• the second cell after the planned cell outage,

• the UE before the planned cell outage, and/or

• the UE after the planned cell outage.

3. The method of any of the previous claims, wherein the UE condition indicates at least UE context information, deployment information, UE geolocation information and/or UE device information.

4. The method of any of the previous claims, wherein the UE condition comprises at least one of the following:

• type of Radio Access Technology, RAT, of the first and/or second cell,

• location area, such as Tracking Area Code, TAC, of the first and/or second cell,

• distance between the UE and the first and/or second cell,

• Timing Advance, TA,

• RRC radio measurement measured by the UE,

• type of the communication running on the UE,

• UE traffic predictions, and/or

• UE battery level.

5. The method of claim 4, wherein the RRC radio measurement comprises at least one of the following values: Reference Signal Received Power, RSRP,; Received Signal Strength Indicator, RSSI, or Reference Signal Received Quality, RSRQ,.

6. The method of claim 4 or 5, wherein the distance between the UE and the first or second cell can be estimated from the RRC radio measurement or from the TA.

7. The method of any of the previous claims, wherein the method further comprises storing the UE condition.

8. The method of any of the previous claims, wherein deciding further comprises comparing UE condition to each other. The method of any claim 1-8, wherein deciding to connect to the second cell comprise meeting at least one of the following UE conditions:

• that the first and second cell are on the same type of RAT and each RAT is configured with the same location area,

• that at least one UE radio measurement value from the second cell before or after outage indicates that the UE is getting closer to the second cell,

• that the TA of the UE is increasing, and/or

• that the type of communication running on the UE could not support a short break. The method of any claim 1-8, wherein deciding to disconnect from the first cell during the period of outage and reconnect to the first cell after the planned outage comprise meeting at least one of the following UE conditions:

• that the first and second cell are on a different RAT,

• that the first and second cell are on the same type of RAT and each RAT is configured with a different location area,

• that at least one UE radio measurement value from the second cell before or after outage indicates that the UE is staying in, or is getting closer to, the first cell,

• that the TA of the UE is stable or decreasing, and/or

• that the type of communication running on the UE could support a short break. The method of claims 9-10, wherein if the period of outage is larger than a predetermined value, the UE directly decides to connect to the second cell. The method of any claim 1 , 8, 9 or 11 , when the UE decides to connect to the second cell, the method further comprises:

• if the UE is in RRC_CONNECTED state, establishing a new call setup with the second cell, and

• if the UE is in INACTIVE state or in RRCJDLE state, triggering a cell reselection procedure,

• wherein the cell reselection may be followed by a RNA update for UE in INACTIVE state or by a tracking area update procedure for the UE in RRCJDLE state. The method of any claim 1 , 8, or 10, when the UE decides to disconnect from the first cell during the period of outage and reconnect to the first cell after the planned outage, the method further comprises:

• losing radio coverage from the first cell,

• waiting camped on the second cell without triggering any signaling procedure on the second cell for period of outage and

• reconnecting to the first cell by triggering a call reestablishment for a UE in RRC_CONNECTED state or a cell reselection to the first cell for a UE in RRCJDLE state or in INACTIVE state. A method for improving wireless communication after a planned cell outage in a wireless network comprising a serving Radio Node, RN, a neighboring RN, a first cell belonging to the serving RN that is serving a User Equipment, UE, and a second cell belonging to the serving RN or the neighboring RN; wherein the method is performed by the serving RN and comprises: • in responsive to determining a planned cell outage of the first cell, holding a UE context of the UE,

• obtaining a period of outage, and

• sending a message to the UE comprising a period of outage. The method of claim 14, wherein obtaining the period of outage comprises:

• previously to the planned outage, measuring, estimating or simulating the period between the first cell going into outage and the recovering radio coverage of the cell. The method of claim 14-15, further comprising requesting to the UE to store the UE conditions. The method of any of the previous claims, wherein sending a message to the UE comprising a period of outage comprises:

• broadcasting the period of outage to the UE in the first cell via a System Information Block, SIB, message, or

• unicasting the period of outage to the UE in the first cell via a RRC message. The method of any claim 14-17, if the UE has decided to connect to the second cell, the method further comprises:

• releasing the UE Context of the UE on the first cell. The method of any claim 14-17, if the UE has decided to disconnect from the first cell during the period of outage and reconnect to the first cell after the planned outage, the method further comprises:

• after the period of outage, reconnecting the UE to the first cell by triggering a call reestablishment for a UE in RRC_CONNECTED state or a cell reselection procedure for a UE in RRCJDLE state or in INACTIVE state. The method of any of the previous claims, wherein the decision to trigger the outage is taken manually by the operator staff or autonomously by the wireless network using an auto-healing tool or a Self-Organizing Networks, SON, procedure. A User Equipment, UE, for improving wireless communication after a planned cell outage in a wireless network comprising a serving Radio Node, RN, a neighboring RN, a first cell belonging to the serving RN that is serving the UE, and a second cell belonging to the serving RN or the neighboring RN; wherein the UE comprises processing circuitry configured to perform any of the following steps:

• receiving a message from the first cell comprising a period of outage, and

• in response to a radio connection loss due to the planned cell outage, deciding, based on at least a UE condition, whether to connect to the second cell, or to disconnect from the first cell during the period of outage and reconnect to the first cell after the planned outage. The UE according to claim 21 , wherein the processing circuitry is further configured to perform any of the any of claims 2 to 13. A serving Radio Node, RN, for improving wireless communication after a planned cell outage in a wireless network comprising the serving Radio Node, RN, a neighboring RN, a first cell belonging to the serving RN that is serving a User Equipment, UE, and a second cell belonging to the serving RN or the neighboring RN, the network node comprising processing circuitry configured to perform any of the following steps:

• in responsive to determining a planned cell outage of the first cell, holding a UE context of the UE,

• obtaining a period of outage, and

• sending a message to the UE comprising a period of outage. The RN according to claim 23, wherein the processing circuitry is further configured to perform any of the any of claims 15 to 20. A method for improving wireless communication after a planned cell outage in a wireless network comprising a serving Radio Node, RN, a neighboring RN, a first cell belonging to the serving RN that is serving a User Equipment, UE, and a second cell belonging to the serving RN or the neighboring RN; wherein the method is performed by the serving RN and in response to an incoming planned cell outage of the first cell, comprises:

• deciding, based on at least a UE condition, whether to trigger a handover procedure on the UE to connect to it the second cell before cell outage, or to disconnect the UE for a period of outage and reconnect it to the first cell after the planned outage. The method of claim25, further comprises storing a UE context of the UE. The method of any of the previous claims, further comprises forwarding the UE context of the UE to neighboring RN. The method of any of the previous claims, wherein the method further comprises obtaining the period of outage and sending a message to the UE comprising the period of outage when the decision is disconnecting the UE for a period of outage and reconnect it to the first cell after the planned outage. The method of any of the previous claims, further comprises sending a request to the UE for a RRC radio measurement report. The method of any of the previous claims, further comprises receiving from the UE the RRC radio measurement report. The method of any of the previous claims, further comprises obtaining the UE condition from at least one of the following:

• the first cell before the planned cell outage,

• the second cell before the planned cell outage,

• the first cell after the planned cell outage,

• the second cell after the planned cell outage,

• the UE before the planned cell outage, and/or

• the UE after the planned cell outage. The method of any of the previous claims, wherein the UE condition comprises at least one of the following:

• type of Radio Access Technology, RAT, of the first and/or second cell,

• location area, such as Tracking Area Code, TAC, of the first and/or second cell, • distance between the UE and the first and/or second cell,

• Timing Advance (TA),

• RRC radio measurement measured by the UE,

• type of the communication running on the UE,

• UE traffic predictions, and/or

• UE battery level. The method of any of claims 29-32, wherein the RRC radio measurement report comprises at least one of the following values: Reference Signal Received Power, ,RSRP,, Received Signal Strength Indicator, RSSI,; or Reference Signal Received Quality (RSRQ). The method of claim 29-33, wherein the distance between the UE and the first and/or second cell can be estimated from the RRC radio measurements report values or form the TA. The method of any of the previous claims, deciding whether to trigger a handover procedure on the UE to connect to it to the second cell before cell outage, or to disconnect the UE for a period of outage and reconnect it to the first cell after the planned outage comprises:

• estimating the UE direction based on the one or more UE conditions. The method of claim 35, wherein estimating the UE direction is based on RRC radio measurement or on TA information. The method of any claim 33-35, wherein deciding whether to trigger a handover procedure on the UE to connect to the UE to the second cell before cell outage comprises:

• estimating that the UE is moving towards the second cell. The method of claim 37 wherein the UE is in RRC_CONNECTED state. The method of any claim 25-35, wherein deciding to disconnect the UE for a period of outage and reconnect it to the first cell after the planned outage comprises:

• estimating that the UE is stationary within the first cell, or it is moving towards the first cell. The method of claim 39, wherein the UE is in connected or RRCJDLE state. The method of claims 25, 35, or 37, wherein when the decision is to trigger a handover procedure to connect the UE to the second cell, the method further comprises releasing a UE context of the UE. The method of claims 25, 35 or 39, wherein when the decision is to disconnect the UE for a period of outage and reconnect it to the first cell after the planned outage, the method further comprises:

• losing radio coverage from the first cell,

• waiting camped on the second cell without triggering any signaling procedure for period of outage and

• reconnecting to the first cell by triggering a call reestablishment or cell reselection procedure for the UE. The method of any of the previous claims, wherein the decision to trigger the outage is taken manually by the operator staff or autonomously by the wireless network using an auto-healing tool or a Self-Organizing Networks, SON, procedure. The method any of the previous claims, wherein when the period of outage is larger than a predetermined value and the UE is in connected, the serving RN directly decides to connect the UE to the second cell and triggers the handover procedure on the UE to be connected to the second cell before the cell outage. A method for improving wireless communication after a planned cell outage in a wireless network comprising a serving Radio Node, RN, a neighboring RN, a first cell belonging to the serving RN that is serving a User Equipment, UE, and a second cell belonging to the serving RN or the neighboring RN; wherein the method is performed by the UE and in response to an incoming planned cell outage of the first cell, the method comprises:

• connecting from the first cell to the second cell by a handover procedure before cell outage, or

• disconnecting for a period of outage and reconnecting to the first cell after the planned outage. The method of claim 45, wherein the method further comprises receiving a period of outage from the first node when the decision is to disconnect the UE for a period of outage and reconnect it to the first cell after the planned outage. The method of any of the previous claims, further comprises receiving a request from the first cell to perform RRC radio measurement report. The method of any claim 45 to 47, further comprises sending the RRC radio measurement report to the first cell. The method of any claim 45 to 48, wherein when the decision is to trigger a handover procedure to connect the UE to the second cell, the method further comprises:

• triggering the handover procedure before the cell outage. The method of any claim 45 to 48, wherein when the decision is to wait for the period of outage and reconnect the UE to the first cell, the method further comprises:

• losing radio coverage from the first cell,

• waiting camped on the second cell without triggering any signaling procedure for the period of outage, and

• reconnecting to the first cell after the planned outage by a call reestablishment or cell reselection procedure. A Radio Node, RN, for improving wireless communication after a planned cell outage in a wireless network comprising a serving Radio Node, RN, a neighboring RN, a first cell belonging to the serving RN that is serving a User Equipment, UE, and a second cell belonging to the serving RN or the neighboring RN, the network node comprising processing circuitry configured to perform any of the following steps in response to an incoming planned cell outage of the first cell:

• deciding, based on at least a UE condition, whether to trigger a handover procedure on the UE to connect to it the second cell before cell outage, or to disconnect the UE for a period of outage and reconnect it to the first cell after the planned outage. The RN according to claim 51 , wherein the processing circuitry is further configured to perform any of the any of claims 26 to 44. A User Equipment, UE, for improving wireless communication after a planned cell outage in a wireless network comprising a serving Radio Node, RN, a neighboring RN, a first cell belonging to the serving RN that is serving the UE, and a second cell belonging to the serving RN or the neighboring RN; wherein the UE comprises processing circuitry configured to perform any of the following steps:

• disconnecting for a period of outage and reconnecting to the first cell after the planned outage. The UE according to claim 53, wherein the processing circuitry is further configured to perform any of the any of the claims 46 to 50.