WO2022098279A1

WO2022098279A1 - Methods and network nodes for handling congestion associated with control plane

Info

Publication number: WO2022098279A1
Application number: PCT/SE2021/051092
Authority: WO
Inventors: Filip BARAC; Marco BELLESCHI; Ajmal MUHAMMAD
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2020-11-06
Filing date: 2021-11-01
Publication date: 2022-05-12
Also published as: EP4241491A1; EP4241491A4

Abstract

Embodiments herein relate to, for example, a method performed by a first network node (21) for handling communication in a wireless communications network (1), wherein the first network node handles CP signalling. The first network node sends an indication to a second network node (22), handling user plane signalling, wherein the indication indicates a congestion associated with a CP related to a UE or another network node.

Description

METHODS AND NETWORK NODES FOR HANDLING CONGESTION ASSOCIATED WITH CONTROL PLANE

TECHNICAL FIELD

Embodiments herein relate to a first network node, a second network node, and methods performed therein regarding wireless communication. Furthermore, a computer program product and a computer-readable storage medium are also provided herein. In particular, embodiments herein relate to handling communication, such as controlling/managing setup of communication and/or control signalling for relay nodes, in a wireless communications network.

BACKGROUND

In a typical wireless communications network, user equipment (UE), also known as 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). The RAN covers a geographical area which is divided into service areas or cell areas, with each service area or cell area being served by radio network node such as an access node e.g. a Wi-Fi access point or a radio base station (RBS), which in some networks may also be called, for example, a NodeB, a gNodeB, or an eNodeB. The service area or cell area is a geographical area where radio coverage is provided by the radio network node. The radio network node operates on radio frequencies to communicate over an air interface with the UEs within range of the radio network node. The radio network node communicates over a downlink (DL) to the UE and the UE communicates over an uplink (UL) to the radio network node.

A Universal Mobile Telecommunications System (UMTS) is a third generation telecommunication network, which evolved from the second generation (2G) Global System for Mobile Communications (GSM). The UMTS terrestrial radio access network (UTRAN) is essentially a RAN using wideband code division multiple access (WCDMA) and/or High-Speed Packet Access (HSPA) for communication with user equipment. In a forum known as the Third Generation Partnership Project (3GPP), telecommunications suppliers propose and agree upon standards for present and future generation networks and UTRAN specifically, and investigate enhanced data rate and radio capacity. In some RANs, e.g. as in UMTS, several radio network nodes may be connected, e.g., by landlines or microwave, to a controller node, such as a radio network controller (RNC) or a base station controller (BSC), which supervises and coordinates various activities of the plural radio network nodes connected thereto. The RNCs are typically connected to one or more core networks.

Specifications for the Evolved Packet System (EPS) have been completed within the 3GPP and this work continues in the coming 3GPP releases, such as 6G networks and development of 5G such as New Radio (NR). The EPS comprises the Evolved Universal Terrestrial Radio Access Network (E-UTRAN), also known as the Long-Term Evolution (LTE) radio access network, and the Evolved Packet Core (EPC), also known as System Architecture Evolution (SAE) core network. E-UTRAN/LTE is a 3GPP radio access technology wherein the radio network nodes are directly connected to the EPC core network. As such, the Radio Access Network (RAN) of an EPS has an essentially “flat” architecture comprising radio network nodes connected directly to one or more core networks.

With the 5G technologies such as new radio (NR), the use of very many transmit- and receive-antenna elements may be of great interest as it makes it possible to utilize beamforming, such as transmit-side and receive-side beamforming. Transmit-side beamforming means that the transmitter can amplify the transmitted signals in a selected direction or directions, while suppressing the transmitted signals in other directions. Similarly, on the receive-side, a receiver can amplify signals from a selected direction or directions, while suppressing unwanted signals from other directions.

Fig. 1 discloses an overall architecture of a next generation RAN (NG-RAN).

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

NOTE: As specified in 38.300 v.15.6.0, an NG-RAN could also comprise a set of ng-eNBs, an ng-eNB may comprise an ng-eNB-central unit (CU) and one or more ng- eNB-distributed units (DU). An ng-eNB-CU and an ng-eNB-DU is connected via a W1 interface.

A gNB can support frequency division duplex (FDD) mode, time division duplex (TDD) mode or dual mode operation. gNBs can be interconnected through a Xn interface.

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

NOTE: In case of network sharing with multiple cell identity (ID) broadcast, each Cell ID associated with a subset of public land mobile networks (PLMN) corresponds to a gNB-Dll and the gNB-Cll it is connected to, i.e. the corresponding gNB-DUs share the same physical layer cell resources.

NOTE: For resiliency, a gNB-Dll may be connected to multiple gNB-CUs by appropriate implementation.

NG, Xn and F1 are logical interfaces.

For NG-RAN, the NG and Xn-C interfaces for a gNB consisting of a gNB-Cll and gNB-DUs, terminate in the gNB-CU. For E-UTRAN New Radio - Dual Connectivity (EN- DC), the S1-U and X2-C interfaces for a gNB consisting of a gNB-CU and gNB-DUs, terminate in the gNB-CU. The gNB-CU and connected gNB-DUs are only visible to other gNBs and the 5GC as a gNB. A possible deployment scenario is described in Annex A.

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

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

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

The NG-RAN architecture, i.e. the NG-RAN logical nodes and interfaces between them, is defined as part of the RNL.

For each NG-RAN interface, e.g., NG, Xn and F1 , the related TNL protocol and the functionality are specified. The TNL provides services for user plane (UP) transport and signalling transport.

In NG-Flex configuration, each NG-RAN node is connected to all Access and Mobility Management Functions (AMF) of AMF Sets within an AMF Region supporting at least one slice also supported by the NG-RAN node. The AMF Set and the AMF Region are defined in 3GPP TS 23.501 v.15.6.0.

If security protection for control plane and user plane data on TNL of NG-RAN interfaces has to be supported, network domain security (NDS)/IP 3GPP TS 33.501 shall be applied. Fig. 2 shows an overall architecture for separation of gNB-CU-control plane (CP) and gNB-CU-user plane (UP).

A gNB may comprise a gNB-CU-CP, multiple gNB-CU-UPs and multiple gNB-DUs;

The gNB-CU-CP is connected to the gNB-DU through the F1-C interface;

The gNB-CU-UP is connected to the gNB-DU through the F1-U interface;

The gNB-CU-UP is connected to the gNB-CU-CP through the E1 interface;

One gNB-DU is connected to only one gNB-CU-CP;

One gNB-CU-UP is connected to only one gNB-CU-CP;

NOTE 1 : For resiliency, a gNB-DU and/or a gNB-CU-UP may be connected to multiple gNB-CU-CPs by appropriate implementation.

One gNB-DU can be connected to multiple gNB-CU-UPs under the control of the same gNB-CU-CP;

One gNB-CU-UP can be connected to multiple DUs under the control of the same gNB-CU-CP;

NOTE 2: The connectivity between a gNB-CU-UP and a gNB-DU is established by the gNB-CU-CP using Bearer Context Management functions.

NOTE 3: The gNB-CU-CP selects the appropriate gNB-CU-UP(s) for the requested services for the UE. In case of multiple CU-UPs they belong to same security domain as defined in TS 33.210 v.15.6.0.

NOTE 4: Data forwarding between gNB-CU-UPs during intra-gNB-CU-CP handover within a gNB may be supported by Xn-U.

F1-AP is specified in TS 38.473 v.15.6.0

E1 is specified in TS 38.463 v.15.6.0

Fig. 3 shows the procedure used to setup the bearer context in the gNB-CU-UP. Thus, Fig. 3 shows bearer context setup over F1-U.

Action 0. Bearer context setup, e.g., following a SgNB ADDITION REQUEST message from the MeNB, is triggered in gNB-CU-CP.

