HANDOVER HANDLING ACCORDING TO TYPE OF UE COMMUNICATION IN CASE OF NETWORK OVERLOAD

TECHNICAL FIELD

Embodiments herein relate generally to a first radio access node, a method performed by the first radio access node, a second radio access node and a method performed by the radio access node. More particularly the embodiments herein relate to handling handover of User Equipment (UE) communication of certain types during overload in a

communications network.

BACKGROUND

In every communications network, wired and wireless, the operator takes different measures, e.g. add more hardware or increase software capacity, e.g. by buying new licenses, etc., in order to prevent congestion and make its subscribers satisfied. However, whatever precautions are made there are always few occasions where the network goes congested due to unexpected events. In one example, an event may be that existing hardware or software on one or more equipment may go faulty. In another example, a natural catastrophe or a criminal act might also make an area experience high congestion. In a wireless communications network, different methods have been used so far to deal with network congestion especially on the radio node side where congestion is most probable to occur because the radio nodes depend on a predefined limited bandwidth on the air interface, e.g. 5 MHz in 3G, 20 MHz in 4G and 100 MHz in 5G. Actually, in Fourth Generation (4G) standards, in particular in the Third Generation Partnership Project (3GPP) Technical Specification (TS) 36.413 V15.0.0 (2017-12), whenever the core node, for example the Mobility Management Entity (MME), becomes congested it starts sending a, overload notification to some radio nodes ordering them to avoid processing some types of call service, e.g. non-delay sensitive call. Moreover, in latest Fifth Generation (5G) standards discussion it seems that the congestion on the 5G core network side will follow also the same procedure as in 4G, that is a core node, e.g. the Access and Mobility Function (AMF) in case of 5G, will send to the radio nodes similar overload notification to the ones being sent by the 4G network. Note that MME or AMF congestion does not necessarily means congestion only on the node itself but the MME and/or AMF will, if they find that another core Node like e.g. the Serving Gateway (SGW) is congested, themselves behave like being congested and send the Overload Start message to the radio access node, e.g. the evolved NodeB (eNodeB, eNB) or the gNB.

Some problems with the current technology will now be described:

Overload Start message notification received by one eNB, e.g. eNB2, is not dispatched to other neighboring eNBs

When any eNB, e.g. eNB2, receives the Overload Start message from the MME, with some type of services, e.g. servicel , to be rejected, then with the current technology, none of the neighbors of the eNB2 is informed about the change at eNB2. As a

consequence, they continue to proceed with the handover of servicel calls towards the eNB2, which will be rejected. In addition, later when the congestion is ceased and the eNB2 receives an Overload Stop message from the MME, also no notification is sent towards neighbors of the eNB2 to inform them about this latest change.

Source eNB, eNB1, does not take any action, e.g. stop handover to eNB2, unless a certain number of handover failures towards target eNB2 is reached

Current methods for handling handover failures prevent handover towards a particular target eNB in case the number of handover failures towards that target eNB exceeds a predefined threshold. In such methods, the handover procedure is performed in the following two steps:

• Step 1 : The UE moves from the eNB1 towards the eNB2 and performs a call

service listed in the Overload Start message, e.g. servicel . The UE sends a Radio Resource Control (RRC) measurement report containing the handover event, e.g. event A3 for intra frequency handover.

• Step 2: The eNB1 will trigger the handover procedure of the call of type service 1 towards the eNB2. As the eNB2 has received an Overload Start message, that call will be rejected. One problem is that until the handover failure threshold is exceeded, such handover procedure failure will generate unnecessary signaling and processing. Moreover, it will delay the handover towards a second-best cell. If handover towards the best cell, e.g. the eNB2, fails, the source eNB1 will try to handover the UE towards a second-best cell, e.g. celU of another eNB, e.g. eNB3.

Note that when the MME is congested and it starts sending the Overload Start message to the eNB, the number of affected eNB might be huge, depending on each operator. As a result the amount of waste of signaling and processing generated during the handover failure procedures by all affected UEs and eNBs, will be huge. That is why it is necessary to try to avoid all this waste. Figure 1 illustrates an example method where the MME is congested and sends an S1 overload start message to the target eNB. The overload start message comprises an indication of that it should reject incoming low priority calls.

In 3GPP TS 36.413 V15.0.0 (2017-12), when the core, e.g. the MME, is congested it sends a S1 AP overload start message to the eNB which might contain the rejection of any of below call service types extracted from 3GPP 36.413:

• "reject RRC connection establishments for non-emergency mobile originated data transfer", i.e. reject traffic corresponding to RRC cause "mo-data", "mo-VoiceCall" and "delayTolerantAccess" in TS 36.331.

· "reject RRC connection establishments for signalling", i.e. reject traffic

corresponding to RRC cause "mo-data", "mo-signalling", "mo-VoiceCall" and "delayTolerantAccess" in TS 36.331.

• "only permit RRC connection establishments for emergency sessions and mobile terminated services", i.e. only permit traffic corresponding to RRC cause

"emergency" and "mt-Access" in TS 36.331.

• "only permit RRC connection establishments for high priority sessions and mobile terminated services", i.e., only permit traffic corresponding to RRC cause

"highPriorityAccess" and "mt-Access" in TS 36.331.

• "reject only RRC connection establishment for delay tolerant access", i.e. only reject traffic corresponding to RRC cause "delayTolerantAccess" in TS 36.331 ,

• "only permit RRC connection establishments for high priority sessions, exception reporting and mobile terminated services", i.e. only permit traffic corresponding to RRC cause "highPriorityAccess",“mo-ExceptionData” and "mt-Access" in TS 36.331.

When the MME is congested it sends an S1AP overload start message to the eNB2, then even though the eNB2 is not congested, the eNB2 will start rejecting some types of calls e.g. as stated in the S1AP overload start message. The S1AP overload start message may state for example“reject any new incoming calls which are not emergency nor terminated call”. The statement that the eNB2 is not congested comprises that there is no congestion on the air interface nor on the eNB equipment, nor on the eNB backbone transmission etc. The eNB equipment refers to the hardware and/or software of the eNB. Such rejection includes incoming handover calls from a neighboring eNB, e.g. eNB1. As a result, when the UE is performing any type of calls mentioned in the overload start message and is moving from celM of eNB1 towards an affected cell2 of eNB2, a handover is triggered and that handover will be rejected.

Therefore, there is a need to at least mitigate or solve the above issue.

SUMMARY

An objective of embodiments herein is therefore to obviate at least one of the above disadvantages and to provide improved handling handover of UE communication.

According to a first aspect, the object is achieved by a method performed by a second radio access node for handling handover of UE communication of certain types during overload in a communications network. The second radio access node detects overload in at least a part of the network. The second radio access node provides overload information to at least one first radio access node which is a neighbor node to the second radio access node. The overload information indicates that handover of the UE

communication of at least one type to the second radio access node should be prevented due to the overload.

According to a second aspect, the object is achieved by a method performed by a first radio access node for handling handover of UE communication of certain types during overload in a communications network. The first radio access node obtains overload information from a second radio access node which is a neighbor node to the first radio access node. The overload information indicates that handover of UE communication of at least one type with the second radio access node should be prevented due to the overload. The first radio access node handles handover of the UE communication of the at least one type according to the obtained overload information.

According to a third aspect, the object is achieved by a second radio access node for handling handover of UE communication of certain types during overload in a communications network. The second radio access node is adapted to detect overload in at least a part of the network. The second radio access node is adapted to provide overload information to at least one first radio access node which is a neighbor node to the second radio access node. The overload information indicates that handover of the UE communication of at least one type to the second radio access node should be prevented due to the overload.

According to a fourth aspect, the object is achieved by a first radio access node for handling handover of UE communication of certain types during overload in a

communications network. The first radio access node is adapted to obtain overload information from a second radio access node which is a neighbor node to the first radio access node. The overload information indicates that handover of UE communication of at least one type with the second radio access node should be prevented due to the overload. The first radio access node is adapted to handle handover of the UE

communication of the at least one type according to the obtained overload information.

Since the second radio access node detects overload in at least a part of the network, then the first radio access node is immediately communicated about such overload and that handover of communication of a certain type to the second radio access node should be prevented. This way, the first radio access network stops forwarding any calls of a certain type towards the second radio access node. Consequently, the handling of handover of UE communication is improved in that a handover procedure towards an overloaded radio access node is prevented.

Embodiments herein afford many advantages, of which a non-exhaustive list of examples follows:

An advantage of the embodiments herein is that preventing a handover procedure that is known in advance to fail because of congestion on the second access node will provide a quicker handover towards a second-best cell whenever the handover towards a primary cell is to fail.

Another advantage of the embodiments herein is that they provide less signaling and processing since the handover procedure is prevented from being triggered on the second access node in the first place whenever the first access node receives the overload information.

A further advantage of the embodiments herein is that unnecessary signalling is avoided and quicker handover on the secondary cell is enabled.

The embodiments herein are not limited to the features and advantages mentioned above. A person skilled in the art will recognize additional features and advantages upon reading the following detailed description.

BRIEF DESCRIPTION OF THE DRAWINGS

The embodiments herein will now be further described in more detail in the following detailed description by reference to the appended drawings illustrating the embodiments and in which:

Fig. 1 is a schematic diagram illustrating a prior art overload procedure.

Fig. 2 is a schematic block diagram illustrating an example of a communications network.

Fig. 3 is a flow chart illustrating an embodiment of a method.

Fig. 4 is a schematic diagram illustrating an overload procedure for MME

congestion and where the X2 link exists.

Fig. 5 is a schematic diagram illustrating an overload procedure for MME

congestion and where the X2 link does not exists

Fig. 6 is a schematic diagram illustrating an overload procedure for MME

congestion where the UE does not send any measurement report that contains a handover event with congestion.

Fig. 7 is a schematic diagram illustrating an overload procedure where the UE does not send any measurement report that contains a handover event when the congestion has ceased.

Fig. 8 is a schematic diagram illustrating an overload procedure for MME

congestion where the UE sends a measurement report that contains a handover event. Fig. 9 is a schematic diagram illustrating an overload procedure for network slice congestion where the UE does not send any measurement report that contains a handover event.

Fig. 10 is a schematic diagram illustrating an overload procedure for network slice congestion where the UE sends a measurement report that contains a handover event.

Fig. 1 1 is a flow chart illustrating embodiments of a method performed by the

second radio access node.

Fig. 12 is a schematic block diagram illustrating embodiments of a second radio access node.

Fig. 13 is a flow chart illustrating embodiments of a method performed by the first radio access node.

Fig. 14 is a schematic block diagram illustrating embodiments of a first radio access node.

The drawings are not necessarily to scale and the dimensions of certain features may have been exaggerated for the sake of clarity. Emphasis is instead placed upon illustrating the principle of the embodiments herein.

DETAILED DESCRIPTION

Instead of letting, as in prior art the handover procedure to be triggered at a first radio access node, e.g. eNB1 , towards a second access node, e.g. eNB2, to be later rejected by a target second access node that has received the overload start message, the embodiments herein prevents the handover procedure from being triggered on the first access node in the first place (immediately) whenever the second radio access node, receives the detects the overload e.g. by receiving an overload start message. The benefit is that unnecessary signaling and processing are spared.

In one embodiment whenever the second radio access node detects overload by e.g. receiving an Overload Start message from a MME with a reject of a specific type of call, e.g. call servicel , then the first radio access node is immediately communicated about such event, e.g. via a notification denoted notif_Overload_Start. Consequently, the first radio access node stops forwarding any calls of type servicel towards the second radio access node. Later when the network congestion is ceased and the second radio access node detects the ceased congestion, e.g. by receiving an Overload Stop message, the second radio access node will again send another notification to the first radio access node to allow handing over any call of type servicel .

In another embodiment, when the first radio access node obtains overload information, e.g. by receiving a notif_Overload_Start from the second radio access node, it prevents, in a first place, the handover of any call of type servicel towards the second radio access node which would have been unsuccessful. There may be two different options to do that.

1 ) The prevention could be performed by automatically adjusting the value of the handover event, e.g. event A3, in a way that the handover towards a second cell on the second radio access node is never triggered. With such option, the UE does not send in the first place a RRC measurement report to the first radio access node indicating radio measurement about the target congested second radio access node.

2) The UE under the first radio access node still sends its measurement report asking for a handover towards a cell in the second radio access node, but the first radio access node will not proceed with that requested handover. Instead it will proceed with the handover towards a second-best cell of cell2, cell3 of another eNB, the third radio access node.

The term“measurement report” used above refers to a transfer of measurement results from the UE 105 to a radio access node. The measurements are performed by the UE 105.

Above, a brief description of the embodiments herein was provided. Before continuing to a more detail description, an example of a communications network will be described.

Figure 2 illustrates a communications network in which embodiments herein may be implemented. The communications network may in some embodiments apply to one or more access technologies such as for example 3G, 4G, 5G or any other 3GPP radio access technology, or other suitable access technologies.

Figure 2 illustrates a network part 100 which may be for example a Core Network (CN) node or a network slice, depending on the technology and terminology used. An example of a CN node may be a Mobility Management Entity (MME), a Serving General Packet Radio Services Support Node (SGSN), a Gateway General Packet Radio Services

Support Node (GGSN), a Serving Gateway (SGW), a Packet Data Network Gateway

(PGW), a network function, a gateway, an Access and Mobility Management Function

(AMF), a Session Management Function (SMF), a User Plane Function (UPF).

The term network slice mentioned above will now be shortly described. Network slicing is used in e.g. 5G and allows a deployed network to be subdivided into multiple separate sets of network resources, i.e. applied end-to-end a network slice may be used to provide network resources dedicated for a specific network service.

The communications network comprises a first radio access node 101 , a second radio access node 102 and a third radio access node 103. Table 1 below provides an overview of some example names of the radio access nodes 101 , 102, 103: Table 1

Each of the first, second and second radio access nodes 101 , 102, 103 may be a Base Station Controller (BSC), a RNC, an eNB or a gNB. The first radio access node 101 covers a first cell 101a, the second radio access node 102 covers a second cell 102a and the third radio access node 103 covers a third cell 103a. The cells 101 a, 102a, 103a are neighbor cells. T able 2 below provides an overview of some example names of the cells 101 a, 102a, 103a: Table 2

A UE 105 may be located in the first cell 101 a and adapted to be served by and to communicate with the first radio access node 101. Note that the UE 105 may be adapted to move and therefore may be served by any of the other radio access nodes illustrated in figure 2.

The UE 105 may be a device by which a subscriber may access services offered by an operator’s network and services outside operator’s network to which the operators radio access network and core network provide access, e.g. access to the Internet. The UE 105 may be any device, mobile or stationary, enabled to communicate in the communications network, for instance but not limited to e.g. user equipment, mobile phone, smart phone, sensors, meters, vehicles, household appliances, medical appliances, media players, cameras, Machine to Machine (M2M) device, Device to Device (D2D) device, Internet of Things (loT) device or any type of consumer electronic, for instance but not limited to television, radio, lighting arrangements, tablet computer, laptop or Personal Computer

(PC). The UE 105 may be portable, pocket storable, hand held, computer comprised, or vehicle mounted devices, enabled to communicate voice and/or data, via the radio access network, with another entity, such as another UE or a server.

Every node in the network, in our figure 2 this applies to first radio access node 101 , second radio access node 102 and third radio access node 103, is connected to an Operation Support System (OSS) 110. The OSS 1 10 provides among others the following services:

In a direction from the nodes to OSS 1 10: All nodes in the network may send information either in real time like node alarms, or periodically like Key Performance Indicator (KPI) Performance Report reports, to the OSS 1 10 where either a monitoring staff or automatic algorithms like auto-healing algorithms and Self-Organizing Network (SON), trigger an action in order to solve the effect of the alarms or KPI report, or at least minimize their impact on the network.

In the opposite direction from the OSS 1 10 to nodes: The operator may use the OSS 110 in order to update the software of the nodes also for updating the configuration of the network, e.g. change a the value of one parameter on one or many nodes or add/remove a new hardware or cell to a node or add/remove a new node to the network etc. As all nodes may be connected to the OSS 110, the may be used herein in order to forward a notification from one node to another node as an alternative solution to using the link between the nodes, e.g. X2 in 4G or Xn in 5G.

It should be noted that the communication links in the communications network may be of any suitable kind including either a wired or wireless link. The link may use any suitable protocol depending on type and level of layer (e.g. as indicated by the OSI model) as understood by the person skilled in the art.

The method for handling handover of UE communication of certain types during overload in a communications network, according to some embodiments will now be described with reference to the flowchart depicted in Figure 3. The method comprises at least one of the following steps, which steps may as well be carried out in another suitable order than described below:

Step 301

At least a part 100 of the network is overloaded. The overloaded part 100 may be e.g. a CN node or a network slice. The overloaded network part 100 may be e.g. the MME.

Step 302

In this step, it is checked whether the second radio access node 102 has detected

overload. This may also be described as questioning whether the second radio access node 102 has received an overload start message.

If the second radio access node 102 has not detected overload, indicated with“no” in figure 3, the method proceeds to step 303. If the second radio access node 102 has detected overload, indicated with“yes” in figure 3, the method proceeds to step 304.

Step 303

This step is performed if the second radio access node 102 has not detected overload in step 302. In such scenario, no action is taken.

Step 304

This step is performed if the second radio access node 102 has detected overload in step 302. In such scenario, it is checked whether a link exist between the second radio access node 102 and its neighbor nodes. The link may be e.g. an X2 link. If there is no link between them, indicated with“no” in figure 3, then the method proceeds to step 305. If there is a link between them, indicated with“yes” in figure 3, then the method proceeds to step 306.

Neighbour nodes are nodes which are adjacent to each other or nearby to each other. Similarly, neighbour cells are cells which are adjacent to each other or nearby to each other.

Step 305

This step is performed if the result of step 304 was that there is no link between the second radio access node 102 and its neighbour nodes. In such scenario, the second radio access node 102 sends a notification to the OSS 110 with overload information to be dispatched to the neighbour nodes of the second radio access node 102. This may also be described as the second radio access node 102 sends a notification to the OSS 1 10, with contents of the overload start message to be dispatched, via the OSS 110, to the neighbors of the second radio access node. The contents of the overload start message may be restricted services. After step 305 has been performed, the method may proceed to step 307.

Step 306

This step is performed if the result of step 304 was that there is a link between the second radio access node 102 and its neighbour nodes. The second radio access node 102 sends to its radio access node neighbours, e.g. the first radio access node 101 , the overload information via the existing link. This may also be described as the second radio access node 102 sends to its radio access node neighbours, e.g. the first radio access node 101 , a modified X2AP Load Information message with the contents of the overload start message. The contents of the overload start message may be the restricted services, e.g. servicel & service2.

Step 307

This step may be performed after step 306 and after step 305. Each neighbor radio access node, e.g. the first radio access node 101 , that receives the overload information may execute one of the steps 308 or 309. Steps 308 and 309 are alternative steps.

Step 308

This step may be performed instead of step 309. For every UE 105, running the restricted servicel or 2, the first radio access node 101 sends a Radio Resource Control (RRC) message containing cells id of the second radio access node 102 which has received the Overload Start message. The RRC message may be a rrcConnectionReconfiguration message. Herein, such existing RRC message is modified compared to what is described in 3GPP TS 36.331 V15.0.1 (2018-01 ) in a way to include the cell identities of the restricted second radio access node 102 in addition to a new parameter, denoted here as parameter^ Parameterl is a integer value being above a threshold to be applied on any parameter, e.g. Hyst or Ocn, that is already used in the formulas of existing handover events, so that the handover event formula is not verified at the UE 105 side and hence the UE 105 never sends a handover event to the first radio access node 101 for any cells of the second radio access node 102. The integer value when it is above than the threshold may also be referred to as a large integer value.

Step 309

This step may be performed instead of step 308. Each time the first radio access node 101 receives a handover measurement event from any UE 105 running a restricted service, the first radio access node 101 will not trigger the handover procedure towards the second radio access node 102, but rather it will trigger a handover towards a second best cell belonging to a non- restricted third radio access node 103. The restricted service may be service 1 or service 2.

More details of the method described above will now be described and using figures 4-8 where the overloaded network part 100 is a CN node, and using figures 9-10 where the overloaded part is a network slice. In figures 4-7, the overloaded network part 100 is

represented by an MME, the first radio access node 101 is represented by an eNB1 , the second radio access node 102 is represented by an eNB2 and the third radio access node 103 is represented by an eNB3. In figures 8-9, the overloaded network part 100 is a network slice, the first radio access node 101 is represented by a gNB1 , the second radio access node 102 is represented by a gNB2 and the third radio access node 103 is

represented by a gNB 3.

Informing first radio access node 101 about overload detected at second radio

access node 102

In the existing X2 Application Protocol (X2AP) specification 3GPP TS 36.423 V15.0.0

(2017-12), one eNB, e.g. the eNB2 102, could inform any other radio access node

connected to it via a link such as the X2 link, e.g. eNB1 101 about some load information, e.g. UL interference Overload Indication. Then it is up to the receiver of the load

information, e.g. the eNB1 101 , to take the appropriate action. However, in the current

X2AP specification there is no load information that takes into consideration a network overload event, e.g. that a part of the network is overloaded such as e.g. the MME. In other words when the network part 100 goes into an overload status and then sends overload information to the eNB2 102. The overload information may be in the form of a S1 AP Overload Start message which might indicate rejection of all incoming calls apart from emergency and terminated call. Then, the actually affected eNB2 102 does not send an X2AP Load Information message, 3GPP TS 36.423 V15.0.0 (2017-12), to its neighbors including the eNB1 101. This is why there is a need to translate or transform the overload information that is sent from the overloaded network part 100 to the eNB2 102 to all radio access nodes which are neighbour nodes to the eNB2 102, e.g. to translate the S1AP Overload Start message. The reason for that is to make all neighbour nodes of the eNB2 102 to take a preventative action about the new status of the eNB2 102 that is rejecting for example all incoming calls apart from emergency and terminated call.

There may be at least the following two scenarios:

1 ) A link exists between the eNB2 102 and its neighbour eNBs, e.g. the eNB1 101 , the eNB3 103 etc.

2) A link does not exist between the eNB2 102 and its neighbour nodes, e.g. the eNB1 101 , the eNB3 103 etc.

1) If the link exists

Figure 4 illustrates an example when there is a direct link between the between the eNB2 102 and its neighbour eNBs, e.g. the eNB1 101 , the eNB3 103 etc. The link may be an X2 link. The method illustrates at least one of the following steps which steps may be performed in any of the suitable order described below:

Step 401

The MME 100 which is overloaded sends information about the overload to the eNB2 102. This information may be in the form of an S1AP overload start message which indicate to reject non-emergency & non-terminated calls.

Step 402

Whenever the eNB2 102 receives the S1AP Overload Start it sends to all neighbors eNBs, a X2AP Load Information message which contains information in the Overload Start, e.g. rejection of all incoming calls apart from emergency and terminated call. Once a neighbor eNB, e.g. a eNB1 101 , receives that X2AP message, it takes necessary action to prevent handover from the eNB1 101 towards any cell of the eNB2 102 as described below.

2) If the link does not exist

Figure 5 illustrates an example when there is not any direct link between the between the eNB2 102 and its neighbour eNBs, e.g. the eNB1 101 , the eNB3 103 etc. In this figure, the eNB2 102 that receives an S1AP Overload Start message sends similar load information to all neighbor eNBs 101 , 103 via OSS notifications. The method comprises at least one of the following steps:

Step 501

The MME 100 which is overloaded sends information about the overload to the eNB2 102. This information may be in the form of a S1 AP overload start message which indicate to reject non-emergency & non-terminated calls.

Step 502

If the link does not exist between the eNB2 102 and its neighbour nodes, when the MME 100 has sent the S1AP Overload Start message to the eNB2 102, then, the eNB2 102 sends a notification to an OSS 110 with same contents as in the Overload Start message, e.g. rejection of all incoming calls apart from emergency and terminated call. Note that the entity that deals with notification in existing OSS 110 needs to be modified in a way to deal with load messages from the MME 100.

Step 503

The OSS 1 10 sends an OSS notification indicating reject non-emergency & non- terminated calls to the eNB1 101 and eNB3 103. Then when the neighbour nodes of the eNB2 102 receive that notification they take necessary action e.g. prevent handover towards the cells of the eNB2 102 as described below.

Preventing handover procedure, of some specific calls, at eNB1 whenever the eNB2 has detected overload

In LTE, the UE 105 continuously performs radio measurements of the serving cell and of the surrounding cells. The type of measurements is indicated by the eNB to the UE 105.

In one example, the UE 1015 measures the received radio power level of the serving cell and of its surroundings. The received radio power level is a unit measured in dbm and may also be referred to as also called Reference Signal Received Power (RSRP). In another example, the UE 105 measures the received radio signal quality of the serving cell and the neighbor cells. The received radio signal quality is measured in dB and may also be called Reference Signal Received Quality (RSRQ). When the UE 105 moves away from one cell, e.g. celM , towards another cell, e.g. cell2, the received signal of cell2 becomes better than the one of celM . At a certain point when the received RSRP or RSRQ or both of cell2 is/are above a predefined threshold or they are better than of celM by a certain predefined hysteresis, then the UE 105 sends a measurement event towards the radio access node of cell 1. That event consists of a RRC signalling message where the UE 105 inserts the radio entity measures RSRP or RSRQ or both of celU , cell2 and whether a predefined threshold was exceeded. There are different types of