Action 1. The gNB-CU-CP sends a BEARER CONTEXT SETUP REQUEST message containing UL TNL address information for S1-U or NG-U, and if required, DL TNL address information for X2-U or Xn-U to setup the bearer context in the gNB-CU-UP. For NG-RAN, the gNB-CU-CP decides flow-to-data radio bearer (DRB) mapping and sends the generated Service Data Adaptation Protocol (SDAP) and PDCP configuration to the gNB-CU-UP.

Action 2. The gNB-CU-UP responds with a BEARER CONTEXT SETUP RESPONSE message containing the UL TNL address information for F1-U, and DL TNL address information for S1-U or NG-U, and if required, UL TNL address information for X2-U or Xn-U.

NOTE: The indirect data transmission for split bearer through the gNB-CU-UP is not precluded.

Action 3. F1 UE context setup procedure is performed to setup one or more bearers in the gNB-DU.

Action 4. The gNB-CU-CP sends a BEARER CONTEXT MODIFICATION REQUEST message containing the DL TNL address information for F1-U and PDCP status.

Action 5. The gNB-CU-UP responds with a BEARER CONTEXT MODIFICATION RESPONSE message.

Fig 4 shows the procedure used to release the bearer context in the gNB-CU-UP initiated by the gNB-CU-CP.

Fig. 4 shows a Bearer context release over F1-U - gNB-CU-CP initiated

Action 0. Bearer context release, e.g., following an SGNB RELEASE REQUEST message from the MeNB, is triggered in gNB-CU-CP.

Action 1. The gNB-CU-CP sends a BEARER CONTEXT MODIFICATION REQUEST message to the gNB-CU-UP.

Action 2. The gNB-CU-UP responds with a BEARER CONTEXT MODIFICATION RESPONSE carrying the PDCP UL/DL status.

Action 3. F1 UE context modification procedure is performed to stop the data transmission for the UE. It is up to gNB-DU implementation when to stop the UE scheduling.

NOTE: actions 1-3 are performed only if the PDCP status of the bearer(s) needs to be preserved e.g., for bearer type change.

Action 4. The gNB-CU-CP may receive the UE CONTEXT RELEASE message from the MeNB in EN-DC operation.

Actions 5 and 7. Bearer context release procedure is performed.

Action 6. F1 UE context release procedure is performed to release the UE context in the gNB-DU. Fig 5 shows the procedure used to release the bearer context in the gNB-CU-UP initiated by the gNB-CU-UP.

Action 0. Bearer context release is triggered in gNB-CU-UP e.g., due to local failure.

Action 1. The gNB-CU-UP sends a BEARER CONTEXT RELEASE REQUEST message to request the release of the bearer context in the gNB-CU-UP. This message may contain the PDCP status.

Actions 2-5. If the PDCP status needs to be preserved, the E1 Bearer Context Modification and the F1 UE Context Modification procedures are performed. The E1 Bearer Context Modification procedure is used to convey data forwarding information to the gNB-CU-UP. The gNB-CU-CP may receive the UE Context Release from the MeNB.

Action 6. The gNB-CU-CP sends a BEARER CONTEXT RELEASE COMMAND message to release the bearer context in the gNB-CU-UP.

Action 7. The gNB-CU-UP responds with a BEARER CONTEXT RELEASE COMPLETE to confirm the release of the bearer context including also data forwarding information.

Action 8. F1 UE context release procedure may be performed to release the UE context in the gNB-DU.

Integrated Access Backhaul Networks.

Protocol and Architecture overview.

3GPP is currently standardizing integrated access and wireless access backhaul (IAB), or integrated access backhaul in short, in NR in Rel-16 see RP-193251.

The usage of short range mm Wave spectrum in NR creates a need for densified deployment with multi-hop backhauling. However, optical fiber to every base station will be too costly and sometimes not even possible, for example, due to historical sites. The main IAB principle is the use of wireless links for the backhaul, instead of fiber, to enable flexible and very dense deployment of cells without the need for densifying the transport network. Use case scenarios for IAB may include coverage extension, deployment of massive number of small cells and fixed wireless access (FWA), e.g., to residential and/or office buildings. The larger bandwidth available for NR in mmWave spectrum provides opportunity for self-backhauling, without limiting the spectrum to be used for the access links. On top of that, the inherent multi-beam and multiple input multiple output (MIMO) support in NR reduce cross-link interference between backhaul and access links allowing higher densification.

During the study item phase of the IAB work, a summary of the study item can be found in the technical report TR 38.874 v0.7.0, it has been agreed to adopt a solution that leverages a CU/Dll split architecture of NR, where a IAB node will be hosting a DU part that is controlled by a CU. The IAB nodes also have a Mobile Termination (MT) part, denoted as IAB-MT, that they use to communicate with their parent nodes.

The specifications for IAB strives to reuse existing functions and interfaces defined in NR. In particular, MT, gNB-DU, gNB-CU, user plane function (UPF), AMF and session management function (SMF) as well as the corresponding interfaces NR Uu, between MT and gNB, F1, NG, X2 and N4 are used as baseline for the IAB architectures. Modifications or enhancements to these functions and interfaces for the support of IAB will be explained in the context of the architecture discussion. Additional functionality such as multi-hop forwarding is included in the architecture discussion as it is necessary for the understanding of IAB operation and since certain aspects may require standardization.

The MT function has been defined as a component of the IAB node. In the context of this study, MT is referred to as a function residing on an lAB-node that terminates the radio interface layers of the backhaul Uu interface toward the lAB-donor or other IAB- nodes.

Fig. 6 shows a reference diagram for IAB in standalone mode, which contains one lAB-donor and multiple lAB-nodes. The lAB-donor is treated as a single logical node that comprises a set of functions such as gNB-DU, gNB-CU-CP, gNB-CU-UP and potentially other functions. In a deployment, the lAB-donor can be split according to these functions, which can all be either collocated or non-collocated as allowed by 3GPP NG-RAN architecture. lAB-related aspects may arise when such split is exercised. Also, some of the functions presently associated with the lAB-donor may eventually be moved outside of the donor in case it becomes evident that they do not perform lAB-specific tasks.

In the context of IAB there are two kinds of nodes that are identified as components of a RAN: lAB-node: A RAN node that supports wireless access to UEs and wirelessly backhauls the access traffic. lAB-donor: An IAB node, i.e. , RAN node, which provides a UE’s interface to a core network and wireless backhauling functionality to IAB nodes. Fig. 6 shows a high-level architectural view of an IAB network, such as a Reference diagram for lAB-architectures, see TR 38.874 v0.7.0.

The baseline user plane and control plane protocol stacks for IAB are shown in the Figs 7-8.

Fig. 7 shows a Baseline UP Protocol stack for IAB in rel-16.

Fig. 8 shows a Baseline CP Protocol stack for IAB in rel-16.

As shown, the chosen protocol stacks reuse the current CU-DU split specification in rel-15, where the full user plane F1-U, GPRS Tunnelling Protocol (GTP)-U/UDP/IP, is terminated at the IAB node, like a normal DU, and the full control plane F1-C, F1- AP/SCTP/IP, is also terminated at the IAB node, like a normal DU. In the above cases, Network Domain Security (NDS) has been employed to protect both UP and CP traffic IPsec in the case of UP, and Datagram Transport Layer Security (DTLS) in the case of CP. IPsec could also be used for the CP protection instead of DTLS, in this case no DTLS layer would be used.

A new protocol layer called Backhaul Adaptation Protocol (BAP) has been introduced in the IAB nodes and the IAB donor, which is used for routing of packets to the appropriate downstream/upstream node and also mapping the UE bearer data to the proper backhaul radio link control (RLC) channel, and also between ingress and egress backhaul RLC channels in intermediate IAB nodes, to satisfy the end-to-end quality of service (QoS) requirements of bearers.

Topology Adaptation Scenarios for Baseline Architecture.