measurements events and they may be denoted event A1 , A2, A3 etc... All these UE radio measurement events are defined in the RRC protocol in 3GPP TS 36.331 V15.0.1 (2018-01 ). For example, the UE 105 triggers an event, called e.g. event A3, when the neighbour cell becomes offset better than the primary cell (PCell). This is translated whenever the UE 105 verifies the formula (1 ) below extracted from section 5.5.4.4 in 3GPP TS 36.331 V15.0.1 (2018-01 ).

Mn + Ofn + Ocn— Hys > Mp + Ofp + Ocp + Off (1)

The parameters in the formula (1 ) are defined as follows:

• Mn is the measurement result of the neighbouring cell, not taking into account any offsets.

• Ofn is the frequency specific offset of the frequency of the neighbour cell.

• Ocn is the cell specific offset of the neighbour cell, and set to zero if not configured for the neighbour cell.

• Mp is the measurement result of the PCell/PSCell, not taking into account any offsets.

• Ofp is the frequency specific offset of the frequency of the PCell/PSCell.

• Ocp is the cell specific offset of the PCell/PSCell, and is set to zero if not

configured for the PCell/PSCell.

• Hys is the hysteresis parameter for this event.

• Off is the offset parameter for this event. Mn, Mp are expressed in dBm in case of RSRP, or in dB in case of RSRQ and RS-SINR. Ofn, Ocn, Ofp, Ocp, Hys, Off are expressed in dB.

Below is a list of some of example events:

• Event A1 : The serving becomes better than threshold

• Event A2: Serving becomes worse than threshold

• Event A3: Neighbour becomes offset better than PCell/PSCell

• Event A4: Neighbour becomes better than threshold

• Event A5: PCell / PSCell becomes worse than thresholdl and neighbour becomes better than threshold2.

• Event A6: Neighbour becomes offset better than SCell.

• Event B1 : Inter RAT neighbour becomes better than threshold.

• Event B2: PCell becomes worse than thresholdl and inter RAT neighbour

becomes better than threshold.

• Event C1 : CSI-RS resource becomes better than threshold.

• Event C2: CSI-RS resource becomes offset better than reference CSI-RS

resource.

• Event W1 : WLAN becomes better than a threshold.

• Event W2: All WLAN inside WLAN mobility set becomes worse than thresholdl and a WLAN outside WLAN mobility set becomes better than threshold2.

• Event W3: All WLAN inside WLAN mobility set becomes worse than a threshold.

• Event V1 : The channel busy ratio is above a threshold.

• Event V2: The channel busy ratio is below a threshold.

In another example, the UE 105 triggers another event, denoted A4, when the neighbour cell becomes better than threshold. This happens when the UE radio measurements on neighbor cell denoted Mn verifies below formula (2) extracted from section 5.5.4.5 in 3GPP TS 36.331 V15.0.1 (2018-01 ).

Mn + Ofn + Ocn— Hys > Thresh (2)

The parameters in the formula (2) are defined as follows:

• Mn is the measurement result of the neighbouring cell, not taking into account any offsets.

• Ofn is the frequency specific offset of the frequency of the neighbour cell. • Ocn is the cell specific offset of the neighbour cell, and set to zero if not configured for the neighbour cell.

• Hys is the hysteresis parameter for this event.

• Thresh is the threshold parameter for this event.

Mn is expressed in dBm in case of RSRP, or in dB in case of RSRQ and RS-SINR.

Ofn, Ocn, Hys are expressed in dB. Thresh is expressed in the same unit as Mn.

In the current technology and as mentioned earlier, when the radio access node receives event A3 or A4 it triggers automatically a handover procedure towards the target cell. However, the embodiments herein prevents the handover triggering towards a cell that is controlled by the radio access node that has detected overload and is rejecting some types of services. Below, two options 1 ) and 2) for handling this will be described:

Option 1) The UE 105 does not send any measurement report that contains a handover event

Figure 6 illustrates an example of a method for option 1 ) where the UE 105 does not send any RRC measurement report that contains a handover event like event A3 or A4. Figure 6 illustrates two UEs 105, UE1 and UE5. UE1 105 performs call servicel and 2. UE5 performs any call other than servicel or service 2. The method in figure 6 comprises at least one of the following steps, which steps may be performed in any suitable order than described below:

Step 601

The MME 100 in congestion sends a S1AP Overload Start message to the eNB2 102.

The overload start message may indicate to the receiver that it should reject all calls of a certain service type, e.g. servicel and service2.

Step 602

Any eNB, e.g. the eNB2 102, that has received the Overload Start message will notify, (as also shown in figure 3 and 4), all its neighbors, e.g. the eNB1 101 , about all types of call services to be rejected, for example servicel & service2.

Step 603 eNB1 101 sends, via SIB or via RRC message, to all UEs 101 with service 1 or 2, a list of affected cells and parameterl .

Step 604

For UE1 105, handover is forbidden towards the eNB2 102, but allowed towards other eNBs. An rrcConnectionRecofiguration message is sent to the UE 105 with the following information:

• All cells id of eNB2 102,

• Parameterl (OCN, Hys ...) to apply for cells of the eNB2 102.

The eNB that receives the notification in step 602, the eNB1 101 in the example shown in figure 6, may communicate to the UEs 105 in at least one of the following two ways:

1 ) The eNB1 101 selects all the communications with type servicel or service2 that are running under its first cell 101 a, and sends to all UEs 101 holding such communication, the following information: The cell identities controlled by the eNB2 102 and a new value of one parameter, e.g. parameterl , that is used in the Handover formulas (formulas (1 ) or (2) mentioned above). This could be done, as shown in figure 6, via a RRC dedicated signalling message, e.g. in

rrcConnectionReconfiguration message.

2) The eNB1 101 sends, to all UEs 101 , one RRC broadcasting System Information Block (SIB) message which contains the same contents to be sent in the first way, but in addition it will specify what are the types of services of communications running under its cell that will to be affected by this SIB message. The contents to be sent may be the cell identities controlled by the eNB2 102 and a new value of one parameter, e.g. parameterl .

Some of the differences between the two different ways may be as follows:

Suppose that we have 100 communications under the celU 101 a of the eNB1 101 and out of them 40 calls are running servicel , e.g. mobile originated data, which is mentioned in the Overload Start message. In the first way, the radio access node will select all UEs 105 who have calls of type’mobile originated data’, 40 in this example, and it will send then 40 RRC dedicated message, one RRC message, e.g. rrcConnectionReconfiguration, to each UE 105. In the second way, the eNB1 101 will send in celM only one broadcasted SIB message and inside that message it lists the service type’mobile originated data’ is the one to be prevented. In that way, even though all UEs 105 in celM 101 a of the eNB1 101 has received the SIB message, only UEs 105 which are running that type of service will apply parameterl and will then be prevented for handover to the second radio access node which has received the Overload Start message. Such second radio access node 102 for which handover should be prevented may also be referred to as a restricted second radio access node 102.

The role of parameterl , is to make the UE 105 adjust the handover formulas, e.g. in case of event A3 (1 ) or event A4 (2), in a way not be verified so that the UE 105 does not send a handover event to the eNB1 101 and hence no handover with servicel or service2 will be triggered towards the eNB2 102 as it is known in advance that they will be rejected. In formula (1 ) or (2), parameterl could be a high temporary value of for example Ocn or Ofn or Hys.

Step 605

For UE5 105, prior art signaling and handover is allowed towards the eNB2 102 or any other eNB.

Figure 7 illustrates another example of a method for option 1 ) and where the overload is ceased. Figure 7 illustrates two UEs 105, UE1 and UE5. UE1 105 performs call servicel and 2. UE5 performs any call other than servicel or service 2. The method in figure 7 comprises at least one of the following steps, which step may be performed in any suitable order than described below:

Step 700

The MME 100 sends an overload stop message to the eNB2 102.

Step 701

The eNB2 102 sends X2 Load Information to the eNB1 101 indicating that there is no restriction on call services at eNB2 102.

Step 702 For UE1 105, handover is now allowed towards the eNB2 102. The eNB1 sends a rrcConnectionRecofiguration message to the UE1 105 comprising:

• All cells id of eNB2 102,

• Initial value of parameterl (OCN, Hys ...) to apply for cells of eNB2 102.

Step 703

For UE5 105, no action is taken, all continues as in the prior art.

Option 2) The UE 105 sends a measurement report with a handover

Figure 8 illustrates an example of a method for option 2) where the UE 105 sends a RRC measurement report that contains in addition to a handover event like event A3 the radio measurements on other neighboring cells. Figure 8 illustrates two UEs 105, UE1 and UE5. UE1 105 performs call servicel and 2. UE5 performs any call other than servicel or service 2. Figure 8 illustrates when the congestion on the core is started. Note that whenever the congestion is triggered at a target MME 100, an Overload Start message is sent from the MME 100 to the eNB2 102. Then the eNB2 102 will notify its neighbors for example eNB1 101 via a X2AP message comprising load information, or via the OSS 1 10 in case the X2 is not available.

The method in figure 8 comprises at least one of the following steps, which steps may be performed in any suitable order than described below:

Step 801

The MME 100 in congestion sends a S1AP Overload Start message to the eNB2 102.

The overload start message may indicate to the receiver that it should reject all calls of a certain service type, e.g. servicel and service2.

Step 802

Any eNB, e.g. the eNB2 102, that has received the Overload Start message will notify, all its neighbors, e.g. the eNB1 101 , about all types of call services to be rejected, for example servicel & service2. This may also be described as the eNB2 102 sends X2AP Load Information to the first radio access node 101 informing the eNB1 101 of that all cells of the eNB2 102 will reject all call with types service 1 & service 2. The radio access node receives this notification, e.g. the eNB1 101 in this example.

Step 803 The eNB1 101 sends to all UEs 105, via a SIB or via RRC message, a list, e.g. Iist1 , of affected cells and asks them to report measurement of neighbor cells when reporting handover event towards any cell in listl .

The eNB1 101 will send to the UEs 105 under its coverage, either via a dedicated RRC message or via a SIB, as it was the case with option 1 described above, the following information: all cell identities of neighbour sites that has received the Overload Start message, e.g. the eNB2 102 in this example. Then instead of sending parameterl like in the case of optionl , the first network node 101 tells the UEs 105 that each time they want to send a handover event, e.g. event A3, towards any cell of the eNB2 102 or of any other radio access node in the list of sites that has received the Overload Start message, then the UE 105 has to report, together with event A3 measurement report, the measurement of some of other neighbors, e.g. report best other cells, e.g. celU of the eNB3 103 where celU of the eNB3 103 is not in the list of congested sites.

Step 804

The eNB1 101 will wait until any UE 105 sends a RRCMeasurementReport with a handover event, e.g. A3 or A4, then it works as follows:

Step 804-1

This step is an alternative to step 804-2. This step is performed if the UE 105, e.g. UE1 , that has sent the measurement report is performing any call service other than servicel & service2. The UE 5 105 sends a measurement report to the eNB2 102 comprising:

• Event A3 towards celU of eNB2 102.

• Radio measurements of neighbor cell, e.g. cell2 & 3 of eNB3 103.

Step 804-2:

This step is an alternative to step 804-1. This step is performed if the UE1 105 is performing servicel or service2. The UE1 105 sends a measurement report to the eNB1 101 which comprises at least one of the following:

• Information indicating event A3 towards celU of the eNB2 102.

• Radio measurements of neighbor cell, e.g. cell2 & 3 of eNB3 103.

Step 804-2-1 This is a substep of step 804-2 and an alternative to step 804-2-2. If the target cell does not belong to any congested cell sent that was sent to in step 803, that is a cell that does not belongs to any eNB that has received the Overload Start message, e.g. the eNB2 102, the handover is proceeded as in prior art.

Step 804-2-2

This is a substep of step 804-2 and an alternative to step 804-2-1. If the reported best cell belongs to any congested cell that was sent to the UE 105 in step 803, then rather than the eNB1 101 triggering a handover towards the congested cell, e.g. cell2 102a of the second radio access node 102a where the event of handover, e.g. event A3, is verified, it will either trigger a handover towards the second-best cell reported by UE1 105 in the Measurement Report message, e.g. towards cell3 103a of the eNB3 103, or it might take any other action like by rejecting the handover or changing the handover parameters value, e.g. the eNB1 101 sends a temporary value of parameterl . All this could be done by the eNB1 101 sending a RRC dedicated message to the UE1 105, e.g. by sending a rrcConnectionReconfiguration message.

Step 805

This is the result of step 804-1. The eNB1 101 sends a handover request for UE5 to ceM2 102a of the eNB2 102.

Step 806

This is the result of step 804-2. The eNB1 101 sends a handover request for UE1 to ceM3 103a of the eNB3 103.

As mentioned earlier, the overloaded part may be a CN node or a network slice. The CN node scenario was described in relation to figures 4-8. The network slice scenario will now be described in relation to figures 9-10. It may be possible for a single radio access node to support multiple slices. In that case, a radio access node, which may be represented by a gNB, may have an issue with one slice.

As soon as one gNB 102, e.g. the NB2, has an issue affecting calls on one slice, e.g. slicel , that issue, issuel , is communicated to all the neighbors of the gNB2 102. Such communication is done via an Xn link or via the OSS 1 10, similarly to what is illustrated in figures 4 and 5. Once any neighbor node has received the information about issuel , either option 1 or option 2 may apply. With both cases, handing over any call belonging to any slice that was received in the Xn message is avoided, from any neighboring gNB towards the gNB2 102. As a result, not even one handover failure will occur from any gNB towards the gNB2 102.

Option 1) Network slicing - The UE 105 does not send any measurement report that contains a handover event

Figure 9 illustrates an example of a method for option 1 ) where the UE 105 does not send any measurement report that contains a handover event like event A3 or A4 in a network slicing scenario. Figure 9 illustrates two UEs 105, UE1 and UE5. UE1 105 performs call of slice 1 and slice 2. UE5 performs any call other than for slice 1 and slice 2. The method in figure 9 comprises at least one of the following steps, which steps may be performed in any suitable order than described below:

Step 901

The gNB2 102 sends an Xn message to the gNB1 101 comprising cells ID of the gNB2 102 indicating that call service for slices 1 & 2 is not possible.

Step 902

For UE1 105, handover is forbidden towards the eNB2 102 but allowed towards other gNBs. The gNB1 sends information to the UE1 105, in an rrcConnectionRecofiguration message comprising:

· All cells id of gNB2 102,

• Parameterl to apply for cells of gNB2 102.

Step 903

For UE5, prior art signaling applies and the gNB1 101 sends information indicating that handover is allowed towards the gNB2 102 or any other gNB.

Option 2) Network slicing - The UE 105 sends a measurement report with a handover event

Figure 10 illustrates an example of a method for option 2) where the UE 105 sends a measurement report that contains a handover event in the scenario with network slicing. Figure 10 illustrates two UEs 105, UE1 and UE5. UE1 105 performs call for slicel and slice 2. UE5 performs any call other than for slicel or slice 2. The method in figure 10 comprises at least one of the following steps, which steps may be performed in any suitable order than described below:

Step 1001

The gNB2 102 sends an Xn message to the gNB1 101. The Xn message comprises cell ID of gNB2 102 indicating that call service for slicel and slice2 is not possible.

Step 1002

gNB1 sends to all UEs 105, via SIB or via RRC message, a list, e.g. listl , of affected cells, e.g. cells of gNB2 102, that are experiencing slice issues, e.g. slicel & slice2 & asks them to report measurement of neighbor cells when reporting handover event towards any cell in listl .

Step 1003-1

The UE5 105 sends an rrcMeasurementreport to the gNB1 101 indicating event 5G handover towards cell 1 of gNB2 102.

Step 1003-2

The UE5 105 sends an rrcMeasurementreport to gNB1 101 indicating event 5G handover towards celU of gNB2 102.

Step 1004-1

The gNBI 101 proceeds with handover of UE5 105 to cell 1 and gNB2 102.

Step 1004-2

The gNB1 101 does not proceed with handover of UE1 105 to the gNB2 102. Instead it proceeds with handover of UE1 105 towards the second-best cell that is not experiencing any issue with call of slicel and slice2, e.g. celU of gNB3 103.

When applying the methods herein, unnecessary signalling is avoided and quicker handover on the secondary cell is enabled.

Unnecessary signaling is avoided LTE handovers between two cells belonging to two different eNBs may be performed either via a X2 link or via a S1 link.