Fig. 9 shows an example of some possible lAB-node migration cases listed in the order of complexity and more details as follow:

Intra-CU Case (A): In this case the lAB-node (E) along with it serving UEs is moved to a new parent node (lAB-node B) under the same donor-DU (1). The successful intra-donor DU migration requires establishing UE context setup for the lAB-node E MT in the DU of the new parent node (lAB-node B), updating routing tables of IAB nodes along the path to lAB-node E and allocating resources on the new path. The IP address for lAB- node E will not change, while the F1-U tunnel/connection between donor-CU (1) and lAB- node E DU will be redirected through lAB-node B.

Intra-CU Case (B): The procedural requirements/complexity of this case is the same as that of Case (A). Also, since the new lAB-donor DU, i.e. , DU2, is connected to the same L2 network, the lAB-node E can use the same IP address under the new donor DU. However, the new donor DU, i.e., DU2 will need to inform the network using IAB- node E L2 address in order to get/keep the same IP address for lAB-node E by employing some mechanism such as Address Resolution Protocol (ARP).

Intra-CU Case (C): This case is more complex than Case (A) as it also needs allocation of a new IP address for lAB-node E. In case, IP security (IPsec) is used for securing the F1-LI tunnel/connection between the Donor-CU (1) and lAB-node E DU, then it might be possible to use existing IP address along the path segment between the Donor-CU (1) and security gateway (SeGW), and new IP address for the IPsec tunnel between SeGW and lAB-node E DU.

Inter-CU Case (D): This is the most complicated case in terms of procedural requirements and may need new specification procedures, such as enhancement of radio resource control (RRC), F1AP, XnAP, Ng signalling, that are beyond the scope of 3GPP Rel-16.

Note that 3GPP Rel-16 has standardized procedure only for intra-CU migration, which is described below.

Thus, Fig. 9 shows examples of different possible scenarios for lAB-node migration of IAB node E.

SUMMARY

As a part of Rel-17 IAB work item, 3GPP is discussing the UP- and CP- based approaches to IAB congestion mitigation. The separation between two approaches is strict: the UP approaches will be based on enhancements to the existing Downlink Data Delivery Status (DDDS) message, defined in TS 38.425. Here, the indication of ongoing or imminent congestion will be sent, per DRB, from the DRB’s access node to the IAB donor CU, or IAB donor CU-UP in case of IAB donor CU is split into CU-UP and CU-CP. Based on this congestion indication, the donor may decide to reduce the rate of sending data on the indicated DRB and alleviate the congestion.

In CP-based approaches, a congestion indication may be carried via the control plane, i.e., the F1AP signaling, from any intermediate node of UE bearers, mapped to a backhaul (BH) RLC channel, to the IAB donor. Based on the congestion indication, the donor changes the route of traffic towards a certain destination UE and/or IAB node. The rerouting requires significant reconfigurations of intermediate IAB nodes, and it should be invoked only if the UP-based approach does not help alleviate the congestion.

In general, a congestion indication sent over the CP, e.g., F1AP signaling, from an intermediate IAB-DU for UE bearers, or UE DRB in case of 1 :1 mapping, that is mapped to a BH RLC channel will reach the IAB donor CU-CP faster than a similar indication sent from the DRB’s access IAB-DU via the user plane, i.e. , in a DDDS message. The reason is that the CP-based indication can be sent from an intermediate IAB-DU for UE bearers over CP channels, that are generally of higher priority than the UP channels. Meanwhile, the DDDS for a DRB can only be sent from the final, i.e., access, IAB-DU for that DRB. This is because the part of the DRB route between the IAB donor and the intermediate IAB-DU does not suffer from congestion, while the congestion occurs downstream from the intermediate IAB-DU, on the part of the route between the intermediate IAB-DU and the access IAB-DU for the DRB in question. Also, this congestion indication by the intermediate IAB node will help the donor CU-CP to precisely identify the IAB node that has congestion issue and so that the donor CU-CP can take proper measures to mitigate it.

It has under development of embodiments herein been discovered that in case the donor is split into the IAB donor CU-CP and IAB donor CU-UP, it is not clear how the congestion received at the former can trigger congestion mitigation measures at the latter.

An object herein is to provide a mechanism to enable communication, e.g., handle or manage communication, in an efficient manner in a wireless communications network.

According to an aspect the object is achieved, according to embodiments herein, by providing a method performed by a first network node for handling communication, such as managing signalling or communication, in a wireless communications network. The first network node, handling CP signalling, sends to a second network node, handling UP signalling, an indication of a congestion associated with a CP related to a UE or another network node.

According to another aspect the object is achieved, according to embodiments herein, by providing a method performed by a second network node for handling communication in a wireless communications network. The second network node handling CP signalling. The second network node receives an indication from a first network node, handle UP signalling, wherein the indication indicates a congestion associated with a CP related to a UE or another network node. The second network node handles communication related to the UE or the other network node based on the received indication. For example, the second network node, handling UP signalling, receives from the first network node, handling CP signalling, the indication of the congestion associated with the CP related to a UE or another network node. The second network node then handles communication related to the UE or the other network node taking the indication into account. It is furthermore provided herein a computer program product comprising instructions, which, when executed on at least one processor, cause the at least one processor to carry out the method above, as performed by the first network node and the second network node, respectively. It is additionally provided herein a computer-readable storage medium, having stored thereon a computer program product comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method above, as performed by the first network node and the second network node, respectively.

The object is achieved by providing a first network node and a second network node configured to perform the methods herein, respectively.

Thus, it is herein provided a first network node for handling communication in a wireless communications network. The first network node is configured to handle CP signalling, and to send an indication to a second network node, handling UP signalling, wherein the indication indicates a congestion associated with a CP related to a UE or another network node.

Thus, it is herein provided a second network node for handling communication in a wireless communications network, wherein the second network node is configured to handle UP signalling. The second network node is further configured to receive an indication from a first network node, handling CP signalling, wherein the indication indicates a congestion associated with a CP related to a UE or another network node. The second network node is configured to handle communication related to the UE or the other network node based on the received indication.

Embodiments herein propose signalling enhancements, such as E1 signalling, between the first network node, such as an CU-CP, and the second network node, such as an CU-UP. It should be noted that the first and the second network node may be collocated in a same network node or located in separate network nodes. For example, an IAB donor CU-CP, based on a congestion indication received over the CP from an intermediate IAB node for a DRB, for example, congestion indication sent via F1AP signalling, sends an E1 message to an IAB donor CU-UP. Th message may comprise the indication of which differentiated services code point (DSCP)/flow label/destination IP address combinations and/or DRBs of UEs that should be subject to an UP-based IAB congestion mitigation action at the IAB donor CU-UP. The congestion mitigation action, at the IAB donor CU-UP being an example of the second network node, may comprise, e.g., slowing down the DL traffic on that DRB or re-routing traffic. Thus, the IAB donor CU-CP conveys the information about the congested traffic to the IAB donor CU-LIP, based on the congestion information/indication sent via F1-AP from an IAB node to the IAB donor CU-CP.

The solution is applicable to network nodes such as IAB donor CUs deployed in a CU-CP - CU-UP split architecture. An advantage of the proposed solution is that it enables speeding up the UP-based measures for IAB congestion mitigation, at the second network node, by exploiting a CP-based congestion indication as a trigger. Thanks to the proposed signalling, the first network node, based on the CP-based congestion indication, triggers the UP-based measures for congestion mitigation, executed by the second network node.

The fact that the CP-based congestion indication may be sent even from intermediate IAB nodes for a DRB, as opposed to the UP-based indication, i.e. , DDDS, which can only be sent from the DRB’s access node, means that a receiving network node, for example, a donor node, is notified about the congestion faster than it would be notified if the UP-based indication, i.e., DDDS, was used.

Thus, embodiments herein enable communication, e.g., handle or manage signalling, in an efficient manner in a wireless communications network.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments will now be described in more detail in relation to the enclosed drawings, in which:

Fig. 1 is an overall architecture of a NG-RAN;

Fig. 2 shows an overall architecture for separation of gNB-CU-CP and gNB-CU- UP;

Fig. 3 shows a procedure used to setup a bearer context in a gNB-CU-UP;

Fig. 4 shows a procedure used to release a bearer context in a gNB-CU-UP initiated by a gNB-CU-CP;

Fig. 5 shows a procedure used to release a bearer context in a gNB-CU-UP initiated by a gNB-CU-UP;

Fig. 6 shows a reference diagram for IAB in standalone mode;

Fig. 7 shows a Baseline User Plane (UP) Protocol stack for IAB in rel-16;

Fig. 8 shows a Baseline control Plane (CP) Protocol stack for IAB in rel-16;

Fig. 9 shows some possible lAB-node migration cases according to prior art;

Fig. 10 is a schematic overview depicting a wireless communication network according to embodiments herein; Fig. 11a is a schematic flowchart depicting a method performed by a first network node according to embodiments herein;

Fig. 11b is a schematic flowchart depicting a method performed by a second network node according to embodiments herein;

Fig. 12a is a schematic combined signalling scheme and flowchart according to embodiments herein;

Fig. 12b is a schematic signalling scheme according to embodiments herein;

Fig. 13a is a block diagram depicting a first network node according to embodiments herein;

Fig. 13b is a block diagram depicting a second network node according to embodiments herein;

Fig. 14 is a telecommunication network connected via an intermediate network to a host computer in accordance with some embodiments;

Fig. 15 is a host computer communicating via a base station with a user equipment over a partially wireless connection in accordance with some embodiments;

Fig. 16 shows methods implemented in a communication system including a host computer, a base station and a user equipment in accordance with some embodiments;

Fig. 17 shows methods implemented in a communication system including a host computer, a base station and a user equipment in accordance with some embodiments;

Fig. 18 shows methods implemented in a communication system including a host computer, a base station and a user equipment in accordance with some embodiments; and

Fig. 19 shows methods implemented in a communication system including a host computer, a base station and a user equipment in accordance with some embodiments.

DETAILED DESCRIPTION

Embodiments herein relate to wireless communications networks in general. Fig.

10 is a schematic overview depicting a wireless communications network 1. The wireless communications network 1 comprises one or more RANs and one or more CNs. The wireless communications network 1 may use one or a number of different technologies. Embodiments herein relate to recent technology trends that are of particular interest in a New Radio (NR) context, however, embodiments are also applicable in further development of existing wireless communications systems such as e.g. LTE or Wideband Code Division Multiple Access (WCDMA).

In the wireless communications network 1, a user equipment (UE) 10 such as a mobile station, a wireless device, a non-access point (non-AP) STA, a STA, and/or a wireless terminal, is comprised communicating via e.g. one or more Access Networks (AN), e.g. RAN, to one or more CNs. It should be understood by the skilled in the art that “UE” is a non-limiting term which means any terminal, wireless communications terminal, user equipment, narrowband (NB)-internet of things (loT) device, Machine Type Communication (MTC) device, Device to Device (D2D) terminal, or node e.g. smart phone, laptop, mobile phone, sensor, relay, mobile tablets or even a small base station capable of communicating using radio communication with a radio network node within an area served by the radio network node.

The wireless communications network 1 comprises a first radio network node 12 e.g. an IAB node such as an lAB-donor node or an IAB-CU, an access node, an access controller, a base station, e.g. a radio base station such as a gNodeB (gNB), an evolved Node B (eNB, eNode B), a NodeB, a base transceiver station, a radio remote unit, an Access Point Base Station, a base station router, a Wireless Local Area Network (WLAN) access point or an Access Point Station (AP STA), MME, AMF, a stand-alone access point or any other network unit or node capable of communicating with a wireless device within a service area served by the radio network node depending e.g. on a first radio access technology and terminology used. The first radio network node 12 may also be referred to as serving or source node or RAN node. It should be noted that a service area may be denoted as cell, beam, beam group or similar to define an area of radio coverage. This first radio network node is also referred to herein as first network node.

The wireless communications network 1 further comprises a first intermediate radio network node 13 connected in-between the first radio network node 12 and the UE 10. The first intermediate radio network node 13 may be an IAB node e.g. a radio remote unit (RRU), an access node, antenna unit, radio unit of e.g. a radio base station such as a gNodeB (gNB), an evolved Node B (eNB, eNode B), a NodeB, a base transceiver station, a radio remote unit, an Access Point Base Station, a base station router, a Wireless Local Area Network (WLAN) access point or an Access Point Station (AP STA), a transmission arrangement of a radio base station, a stand-alone access point or any other network unit or node capable of communicating with a wireless device within a service area served by the radio network node depending e.g. on a first radio access technology and terminology used.

The wireless communications network further comprises a second intermediate radio network node 14 connected in-between the first radio network node 12 and the UE 10. The second intermediate radio network node 14 may be connected to the UE 10 directly and may be an egress point. The second intermediate radio network node 14 may be an IAB node e.g. a radio remote unit (RRU), an access node, antenna unit, radio unit of e.g. a radio base station such as a gNodeB (gNB), an evolved Node B (eNB, eNode B), a NodeB, a base transceiver station, a radio remote unit, an Access Point Base Station, a base station router, a Wireless Local Area Network (WLAN) access point or an Access Point Station (AP STA), a transmission arrangement of a radio base station, a stand-alone access point or any other network unit or node capable of communicating with a wireless device within a service area served by the radio network node depending e.g. on a radio access technology and terminology used. It should be noted that a service area may be denoted as cell, beam, beam group or similar to define an area of radio coverage. This second intermediate radio network node is also referred to herein as third network node or migrating network node.

Furthermore, the wireless communications network 1 comprises a second radio network node 15 e.g. an IAB node such as an lAB-donor node or an IAB-CU, an access node, an access controller, a base station, e.g. a radio base station such as a gNodeB (gNB), an evolved Node B (eNB, eNode B), a NodeB, a base transceiver station, a radio remote unit, an Access Point Base Station, a base station router, a Wireless Local Area Network (WLAN) access point or an Access Point Station (AP STA), MME, AMF, a standalone access point or any other network unit or node capable of communicating with a wireless device within a service area served by the radio network node depending e.g. on a radio access technology and terminology used. The second radio network node 15 may be referred to as a target node or RAN node. It should be noted that a service area may be denoted as cell, beam, beam group or similar to define an area of radio coverage. This second radio network node is also referred to herein as second network node or target network node.

The wireless communications network 1 may further comprise a third intermediate radio network node 16 connected in-between the second radio network node 15 and served UEs. The third intermediate radio network node 16 may be an IAB node e.g. a radio remote unit (RRU) such as an access node, antenna unit, radio unit of e.g. a radio base station such as a gNodeB (gNB), an evolved Node B (eNB, eNode B), a NodeB, a base transceiver station, a radio remote unit, an Access Point Base Station, a base station router, a Wireless Local Area Network (WLAN) access point or an Access Point Station (AP STA), a transmission arrangement of a radio base station, a stand-alone access point or any other network unit or node capable of communicating with a wireless device within a service area served by the radio network node depending e.g. on a radio access technology and terminology used. It should be noted that a service area may be denoted as cell, beam, beam group or similar to define an area of radio coverage.

According to embodiments herein a first network node 21 handling control plane (CP) signalling such as a central unit node, e.g., a CU-CP sends, to a second network node 22 handling user plane (UP) signalling such as a central unit, e.g., a CU-UP, an indication of a congestion associated with a CP for a UE such as the UE 10 or another network node, such as an I AB node. The first network node 21 and the second network node 22 may be collocated in a same network node such as the first radio network node 12 or located in separate network nodes.