When the target cell, e.g. cell2, has an incoming handover issue, for example when the eNB controlling cell2 has received the Overload Start message, the handover procedure will fail at the preparation phase: When a target cell, e.g. cell2, on one eNB, e.g. the eNB2 102, will not accept any more handovers, e.g. it has received an Overload Start message, whether it is X2 or S1 based handover, the handover procedure from any cell, celM , from another eNB, e.g. eNB1 101 , towards that target cell2 will fail at the handover preparation phase.

As mentioned above, failure messages, between two eNBs, may be spared:

• X2 HO: The eNB1 101 sends a X2AP Handover Request, the eNB2 102 rejects that request by replying with an X2AP Handover Preparation Failure message and the handover procedure stops at this stage. As a result, two handover messages will be spared.

• S1 HO: The preparation phase starts by the eNB1 101 sending a S1AP Handover Required message to source MME, source MME sends GTP-C Forward

Relocation Request to target MME. The target MME sends a S1 AP Handover Request to target eNB2 102 which replies with S1AP Handover Failure to target MME. Then the target MME replies to the source MME with GTP-C Forward Relocation Response with cause‘Relocation failure’. The source MME replies to source eNB1 with S1AP Handover Preparation Failure. As a result, the above handover failure messages will be spared.

In addition to the handover failures messages spared between two eNBs, messages between the UE 105 and the eNB will be spared with the embodiments herein. After the UE1 105 receives the rrcConnection Reconfiguration message, it will not send any RRC message, e.g. rrcMeasuremrentReport, with the handover event, e.g. A3, to the eNB1 101 that might trigger a handover procedure towards the eNB2 102. As a consequence, the eNB1 101 will not send any handover signalling request message to eNB2 102 that will be rejected at a later stage. In addition, the processing at both the eNB1 101 and at the eNB2 102 to treat the received rrcMeasuremrentReport at the eNB1 101 and to treat the X2AP Handover Request at the eNB2 102 is spared. Quicker handover on secondary cell in case of handover failure on primary cell

As mentioned before in prior art, when one eNB, e.g. eNB2 102, receives the Overload Start message it does not automatically update its neighbors about the new call service restrictions on cells of the eNB2 102. As a result, the handover of any restricted call service from any neighbour of the eNB2 102, e.g. celM of eNB1 101 , towards any cell of eNB2 102, will be rejected. Then the UE1 105 will come back to its eNB1 101 before trying handing over towards a second cell, e.g. cell3 of eNB3 103. With the embodiments herein, the UE1 105 does not have to try first on a target cell, which it is known in advance that it will reject certain types of service, but rather it will try in the first place to go to another cell, cell3 of the eNB3 103 as any eNB, which is a neighbour of the eNB2 102 where the issue is, controlling the UE1 105 will be notified in the first moment that the eNB2 102 will reject any incoming handover of a specific type. By avoiding to try to a cell where the handover will fail and just going directly to an alternative cell, the handover of UE1 101 towards cell3 of the eNB3 103 is quicker.

The method described above will now be described seen from the perspective of the second radio access node 102. The second radio access node may be a BTS, a RNC, a NodeB, an eNB or a gNB. The first radio access node 101 and the second radio access node 102 may apply the same or different access technology. Figure 11 is a flowchart describing the present method performed by the second radio access node 102 for handling handover of UE communication of at least one of the following steps to be performed by the second radio access node 102, which steps may be performed in any suitable order than described below:

Step 1 101

This step corresponds to step 301 in figure 3, step 401 in figure 4, step 501 in figure 5, step 601 in figure 6, step 701 in figure 7, step 901 in figure 9 and step 1001 in figure 10. The second radio access node 102 detects overload in at least a part 100 of the network.

The overload may be detected by receiving an indication of the overload from a MME or an AMF.

The overloaded part of the communications network may be a CN node or a network slice. The overload may be detected by receiving an overload message form the MME or the AMF. The overload message may be an overload message or an overload start message.

Step 1 102

This step corresponds to step 306 in figure 3, step 402 in figure 4, step 502 and step 503 in figure 5, step 602 in figure 6, step 702 in figure 7, step 901 in figure 9 and step 1001 in figure 10. The second radio access node 102 provides overload information to at least one first radio access node 101 which is a neighbor node to the second radio access node 102. The overload information indicates that handover of the UE communication of at least one type to the second radio access node 102 should be prevented due to the overload. The“should be prevented” may also be described as is not allowed.

The overload information may be provided by direct transmission to the at least one first radio access node 101 or by transmission via an OSS 1 10.

There may be an X2 or Xn link between the second radio access node 102 and the at least one first radio access node 101.

The overload information may indicate that handover of UE communication of a first type should be allowed and handover of UE communication of a second type should be prevented. The first type may be e.g. high priority communication, emergency

communication etc. The second type may be non-priority communication, non-emergency communication etc.

UE communication of at least one type may also be referred to as UE types of call services or UE types of communication etc. The UE 105 has already a communication and a part of it is reduced. However what is meant by the overload effect is that the UE 105 either he can make one type of communication or he cannot. For example, the UE 105 might be able to make one type of call service. For example, the UE 105 can do the following call services: a mobile terminated call (he could receive a phone call), he could make an emergency call, he could do voice call but for example he could not do mobile originated call or a packet call (connect to the internet).

Step 1 103 This step corresponds to step 800 in figure 8. The second radio access node 102 may detect that the overload has ceased. The ceased overload may be detected by receiving an overload ceased indication from the overloaded network part 100, e.g. the MME or the AMF. With the term“ceased” it is referred to a case there the load on the network part 100 is reduced compared to when the network part 110 was overloaded. The overload may be considered to be ceased when the load is below a threshold.

Step 1 104

This step corresponds to step 801 in figure 8. The second radio access node 102 may provide, to the at least one first radio access node 101 information indicating that the overload has ceased.

To perform the method steps shown in figures 3-11 for for handling handover of UE communication of certain types during overload in a communications network, the second radio access node 102 comprises an arrangement as shown in Figure 12.

The second radio access node 102 is adapted to, e.g. by means of a detecting module 1201 , detect overload in at least a part of the network 100. The overload may be detected by receiving an indication of the overload from a MME or an AMF. The overloaded part of the communications network may be a CN node or a network slice. The detecting module 1201 may also be referred to as a detecting unit, a detecting means, a detecting circuit, means for detecting etc. The detecting module 1201 may be a processor 1203 of the second radio access node 102 or comprised in the processor 1203 of the second radio access node 102.

The second radio access node 102 is adapted to, e.g. by means of a providing module 1205, provide overload information to at least one first radio access node 101 which is a neighbor node to the second radio access node 102. The overload information indicates that handover of the UE communication of at least one type to the second radio access node 102 should be prevented due to the overload. The overload information may be provided by direct transmission to the at least one first radio access node 101 or by transmission via an OSS 110. The overload information may indicate that handover of UE communication of a first type should be allowed and handover of UE communication of a second type should be prevented. The providing module 1205 may also be referred to as a providing unit, a providing means, a providing circuit, means for providing etc. The providing module 1205 may be the processor 1203 of the second radio access node 102 or comprised in the processor 1203 of the second radio access node 102.

There may be an X2 or Xn link between the second radio access node 102 and the at least one first radio access node 101.

The second radio access node 102 may be further adapted to, e.g. by means of the

detecting module 1201 , detect that the overload has ceased.

The second radio access node 102 may be further adapted to, e.g. by means of the

providing module 1205, provide, to the at least one first radio access node 101

information indicating that the overload has ceased.

The second radio access node 102 may be further adapted to, e.g. by means of a

receiving module 1208, receive information, messages, data from other nodes, e.g. the first radio access node 101 , the third radio access node 103, the UE 105 etc. The

receiving module 1208 may also be referred to as a receiving unit, a receiving means, a receiving circuit, means for receiving, input unit etc. The receiving module 1208 may be a receiver, a transceiver etc. The receiving module 1208 may be a wireless receiver of the second radio access node 102 of a wireless or fixed communications system. The

receiving module 1208 may also be referred to as an obtaining module.

The second radio access node 102 may be further adapted to, e.g. by means of a transmitting module 1210, transmit information, messages, data to other nodes, e.g. the first radio access node 101 , the third radio access node 103, the UE 105 etc. The transmitting module 1210 may also be referred to as a transmitting unit, a transmitting means, a transmitting circuit, means for transmitting, output unit etc. The transmitting module 1210 may be a transmitter, a transceiver etc. The transmitting module 1210 may be a wireless transmitter of the second radio access node 102 of a wireless or fixed communications system. The transmitting module 1210 may be the same as the providing module 1205.

In some embodiments, the second radio access node 102 comprises the processor 1203 and a memory 1213. The memory 1213 comprises instructions executable by the

processor 1203. The memory 1213 may comprise one or more memory units. The

memory 1213 is arranged to be used to store data, received data streams, power level measurements, overload information, communication types, ceased overload information, neighbour node information, handover parameter, formulas, handover indication, threshold values, time periods, configurations, schedulings etc., and applications to perform the methods herein when being executed in the second radio access node 102.

Those skilled in the art will also appreciate that the detecting module 1201 , the providing module 1205, the receiving module 1208, and the transmitting module 1210 described above may refer to a combination of analog and digital circuits, and/or one or more processors configured with software and/or firmware, e.g. stored in a memory, that when executed by the one or more processors such as the processor 1203 perform as described above. One or more of these processors, as well as the other digital hardware, may be included in a single application-specific integrated circuit (ASIC), or several processors and various digital hardware may be distributed among several separate components, whether individually packaged or assembled into a system-on-a-chip (SoC).

In some embodiments, a first computer program may comprise instructions which, when executed on at least one processor, cause the at least one processor to carry out the method steps 1 101-1 104. A first carrier may comprise the first computer program, and the first carrier is one of an electronic signal, optical signal, radio signal or computer readable storage medium.

The method described above will now be described seen from the perspective of the first radio access node 101. The first radio access node may be a BTS, a RNC, a NodeB, an eNB or a gNB. The first radio access node 101 and the second radio access node 102 may apply the same or different access technology. There may be an X2 or Xn link between the second radio access node 102 and the first radio access node 101. Figure 13 is a flowchart describing the present method performed by the first radio access node 101 for handling handover of UE communication of at least one of the following steps to be performed by the first radio access node 101 , which steps may be performed in any suitable order than described below:

Step 1301

This step corresponds to step 306, 402, 502, 503, 602, 702, 901 , 1001 in figure 10. The first radio access node 101 obtains overload information from the second radio access node 102 which is a neighbor node to the first radio access node 101. The overload information indicates that handover of UE communication of at least one type with the second radio access node 102 should be prevented due to the overload.

The overload information may be obtained by direct reception from the second radio access node 102 or by reception via an OSS 110.

The overload information may indicate that handover of UE communication of a first type should be allowed and handover of UE communication of a second type should be prevented.

The overloaded part of the communications network may be a CN node or a network slice.

Step 1302

This step corresponds to step 308 and step 309 in figure 3, step 604 in figure 6 and steps 703 and 704 in figure 7. The first radio access node 101 handles handover of the UE communication of the at least one type according to the obtained overload information.

Step 1303

This step corresponds to step 308 in figure 3 and step 604 in figure 6. This step may be seen as a substep of step 1302. The first radio access node 101 may set at least one handover parameter to a value such that a UE 105 receiving the at least one handover parameter does not send a handover measurement event about a second cell 102a belonging to a plurality of overloaded cells. The plurality of overloaded cells may be presented in a list of overloaded cell, a matrix of overloaded cells, etc.

The UE 105 may always perform radio measurements on the cell, cell2 102a of the second radio access node 102. However, by applying the handover parameter, the second radio access node 102 will not be able to send a handover measurement event to celH 101a of the first radio access node 101 , about cell2 102a of the second radio access node 102, because may be will be useless to trigger a handover procedure in that case.

The value which the handover parameter is set to may be equal to or above a certain threshold. The threshold may be predetermined or preconfigured in the first radio access node 101. Step 1304

This step corresponds to step 308 in figure 3 and step 604 in figure 6. This step may be seen as a substep of step 1302, and a step that is performed after step 1303. The first radio access node 101 may provide the handover parameter and information indicating the plurality of overloaded cells to all UEs 105 currently performing the UE communication of the at least one type which should be prevented. The handover parameter may be associated with a handover formula, and the handover parameter may at least one of the following parameters in the handover formula: Mn, Ofn, Ocn, Hys, Mp, Ofp, Ocp and Off. These parameters are described in detail earlier.

The handover parameter may be provided together with a list of identities of overloaded cells. The handover parameter may only be applied if a handover event is triggered at one cell belonging to that list. Because if a cell is not overloaded, then the handover parameter does not need to be applied, and the handover procedure is triggered as there is no service to be rejected.

Only UEs 101 which have the types of communication associated with the detected overload are to be prevented.

The information indicating the plurality of overloaded cells may be in the form of their identities.

Step 1305

This step corresponds to step 309 in figure 3 and step 703 in figure 7. This step may be seen as a substep of step 1302. The first radio access node 101 may request all UEs 105 to report measurements of their neighboring cell whenever handover event about a second cell 102a served by the second radio access node 102 is triggered. The first radio access node 101 asks the UE 105 to report measurements of neighbour cells whenever they trigger a handover event, e.g. event A3, toward any cells that is congested. Note that in prior art when the UE 105 trigger a handover event, e.g. event A3 towards cell2 102a, it will not report any additional measurements for other cells. In other words, in the prior art when a UE 105 reports a handover event toward a cell, cell2 102a, it will only put the measurement of cell2 102a and of the serving celU , celU 101 a, which is always reported in every measurement report. It does not include measurements of cell3 103a for example. That is why in this step, the first radio access node 101 asks the UE 105 to report the measurements of neighboring cells.

Step 1306

This step corresponds to step 309 in figure 3 and step 704 in figure 7. This step may be seen as a substep of step 1302, and a step that is performed after step 1305. Steps 1305- 1306 may be alternatives to steps 1303-1304, i.e. steps 1305-1306 may be performed instead of steps 1305-1306. The first radio access node 101 may obtain, from a UE 105 served by the first radio access node 101 , a handover indication together with

measurements of the UE’s neighbor cells.

Step 1307

This step corresponds to step 309 in figure 3. The first radio access node may allow the handover to the second radio access node 102 when the UE 105 which sent the handover indication performs communication of a type other than the communication of the at least one type for which handover should be prevented, and when a target for the handover is the second radio access node 102.

Step 1307

This step corresponds to step 706 in figure 7 and steps 1002 and 1003 in figure 10. The first radio access node 101 may allow the handover to a third radio access node 103 when the UE 105 which sent the handover indication performs the communication of the type for which handover should be prevented on the second radio access node 102 and when the target for the handover is the third radio access node 103 where the

communication of the at least one type for which handover is not prevented.

Thus, handover to the third radio access node 103 may be acceptable only if it did not receive any overload information. Otherwise, the handover towards third radio access node 103 should be prevented as it will be rejected. Instead a handover towards a fourth radio access node (not shown) which did not receive the overload information should be triggered.

As an alternative to step 1307, the first radio access node 101 may take other actions such as rejecting the handover request or adjusting handover parameters. Step 1307

This step corresponds to step 801 figure 8. The first radio access node 101 may obtain information indicating that the overload has ceased.

Step 1308

This step corresponds to step 802 in figure 8. The first radio access node 101 may allow handover to the second radio access node 102. The first radio access node 10 may allow the handover based on the obtained information.

Step 1309

This step corresponds to step 801 in figure 8. The first radio access node 101 may detect that the overload has ceased. Step 1308

This step corresponds to step 801 in figure 8. The first radio access node 101 may, provide, to the second radio access node 102, information indicating that the overload has ceased. The providing may be done when the ceased overload has been detected in step 1307.

To perform the method steps shown in figures 3-11 and 13 for for handling handover of UE communication of certain types during overload in a communications network, the first radio access node 101 comprises an arrangement as shown in Figure 14. There may be an X2 or Xn link between the second radio access node 102 and the first radio access node 101.

The first radio access node 101 is adapted to, e.g. by means of an obtaining module 1401 , obtain overload information from a second radio access node 102 which is a neighbor node to the first radio access node 101. The overload information indicates that handover of UE communication of at least one type with the second radio access node 102 should be prevented due to the overload. The overload information may be obtained by direct reception from the second radio access node 102 or by reception via an OSS 110. The overload information may indicate that handover of UE communication of a first type should be allowed and handover of UE communication of a second type should be prevented. The overloaded part of the communications network may be a CN node or a network slice. The obtaining module 1401 may also be referred to as an obtaining unit, an obtaining means, an obtaining circuit, means for obtaining etc. The obtaining module 1401 may be a processor 1403 of the first radio access node 101 or comprised in the processor 1403 of the first radio access node 101.