It should be noted that:

• The term “access IAB-DU for a DRB” denotes the IAB-DU directly serving the UE at which the DRB is terminated.

• The term “intermediate IAB-DU for a DRB” denotes all the lAB-DUs, including the lAB-donor-DU, that the packets on the DRB traverse on the path from the donor to the access IAB-DU, excluding the access IAB-DU.

• The terms “IAB node” and “IAB-DU” are used interchangeably.

• An intermediate IAB-DU for a UE DRB is aware of its ingress/egress BH RLC channels.

• An intermediate IAB-DU for a UE DRB is aware of BAP routing IDs, destination BAP addresses and path IDs of the packets carried over its ingress/egress BH RLC channels.

• An intermediate IAB-DU for a UE DRB is not aware of individual DRBs carried over its ingress/egress BH RLC channels and is not aware of which UE DRB is carried over which ingress/egress BH RLC channel and with which BAP routing ID, destination BAP address and path ID.

The method actions performed by the first network node 21 , such as an IAB node or a CU-CP of an IAB node, for handling communication in the wireless communications network 1 according to embodiments herein will now be described with reference to a flowchart depicted in Fig. 11a. The first network node 21 handles CP signalling. Action 1201. The first network node 21 may receive a congestion indication, from another network node or a UE, e.g., for a UE DRB, delivered over the CP. The congestion indication may indicate traffic pertaining to one or more of the following: a. One or more egress BH RLC channels served by said network node; b. One or more BAP routing IDs pertaining to the traffic traversing said network node; c. One or more destination BAP addresses pertaining to the traffic traversing said network node; d. One or more path IDs pertaining to the traffic traversing said network node; and e. A physical link comprising all egress BH RLC channels from the network node itself towards one or more children nodes.

Action 1202. The first network node 21 may identify traffic pertaining to the congestion indication. For example, first network node 21 may identify traffic based on the congestion indication or information related to the congestion indication.

Action 1203. The first network node 21 may determine which network node, handling UP signalling, that serves the identified traffic. This may thus be based on the information indicated by the congestion indication used to identify the traffic.

Action 1204. The first network node 21 sends an indication to the second network node 22, handling UP signalling, wherein the indication indicates the congestion associated with the CP related to the UE or the other network node. For example, the first network node 21 , handling the CP signalling, sends the indication, also referred to as CP congestion indication, to the second network node 22, wherein the indication indicates the congestion associated with the CP related to the UE or the other network node. Thus, the first network node 21 may send the indication to the determined network node. The indication may comprise one or more of the following: a. DRB ID and indication identifying the UE that terminates this DRB; b. DSCP or differentiated service (DS) values; c. Flow label values; d. Destination IP addresses.

The method actions performed by the second network node 22, such as an IAB node for example a CU-UP, for handling communication in the wireless communications network 1 according to embodiments herein will now be described with reference to a flowchart depicted in Fig. 11b. The second network node 22 handles UP signalling. The first network node 21 may comprise an IAB-CU-CP, and the second network node 22 may comprise an IAB-CU-UP.

Action 1211. The second network node 22 receives the indication from the first network node 21 , handling CP signalling, wherein the indication indicates the congestion associated with the CP related to the UE, or the other network node. For example, the second network node 22 handling the user plane signalling, may receive the indication, wherein the indication indicates the congestion associated with the CP related to the UE or the other network node. The indication may comprise one or more of the following: a. DRB ID and indication identifying the UE that terminates this DRB; b. DSCP or DS values; c. Flow label values; d. Destination IP addresses.

Action 1212. The second network node 22 handles communication related to the UE or the network node based on the received indication. For example, the second network node 22 may slow down downlink sending data rate for the indicated congestion, and/or change route for UE bearer.

Fig. 12a is a combined signalling scheme and flowchart according to some embodiments.

Embodiments herein comprise one or more of the following steps:

Action 1221. An IAB donor CU-CP, i.e., the first network node 21 , may receive a (traffic) congestion indication from an IAB node, which is an intermediate IAB-DU for a UE DRB, e.g., the first intermediate radio network node 13. This UE DRB is either N:1 or 1 :1 mapped to, i.e., carried over, one of IAB node’s ingress and egress channels. This is an example of action 1201 in Fig. 11a. This congestion indication is delivered via the CP, e.g., in an F1AP message, and may comprise a further indication that, there is traffic congestion of the DL traffic pertaining to: a. One or more egress BH RLC channels served by said IAB node i. This implies that all DRBs mapped to this BH RLC channel(s) are experiencing congestion b. One or more BAP routing IDs pertaining to the traffic traversing said IAB node i. This implies that all DRBs whose packets are bearing these BAP routing ID(s) are experiencing congestion c. One or more destination BAP addresses pertaining to the traffic traversing said IAB node i. This implies that all packets destined to these BAP addresses are experiencing congestion d. One or more path IDs pertaining to the traffic traversing said IAB node i. This implies that all packets that are to be sent by the intermediate IAB node in a certain egress link associated to these path IDs are experiencing congestion e. A physical link, comprising all egress BH RLC channels, from the IAB node itself towards one or more child lAB-MTs. i. This means that all traffic carried on all egress BH RLC channels of said IAB node is experiencing congestion f. Any combination of the above points a. - e.

Alternatively, the congestion indication is sent from the access node of the UE DRB, in which case the granularity of congestion indication can be per DRB.

The congestion may be evaluated by an IAB node, such as the IAB DU, on the basis of a threshold on the traffic incoming at the IAB node, wherein the evaluation may be different depending on how the congestion indication is represented. For example, if the congestion indication is represented per BH RLC channel, the IAB node evaluates the incoming traffic associated to that BH RLC channel. If that is represented per path ID, the IAB node evaluates the incoming traffic which is associated to a certain path ID. In another example, the IAB DU evaluates the congestion on the basis of the packets currently buffered and available for transmission on the egress links.

Action 1222. Upon receiving the congestion indication, the IAB donor CU-CP, i.e., the first network node 21 , may determine the traffic pertaining to the congestion indication, with the goal of indicating this traffic to the IAB donor CU-UP. Based on the congestion indications described in points a. - e. in action 1221 , and based on its complete knowledge of routing, topology and traffic mapping in the network, the IAB donor CU-CP may determine: a. The DRB IDs of the congested traffic and the corresponding UE IDs. On the E1 interface, every UE context is identified by its gNB-CU-CP UE E1AP ID and gNB-CU-CP UE E1AP ID. b. The DSCP/DS values and/or flow labels and/or destination IP addresses and/or GTP- Tunnel Endpoint Identifiers (TEID) pertaining to the congested traffic. This is an example of action 1202 in Fig. 11a.

Note: this is possible because the IAB donor CLI-CP knows, for every DRB of every UE served, the associated set of intermediate IAB nodes, BH RLC channels and/or physical links, BAP routing IDs, PATH IDs, BAP destination addresses, DSCP/DS and flow label values and destination IP addresses.

It should be noted that intermediate nodes for a DRB do not see the DRB ID, the intermediate nodes only see the IDs of BH RLC channels carrying the DRBs and the intermediate nodes may see the BAP routing IDs of packets, but do not see which exact DRBs to which UEs are carried over that BH RLC channel and with that BAP routing ID.

Action 1223. The IAB donor CU-CP, i.e., the first network node 21 , may then determine one or more IAB donor CU-UPs, i.e., the second network nodes, that serve the traffic identified in action 1222. This is an example of action 1203 in Fig. 11a.

Action 1224. The first network node 21 , such as the IAB donor CU-CP, indicates to the second network node 22, such as the IAB donor CU-UP, the congested traffic by using one or more of the following indications or indicators, which are all understandable by the IAB donor CU-UPs receiving the indication: a. DRB IDs and gNB-CU-CP UE E1AP ID and gNB-CU-CP UE E1AP ID. The latter two to identify the UE that terminates this DRB; b. DSCP/DS values; c. Flow label values; d. Destination IP addresses.

This is an example of action 1204 in Fig. 11a.

Action 1225. Based on the indication from points a-d. in step 1224, the IAB donor CU-UP, i.e., the second network node 22, may perform measure(s) for congestion mitigation, e.g., slow down the downlink sending data rate for the indicated congested traffic. Alternatively, or additionally, the IAB donor CU-UPs may also change the route for these UE bearers, if indicated by the IAB donor CU-CP, for example, in case the route change only requires the change of DSCP/DS and/or flow label value and/or destination IP address, without reconfiguration at the intermediate IAB nodes, i.e., the existing configuration is valid. This is an example of action 1212 in Fig. 11b.

Example implementation in TS 38.463.

8.2.x Traffic Congestion Indication

8.2.X.1 General The gNB-CU-CP initiates the procedure by sending the CONGESTION INDICATION message to the gNB-CU-UP. The procedure uses non-U E-associated signalling

Fig. 12b: Traffic Congestion Indication procedure. Successful operation.

5 9.2.1.x TRAFFIC CONGESTION INDICATION

This message is sent by gNB-CU-CP, e.g. the first network node 21, to gNB-CU- UP, e.g. the second network node 22, to indicate traffic congestion.

Direction: gNB-CU-CP gNB-CU-UP.

0

Fig. 13a is a block diagram depicting the first network node 21 for handling communication in a wireless communications network 1 according to embodiments 5 herein. The first network node 21 is configured to handle CP signalling. The first network node 21 may comprise processing circuitry 1301 , e.g., one or more processors, configured to perform the methods herein.

The first network node 21 may comprise a transmitting unit 1302, e.g. a transmitter or a transceiver. The first network node 21 , the processing circuitry 1301, and/or the transmitting unit 1302 is configured to send the indication to the second network node 22, handle UP signalling, wherein the indication indicates the congestion associated with the CP related to the UE 10, or another network node. The indication may comprise one or more of the following: a. DRB ID and indication identifying the UE that terminates this DRB; b. DSCP or DS values; c. Flow label values; d. Destination IP addresses.

The first network node 21 may comprise a receiving unit 1303, e.g., a receiver or a transceiver. The first network node 21 , the processing circuitry 1301, and/or the receiving unit 1303 may be configured to receive the congestion indication, from another network node or the UE, e.g., for the UE DRB, delivered over the CP.

The first network node 21 may comprise an identifying unit 1304. The first network node 21 , the processing circuitry 1301, and/or the identifying unit 1304 may be configured to identify traffic pertaining to the congestion indication. The congestion indication may indicate traffic pertaining to one or more of the following: a. One or more egress BH RLC channels served by said network node; b. One or more BAP routing IDs pertaining to the traffic traversing said network node; c. One or more destination BAP addresses pertaining to the traffic traversing said network node; d. One or more path IDs pertaining to the traffic traversing said network node; and e. A physical link comprising all egress BH RLC channels from the network node itself towards one or more children nodes.

The first network node 21 may comprise a selecting unit 1305. The first network node 21, the processing circuitry 1301, and/or the selecting unit 1305 may be configured to determine which network node, handling user plane signalling, that serves the identified traffic. The first network node 21, the processing circuitry 1301, and/or the transmitting unit 1302 may be configured to send the indication to the determined network node. The first network node 21 further comprises a memory 1306. The memory 1306 comprises one or more units to be used to store data on, such as indications, congestion indications, contexts, measurements, thresholds, data related to nodes, and applications to perform the methods disclosed herein when being executed, and similar. Furthermore, the first network node 21 may comprise a communication interface 1309 such as comprising a transmitter, a receiver and/or a transceiver.

The methods according to the embodiments described herein for the first network node 21 are respectively implemented by means of, e.g., a computer program product 1307 or a computer program, comprising instructions, i.e., software code portions, which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the first network node 21. The computer program product 1307 may be stored on a computer-readable storage medium 1308, e.g., a disc, a universal serial bus (USB) stick or similar. The computer-readable storage medium 1308, having stored thereon the computer program product, may comprise the instructions which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the first network node. In some embodiments, the computer-readable storage medium may be a transitory or a non-transitory computer-readable storage medium. Thus, embodiments herein may disclose a first radio network node for handling communication in a wireless communications network, wherein the first network node comprises processing circuitry and a memory, said memory comprising instructions executable by said processing circuitry whereby said first network node is operative to perform any of the methods herein.

Fig. 13b is a block diagram depicting the second network node 22, such as a central unit node of a radio network node, e.g., a CU-UP, for handling communication in the wireless communications network 1 according to embodiments herein. The second network node 22 is configured to handle UP signalling. The first network node 21 may comprise the IAB-CU-CP, and the second network node 22 may comprise the IAB-CU- UP.

The second network node 22 may comprise processing circuitry 1311 , e.g. one or more processors, configured to perform the methods herein.

The second network node 22 may comprise a receiving unit 1312, e.g., a receiver or a transceiver. The second network node 22, the processing circuitry 1311, and/or the receiving unit 1312 is configured to receive the indication (control plane congestion indication) from the first network node 21 , handling CP signalling, wherein the indication indicates the congestion associated with the CP related to the UE or the other network node. The indication comprises one or more of the following: a. DRB ID and indication identifying the UE that terminates this DRB; b. DSCP or DS values; c. Flow label values; d. Destination IP addresses.

The second network node 22 may comprise a handling unit 1313. The second network node 22, the processing circuitry 1311 , and/or the handling unit 1313 is configured to handle communication related to the UE or the other network node based on the received indication. For example, the second network node 22 may handle the communication by slowing down downlink sending data rate for the indicated congestion or by changing the route for UE bearer(s) and/or take one or more measures for congestion mitigation.

The second network node 22 further comprises a memory 1315. The memory 1315 comprises one or more units to be used to store data on, such as indications, contexts, measurements, thresholds, data related to nodes, and applications to perform the methods disclosed herein when being executed, and similar. Furthermore, the second network node 22 may comprise a communication interface 1318 such as comprising a transmitter, a receiver and/or a transceiver.

The methods according to the embodiments described herein for the second network node 22 are respectively implemented by means of, e.g., a computer program product 1316 or a computer program, comprising instructions, i.e. , software code portions, which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the second network node 22. The computer program product 1316 may be stored on a computer-readable storage medium 1317, e.g., a disc, a universal serial bus (USB) stick or similar. The computer-readable storage medium 1317, having stored thereon the computer program product, may comprise the instructions which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the second network node 22. In some embodiments, the computer-readable storage medium may be a transitory or a non-transitory computer-readable storage medium. Thus, embodiments herein may disclose a second network node for handling communication in a wireless communications network, wherein the second network node comprises processing circuitry and a memory, said memory comprising instructions executable by said processing circuitry whereby said second network node is operative to perform any of the methods herein.

In some embodiments a more general term “radio network node” is used and it can correspond to any type of radio-network node or any network node, which communicates with a wireless device and/or with another network node. Examples of network nodes are NodeB, MeNB, SeNB, a network node belonging to Master cell group (MCG) or Secondary cell group (SCG), base station (BS), multi-standard radio (MSR) radio node such as MSR BS, eNodeB, network controller, radio-network controller (RNC), base station controller (BSC), relay, donor node controlling relay, base transceiver station (BTS), access point (AP), transmission points, transmission nodes, Remote radio Unit (RRU), Remote Radio Head (RRH), nodes in distributed antenna system (DAS), etc.

In some embodiments the non-limiting term wireless device or user equipment (UE) is used and it refers to any type of wireless device communicating with a network node and/or with another wireless device in a cellular or mobile communication system. Examples of UE are loT capable device, target device, device to device (D2D) UE, proximity capable UE (aka ProSe UE), machine type UE or UE capable of machine to machine (M2M) communication, Tablet, mobile terminals, smart phone, laptop embedded equipped (LEE), laptop mounted equipment (LME), USB dongles etc.