The first radio access node 101 is adapted to, e.g. by means of a handling module 1405, handle handover of the UE communication of the at least one type according to the obtained overload information. The handling module 1405 may also be referred to as a handling unit, a handling means, a handling circuit, means for handling etc. The handling module 1405 may be a processor 1403 of the first radio access node 101 or comprised in the processor 1403 of the first radio access node 101.

The first radio access node 101 may be further adapted to, e.g. by means of a setting module 1408, set at least one handover parameter to a value such that a UE 105 receiving the at least one handover parameter does not send a handover measurement event about a second cell 102a belonging to a plurality of overloaded cells. The setting module 1408 may also be referred to as a setting unit, a setting means, a setting circuit, means for setting etc. The setting module 1408 may be the processor 1403 of the first radio access node 101 or comprised in the processor 1403 of the first radio access node 101.

The first radio access node 101 may be further adapted to, e.g. by means of a providing unit 1410, provide the handover parameter and information indicating the plurality of overloaded cells to all UEs 105 currently performing the UE communication of the at least one type which should be prevented. The handover parameter may be associated with a handover formula, and the handover parameter may at least one of the following parameters in the handover formula: Mn, Ofn, Ocn, Hys, Mp, Ofp, Ocp and Off. The parameters are described in more detail earlier. The providing module 1410 may also be referred to as a providing unit, a providing means, a providing circuit, means for providing etc. The providing module 1410 may be the processor 1403 of the first radio access node 101 or comprised in the processor 1403 of the first radio access node 101.

The first radio access node 101 may be further adapted to, e.g. by means of a requesting module 1413, request all UEs 105 to report measurements of their neighboring cell whenever handover event about a second cell 102a served by the second radio access node 102 is triggered. The requesting module 1413 may also be referred to as a requesting unit, a requesting means, a requesting circuit, means for requesting etc. The requesting module 1413 may be the processor 1403 of the first radio access node 101 or comprised in the processor 1403 of the first radio access node 101.

The first radio access node 101 may be further adapted to, e.g. by means of the obtaining module 1401 , obtain, from a UE 105 served by the first radio access node 101 , a handover indication together with measurements of the UE’s neighbor cells.

The first radio access node 101 may be further adapted to, e.g. by means of an allowing module 1415, allow the handover to the second radio access node 102 when the UE 105 which sent the handover indication performs communication of a type other than the communication of the at least one type for which handover should be prevented, and when a target for the handover is the second radio access node 102. The allowing module 1415 may also be referred to as an allowing unit, an allowing means, an allowing circuit, means for allowing etc. The allowing module 1415 may be the processor 1403 of the first radio access node 101 or comprised in the processor 1403 of the first radio access node 101.

The first radio access node 101 may be further adapted to, e.g. by means of the allowing module 1415, allow the handover to a third radio access node 103 when the UE 105 which sent the handover indication performs the communication of the type for which handover should be prevented on the second radio access node 102 and when the target for the handover is the third radio access node 103 where the communication of the at least one type for which handover is not prevented.

The first radio access node 101 may be further adapted to, e.g. by means of the obtaining module 1401 , obtain information indicating that the overload has ceased.

The first radio access node 101 may be further adapted to, e.g. by means of the allowing module 1415, allow handover to the second radio access node 102.

The first radio access node 101 may be further adapted to, e.g. by means of a detecting module 1418, detect that the overload has ceased. The detecting module 1418 may also be referred to as a detecting unit, a detecting means, a detecting circuit, means for detecting etc. The detecting module 1418 may be the processor 1403 of the first radio access node 101 or comprised in the processor 1403 of the first radio access node 101.

The first radio access node 101 may be further adapted to, e.g. by means of the providing module 1410, provide, to the second radio access node 102, information indicating that the overload has ceased.

The first radio access node 101 may be further adapted to, e.g. by means of a receiving module 1420, receive overload information, requests, responses, indications, handover parameter, UE measurements, overload ceased information etc. The receiving module 1420 may also be referred to as a receiving unit, a receiving means, a receiving circuit, means for receiving, input unit etc. The receiving module 1420 may be a receiver, a transceiver etc. The receiving module 1420 may be a wireless receiver of the second radio access node 1420 of a wireless or fixed communications system. The receiving module 1420 may be the obtaining module 1401.

The first radio access node 101 may be further adapted to, e.g. by means of a

transmitting module 1423, transmit overload information, requests, responses, indications, handover parameter, UE measurements, overload ceased information etc.

The transmitting module 1423 may also be referred to as a transmitting unit, a transmitting means, a transmitting circuit, means for transmitting, output unit etc. The transmitting module 1423 may be a transmitter, a transceiver etc. The transmitting module 1423 may be a wireless transmitter of the first radio access node 101 of a wireless or fixed communications system. The transmitting module 1423 may be the providing module 1410 and or the requesting module 1413.

In some embodiments, the first radio access node 102 comprises the processor 1403 and a memory 1425. The memory 1425 comprises instructions executable by the processor 1403. The memory 1425 may comprise one or more memory units. The memory 1425 is arranged to be used to store data, received data streams, power level measurements, overload information, communication types, ceased overload information, neighbour node information, handover parameter, formulas, handover indication, threshold values, time periods, configurations, schedulings etc., and applications to perform the methods herein when being executed in the first radio access node 101. In some embodiments, a second computer program may comprise instructions which, when executed on at least one processor, cause the at least one processor to carry out the method steps 1301-1312. A second carrier may comprise the second computer program, and the second carrier is one of an electronic signal, optical signal, radio signal or computer readable storage medium.

Those skilled in the art will also appreciate that the obtaining module 1401 , the handling module 1405, a setting module 1408, a providing module 1410, a requesting module 1413, an allowing module 1415, a detecting module 1418, a receiving module 4120 and a transmitting module 1423 described above may refer to a combination of analog and digital circuits, and/or one or more processors configured with software and/or firmware, e.g. stored in a memory, that when executed by the one or more processors such as the processor 1403 perform as described above. One or more of these processors, as well as the other digital hardware, may be included in a single application-specific integrated circuit (ASIC), or several processors and various digital hardware may be distributed among several separate components, whether individually packaged or assembled into a system-on-a-chip (SoC).

The present mechanism for handling handover of UE communication of certain types during overload in a communications network may be implemented through one or more processors, such as a processor 1203 in the second radio access node arrangement depicted in Figure 12 and a processor 1403 in the first radio access node arrangement depicted in Figure 14, together with computer program code for performing the functions of the embodiments herein. The processor may be for example a Digital Signal Processor (DSP), Application Specific Integrated Circuit (ASIC) processor, Field-programmable gate array (FPGA) processor or microprocessor. The program code mentioned above may also be provided as a computer program product, for instance in the form of a data carrier carrying computer program code for performing the embodiments herein when being loaded into at least one of the first and second radio access nodes 101 , 102. One such carrier may be in the form of a CD ROM disc. It is however feasible with other data carriers such as a memory stick. The computer program code can furthermore be provided as pure program code on a server and downloaded to at least one of the first and second radio access nodes 101 , 102. The embodiments herein relates to preventing the handover failure of a UE 105 that is moving towards a radio node cell, celM , where one of the following two issues has occurred:

celM 101a has received overload notifications from the core side 100, or

celM 101a has had an issue with one of its running slices 100. The issue may be related to hardware or software.

Any advantage that would result from the embodiments herein is beneficial because in 5G networks there will be many‘sensitive’ applications which do not tolerate latency not only in the call setup but also in the handovers procedure.

The embodiments herein apply equally to 4G and 5G.

The embodiments herein are not limited to the above described embodiments. Various alternatives, modifications and equivalents may be used. Therefore, the above

embodiments should not be taken as limiting the scope of the embodiments, which is defined by the appending claims. A feature from one embodiment may be combined with one or more features of any other embodiment.

It should be emphasized that the term“comprises/comprising” when used in this

specification is taken to specify the presence of stated features, integers, steps or components, but does not preclude the presence or addition of one or more other features, integers, steps, components or groups thereof. It should also be noted that the words“a” or“an” preceding an element do not exclude the presence of a plurality of such elements. The terms“consisting of” or“consisting essentially of” may be used instead of the term comprising.

The term“configured to” used herein may also be referred to as“arranged to”,“adapted to”, “capable of or“operative to”.

It should also be emphasised that the steps of the methods defined in the appended claims may, without departing from the embodiments herein, be performed in another order than the order in which they appear in the claims.