Embodiments are applicable to any radio access technology (RAT) or multi-RAT systems, where the wireless device receives and/or transmit signals (e.g. data) e.g. New Radio (NR), Wi-Fi, Long Term Evolution (LTE), LTE-Advanced, Wideband Code Division Multiple Access (WCDMA), Global System for Mobile communications/enhanced Data rate for GSM Evolution (GSM/EDGE), Worldwide Interoperability for Microwave Access (WiMax), or Ultra Mobile Broadband (UMB), just to mention a few possible implementations.

As will be readily understood by those familiar with communications design, that functions means or circuits may be implemented using digital logic and/or one or more microcontrollers, microprocessors, or other digital hardware. In some embodiments, several or all of the various functions may be implemented together, such as in a single application-specific integrated circuit (ASIC), or in two or more separate devices with appropriate hardware and/or software interfaces between them. Several of the functions may be implemented on a processor shared with other functional components of a wireless device or network node, for example. Alternatively, several of the functional elements of the processing means discussed may be provided through the use of dedicated hardware, while others are provided with hardware for executing software, in association with the appropriate software or firmware. Thus, the term “processor” or “controller” as used herein does not exclusively refer to hardware capable of executing software and may implicitly include, without limitation, digital signal processor (DSP) hardware and/or program or application data. Other hardware, conventional and/or custom, may also be included. Designers of communications devices will appreciate the cost, performance, and maintenance trade-offs inherent in these design choices.

Fig. 14 shows a Telecommunication network connected via an intermediate network to a host computer in accordance with some embodiments. With reference to Fig. 14, in accordance with an embodiment, a communication system includes telecommunication network 3210, such as a 3GPP-type cellular network, which comprises access network 3211, such as a radio access network, and core network 3214. Access network 3211 comprises a plurality of base stations 3212a, 3212b, 3212c, such as NBs, eNBs, gNBs or other types of wireless access points being examples of the radio network node 12 above, each defining a corresponding coverage area 3213a, 3213b, 3213c. Each base station 3212a, 3212b, 3212c is connectable to core network 3214 over a wired or wireless connection 3215. A first UE 3291 located in coverage area 3213c is configured to wirelessly connect to, or be paged by, the corresponding base station 3212c. A second UE 3292 in coverage area 3213a is wirelessly connectable to the corresponding base station 3212a. While a plurality of UEs 3291 , 3292 are illustrated in this example being examples of the wireless device 10 above, the disclosed embodiments are equally applicable to a situation where a sole UE is in the coverage area or where a sole UE is connecting to the corresponding base station 3212.

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

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

Fig. 15 shows a host computer communicating via a base station and with a user equipment over a partially wireless connection in accordance with some embodiments Example implementations, in accordance with an embodiment, of the UE, base station and host computer discussed in the preceding paragraphs will now be described with reference to Fig 15. In communication system 3300, host computer 3310 comprises hardware 3315 including communication interface 3316 configured to set up and maintain a wired or wireless connection with an interface of a different communication device of communication system 3300. Host computer 3310 further comprises processing circuitry 3318, which may have storage and/or processing capabilities. In particular, processing circuitry 3318 may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. Host computer 3310 further comprises software 3311, which is stored in or accessible by host computer 3310 and executable by processing circuitry 3318. Software 3311 includes host application 3312. Host application 3312 may be operable to provide a service to a remote user, such as UE 3330 connecting via OTT connection 3350 terminating at UE 3330 and host computer 3310. In providing the service to the remote user, host application 3312 may provide user data which is transmitted using OTT connection 3350. Communication system 3300 further includes base station 3320 provided in a telecommunication system and comprising hardware 3325 enabling it to communicate with host computer 3310 and with UE 3330. Hardware 3325 may include communication interface 3326 for setting up and maintaining a wired or wireless connection with an interface of a different communication device of communication system 3300, as well as radio interface 3327 for setting up and maintaining at least wireless connection 3370 with UE 3330 located in a coverage area (not shown in Fig. 15) served by base station 3320. Communication interface 3326 may be configured to facilitate connection 3360 to host computer 3310. Connection 3360 may be direct or it may pass through a core network (not shown in Fig 15) of the telecommunication system and/or through one or more intermediate networks outside the telecommunication system. In the embodiment shown, hardware 3325 of base station 3320 further includes processing circuitry 3328, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. Base station 3320 further has software 3321 stored internally or accessible via an external connection.

Communication system 3300 further includes UE 3330 already referred to. It’s hardware 3333 may include radio interface 3337 configured to set up and maintain wireless connection 3370 with a base station serving a coverage area in which UE 3330 is currently located. Hardware 3333 of UE 3330 further includes processing circuitry 3338, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. UE 3330 further comprises software 3331, which is stored in or accessible by UE 3330 and executable by processing circuitry 3338. Software 3331 includes client application 3332. Client application 3332 may be operable to provide a service to a human or non-human user via UE 3330, with the support of host computer 3310. In host computer 3310, an executing host application 3312 may communicate with the executing client application 3332 via OTT connection 3350 terminating at UE 3330 and host computer 3310. In providing the service to the user, client application 3332 may receive request data from host application 3312 and provide user data in response to the request data. OTT connection 3350 may transfer both the request data and the user data. Client application 3332 may interact with the user to generate the user data that it provides.

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

In Fig. 15, OTT connection 3350 has been drawn abstractly to illustrate the communication between host computer 3310 and UE 3330 via base station 3320, without explicit reference to any intermediary devices and the precise routing of messages via these devices. Network infrastructure may determine the routing, which it may be configured to hide from UE 3330 or from the service provider operating host computer

3310, or both. While OTT connection 3350 is active, the network infrastructure may further take decisions by which it dynamically changes the routing, e.g., on the basis of load balancing consideration or reconfiguration of the network.

Wireless connection 3370 between UE 3330 and base station 3320 is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to UE 3330 using OTT connection 3350, in which wireless connection 3370 forms the last segment. More precisely, the teachings of these embodiments make it possible for handling or managing congestion of communication in an efficient manner and thereby provide benefits such as reduced user waiting time, and better responsiveness.

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 OTT connection 3350 between host computer 3310 and UE 3330, in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring OTT connection 3350 may be implemented in software 3311 and hardware 3315 of host computer 3310 or in software 3331 and hardware 3333 of UE 3330, or both. In embodiments, sensors (not shown) may be deployed in or in association with communication devices through which OTT connection 3350 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software

3311, 3331 may compute or estimate the monitored quantities. The reconfiguring of OTT connection 3350 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not affect base station 3320, and it may be unknown or imperceptible to base station 3320. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signalling facilitating host computer 3310 s measurements of throughput, propagation times, latency and the like. The measurements may be implemented in that software 3311 and 3331 causes messages to be transmitted, in particular empty or ‘dummy’ messages, using OTT connection 3350 while it monitors propagation times, errors etc.

Fig. 16 shows methods implemented in a communication system including a host computer, a base station and a user equipment in accordance with some embodiments.

Fig. 16 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Fig. 14 and Fig. 15. For simplicity of the present disclosure, only drawing references to Fig. 16 will be included in this section. In step 3410, the host computer provides user data. In substep 3411 (which may be optional) of step 3410, the host computer provides the user data by executing a host application. In step 3420, the host computer initiates a transmission carrying the user data to the UE. In step 3430 (which may be optional), the base station transmits to the UE the user data which was carried in the transmission that the host computer initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In step 3440 (which may also be optional), the UE executes a client application associated with the host application executed by the host computer.

Fig. 17 shows methods implemented in a communication system including a host computer, a base station and a user equipment in accordance with some embodiments.

Fig. 17 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Fig. 14 and Fig. 15. For simplicity of the present disclosure, only drawing references to Fig. 17 will be included in this section. In step 3510 of the method, the host computer provides user data. In an optional substep (not shown) the host computer provides the user data by executing a host application. In step 3520, the host computer initiates a transmission carrying the user data to the UE. The transmission may pass via the base station, in accordance with the teachings of the embodiments described throughout this disclosure. In step 3530 (which may be optional), the UE receives the user data carried in the transmission. Fig. 18 shows methods implemented in a communication system including a host computer, a base station and a user equipment in accordance with some embodiments.

Fig. 18 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Fig. 14 and Fig. 15. For simplicity of the present disclosure, only drawing references to Fig. 18 will be included in this section. In step 3610 (which may be optional), the UE receives input data provided by the host computer. Additionally or alternatively, in step 3620, the UE provides user data. In substep 3621 (which may be optional) of step 3620, the UE provides the user data by executing a client application. In substep 3611 (which may be optional) of step 3610, the UE executes a client application which provides the user data in reaction to the received input data provided by the host computer. In providing the user data, the executed client application may further consider user input received from the user. Regardless of the specific manner in which the user data was provided, the UE initiates, in substep 3630 (which may be optional), transmission of the user data to the host computer. In step 3640 of the method, the host computer receives the user data transmitted from the UE, in accordance with the teachings of the embodiments described throughout this disclosure.

Fig. 19 show methods implemented in a communication system including a host computer, a base station and a user equipment in accordance with some embodiments.

Fig. 19 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Fig. 14 and Fig. 15. For simplicity of the present disclosure, only drawing references to Fig. 19 will be included in this section. In step 3710 (which may be optional), in accordance with the teachings of the embodiments described throughout this disclosure, the base station receives user data from the UE. In step 3720 (which may be optional), the base station initiates transmission of the received user data to the host computer. In step 3730 (which may be optional), the host computer receives the user data carried in the transmission initiated by the base station.

Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as read-only memory (ROM), random-access memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure.

It will be appreciated that the foregoing description and the accompanying drawings represent non-limiting examples of the methods and apparatus taught herein. As such, the apparatus and techniques taught herein are not limited by the foregoing description and accompanying drawings. Instead, the embodiments herein are limited only by the following claims and their legal equivalents.

Claims

1. A method performed by a first network node (21) for handling communication in a wireless communications network (1), wherein the first network node (21) handles control plane, CP, signalling, the method comprising sending (1204) an indication to a second network node (22), handling user plane signalling, wherein the indication indicates a congestion associated with a CP related to a user equipment, UE, or another network node.

2. The method according to claim 1 , further comprising receiving (1201) a congestion indication, from another network node or a UE delivered over the CP.

3. The method according to claim 2, further comprising identifying (1202) traffic pertaining to the congestion indication; determining (1203), which network node, handling user plane signalling, that serves the identified traffic; and the indication is sent to the determined network node.

4. The method according to any of the claims 2-3, wherein the congestion indication indicates traffic pertaining to one or more of the following: a. One or more egress backhaul, BH, radio link control, RLC, channels served by said network node; b. One or more Backhaul Adaptation Protocol, BAP, routing IDs pertaining to the traffic traversing said network node; c. One or more destination BAP addresses pertaining to the traffic traversing said network node; d. One or more path IDs pertaining to the traffic traversing said network node; and e. A physical link comprising all egress BH RLC channels from the network node itself towards one or more children nodes.

5. The method according to any of the claims 1-4, wherein the indication comprises one or more of the following: a. Data radio bearer, DRB, ID and indication identifying the UE that terminates this DRB; b. differentiated services code point, DSCP, or differentiated service, DS, values; c. Flow label values; d. Destination IP addresses.

6. A method performed by a second network node (22) for handling communication in a wireless communications network (1), wherein the second network node (22) handles user plane, UP, signalling, the method comprising receiving (1211) an indication from a first network node (21), handling control plane, CP, signalling, wherein the indication indicates a congestion associated with a CP related to a user equipment, UE, or another network node; and handling (1212) communication related to the UE or the other network node based on the received indication.

7. The method according to claim 6, wherein handling (1212) communication comprises slowing down downlink sending data rate for the indicated congestion.

8. The method according to any of the claims 6-7, wherein handling (1212) communication comprises changing route for a UE bearer.

9. The method according to any of the claims 6-8, wherein the indication comprises one or more of the following: a. Data radio bearer, DRB, ID and indication identifying the UE that terminates this DRB; b. Differentiated services code point, DSCP, or differentiated service, DS, values; c. Flow label values; d. Destination IP addresses.

10. The method according to any of the claims 6-9, wherein the first network node (21) comprises an integrated access backhaul-central unit-control plane, IAB- CU-CP, and the second network node (22) comprises an integrated access backhaul-central unit-user plane, IAB-CU-UP.

11. A first network node (21) for handling communication in a wireless communications network (1), wherein the first network node (21) is configured to handle control plane, CP, signalling, and wherein the first network node (21) is configured to: send an indication to a second network node (22), handling user plane signalling, wherein the indication indicates a congestion associated with a CP related to a user equipment, UE, or another network node.

12. The first network node (21) according to claim 11 , wherein the first network node (21) is configured to receive a congestion indication, from another network node or a UE delivered over the CP.

13. The first network node (21) according to claim 12, wherein the first network node (21) is configured to: identify traffic pertaining to the congestion indication; and determine, which network node, handling user plane signalling, that serves the identified traffic; and the indication is sent to the determined network node.

14. The first network node (21) according to any of the claims 12-13, wherein the congestion indication indicates traffic pertaining to one or more of the following: a. One or more egress backhaul, BH, radio link control, RLC, channels served by said network node; b. One or more Backhaul Adaptation Protocol, BAP, routing IDs pertaining to the traffic traversing said network node; c. One or more destination BAP addresses pertaining to the traffic traversing said network node; d. One or more path IDs pertaining to the traffic traversing said network node; and e. A physical link comprising all egress BH RLC channels from the network node itself towards one or more children nodes.

15. The first network node according to any of the claims 11-14, wherein the indication comprises one or more of the following: a. Data radio bearer, DRB, ID and indication identifying the UE that terminates this DRB; b. differentiated services code point, DSCP, or differentiated service, DS, values; c. Flow label values; d. Destination IP addresses.

16. A second network node (22) for handling communication in a wireless communications network, wherein the second network node (22) is configured to handle user plane, UP, signalling, and wherein the second network node (22) is configured to: receive an indication from a first network node (21), handling control plane, CP, signalling, wherein the indication indicates a congestion associated with a CP related to a user equipment, UE, or another network node; and handle communication related to the UE or the other network node based on the received indication.

17. The second network node (22) according to claim 16, wherein the second network node (22) is configured to handle the communication by slowing down downlink sending data rate for the indicated congestion.

18. The second network node (22) according to any of the claims 16-17, wherein the second network node (22) is configured to handle the communication by changing route for UE bearer.

19. The second network node (22) according to any of the claims 16-18, wherein the indication comprises one or more of the following: a. Data radio bearer, DRB, ID and indication identifying the UE that terminates this DRB; b. differentiated services code point, DSCP, or differentiated service, DS, values; c. Flow label values; d. Destination IP addresses. The second network node (22) according to any of the claims 16-19, wherein the first network node comprises an integrated access backhaul-central unitcontrol plane, IAB-CU-CP, and the second network node comprises an integrated access backhaul-central unit-user plane, IAB-CU-UP. A computer program product comprising instructions, which, when executed on at least one processor, cause the at least one processor to carry out the method according to any of the claims 1-10, as performed by the first network node (21) and the second network node (22), respectively. A computer-readable storage medium, having stored thereon a computer program product comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to any of the claims 1-10, as performed by the first network node (21) and the second network node (22), respectively.