WO2025210178A1

WO2025210178A1 - Managing authorization of a wireless access and backhaul node

Info

Publication number: WO2025210178A1
Application number: PCT/EP2025/059173
Authority: WO
Inventors: Pierre Visa; Yacine El Kolli; Pascal Lagrange
Original assignee: Canon Europe Ltd; Canon Inc
Current assignee: Canon Europe Ltd; Canon Inc
Priority date: 2024-04-04
Filing date: 2025-04-03
Publication date: 2025-10-09
Anticipated expiration: 2026-10-04

Abstract

Methods and apparatus for use in managing authorization of a WAB node (e.g. a mobile WAB node) is disclosed. The mobile WAB node includes a MT component and a gNB component for serving one or more User Equipment, UE. A method at the mobile WAB node comprises receiving authorization status information for indicating whether the mobile WAB node is authorized to operate as a mobile WAB node. A method at an AMF entity comprises sending authorization status information for indicating whether the mobile WAB node is authorized to operate as a mobile WAB node. The authorization status information may include at least one of: cause information for indicating a cause in a case where the mobile WAB node is not authorized to operate; information for indicating the mobile WAB node is authorized to operate as a mobile WAB node and the authorization is limited to providing local services; MW AB authorization status information for indicating whether the gNB component of the mobile WAB node is authorized to serve one or more UE and/or for indicating whether the MT component of the mobile WAB node is authorized to connect to one or more Public Land Mobile Networks, PLMNs.

Description

MANAGING AUTHORIZATION OF A WIRELESS ACCESS AND BACKHAUL NODE

FIELD OF THE INVENTION

The present invention generally relates to methods for use in managing authorization of a Wireless Access Backhaul (WAB) node of a wireless communication system. For example, the disclosure relates to methods for use in a process for managing the mobility of nodes of a wireless communication system involving at least one mobile Wireless Access Backhaul, WAB, nodes.

BACKGROUND

Wireless communication systems are largely deployed to address a wide range of applications, from mobile broadband, massive machine type communications to Ultra Reliable Low Latency Communications (URLLC). Such systems allow a plurality of user equipment (UE) or mobile terminals to share the wireless medium to exchange several types of data content (e.g. video, voice, messaging . . .) over a radio access network (RAN) through one or more base stations (gNBs). The base stations are conventionally wired-connected (e.g. through fiber) to a core network, forming an intermediate network, named backhaul (BH).

Examples of such wireless multiple-access communication systems include systems based on 3rd generation partnership project (3GPP - RTM) standards, such as fourth-generation (4G) Long Term Evolution (LTE) or recent fifth-generation (5G) New Radio (NR) systems, or systems-based IEEE 802.11 standards, such as WiFi.

The demand for network densification increases due to the rising number of users and higher throughput requirement.

Facing the issues of high deployment costs and time of the wired backhaul networks with network densification, 3GPP has proposed, from release 16 for 5G NR, a wireless backhaul, also known as Integrated Access and Backhaul, IAB, where part of the wireless (i.e. radio) spectrum is used for the backhaul connection of base stations instead of fiber. The wireless backhaul communications (between base stations) may use the same radio resources as access communications (between a base station and UEs).

IAB turns out to be a competitive alternative to the fiber-based backhauling in dense areas or areas difficult to cover, as it allows scalable and rapid installations without the burden of cabling the base stations.

IAB is most likely to operate in the millimeter wave (mmWave) band to achieve the required Gbps (gigabits per second) data rate. Urban environments are usually characterised by a high density of users along with the presence of a significant number of vehicles (e.g. public/private passengers transportation, goods delivery, food trucks . . .). The speed of some of the vehicles may be pretty low or at least similar to pedestrian speed and some of these vehicles may even be temporarily stationary. Some of these vehicles (e.g. buses, trains or trams), may have predictable routes and / or limited mobility areas (e.g. some vehicles, such as food trucks or promotional vehicles, may be located outside stadiums or show venues) while others may have predictable stationary locations (e.g. taxis).

3GPP is considering that such vehicles could offer an opportunity to increase network coverage and connectivity to the UEs inside the vehicles, or even to UEs in proximity to the vehicles, by installing on these vehicles on-board base stations (or base station elements) that would act as relays. These relays would rely on 5G wireless backhaul (typically IAB, or Integrated Access & Backhaul) for connecting to a fixed donor device. Thus, based upon the fixed IAB foundations set out in Releases 16 and 17, 3 GPP is now considering Mobile IAB systems and architecture, as a part of the Release 18 framework, in order to address scenarios focusing on mobile lAB-nodes mounted on vehicles (for example, a bus, a train, a taxi). In such scenarios, mobile lAB-nodes can also be referred to as Vehicle Mounted Relays (VMR), providing 5G coverage/capacity to on-board and/or surrounding UEs. The technical benefits of using vehicle relays include, among others, the ability of the relay vehicle to get better coverage than the nearby UE, thanks to better RF/antenna capabilities, thus providing the UE with a better link to the macro network. Additionally, a vehicle relay is expected to have less stringent power / battery constraints than the UEs.

Some enhancements further considered by 3GPP for Release 19, consider the need for 5G access for UEs onboard aircrafts, cruise ships, helicopters and vehicles in remote areas with limited sky visibility (e.g. where terrestrial cellular coverage or Wi-Fi coverage is not available), support for onboard/on-site mobile edge computing (MEC), local services, and direct local inter-UE communications, or local gNB deployment in public safety or disaster recovery scenarios. The backhauling links for the base stations providing the 5G access in such scenarios, which base stations are referred to as mobile wireless access backhaul (MW AB) nodes, would then be operated over either a terrestrial network (TN), or a non-terrestrial network (NTN), with a possibility to handover communications from a terrestrial network to a non-terrestrial network and vice-versa. Such base stations can be referred to as Wireless Access Backhaul (WAB) nodes, or WAB nodes, or mobile WAB nodes, or MW AB nodes.

As part of these wireless backhauling enhancements, 3GPP is also considering some evolution to the former LTE-based Femto framework, including a new 5G Femto or 5G Femtocell that would offer 5G indoor coverage improvement while allowing high bandwidth and throughput at home for new immersive applications such as AR/VR/MR gaming, e-sports, UHD 8K video, telepresence, etc. It can be noted that a MW AB node may deploy 5G Femto cells to serve UEs inside vehicles.

While moving, a MW AB node may lose the backhaul connectivity with the serving base station (which may be terrestrial or non-terrestrial), the MW AB node may experience a radio link failure (RLF), and as a result, the MW AB node may then perform a reestablishment procedure with a new base station. To prevent situations with radio link failure, when the backhaul link is becoming weak with a serving base station, the MW AB node may be handed over from the serving (source) base station to a target base station. Prior to the handover procedure, dual -connectivity may be setup for a MW AB node, so that it will be served by two base stations at the same time, with one master base station and a secondary base station. Such actions (reestablishment, handover, dualconnection) would preserve the connectivity of the UEs served by the MW AB node, and so guarantee service continuity at the UEs.

A MW AB node that uses a Public Land Mobile Network (PLMN) to connect to the network through a wireless backhaul link, is subject to authorization. Besides, the MW AB has to serve UEs through one or several PLMNs that may be different from the PLMN used by the MW AB node for the backhaul link. Thus, the authorization for the MW AB node is related to the authorization to use the backhaul link and the authorization to operate as a base station to serve the UEs. The authorization status depends on the subscription associated to the MW AB node, and on the geographical location of the MW AB node. The authorization status for a MW AB node may also be subject to changes (i.e. transition from authorized to non-authorized, or from non-authorized to authorized). The authorization is handled in the core network either by AMF (Access and Mobility management Function), or by OAM (Operations, Administration and Maintenance).

There is therefore a need for a MW AB node to be informed at different times about its authorization status.

SUMMARY

In accordance with an aspect of the invention, there is provided a method for use in managing authorization of a mobile wireless access backhaul, WAB, node, the mobile WAB node including a mobile termination, MT, component and a gNB component for serving one or more User Equipment, UE, the method at the mobile WAB node comprising: receiving authorization status information for indicating whether the mobile WAB node is authorized to operate as a mobile WAB node.

In accordance with an aspect of the invention, there is provided a method for use in managing authorization of a mobile wireless access backhaul, WAB, node, the mobile WAB node including a mobile termination, MT, component and a gNB component for serving one or more User Equipment, UE, the method at an Access and Mobility management Function, AMF, entity comprising: sending authorization status information for indicating whether the mobile WAB node is authorized to operate as a mobile WAB node.

In accordance with an aspect of the invention, there is provided a method for use in managing authorization of a mobile wireless access backhaul, WAB, node, the mobile WAB node including a mobile termination, MT, component and a gNB component for serving one or more User Equipment, UE, the method at the mobile WAB node comprising: sending, to an Access and Mobility management function, AMF, entity of a core network, a setup request including information for indicating the mobile WAB node intends to operate as a mobile WAB node and information for indicating a location of the mobile WAB node; receiving authorization status information for indicating whether the mobile WAB node is authorized to operate as a mobile WAB node.

In accordance with an aspect of the invention, there is provided a method for use in managing authorization of a wireless access backhaul, WAB, node, the WAB node including a mobile termination, MT, component and a gNB component for serving one or more User Equipment, UE, wherein in a case where the gNB component of the WAB node is in an authorized state in which the gNB component of the WAB node is authorized to serve UEs, the method at the WAB node comprises: receiving information indicating the gNB component of the WAB node is not authorized to serve UEs; after receiving the information, initiating handover of the UEs served by the gNB component of the WAB node.

In an example, PDU sessions of the MT component of the WAB node may be released after termination or completion of operations related to handover and removal of Xn and NG connections. In other words, PDU sessions of the MT component of the WAB node may be maintained until termination or completion of operations related to the handover of UEs served by the WAB node, and related to the removal of Xn and NG connections of the WAB node.

In an example, there is provided a method for use in managing authorization of a mobile wireless access backhaul, WAB, node, the mobile WAB node including a mobile termination, MT, component and a gNB component for serving one or more User Equipment, UE, wherein in a case where the mobile WAB node is in an authorized state in which the mobile WAB node is authorized to operate as a mobile WAB node, the method at the mobile WAB node comprises: receiving authorization status information indicating the mobile WAB node is not authorized to operate as a mobile WAB node; after receiving authorization status information indicating the mobile WAB node is not authorized to operate as a mobile WAB node, sending a reset message. In accordance with an aspect of the invention, there is provided a method for use in managing authorization of a mobile wireless access backhaul, WAB, node, the mobile WAB node including a mobile termination, MT, component and a gNB component for serving one or more User Equipment, UE, wherein in a case where the mobile WAB node is in an authorized state in which the mobile WAB node is authorized to operate as a mobile WAB node, the method at the mobile WAB node comprises: receiving authorization status information indicating the mobile WAB node is not authorized to operate as a mobile WAB node; after receiving authorization status information indicating the mobile WAB node is not authorized to operate as a mobile WAB node, initiating handover of the UEs served by the mobile WAB node; on completion of handover of the UEs served by the mobile WAB node, or on expiry of a certain time period for performing a handover procedure for the UEs served by the mobile WAB node, terminating the handover procedure.

In accordance with an aspect of the present invention, there is provided an apparatus for a WAB node as recited in claim 73 of the accompanying claims.

In accordance with an aspect of the present invention, there is provided an apparatus for an Access and Mobility management Function, AMF, entity as recited in claim 74 of the accompanying claims.

By providing to the mobile WAB node authorization status information for indicating whether the mobile WAB node is authorized to operate as a mobile WAB node, the authorization of the mobile WAB node can be managed and the mobile WAB node can determine whether its authorized or not to operate as a mobile WAB node and can operate accordingly. In an example, where the authorization status information includes information such as cause information, and/or information that the authorization is limited to providing local services, and/or gNB authorization status information and/or MT authorization status information, the additional information provided enables the mobile WAB node to operate properly in accordance with the received information. In the following description and claims some new mechanisms are described to provide the authorization status information to the mobile WAB node when it registers to the network but also along its operation moving over long distances. Providing a global status indicating solely that the WAB node is “authorized” or “not authorized” would prevent the MW AB node to operate with limited services.

For instance, separating the authorization status of the MWAB-MT and the MWAB-gNB would allow to not authorize the MWAB-gNB to serve UEs (e.g. because of the region where the MW AB node is currently located), but to authorize the MWAB-MT to connect to the RAN and to be handed over while moving until the MWAB-node enters a new region where the MWAB-gNB is authorized to serve UEs. If the MWAB-MT is not authorized and is deregistered, it would not be able to receive an updated authorization status.

Besides, allowing for instance the MWAB-gNB to operate local services only would allow the MWAB-gNB to serve onboard UEs (e.g. where the MW AB node and UEs are located in a cruise ship or in a plane) providing access to onboard servers and/or enabling communications between onboard UEs, despite the MW AB node being not allowed to provide access to the data network through a backhaul link.

In one aspect of the invention, the authorization status for a MW AB node is checked when the MWAB-gNB establishes an interface with an AMF for served UEs, in addition to the authorization status determined when the MWAB-MT registered to the network or when the MWAB-MT switched to a new cell (because of handover or radio link failure). The advantage of this is that a double check can be made as to whether the MWAB-gNB is actually serving UEs while it was not authorized to do so.

The invention in general relates to signaling to inform a MW AB node about its authorization status to operate as a MW AB node. Examples of how the MW AB node may behave when the authorization status changes, from authorized to non-authorized, and from non-authorized to authorized are also provided.

This has particular relevance to a mobile communications network (e.g. 5G) utilizing MW AB nodes. Other applications including other wireless communication networks such as WiFi where a mobile base station, or relay, or access point may be utilized.

In the example of a mobile communications network such as 5G, the messages are exchanged between the MW AB node and the core network with a function in charge of determining the authorization status of the MW AB node. Other network nodes like base stations may be involved to relay the protocol messages. Other wireless networks may have equivalent nodes and the invention may equally apply to these.

It is noted that the terms WAB node and mobile WAB node may be used interchangeably herein.

Further example features of the invention are described in other independent and dependent claims.

Any feature in one aspect of the invention may be applied to other aspects of the invention, in any appropriate combination. In particular, method aspects may be applied to apparatus/device/unit aspects, and vice versa.

Furthermore, features implemented in hardware may be implemented in software, and vice versa. Any reference to software and hardware features herein should be construed accordingly. For example, in accordance with other aspects of the invention, there are provided a computer program comprising instructions which, when the program is executed by one or more processing units, cause the one or more processing units to carry out the method of any aspect or example described above and a computer readable storage medium carrying the computer program.

BRIEF DESCRIPTION OF THE DRAWINGS

Different aspects of the invention will now be described, by way of example only, and with reference to the following drawings in which:

Figure 1 is a schematic diagram of a communication system in which the present invention may be implemented according to one or more example embodiments;

Figure 2 is a simplified schematic diagram of a 5G system in which the present invention may be implemented according to one or more example embodiments;

Figure 3 is a simplified schematic diagram of a 5G system involving a Mobile Wireless Access Backhaul (MW AB) node, and in which the present invention may be implemented according to one or more example embodiments.

Figure 4 is a block schematic diagram of an example network node or base station in accordance with one or more embodiments of the invention;

Figure 5 is a simplified schematic diagram showing an example of a wireless communication system, including a WAB network or WAB network system, in which embodiments and examples of embodiments of the present invention may be implemented;

Figure 6 is a schematic and simplified diagram showing an example message flow for performing the RRC connection setup of a MW AB node while providing the authorization status, in accordance with one or more embodiments of the invention;

Figure 7 is a schematic and simplified diagram showing an example message flow for performing the NGAP connection setup of a MW AB node while providing the authorization status, in accordance with one or more embodiments of the invention;

Figure 8 is a schematic and simplified diagram showing an example message flow for providing an update of the authorization status of a MW AB node, in accordance with one or more embodiments of the invention;

Figure 9 is a schematic and simplified diagram showing an example message flow for providing an update of the authorization status of a MW AB node, in accordance with one or more embodiments of the invention;

Figure 10 is a schematic and simplified diagram showing an example message flow for performing a Xn handover of a MW AB node while providing an update of the authorization status, in accordance with one or more embodiments of the invention; Figure 11 is a schematic and simplified diagram showing an example message flow for performing a NG handover of a MW AB node while providing and update of the authorization status at the MW AB node, in accordance with one or more embodiments of the invention;

Figure 12 is a schematic and simplified diagram showing an example message flow for connection reestablishment for a MW AB node while providing an update of the authorization status at the MW AB node, in accordance with one or more embodiments of the invention;

Figure 13 is a schematic and simplified diagram showing an example message flow following the transition from “authorized” to “not authorized” at a MW AB node, in accordance with one or more embodiments of the invention;

Figure 14a is a flowchart of an example method for managing at a MW AB node the reception of its authorization status in accordance with one or more embodiments of the invention;

Figure 14b is a flowchart of an example method for managing at an AMF the authorization status related to a MW AB node connecting to the network in accordance with one or more embodiments of the invention;

Figure 14c is a flowchart of an example method for managing at an AMF the update of authorization status related to a MW AB node in accordance with one or more embodiments of the invention;

Figure 15 is a schematic and simplified diagram showing an example message flow following the transition from “authorized” to “not authorized” at a WAB-MT, in accordance with one or more embodiments of the invention;

Figure 16 is a schematic and simplified diagram showing an example message flow following the transition from “not authorized” to “authorized” at a WAB-MT, in accordance with one or more embodiments of the invention;

Figure 17 is a schematic and simplified diagram showing an example message flow following the transition from “authorized” to “not authorized” at a WAB-gNB, in accordance with one or more embodiments of the invention;

Figure 18 is a schematic and simplified diagram showing an example message flow following the transition from “not authorized” to “authorized” at a WAB-gNB, in accordance with one or more embodiments of the invention.

DETAILED DESCRIPTION

Figure 1 illustrates an example communication system 100 in which the present invention may be implemented according to one or more embodiments. As depicted, the example system 100 is a wireless communication system, in particular a mobile radio communication system such as a fifth-generation (5G) New Radio (NR) system including a Wireless Access Backhaul (WAB) communication system or network. Although in the following description, embodiments and examples of embodiments of the present invention will be described with respect to a 5G NR system, it will be appreciated that it is not intended that the present invention is limited to 5G NR systems and may be used in any wireless communication systems having an integrated access and backhaul communication system which shares radio resources for wireless access links and wireless backhaul links.

The system 100 comprises a plurality ofUEs (User Equipment) 111, 112, 113, 121, 122, 123, 131, 132, 133, 134, 141, 142, 143, 151, 152, 153 and 154, a communication satellite 160, a satellite dish 101, a remote core network 170, three fixed Base Stations 102, 103 and 104, a plurality of Mobile Wireless Access Backhaul (MW AB) nodes 110 (mounted on plane 161), 120a and 120b (mounted on train 162), 140 (mounted on Unmanned Aerial Vehicle (UAV) UAV 164) and 150 (mounted on backpack 165 or other carrier that can be carried by a user (e.g. in a disaster zone)), and a Wireless Access Backhaul (WAB) node 130 (or Home gNB, mounted in house 163) which is fixed but based on the same architecture as a MW AB node. In more general terms, a MW AB node may be mounted on or in a vehicle (such as a train, bus, taxi, tram, etc.) and/or an aircraft or flying vehicle (such as a plane, UAV, helicopter, etc. ) and/or a building (such as a house, enterprise/company/office building, hotel building, airport building, sports/event buildings, shopping centre building, etc..) and/or a portable carrier that can be carried by a user (such as a backpack, bag, etc), for example, in a disaster zone or for public safety or for emergency services, and/or public infrastructure elements or units (such as lamp posts, traffic lights, etc.). In an example where the MW AB node is implemented in a Femto network, a WAB node functions as a 5G Femto node and may be mounted at a building (such as a house, enterprise/company/office building, hotel building, airport building, sports/event buildings, shopping centre building, etc..) and/or public infrastructure elements or units (such as lamp posts, traffic lights, etc.). When it is a mobile base station, a WAB node is also referred to as a Mobile WAB (MW AB) node.

Some examples of UEs include smartphones/tablets (such as UEs 111, 123, 134, 142, 152), XR headsets (such as UEs 112, 122, 132), cameras (such as UEs 141 and 151), fixed video cameras (such as UEs 113, 121, 133, 153) or mobile/wearable video cameras (such as UEs 143 and 154). In general, the UE may be any portable or handheld or mobile telephone, a smartphone, a tablet, a portable or fixed computer, fixed or mobile camera, portable television or other similar wireless communication device. In the following description, the term UE will be used and it is not intended to limit the description to any particular type of wireless communication device. Base stations 102, 103 and 104 are interconnected through a wired link infrastructure 180, preferably based on optical fiber or any other wired means.

Base stations 102, 103 and 104 are also connected to the core network 170 through a wired link infrastructure 190, preferably based on optical fiber or any other wired means. In embodiments and examples of embodiments of the invention, base stations 102, 103 and 104 are 5G NR base stations (referred to as a gNB), as defined in 3GPP TS 38.300 vl8.0.0 specification document.

Satellite dish 101 (e.g. satellite gateway) is also connected to wired link infrastructure 180 or 190, or to both infrastructures. Besides infrastructures 180 and 190 may be the same infrastructure. In one example, a part of a base station is embedded in the satellite 160 while the other part is embedded in the gateway 101, meaning that the base station is split between the satellite 160 and the gateway 101. In another example, a full base station is embedded in the satellite 160 and the gateway 101 connects the base station 160 with the infrastructure 180 or 190.

In order to extend the network coverage of base stations 102, 103 and 104 and reach the remote UEs 111, 112, 113, 121, 122, 123, 131, 132, 133, 134, 141, 142, 143, 151, 152, 153 and 154, mobile WAB nodes or MW AB nodes, or MWAB-nodes, 110, 120a, 120b, 130, 140 and 150, have been installed on vehicles / mobile equipment 161, 162, 163, 164 and 165. By acting as relaying nodes between the base stations 102, 103 and 104 and the UEs 111, 112, 113, 121, 122, 123, 131, 132, 133, 134, 141, 142, 143, 151, 152, 153 and 154, MWAB-nodes 110, 120a, 120b, 130, 140 and 150 allow overcoming the reachability issue resulting from limited sky visibility while ensuring support for onboard/on-site mobile edge computing (MEC), local services, and direct local inter-UE communications. This allows further communication between base stations 102, 103 and 104 and the UEs 111, 112, 113, 121, 122, 123, 131, 132, 133, 134, 141, 142, 143, 151, 152, 153 and 154 and/or communications between the UEs served by a same MWAB-node (e.g., UEs 151, 152, 153 and 154 connected to MW AB node 150).

The base stations 102, 103 and 104, the MW AB nodes 110, 120a, 120b, 130, 140 and 150, the satellite 160, the satellite dish 101 are thus forming a backhaul network or WAB network (also referred to as WAB topology), or MW AB network (also referred to as MW AB topology), which accommodates UEs 111, 112, 113, 121, 122, 123, 131, 132, 133, 134, 141, 142, 143, 151, 152, 153 and 154.

The terms WAB network, MW AB network, WAB topology and MW AB topology will be used interchangeably in the following. The WAB network is part of the Radio Access Network (RAN) or as referred to with respect to 5G, the Next Generation (NG) RAN.

The base stations 102, 103 and 104, the MW AB nodes 110, 120a, 120b, 130, 140 and 150, the satellite 160, the satellite dish 101, and the core network 170 are thus forming a WAB system, or MW AB system, which accommodates UEs 111, 112, 113, 121, 122, 123, 131, 132, 133, 134, 141, 142, 143, 151, 152, 153 and 154.

The terms WAB system and MW AB system will be used interchangeably in the following.

A base station, or gNB, such as base station 102, 103 or 104, is a logical node that provides the NR-connectivity, hosting both higher layer protocols, such as PDCP (Packet Data Convergence Protocol) and RRC (Radio Resource Control) protocols, and lower layer protocols, such as the RLC (Radio Link Control), MAC (Medium Access Control) and physical layer protocols.

The MW AB nodes 110, 120a, 120b, 130, 140 and 150, which may serve multiple radio sectors, are wireless backhauled to the base station 102, 103 or 104, via a single logical hop associated to a single radio link (i.e., radio links D1041a, D1041b, D1031, D1022, D1021), or split into two radio links in the case of satellite relaying (radio links D1601a and D1601b). Although a single logical hop is shown in figure 1, it will be appreciated, if allowed, that the MW AB nodes could be wirelessly backhauled to the base station over multiple logical hops (for example, similar to the multiple hops provided in an IAB network).

Each MW AB node consists or includes a gNB or RAN node or base station component or entity which is referred to as a MWAB-gNB, or MW AB base station, and Mobile Termination (MT) component or entity which is referred to as an IAB-MT, or MWAB-Mobile Termination. The MWAB-gNB functionality on an MWAB-node allows or enables the MWAB-node to serve UEs. The MWAB-MT functionality includes, e.g., physical layer, layer-2, RRC and Non-Access Stratum (NAS) functionalities and allows or enables the MWAB-MT to connect to a fixed base station, or gNB, such as base station 102, 103 or 104.

MW AB nodes 110, 120a, 120b, 140 and 150 are intended to be mobile devices that will move along with the vehicle they are mounted on. However, these MW AB nodes may remain at a fixed location for a significant duration when their associated vehicle is remaining still (e.g., a train may stop at a railway station, a plane may be parked at an airport for a while, a car/truck/fire engine or any other emergency vehicle may be parked nearby a disaster area).

MW AB node 130 is likely to remain at fixed location and may be a 5G Femto node, which provides NR access at home or at enterprise premises. In such case, the 5G Femto node 130 may have a direct connection DI 700 to the Core Network 170 through the wired link infrastructure 190, which is preferably based on optical fiber or any other wired means.

Figure 2 is a simplified schematic diagram of a 5G system 200 in which the present invention may be implemented according to one or more example embodiments. This figure illustrates the possible standardized interfaces between the various elements composing the system. First, it represents a User Equipment (UE) 201 having a Uu interface with the New Generation (NG) Radio Access Network (RAN or NG-RAN) 202, and a N1 interface with an Access and Mobility management Function (AMF) entity or AMF 212 in a 5G core network (5GC) 210. Each base station composing the RAN 202 has a N2 interface with one or more Access and Mobility management Function (AMF) entity or AMF, like AMF 212, and a N3 interface with one or more User Plane Function (UPF) entity or UPF, like UPF 211.

The N1 interface is used to convey Non-Access Stratum (NAS) protocol messages between a UE 201 and an AMF 212. For a WAB node, the AMF may apply the procedures defined in NAS protocol specifications (TS 24.502 section 5), considering the WAB node is a Mobile Base Station Relay (MBSR) introduced in Release 18. NAS messages are used for the signaling between the UE and the core network for various procedures such as registration, session establishment, security, and mobility management. Actually, NAS messages are conveyed through the Uu interface between the UE 201 and the RAN 202, and the N2 interface between the RAN 202 and the AMF 212.

An AMF 212 is responsible for handling registration, authentication, connection and mobility management tasks for a UE. For a MW AB node, the AMF may apply the procedures defined in NAS protocol specifications (TS 24.502 section 5), considering the MW AB node is a Mobile Base Station Relay (MBSR) introduced in Release 18. There may be several AMFs in a 5G core network, a standardized interface N14 enables the communications between AMFs. When a UE registers to the network through a serving base station, the serving base station will connect to an AMF suitable to handle the UE.

When the UE 201 is registered, one or more Protocol Data Unit (PDU) session(s) can be set up to transfer data flows between the UE 201 and the Data Network (DN) 220 providing internet access. A PDU session is established between a UE 201 and a User Plane Function (UPF) 211 in the 5G core network 210. In the user plane, the UPF 211 connects to the Data Network (DN) 220 through the interface N6, and it is responsible for data packets routing with the required Quality of Service (QoS). There may be several UPFs on the data path with a N9 interface between UPFs. The user data between a UE 201 and the Data Network 220 are thus conveyed through interfaces Uu, N3, N6 and potentially N9.

In the control plane, the setup of PDU sessions is handled through NAS messages involving the Session Management Function (SMF) entity or SMF 213 in the 5G core network 210. The NAS messages are still exchanged between the UE 201 and the AMF 212 through the N1 interface, but an additional interface N11 between an AMF 212 and the SMF 213 is used to reach the SMF 213. In a 5G core network, the SMF is responsible for the setup, modification, and release of PDU sessions for a UE, as well as the Internet Protocol (IP) address allocation for the UE. To manage a PDU session, the SMF 213 controls the UPF 211 (configuration) based on QoS policy defined for the PDU session. For this purpose, a N4 interface exists between the SMF 213 and the UPF 211.

A base station in RAN 202 operating in a first Public Land Mobile Network (PLMN) may serve a UE having a subscription for a second PLMN (called home PLMN) different from the first PLMN (called visited PLMN). In such a roaming case, there are two options to provide the UE 201 with an access to the Data Network 220. In a first option called home routed, the UPF and its controlling SMF to access the Data Network 220 are located in the 5G core network for the home PLMN. However, the SMF of the visited PLMN controls the intermediate UPF(s) of the visited PLMN, and interacts with the SMF of the home PLMN. In a second option called local breakout, the UPF and its controlling SMF to access the Data Network 220 are located in the 5G core network for the visited PLMN. However, the SMF interacts with the home 5G core network to get QoS policies associated with the UE’s PDU session(s).

Figure 3 is a simplified schematic diagram of a 5G system 300 involving a Mobile Wireless Access Backhaul (MW AB) node, and in which the present invention may be implemented according to one or more example embodiments. This figure first represents a User Equipment (UE) 301 served by a MW AB node 310 through the Uu interface. The MW AB node 310 is composed of or includes a MT or MWAB-MT unit/component/entity 311 (also called MWAB-UE), and a gNB or MWAB-gNB unit/component/entity 312. Through the MWAB-gNB 312, a MW AB node acts as a gNB for UEs providing access to the 5G network, i.e. providing a NR access link to the UEs that can be located inside or outside the entity, such as a vehicle, equipped with the MW AB node 310 (e.g. on entering/leaving the vehicle). In other words, the MWAB-gNB 312 includes full base station or gNB function (including both Central Unit (CU) and distributed unit (DU)) and MT function, where the gNB function is used to communicate with UEs for access service and the MT function is used to communicate with another gNB for backhauling purpose. The MW AB node 310 wirelessly connects to the 5G Core Network (using NR Uu interface) through an IP connectivity provided by PDU session(s) established by the MWAB-MT 311 via a gNB 320, which can be called a backhaul RAN node, backhaul base station, backhaul gNB or BH gNB, or backhaul RAN node, or BH RAN node. Acting as a legacy UE, the MWAB-MT 311 connects via a NG-RAN cell of the BH gNB 320, through a backhaul link that may be a direct link or via a satellite (e.g. when the MW AB node 310 is embedded in an airplane). Thus, a PDU session is provided either by a Terrestrial Network (TN) or by a Non-Terrestrial Network (NTN). In addition, the MW AB node 310 may embed some core network functions, like a UPF 313, to enable local services to the served UEs. The traffic associated to these local services does not need to use the links to/from the core network via the BH gNB 320, which has the advantages to reduce the load on these links and to run applications having very low latency requirements. For example, where the MW AB node 310 includes a UPF 313, the MW AB node can connect to one or more local servers (e.g. mounted at the same entity as the MW AB 310) enabling a UE served by the MW AB access to local services provided by the local servers with no traffic required outside of the MW AB node/server environment.

The BH gNB 320 provides N3 and N2 interfaces so that the MWAB-MT 311 can access the functions of its 5G core network 330. Indeed, a MWAB-MT 311 may have access to some or several PLMNs through the appropriate subscriptions, and it may connect in a non-roaming manner to one PLMN, e.g. PLMN1 supported by the BH gNB 320, and may then have access to the corresponding 5G core network 330. In particular the MWAB-MT 311 interacts with the AMF 332, which can be called the MW AB AMF or BH AMF, and establishes PDU session(s) with the UPF 331, which can be called the MW AB UPF or BH UPF. The MW AB UPF 331 is controlled by the SMF 333 (through N4 interface), which can be called the MW AB SMF or BH SMF, and which also interacts with the MW AB AMF 332 (through N11 interface). There may be one or several intermediate UPFs between the BH gNB 320 and the MW AB UPF 331 as mentioned in the Figure 2.

An interface internal to the MW AB node 310 exists between the MWAB-gNB 312 and the MWAB-MT 311, which may be implemented on different or the same hardware resources. For instance, these two functions are implemented on the same processing unit 402 of Figure 4, and interactions exist between the two functions.

Once the MWAB-MT 311 has established a PDU session with the MW AB UPF 331, the MW AB node is ready to serve UEs and the MWAB-gNB 312 can start operating as a legacy gNB. The MWAB-gNB may support various PLMNs and the UE 301 connects to one PLMN, e.g. PLMN2, which may be different from the PLMN1 the MWAB-MT 311 connects to. In the case where PLMN1 and PLMN2 are different, the UE 301 connects to the 5G core network 340, including a UPF 341, which can be called the UE UPF, an AMF 342, which can be called the UE AMF, and a SMF 343, which can be called the UE SMF. The UE SMF 343 interacts with the UE AMF 342 (through Ni l interface) and the UE UPF 341 (through N4 interface). In the case where the PLMN1 and the PLMN2 are the same, the UE UPF 341, the UE AMF 342, the UE SMF 343, the MW AB UPF 331, the MW AB AMF 332, and the MW AB SMF 333 belong to the same 5G core network 350. In addition, the UE UPF 341 and the MW AB UPF 331 may be the same UPF, the UE AMF 342 and the MW AB AMF 332 may be the same AMF, the UE SMF 343 and the MW AB SMF 333 may be the same SMF.

The connections between the UE 301 to the UE UPF 341 and to the UE AMF 342 are possible thanks to the N6 interface between the UE UPF 341 and the MW AB UPF 331, and thanks to the N6 interface between the MW AB UPF 331 and the UE AMF 342. These N6 interfaces enable the establishment of N2 interface between the MWAB-gNB 312 and the UE AMF 342, and the establishment of N3 interface between the MWAB-gNB 312 and the UE UPF 341, which allows the UE 301 to access the Data Network 360.

In case the MWAB-MT 311 connects to the 5G network in a roaming manner corresponding to the home routed option, then the PLMN1 is the visited PLMN and the MW AB UPF 331 connects to another UPF not represented in the Figure 3 in the home PLMN through a N9 interface. It is this other UPF that provides the connection to the UE UPF 341 and the UE AMF 342 through N6 interfaces.

In case the MWAB-MT 311 connects to the 5G network in a roaming manner corresponding to the local breakout option, then the PLMN 1 is the visited PLMN and the MW AB UPF 331 directly connects to the UE UPF 341 and the UE AMF 342 through N6 interfaces as shown in the Figure 3.

Figure 4 is a block schematic diagram of an example network node or RAN node or base station 400, such as base stations or gNBs or MW AB nodes shown in Figure 1, in accordance with one or more embodiments of the invention. Each of a MW AB node 110, 120a, 120b, 130, 140, or 150 of figure 1 may comprise the elements of the base station of figure 4. In the following description, the network node 400 will be referred to generally as a base station. As will be apparent to a skilled person, Figure 4 is a simplified schematic diagram and shows only some of the functional components of an example base station 400 for use in describing the one or more embodiments of the invention.

The base station 400 includes components for transmitting and receiving communications. As shown in Figure 4, the base station 400 includes a processing unit 402, a wireless interface 404, one or more antennas 410, a network interface 432, and memory 418.

The network interface 432 manages communications of the base station 400 with the core network, other base stations, local network functions (like UPF), or local servers. It may provide a standardized interface, wired (e.g. fiber) or wireless, to support these communications. Through this network interface 432, the base station 400 may implement the standardized interfaces N2 (based on NGAP protocol) and N3 (based on GPRS tunneling protocol) with the core network, and the standardized interface Xn (based on XnAP protocol) with other base station of the Radio Access Network (RAN), all defined by the 3 GPP standard. The network interface 432 may not be present or active in case the base station 400 is a MW AB node that does not support local services, that is not used as a legacy base station like base station 102, 104 in Figure 1, and that is not used as a home base station providing Femto cells like base station 130 in Figure 1. The wireless interface 404 is configured to provide wireless communication via communication links (414) with other wireless devices, such as one or more UEs, e.g. link 1041b between base station 104 and the MT/UE unit of MW AB node 120b, or link 1202 between the gNB unit of MW AB node 120b and the UE 122. In case of MW AB node, the wireless interface 410 may then be used both for the wireless backhaul link(s) with backhaul base station(s) and for the wireless link(s) with the UE(s) served by the MW AB node. The wireless interface 404 may be compliant with a fifth-generation (5G) New Radio (NR) system and thus implementing the Uu interface defined by 3GPP standard, or with other wireless communication system. The wireless interface 404 is coupled to the processing unit 402 and typically includes one or more antennas (such as the antenna 410), a receiving unit 406 and a transmitting unit 408. The configuration of the wireless interface 404 may be limited to connect to one antenna, but preferably several antennas are used, in order to provide beamforming capability. Although not shown in Figure 4, the receiving unit 406 typically includes elements such as a receiver, demodulator, decoder, and the transmitting unit 408 typically includes elements such as a transmitter, modulator, coder. The receiving unit 406 and transmitting unit 408 may together be referred to as a transceiver.

The processing unit 402 is configured to carrying out processing for operation of the base station 400. The processing unit 402 may be a single processor (e.g. Central Processing Unit) or may comprise two or more processors. The number of processors and the allocation of processing functions to the processors is a matter of design choice for a skilled person. The base station 400 includes memory 418 for storing data and computer programs containing instructions for the operation of the base station 400. Memory 418 includes RAM (Random Access Memory), ROM (Read Only Memory), or combination of both or as a non-limiting example a mass storage device such as a disk or a Solid-State Drive. Memory 418 includes a program memory in which are stored programs containing processor instructions for operation of the base station 400 and for implementing the methods in accordance with one or more embodiments of the invention. The programs may contain a number of different program elements or sub-routines containing processor instructions for a variety of different tasks, for example, for: establishing, controlling and releasing communications with the UEs (e.g. implementing the Uu interface); processing data and signalling received at the receiving unit 406; processing signalling (e.g., paging messages, System Information Blocks) and data for transmission by the transmitting unit 408. Memory 418 may further include memory (e.g. RAM) for storing information. For example, information stored in memory 418 may include information associated with the mobile WAB node, such as information elements 420 related to a MW AB node, including the authorization status of the mobile WAB node. The information elements 420 may be associated to the base station 400 (when the base station is a MW AB node), and may be communicated to any network node when necessary. The information elements may also be related to a MW AB node (which is not the base station 400), and stored after reception from the MW AB node or from another network node. The operation of the information elements 420 will be described in more detail below. Specific program elements/sub-routines stored in program memory may include one or more of the following for a MW AB node: an element for receiving authorization status information for indicating whether the mobile WAB node is authorized to operate as a mobile WAB node; an element for sending a request, such as a connection setup request, including information for indicating the request is associated with a mobile WAB node and/or indicating the mobile WAB node intends to operate as a mobile WAB node; an element for controlling handover of UEs served by the MW AB node based on received authorization status information; an element for switching between authorized and unauthorized states; an element for changing or not changing, based on the received updated authorization status information, one of the authorized state of the mobile WAB node and how the mobile WAB node operates. The operation of the information elements 420 will be described in more detail below. Specific program elements/sub-routines stored in program memory may include one or more of the following for a AMF entity: an element for determining the authorization status for operation of the mobile WAB node as a mobile WAB node; an element for receiving a request, such as a connection setup request, including information for indicating the request is associated with a mobile WAB node and/or indicating the mobile WAB node intends to operate as a mobile WAB node; an element for sending authorization status information for indicating whether the mobile WAB node is authorized to operate as a mobile WAB node; an element for sending updated authorization status information after determining a change in conditions of operation of the mobile WAB node.

In an example arrangement, a communication bus 424 provides communication and interoperability between the various elements included in the base station 400 or connected to it. The representation of the bus is not limiting and in particular, the processing unit 402 is operable to communicate instructions to any element of the base station 400 directly or by means of another element of the base station 400.

In an example implementation, the base station 400 may be or may include an apparatus comprising one or more processing units or processors for performing or implementing the methods in accordance with one or more embodiments of the invention. In other words, the apparatus is capable of performing one or more functions of the base station including performing the methods in accordance with one or more embodiments of the invention by means of the one or more processing units. For example, the one or more processing units uses software to implement the one or more embodiments of the invention as described above with reference to the processing unit 402 of Figure 4. Instructions may be executed by one or more processors, such as one or more digital signal processors (DSPs), general purpose microprocessors, a CPU of a microcontroller Unit (MCU), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or other equivalent integrated (e.g. on an Integrated Circuit) or discrete logic circuitry. However, alternatively, the one or more processing units for performing or implementing the methods may be implemented in hardware: for example, in the form of an Application Specific Integrated Circuit or ASIC or other hardware comprising logic element (s). Accordingly, the term “processing unit” as used herein may refer to any of the foregoing structure or any other structure suitable for implementation of the techniques described herein.

In a 5G core network, an AMF (Access and Mobility management Function) like the MW AB AMF 332 or the UE AMF 342, may be implemented with the apparatus described in the Figure 4 where the Wireless Interface 404 and the antenna 410 is not present.

Figure 5 illustrates an example of a wireless communication system 500, including a WAB network or WAB network system, in which embodiments and examples of embodiments of the present invention may be implemented.

A WAB network will also be referred to as a WAB network system, WAB topology, WAB system, topology or system and so in this application, the terms WAB network system, WAB network, WAB topology, WAB system, topology or system will be used interchangeably.

The WAB network system of Figure 5, is composed of three base stations 501, 502 and 503, also referred to as Backhaul base stations, or backhaul RAN nodes, or backhaul gNBs (also referred to as BH-gNB), two core networks 510 and 520, with the respective AMF entities 511a and 511b (for Core Network 510) and 521a and 521b (for Core Network 520) and the respective UPF entities 512a and 512b (for Core Network 510) and 522a and 522b (for Core Network 520), and two MW AB nodes 530 and 540.

A wired backhaul IP network 590 interconnects the base stations 501, 502 and 503 and the Core Networks 510 and 520. For instance, this wired link consists of optical fiber cable(s).

As discussed above, each MW AB node comprises a Mobile Termination (MT) part or unit (MWAB-MT 531 for MWAB node 530 and MWAB-MT 541 for MWAB node 540) and a RAN node or base station part or unit (MWAB-gNB 532 for MWAB node 530 and MWAB-MT 542 for MWAB node 540).

MWAB node 530 and MWAB node 540 may also embed a UPF entity, respectively UPF entity 533 and UPF 543, as previously discussed in figure 3, allowing MWAB-node 530 to provide UEs 551, 552 and 561 with some local services, such as for instance inter-UE communication where the user data exchanged between the two UEs would be routed through UPF entity 533 instead of being routed through a UPF entity belonging to Core Network 510 or 520.

MW AB node 530 is connected to the serving backhaul base station referred to as BH-gNBl, 501 through BH link 5011.

MW AB node 540 may be connected to the serving backhaul base station referred to as BH- gNB2, 502 through BH link 5021 or to the serving backhaul base station referred to as BH-gNB3, 503 through BH link 5031 or, in case of dual connectivity, to both the serving backhaul base station BH-gNB2, 502 through BH link 5021 and the serving backhaul base station BH-gNB3, 503 through BH link 5031.

MWAB-gNB 532 of MW AB node 530 is also connected to UE 551 through communication link or radio link 5301 and to UE 552 through communication link or radio link 5302.

Similarly, MWAB-gNB 542 of MW AB node 540 is also connected to UE 561 through communication link or radio link 5401.

Although Figure 5 shows only UE 561 connected to MW AB node 540, it will be appreciated that there will be a plurality of UEs connected to MW AB nodes of the wireless communication system.

MWAB-gNB 532 and MWAB-MT 531 may be connected to a same AMF function or entity (e.g., AMF 511a) or to different AMF functions or entities belonging to the same Core Network (e.g., AMF 511a and AMF 511b) or to different Core Network (e.g., AMF 511a and AMF 521a).

Some AMF functions may be implementing MWAB-specific features for managing a MW AB node (e.g., advanced mobility features). Some AMF functions may not implement such features but may still be capable of serving a MW AB node with a limited set of basic features. Some AMF functions may not be capable of serving a MW AB node.

The processes and arrangements for managing one or more network connections and managing mobile WAB node authorization in a wireless communication system including one or more mobile WAB (MW AB) nodes will now be described according to some embodiments of the present invention.

Several scenarios are possible according for the mobility of MW AB nodes 530 and 540.

As a first scenario, and taking the example of MW AB node 540, a dual -connectivity configuration may be applied to the MWAB-MT 541, initially connected to BH-gNB2 502 only through the link 5021. Indeed, the MWAB-MT 541 periodically performs a cell search procedure, as defined in 3GPP TS 38.300, trying to detect PSS (Primary Synchronization Signal) and SSS (Secondary Synchronization Signal). The MWAB-node may report to BH-gNB2 502 the presence of a new cell, for instance one cell managed by the BH-gNB3 503, through a measurement report. Based on the analysis of the measurement report, the BH-gNB2 502 may request to the BH- gNB3 503 the establishment of a dual connectivity for the MWAB-MT 541 with an additional connection through the link 5031. The BH-gNB3 503 may accept the request and proceed to the connection of the MWAB-MT 541 according to the procedure described in TS 37.340 section 10.2.2. As a result, the MWAB-MT 541, and thus the MW AB node 540 is dual -connected. The BH- gNB2 502 may take benefit of the dual connectivity of MW AB node 540 to balance the traffic load by offloading some traffic (data/user traffic or control traffic) initially planned to be transmitted through the link 5021. Some or all the traffic associated to the MW AB node 540 (i.e. control data related to the MW AB node, and control and user data related to the UEs served by the MW AB node 540) may be transmitted through the link 5031 and through the IP connectivity between BH- gNB2 502 and BH-gNB3 503. Dual -connectivity configuration is however transparent for the MMWAB-gNB 542 and for the UEs served by the MWAB-gNB 542.

As a second scenario, the radio link 5021 may experience radio link deficiency due to some unexpected interference or shadowing phenomena. For such reasons, the MWAB-MT 541 may lose the connection with the BH-gNB2 502 and declare a Radio Link Failure (RLF). Then, the MWAB- MT 541 will try to reestablish the connection in the same or a different cell controlled by BH gNB2 502 or by another gNB. Thus, the MWAB-MT 541 may try to connect to a cell controlled by BH-gNB3 503 by requesting the establishment of the link 5031. In this case, the reestablishment procedure described in TS 38.300 section 9.2.3.3 may be applied, which enables a UE to maintain the RRC connection. With such procedure, the BH gNB3 503 sends to the BH gNB2 502 a request to retrieve the context of the MWAB-MT 541. Based on the response from the BH gNB2 502, the BH gNB3 503 may accept the connection of the MWAB-MT 541. Then, all the traffic related to the MW AB node 540 (and the served UEs) will now transit through the BH gNB 503. The reestablishment procedure does not involve the MWAB-gNB 542 and its served UEs. If the reestablishment is rapidly performed after RLF, the service interruption at the UE 561 may be avoided or limited.

As a third scenario, the MWAB-MT 541 may be handed over from the current serving cell to a new cell. Indeed, based on the measurement reports provided by the MWAB-MT 541, the BH- gNB2 502 may detect that the MWAB-MT 541 would have a better connection through a cell managed by the BH gNB3 503. Then, the BH-gNB2 502 may trigger a handover procedure described in TS 38.300 section 9.2.3.2. In this procedure, the BH-gNB2 502 sends a handover request to the BH gNB3 503 along with information related to the MWAB-MT 541. Based on this information, the BH gNB3 503 may accept the handover request and proceed to the admission of the MWAB-MT 541. Then, all the traffic related to the MW AB node 540 (and the served UEs) will now transit through the BH gNB 503. The handover procedure does not involve the MWAB-gNB 542 and its served UEs, and it may be transparent for MWAB-gNB and the served UEs (no interruption of service).

The second and third scenario corresponds to the mobility of the MW AB node 540 that may involve a new backhaul gNB serving the MWAB-MT 541 in RRC_CONNECTED state. This may mean that the MW AB node 540 is located in a new geographical area and the authorization status of the MW AB node should be re-evaluated. For example, in the new geographical area the MW AB node 540 may not be authorized to operate as a MW AB node or in the new geographical area the MW AB node 540 may be authorized but the authorization has changed. For example, in a previous geographical area the MW AB node was authorized to provide local services whereas in the new geographical area the MW AB node is not or no longer authorized to provide local services. In the following description of figures 6-13 and 14a-14c, details of authorization status information associated with the MW AB node that can be provided to the MW AB node is disclosed along with mechanisms that can be used to provide such information. Different cases where the authorization status information or updated authorization status information is provided will be discussed such as when the MW AB node registers to or integrates with the network, during operation (e.g. on handover, dual -connectivity setup, reestablishment after RLF detection), such as where the MW AB node may be moving over large distances.

It can be noted that the authorization of a WAB node (or MW AB node) may be divided into two authorizations:

The authorization of the WAB-MT to support backhauling of the traffic of the co-located WAB-gNB via BH PDU session(s). Backhauling means using the wireless link between the WAB-MT and the serving backhaul gNB (or BH RAN node). This authorization may be handled by the backhaul AMF (BH AMF) serving the WAB-MT, based on subscription information, in addition to the registration process, meaning that the registration of the WAB-MT may be accepted by the BH AMF but the WAB-MT may not be authorized to support the traffic of the co-located WAB-gNB.

The authorization of WAB-gNB to serve UEs. This authorization may be handled by an AMF or by an 0AM (Operations, Administration and Maintenance) server for the PLMN operated by the WAB-gNB.

Communications in the core network between AMFs and 0AM servers may be required to avoid conflicts and to coordinate the authorization of the WAB-MT and the authorization of the WAB-gNB. Thus, depending on the situations, the authorization status of a WAB node (or MW AB node) may be related to the WAB-MT (or MWAB-MT) only, or related to the WAB-gNB (or MWAB-gNB) only, or related to both the WAB-MT (or MWAB-MT) and the WAB-gNB (or MWAB-gNB). In most cases, a WAB node will be considered as authorized to operate as a WAB node when the WAB-MT is authorized to support backhauling of WAB-gNB’ s traffic via PDU sessions, and the WAB-gNB is authorized to serve UEs.

Figure 6 is a schematic and simplified diagram illustrating an example message flow 600 for performing RRC connection setup of a MW AB node while providing the authorization status to the MW AB node according to embodiments of the invention. This figure shows a gNB 602 (or backhaul gNB, or BH gNB, or BH RAN node) like the BH-gNB 502 of figure 5, a MW AB node 610 like the MW AB node 540 of figure 5, composed of or including the gNB or RAN node or MWAB-gNB unit 611 and the MT or MWAB-MT unit 612 (or MWAB-UE), and the AMF or AMF entity 604 of the MWAB-MT 612 (MWAB AMF or BH AMF) like the AMF 521a of figure 5, in a 5G core network (5GC) like the core network 520 of figure 5. As discussed above, the AMF or AMF entity 604 is an AMF to which the MWAB node (e.g. MT of the MWAB node) is connected.

At the beginning of the message flow, the MWAB node 610 is powered on, and the MWAB- MT 612 is the first unit to operate in order to connect the MWAB node 610 to the network (i.e. the 5G core network through the Radio Access Network (RAN)). For this purpose, at step 620, the MWAB-MT 612 triggers the RRC connection setup. First, the MWAB-MT 612 has to detect signals such as the Signal Synchronization Block (SSB) transmitted by gNBs and in particular by the BH gNB 602. Once the MWAB-MT 612 discovers at least one SSB in a target cell that meets predefined criteria (for instance a received power that exceeds a predefined threshold), the MWAB-MT 612 reads the System Information Block 1 (SIB1) broadcasted by the BH gNB 602 and from reading the SIB1, the MWAB node 610 is informed about the different supported Public Land Mobile Networks (PLMNs): that is, the different PLMNs that are supported by the BH gNB 602 or in which the BH gNB 602 can operate. If the MWAB-MT 612 is configured to connect to at least one of these PLMNs, it performs a random-access channel (RACH) procedure to acquire uplink synchronization. For example, the MWAB node 610 selects one of the PLMNs that are supported by the BH gNB and performs a RACH procedure. Once synchronization is established, the MWAB-MT 612 sends a RRC Setup Request. The BH gNB 602 receiving this RRC Setup Request message may accept the request, and then respond by sending a RRC setup message to the MWAB-MT 612, assigning uplink resource to the MWAB-MT 612, so that the MWAB-MT 612 can send the RRC Setup Complete message 621. At this stage, the MWAB-MT 612 is in RRC_CONNECTED state. The different Radio Resource Control (RRC) states and the transitions between them are described in TS 38.331 section 4.2.1. The RRC Setup Complete message 621 includes a Registration Request message, which is a Non-Access Stratum (NAS) protocol message to be handled by an Access and Mobility management function (AMF) in the core network associated with the selected PLMN (indicated by the MWAB-MT 612 in the message 621). The NAS Registration Request message or request may include an indication that the request is related to or associated with a MW AB node, e.g. it includes a MW AB indication Information Element (IE). The indication can indicate to the AMF in the core network that the MW AB node 610 intends to operate as a MW AB node. One or more other IES may be communicated to the AMF along with the MW AB indication IE. For instance, the MWAB-MT 612 may indicate the list of PLMNs the MWAB-gNB will support, whether the MWAB-node supports local services for on-board UEs or served UEs, the expected trajectory or path of the MW AB node 610 (e.g. in the form of a list of cells to connect to along the trajectory or path, or of regions to be visited by the MWAB-node. . .).

The RRC Setup Complete message 621 is received by the BH gNB 602, which extracts the NAS Registration Request message and includes this NAS message in a NGAP Initial UE message 622. This message 622 is transmitted to the AMF 604, selected by the BH-gNB 602 as an AMF in the core network corresponding to the selected PLMN. The AMF 604 can be called the MW AB AMF.

After authentication of the MWAB-MT 612 at step 630 to check the MWAB-MT 512 is a valid UE, the MW AB AMF 604 determines the MW AB authorization status of the MW AB node 610 based on the available information at the MW AB AMF 604. The available information includes at least one of:

The User Location Information, ULI, of the MWAB-MT 612, IE defined in TS 38.413 section 9.3.1.16, and included in the NGAP Initial UE message 622. The ULI represents information for indicating the location of the MW AB node 610;

- Local services support by the MW AB node 610, IE that may be included in the NAS Registration Request message. For example, such local services support information may include information indicating the MW AB node supports local services for the served UEs; The identified s) of PLMN(s) the MWAB-gNB 611 may operate, IE that may be included in the NAS Registration Request message or request;

The subscription information related to the MWAB-MT 612, IE that is stored in a network function in the home PLMN of the MWAB-MT 612, and that the MW AB AMF 604 can access.

The authorization status (or MW AB authorization status) of the MW AB node 610 may include at least one of the following IEs: The authorization of the MWAB-MT 612 to connect to the selected PLMN (e.g. PLMN selected by the MW AB node 610) or to one or more PLMNs, and to support backhauling of the traffic to and from the MWAB-gNB 611;

The region of validity. For example, the IE may include information for indicating a region in which the MWAB-MT 612 is authorized to connect to the selected PLMN or to one or more PLMNs;

The time or duration of validity of this authorization at the MWAB-MT 612. For example, the IE may include information for indicating a time period for which the MWAB-MT 612 is authorized to connect to the selected PLMN or one or more PLMNs;

The authorization for the MWAB-gNB 611 to serve UEs for each supported PLMN;

The region of validity. For example, the IE may include information for indicating a region in which the MWAB-gNB 611 is authorized to serve for each of the one or more authorized PLMNs supported by the MWAB-gNB 611;

The time of validity of this authorization at the MWAB-gNB 611. For example, the IE may include information for indicating a time period for which the MWAB-gNB 611 is authorized to serve for the one or more authorized PLMNs supported by the MWAB-gNB 611;

The authorization to provide local services only. For example, the IE may include information for indicating the MW AB node 610 is authorized to operate as a MW AB node but the authorization is limited to providing local services;

The cause of a “not authorized” notification (e.g. the subscription information does not allow it, the time of validity is expired. . .).

The information indicating authorization of the MWAB-MT 612, the region of validity for the MWAB-MT 612 and the time of validity for the MWAB-MT 612 may be included in the same IE. The information indicating authorization of the MWAB-gNB 611, the region of validity for the MWAB-gNB 611 and the time of validity for the MWAB-gNB 612 may be included in the same IE.

In an example, the authorization of the MWAB-MT 612 to connect to the selected PLMN or to one or more PLMNs may include a list of one or more PLMNs for or with which the MWAB-MT 612, is authorized to operate and/or a list of one or more PLMNs for which the MWAB-MT 612 is not authorized to operate. The authorization of the MWAB-gNB 611 to serve UEs may include a list of one or more PLMNs for or with which the MWAB-gNB 611 is authorized to operate and/or a list of one or more PLMNs for which the MWAB-gNB 611 is not authorized to operate. The authorization status determined at step 640 may be stored by the MW AB AMF 604 in a network function of the core network (for instance the same function storing the subscription information for the MWAB-MT 612, which can be the Unified Data Management (UDM) function not represented in the figures).

When the MW AB AMF 604 has not authorized the MWAB-node 610 (i.e. the MWAB-MT 612 and/or the MWAB-gNB 611), the MW AB AMF 604 may decide to not register the MWAB-MT 612. Then the MW AB AMF 604 may send a NAS Registration Reject message (not represented in the Figure 6), defined in TS 24.501 section 8.2.9, and which may be transmitted to the MWAB-MT 612 through the NGAP message Downlink NAS Transport 623 (defined in TS 38.413 section 9.2.5.2) between the MW AB AMF 604 and the BH gNB 602, and then through the RRC message DL Information Transfer 625 defined in TS 38.331 section 5.7.1) between the BH gNB 602 and the MWAB-MT 612. The authorization status “not authorized” at the MWAB-gNB 611 is transferred by the MWAB-MT 612 to the MWAB-gNB 611 through the internal message 627.

When the MW AB AMF 604 has authorized the MWAB-MT 612 to connect to the network the MW AB AMF 604 registers the MWAB-MT 612. For this purpose, the MW AB AMF 604 sends a NAS Registration Accept message (not represented in the Figure 6), defined in TS 24.501 section 8.2.7, and which is transmitted to the MWAB-MT 612 through the NGAP message Initial Context Setup Request 624 (defined in TS 38.413 section 9.2.2.1) between the MW AB AMF 604 and the BH gNB 602, and then through the RRC message RRC Reconfiguration 626 defined in TS 38.331 section 6.2.2) between the BH gNB 602 and the MWAB-MT 612. The MW AB authorization status (related to MWAB-MT 612 and MWAB-gNB 611) is included in the NAS Registration Accept message. For example, one or more of the authorization status IES listed above may be included in the NAS Registration Accept message. The authorization status at the MWAB-gNB 611 is transferred by the MWAB-MT 612 to the MWAB-gNB 611 through the internal message 627. The MW AB authorization status may also be explicitly included in the message NGAP message Initial Context Setup Request 624, and the BH gNB 602 may store the MW AB authorization status at step 650.

The MWAB-MT 612 may be registered while the MWAB-gNB is “not authorized”. The operation of MWAB-MT 612 may then be allowed), so that the MWAB-MT 612 may be handed over in RRC CONNECTED through control plane signaling. In such a case, the MW AB node 610 is not authorized to operate as a mobile WAB node serving UEs connected to the MWAB-gNB 611 (e.g. the MW AB node 610 is not authorized to operate as a gNB).

Figure 7 is a schematic and simplified diagram illustrating an example message flow 700 for performing the NGAP connection setup of a MW AB node while providing the authorization status, in accordance with one or more embodiments of the invention. This figure shows a gNB 702 (or backhaul gNB, or BH gNB, or BH RAN node) like the BH-gNB 502 of figure 5, a MW AB node 710 composed of or including the gNB or RAN node or MWAB-gNB unit 711 and the MT or MWAB-MT unit 712 (or MWAB-UE), and the AMF 704 of the MWAB-MT 712 (MWAB AMF or BH AMF), like the AMF 521a of figure 5, in a 5G core network (5GC) like the core network 520 of figure 5. This figure also shows a UPF 703 (referred to as BH UPF) corresponding to the UPF providing access to the Data Network (not represented in the Figure 7) for the MWAB-MT 712, and thus providing access to core network functions for the MWAB-gNB 711, and access to core network functions and to the Data Network for the UEs served by the MWAB-gNB 711. As an example with reference to figure 5, the UPF 703 may be the UPF 522a. The AMF 705 (or UE’s AMF) is an AMF handling UEs (not represented in the Figure 7) served by the MWAB-gNB 711. The AMF 705 may be in the same or different core network as the core network of MWAB AMF

704. The AMF 705 and the MWAB AMF 704 may be the same AMF (e.g. AMF 521a of figure 5).

At the beginning of the message flow, the MWAB-MT 712 is in RRC_CONNECTED state and it has registered toward the MWAB AMF 704 as described above with reference to figure 6. Also, the MWAB-MT 712 has setup or is able to setup PDU session(s). The MWAB-gNB 711 may or may not have received an authorization status as described above with reference to figure 6. The MWAB-gNB 711 may need to setup a NG interface (N2) with an AMF, for instance the AMF 705, to serve UE(s). Then, the MWAB-gNB sends a NG Setup Request message 721 targeting the AMF

705. This message 721 is internally provided to the MWAB-MT 712. To forward this message to the AMF 705, the MWAB-MT 712 may need to setup a PDU session at step 720. This operation is described in TS 23.501 section 5.6. At this stage, the MWAB-MT 712 can exchange data packets with the BH UPF 703 (in the user plane at PDU layer as described in TS 23.501 section 8.3). Then the NG setup Request message 721 is embedded in PDU layer packet(s) to be transmitted to the BH UPF 703 through the BH gNB 702: packet(s) 722 transmitted over the Uu interface between the MWAB-MT 712 and the BH gNB 702, packet(s) 723 over the N3 interface between the BH-gNB 702 and the BH UPF 703. The NG setup request message 721 is finally provided to the AMF 705 through packet(s) 724 transmitted over the N6 interface between the BH UPF 703 and the AMF 705. Thus, the NG setup request message 721 or request for setting up a NG interface is sent from the MWAB node 710 to the AMF 705 in the core network (via the PDU packets 722, 723, 724).

Upon reception of the NG setup request message 721, the AMF 705 may retrieve the authorization status for the MWAB node 710. For instance, the AMF 705 sends a request to a network function storing the authorization status (e.g. the UDM function) of the MWAB node 710, and the AMF 705 receives the authorization status in a response message. If the authorization status of the MW AB node 710 was not determined before, the MW AB AMF 704 may be requested (by the UDM function or directly by the AMF 705) to determine and to provide the authorization status. To make this request, the AMF 705 may need the identifier of the MWAB-MT 712 co-located with MWAB-gNB 711 (e.g. the identifier of the MWAB-MT 712 included in the MW AB node 710 with the MWAB-gNB711). This identifier may be the 5G-GUTI as defined in TS 24.502 section 9.11.3.4, which then has to be included in the message NG Setup Request message 721.

If the authorization status of MWAB-gNB 711 is “authorized” (e.g. the MW AB node 710 is authorized to operate as a gNB and to serve UEs), the AMF 705 may respond to the MWAB-gNB 711 with the message NG Setup Response 728 including the authorization status of the MW AB node 711. For example, one or more of the authorization status IES listed above with reference to figure 6 may be included in the NG Setup Response message 728. The NG Setup Response message 728 is actually first provided to the BH UPF 703 through packet(s) 725 transmitted over the N6 interface, then embedded in PDU layer packet(s) transmitted to the MWAB-MT 712 through the BH gNB 702: packet(s) 726 transmitted over the N3 interface between the BH UPF 703 and the BH gNB 702, and packet(s) 727 transmitted over the Uu interface between the BH gNB 702 and MWAB-MT 712. The NG Setup request message 728 is finally provided to the MWAB-gNB 711 through the internal interface at the MW AB node 710. The MWAB-gNB 711 may then be able to serve UE(s) connecting to the AMF 705.

If the authorization status of MWAB-gNB 711 is “not authorized”, the AMF 705 may respond with the NG Setup Failure message (not represented in the Figure 7) with a cause IE indicating the MWAB-gNB 711 is not authorized. The NG Setup Failure message would be transmitted in the same way as the NG Setup Response message.

In this Figure 7, the messages 721, 728 may correspond to the messages with the same name described in TS 38.413.

Figure 8 is a schematic and simplified diagram illustrating an example message flow 800 for providing an update of the authorization status of a MW AB node, in accordance with one or more embodiments of the invention. This figure shows a gNB 802 (or backhaul gNB, or BH gNB or BH RAN node) like the BH-gNB 502 of figure 5, a MW AB node 810 like the MW AB node 540 of figure 5, composed of or including a gNB or RAN node or the MWAB-gNB unit 811 and the MT or MWAB-MT unit 812 (or MWAB-UE), and the AMF 804 of the MWAB-MT 812 (MWAB AMF or BH AMF), like the AMF 521a of figure 5, in a 5G core network (5GC) like the core network 520 of figure 5.

At the beginning of the flowchart, the MWAB-MT 812 has registered toward the MWAB AMF 804 as described above with reference to figure 6. At some point, the MW AB AMF 804 may have detected a change in the conditions of operation of the MW AB node 810 (e.g. because of mobility of the MWAB-MT 812 as described with reference to figures 10, 11, 12) and an authorization control step 820 is performed to update the authorization status. The outcome of this authorization control step 820 (i.e. the updated authorization status) may result in no change for the authorization status, or in a change from “not authorized” to “authorized”, or from “authorized” to “not authorized” (e.g. which can change how the MW AB node operates as a MW AB node, such as change whether the MW AB node 810 is authorized or not to operate as a gNB and to serve UEs), or in a change for some aspects like time of validity, region of validity, local services only allowed or no local services allowed, whether only the MWAB-MT 812 is authorized or other aspects described above with reference to figure 6.

The updated authorization status may be provided to the MWAB-MT 812 by the MW AB AMF 804 with the procedure 830 (which can be called the Updated Authorization Status Transmission procedure). In case the MWAB-MT 812 is not in RRC CONNECTED state and/or the MW AB AMF 804 does not know the location of the MWAB-MT 812, a paging procedure may be applied as described in TS 24.501 section 5.6.2 prior to the procedure 830. There are different methods for this procedure 830. In a first method, the MW AB AMF 804 may execute the UE Context Modification procedure 831 toward BH gNB 802, as defined in TS 38.413 section 8.3.4, where the UE Context Modification Request message 831 may explicitly include (i.e. with MW AB authorization IE(s) such as one or more of the MW AB authorization status IE(s) discussed above with reference to figure 6) the updated authorization status determined at step 820. The BH gNB 802 responds to the MW AB AMF 804 with the message UE Context Modification Response message to complete the UE Context Modification procedure 831. At step 840, the BH gNB 802 may store the updated authorization status for the MW AB node 810. The BH gNB 802 may also propagate the authorization status of the MW AB node 810 to the MWAB-MT 812 through the RRC Reconfiguration message 832.

In a second method, the MW AB AMF 804 may send the updated authorization status to the MWAB-MT 812 through the Downlink NAS Transport message 833. This NAS message is then embedded in the RRC message DL Information Transfer 834. Both messages 833 and 834 includes a MW AB authorization IE(s) (such as one or more of the MW AB authorization status IE(s) discussed above with reference to figure 6) containing the updated authorization status. With this second method the transmission of the authorization status to the MWAB-MT 812 is transparent for the BH gNB 802.

Finally, upon reception of the updated authorization status through the procedure 830, the MWAB-MT 812 transmits the updated authorization status to the MWAB-gNB 1111 through the internal interface and the Authorization Status message 825. On reading the authorization status information (e.g. in the MW AB authorization IE(s) received at the MW AB node 810), the MW AB node 810 can change/account for or not change its authorized status and/or how it operates as a MW AB node (e.g. whether or not it is limited only to providing local services, there is a region of validity, time of validity, whether only the MWAB-MT unit is authorized, whether the MW AB node is authorized or not to operate as a gNB and to serve UEs) based on the received updated authorization status information.

In this Figure 8, the messages 832, 834 may correspond to the messages with the same name described in TS 38.331, the message 833 may correspond to the message with the same name described in TS 38.413, and the procedure 831 may correspond to the procedure with the same name described in TS 38.413.

Figure 9 is a schematic and simplified diagram illustrating an example message flow 900 for providing an update of the authorization status of a MW AB node, in accordance with one or more embodiments of the invention. This figure shows a gNB 902 (or backhaul gNB, or BH gNB or BH RAN node) like the BH-gNB 502 of figure 5, a MW AB node 910 composed of the gNB or RAN node or MWAB-gNB unit 911 and the MT or MWAB-MT unit 912 (or MWAB-UE), and the AMF 904 of the MWAB-MT 912 (MWAB AMF or BH AMF) like the AMF 521a of figure 5, in a 5G core network (5GC) like the core network 520 of figure 5. This figure also shows a UPF 903 (referred to as BH UPF) corresponding to the UPF providing access to the Data Network (not represented in the Figure 9) for the MWAB-MT 912, and thus providing access to core network functions for the MWAB-gNB 911, and access to core network functions and to the Data Network for the UEs served by the MWAB-gNB 911. As an example with reference to figure 5, the UPF 903 may be the UPF 522a. The AMF 905 is an AMF handling UEs (not represented in the Figure 9) served by the MWAB-gNB 911. The AMF 905 (or UE’ s AMF) may be in the same or different core network as the core network of MWAB AMF 904. The AMF 905 and the MWAB AMF 904 may be the same AMF (e.g. AMF 521a of figure 5).

At the beginning of the message flow, the MWAB-MT 912 has registered toward the MWAB AMF 904 as described with reference to figure 6. Also, the MWAB-MT 912 has setup PDU session(s) involving the BH UPF 903, at least to support the setup of NG interface (N2) between the MWAB-gNB 911 and the AMF 905.

At some point, the AMF 905 may be notified at step 920 about an update of authorization status for the MWAB node 910. For instance, the MWAB AMF 904 may have detected a change in the conditions of operation of the MWAB node 910 (e.g. because of mobility of the MWAB-MT 912 as described with reference to figures 10, 11, 12) and it may have determined an updated authorization status. A core network function may store the authorization and may notify the AMF 905 handling UEs served by the MWAB-gNB 911. The AMF 905 may be known because of a previous procedure to retrieve the authorization status of the MW AB node 910, as described with respect to the step 730 in the figure 7.

The updated authorization status of the MW AB node 910 may be provided to the MWAB- gNB 911 by the AMF 905 through the transmission of the AMF Configuration Update message 924, which then includes a MW AB authorization IE(s) (such as one or more of the MW AB authorization status IE(s) discussed above with reference to figure 6) containing the updated authorization status. The AMF Configuration Update message 924 is actually first provided to the BH UPF 903 through packet(s) 921 transmitted over the N6 interface, then embedded in PDU layer packet(s) transmitted to the MWAB-MT 912 through BH UPF 903 and the BH gNB 902: packet(s)

922 transmitted over the N3 interface between the BH UPF 903 and the BH gNB 902, and packet(s)

923 transmitted over the Uu interface between the BH gNB 902 and MWAB-MT 912. The AMF Configuration Update message 924 is finally provided to the MWAB-gNB 911 through the internal interface at the MW AB node 910. The MWAB-gNB 911 may then take into account the updated status.

On reading the authorization status information (e.g. in the MW AB authorization status IE(s) received at the MW AB node 910), the MW AB node 910 can change/account for or not change its authorized status and/or how it operates as a MW AB node (e.g. whether or not it is limited only to providing local services, there is a region of validity, time of validity, whether only the MWAB-MT unit is authorized, whether the MW AB node is authorized or not to operate as a gNB and to serve UEs) based on the received updated authorization status information.

In this Figure 9, the message 924 may correspond to the message with the same name described in TS 38.413.

In case the MWAB-MT 912 is not in RRC CONNECTED state, the BH gNB 902 receiving a packet 922 may trigger the paging procedure described in TS 38.300 section 9.2.5.

Figure 10 is a schematic and simplified diagram illustrating an example message flow 1000 for performing a Xn handover of a MW AB node while providing an update of the authorization status, in accordance with one or more embodiments of the invention. This figure shows a source or first gNB 1002 (or source backhaul gNB, or source BH gNB or source backhaul RAN node or source BH RAN node) like the BH-gNB 502 of figure 5, a target or second gNB 1003 (or target backhaul gNB, or target BH gNB or target backhaul RAN node or target BH RAN node) like the BH-gNB 503 of figure 5, a MW AB node 1010 composed of or including the gNB or RAN node or MWAB- gNB unit 1011 and the MT or MWAB-MT unit 1012 (or MWAB-UE), and the AMF 1004 of the MWAB-MT 1012 (MW AB AMF or BH AMF) like the AMF 521a of figure 5, in a 5G core network (5GC), like the core network 520 of figure 5.

At the beginning of the message flow, the MWAB-MT 1012is in RRC_CONNECTED state and it is served by the gNB 1002 through a cell (i.e. serving or source cell) controlled by this gNB 1002. The gNB 1002 may be called source or first backhaul gNB or source or first BH gNB. The MW AB node may serve one or several UEs (not represented in the figure 10). The user data in downlink are provided by the 5GC to the source BH gNB 1002 through a UPF (not represented in the figure 6), then the user data are transmitted to the MWAB-MT 1012. Once transferred to MWAB-gNB 1011 through the internal interface between the MWAB-MT 1012 and the MWAB- gNB 1011, the user data are transmitted to the UE(s) through a radio bearer. The user data in uplink are similarly transmitted in the opposite direction from the UE(s) to the UPF in the 5GC.

When served by the source BH gNB 1002, the MWAB-MT 1012 regularly performs measurement on signals received at the MWAB-MT 1012 from the serving cell and one or more target cells, such as the Signal Synchronization Block (SSB) transmitted in the serving cell and in the target cells. The target cells may be neighbouring cells to the serving or source cell (i.e. the current serving cell).

Once the MWAB-MT 1012 discovers at least one SSB that meets predefined criteria (for instance a received power that exceeds a predefined threshold), the MWAB-MT 1012 may send a measurement report 1021 to the source BH gNB 1002 through a RRC message. The measurements provide radio link quality information for different cells in the vicinity of the MW AB node 1010. The identity of each cell is included in the measurement report to allow the source BH gNB 1002 to identify the gNB(s) controlling the reported cell(s).

Based on the received measurement report, the source BH gNB 1002 may detect that the MWAB-MT 1012 receives radio signals in a cell controlled by the target gNB (or target backhaul gNB, or target BH gNB) 1003 with a better quality than in the current serving cell controlled by the source BH gNB 1002. The source BH gNB 1002 may then decide at step 1020 the handover of the MWAB-MT 1012, and thus the handover of the MW AB node 1010 to the target gNB (or target backhaul gNB, or target BH gNB) 1003.

The source BH gNB 1002 may execute a Xn handover when there is a Xn interface between the source BH gNB 1002 and the target BH gNB 1003.

To trigger the handover, the source BH gNB 1002, sends a Handover Request message 1022 to the selected target BH gNB 1003 including information related to the MW AB node 1010 to be handed over. The handover request message may be the Handover Request message specified in the 3GPP document TS 38.423 section 9.1.1.1. Then, the target BH gNB 1003 executes the admission control step 1030 to decide whether the request is accepted or not. The decision may be based on criteria such as the current load at the target BH gNB 1003 (load of the processing resources), and/or the current load on the target cell through which the MWAB-MT 1012 would connect to the target BH gNB 1003. The target BH gNB 1003 may reject the handover request in the case where a connection with the MW AB node 1010 may create situations with overload. When the handover request concerns the handover of a MW AB node, the target BH gNB 1003 may accept such request, as it may be the only possible option for the MW AB node to continue serving its UEs, taking also into account that the presence of the MW AB node may be temporary as it may not remain a long time in the target cell.

If the target BH gNB 1003 has rejected the handover request, it sends a Handover Request Failure message (not represented in the figure 10) as defined in TS 38.423 section 8.2.1.3. Upon reception of this message, the source BH gNB 1002 may consider another cell to hand over the MWAB-MT 1012.

If the target BH gNB 1003 has accepted the handover request, the handover procedure can be completed as defined in TS 38.300 section 9.2.3. Briefly, the target BH gNB 1003 sends a Handover Request Acknowledge message 1023 to the source BH gNB 1002. Then, the source BH gNB 1002 sends a RRC Reconfiguration message 1024 containing the necessary information for the MWAB- MT 1012 to connect to the target cell, such as radio bearer(s), measurement configuration, (information previously received by the source BH gNB 1002 from the target BH gNB 1003 in the acknowledgment message 1023). In case of conditional handover (CHO), the MWAB-MT 1012 is configured with a triggering condition to fulfil before switching to the target cell.

After switching to the target cell as the new serving cell, the MWAB-MT 1012 performs a random-access channel (RACH) procedure 1025 towards the target BH gNB 1003 to acquire uplink synchronization. Once synchronization is established, the MWAB-MT 1012 sends a RRC Reconfiguration Complete message 1026 to the target BH gNB 1003, which is now the new source or serving gNB for the MWAB-MT 1012.

In the meantime, the target BH gNB 1003 may perform the Path Switch Request procedure toward the MW AB AMF 1004, with the exchange of Path Switch Request message 1027 and Path Switch Request Acknowledge 1028. It can be noted that the target BH gNB 1003 knows the AMF of the MWAB-MT 1012 as the identifier of this AMF is included in the Handover Request message 1022.

Upon reception of the Path Switch Request message 1027, the MW AB AMF 1004 executes the authorization control step 1040 to determine the updated authorization status of the MW AB node 1010. For this decision, the MW AB AMF 1004 uses the User Location Information (ULI) present in the Path Switch Request message 1027, defined in TS 38.413 section 9.3.1.16, and corresponding to the target cell to which the MWAB-MT 1012 is being handed over. The MW AB AMF 1004 uses the other information it already knows from the registration of the MWAB-MT 1012 (as described with reference to figure 6). The outcome of the authorization control step 1040 updates the authorization status of the MW AB node 1010 with the same level of information as defined with reference to figure 6. For example, as a result of executing the authorization control step 1040, the MW AB AMF 1004 provides authorization status information or updated authorization status information including information such as the information described with reference to one or more of the MW AB authorization status IE(s) discussed above with reference to figure 6. The updated authorization status may be included in the Path Switch Request Acknowledge message 1027. The target BH gNB 1003 may store the updated authorization status of the MW AB node 1010 at step 1050. The target BH gNB 1003 may also propagate the authorization status of the MW AB node 1010 to the MWAB-MT 1012 through the RRC Reconfiguration message 1031.

The MW AB AMF 1004 may also send the updated authorization status to the MWAB-MT 1012 through the Downlink NAS Transport message 1029. This NAS message is then embedded in the RRC message DL Information Transfer 1032, as described with reference to figure 8.

The authorization status or updated authorization status included in the message (e.g. 1028 or 1029) sent by the MW AB AMF 1004 may include authorization status information such as one or more of the MW AB authorization IE(s) discussed above with reference to figure 6.

When the MWAB-MT 1012 receives an updated authorization status, the MWAB-MT 1012 transmits the updated authorization status to the MWAB-gNB 1011 through the internal interface at the MW AB node 1010 and the Authorization Status message 1033. In case the MWAB-gNB 1011 is still “authorized” to operate without change in time and region of validity, then there is no particular action. In case the time and/or region of validity has changed, the MWAB-gNB 1011 should take into account this information (checking the current time and the current location (known by the MWAB-MT 1012 from the SIB1 message broadcasted in each cell)). In case the MWAB- gNB 1011 becomes “authorized”, the MWAB-gNB 1011 can serve UEs and it starts broadcasting synchronization signals and SIB1 message according to the content of the updated authorization status (e.g. according to the list of authorized PLMNs provided in the updated authorized status). Besides, the MWAB-MT 1012 can establish PDU sessions when necessary. In case the MWAB- gNB 1011 and/or the MWAB-MT 1012 become(s) “not authorized”, the procedure described with reference to figure 13, 15, or 17 may be applied.

When authorized and once the Path Switch Request procedure is completed, the control and user data associated with the MW AB node 1010 and its served UEs will transit through the target BH gNB 1003 and no more through the source BH gNB 1002. The target BH gNB 1003 sends a UE Context Release message 1034 to the source BH gNB 1002, to indicate that the handover procedure is completed, and the source BH gNB 1002 can delete the stored context information related to the MW AB node 1010.

In this Figure 10, the messages 1022, 1023, 1034 may correspond to the messages with the same name described in TS 38.423, the messages 1021, 1024, 1026, 1031, 1032 may correspond to the messages with the same name described in TS 38.331, the messages 1027, 1028, 1029 may correspond to the messages with the same name described in TS 38.413, and the RACH procedure 1025 may correspond to the RACH procedure described in TS 38.321.

Figure 11 is a schematic and simplified diagram illustrating an example message flow 1100 for performing a NG handover of a MW AB node while providing an update of the authorization status at the MW AB node, in accordance with one or more embodiments of the invention. This figure shows a source of first gNB 1102 (or source backhaul gNB, or source BH gNB or source backhaul RAN node or source BH RAN node) like the BH-gNB 502 of figure 5, a target or second gNB 1103 (or target backhaul gNB, or target BH gNB or target backhaul RAN node or target BH RAN node) like the BH-gNB 503 of figure 5, a MW AB node 1110 composed of or including the gNB or RAN node or MWAB-gNB unit 1111 and the MT or MWAB-MT unit 1112 (or MWAB- UE), and the AMF 1104 of the MWAB-MT 1112 (MWAB AMF or BH AMF) like the AMF 521a of figure 5, in a 5G core network (5GC) like the core network 520 of figure 5.

The beginning of the message flow is similar to the message flow 1000 described with reference to figure 10. The MWAB-MT 1112 is in RRC CONNECTED state and it is served by the source BH gNB 1102 through a cell (e.g source or serving cell) controlled by this gNB 1102. The MWAB-MT 1112 regularly performs measurement on signals received at the MWAB-MT 1112 from the serving cell and one or more target cells.

Based on the received measurement reports, the source BH gNB 1102 may detect that the MWAB-MT 1112 receives radio signals in a cell controlled by the target gNB (or target backhaul gNB, or target BH gNB) 1103 with a better quality than in the current serving cell controlled by the source BH gNB 1102. The source BH gNB 1102 may then decide at step 1120 the handover of the MWAB-MT 1112, and thus the handover of the MWAB node 1110.

The source BH gNB 1102 may execute a NG handover, for instance when there is no Xn interface between the source BH gNB 1102 and the target BH gNB 1103.

To trigger the handover, the source BH gNB 1102 sends a Handover Required message 1122 to the MWAB AMF 1104 indicating the selected target BH gNB 1103. Then, the MWAB AMF 1104 sends a Handover Request message 1123 to the target BH gNB 1103 including the information related to the MW AB node 1110 to be handed over. In particular, it may include the current authorization status of the MW AB node 1110.

However, upon reception of the Handover Required message 1122, the MW AB AMF 1104 may execute the authorization control step 1130 to determine what would be the update of the authorization status for the MW AB node 1110 if the handover to the target BH gNB 1103 is confirmed. For this step 1130, the MW AB AMF 1104 may use the Target ID IE (e.g. which includes information for identifying the target BH gNB 1103) present in the Handover Required message 1122, defined in TS 38.413 section 9.3.1.25. The MW AB AMF 1104 uses the other information it already knows from the registration of the MWAB-MT 1112 (as described with reference to figure 6). The outcome of the authorization control step 1130 provides an authorization status of the MW AB node 1110 with the same level of information as defined with reference to figure 6. For example, as a result of executing the authorization control step 1130, the MW AB AMF 1104 provides authorization status information or updated authorization status information including information such as the information described with reference to one or more of the MW AB authorization status IE(s) discussed above with reference to figure 6. As the handover to the target BH gNB 1103 has not yet been confirmed, such authorization status information may be considered as potential or future authorization status information (e.g. which will be applied once handover has been completed). This potential authorization status may be included in the Handover Request message 1123 in addition or instead of the current authorization status.

The target BH gNB 1103 may store the received authorization status of the MW AB node 1110 at the admission control step 1140. This step 1140 is similar to the step 1030 of the Figure 10 to decide whether the request is accepted or not.

If the target BH gNB 1103 has rejected the handover request, it sends a Handover Failure message (not represented in the Figure 11) as defined in TS 38.413 section 9.2.3.6. Upon reception of this message, the MW AB AMF 1104 sends to the source BH gNB 1102 a Handover Preparation Failure message (not represented in the Figure 11) as defined in TS 38.413 section 9.2.3.3, and the source BH gNB 1102 may consider another cell to hand over the MWAB-MT 1112. Also, the MW AB AMF 1104 does not consider the authorization status determined at step 1130 as a valid result, and keeps the authorization status as it was before the reception of the Handover Required message 1122.

If the target BH gNB 1103 has accepted the handover request, the handover procedure can be completed. Briefly, the target BH gNB 1103 sends a Handover Request Acknowledge message 1124 to the MW AB AMF 1104. Then, the MW AB AMF 1104 sends a Handover Command message 1125 to the source BH gNB 1102. Then, the source BH gNB 1102 sends a RRC Reconfiguration message 1126 containing the necessary information for the MWAB-MT 1112 to connect to the target cell, such as radio bearer(s), measurement configuration (information previously received by the source BH gNB 1102 from the target BH gNB 1103 via the acknowledgment message 1124 and the Handover Command message 1125). In case of conditional handover (CHO), the MWAB-MT 1112 is configured with a triggering condition to fulfil before switching to the target cell.

After switching to the target cell as the new serving cell, the MWAB-MT 1112 performs a random-access channel (RACH) procedure 1127 towards the target BH gNB 1103 to acquire uplink synchronization. Once synchronization is established, the MWAB-MT 1112 sends a RRC Reconfiguration Complete message 1128 to the target BH gNB 1103, which is now the new source or serving gNB for the MWAB-MT 1112.

The target BH gNB 1103 can then send a Handover Notify message 1129 to the MW AB AMF 1104 to indicate that the handover procedure is completed. At this stage, the target MW AB AMF 1104 may confirm the authorization status for the MW AB node 1110 it may have determined at the step 1130. As an alternative method, the MW AB AMF 1104 may perform the authorization control at this stage (with step 1140 instead of step 1130), using the User Location Information (ULI) present in the Handover Notify message 1129, defined in TS 38.413 section 9.3.1.16, and corresponding to the target cell to which the MWAB-MT 1112 has been handed over.

It can be noted that the target BH gNB 1103 does not need to execute the Path Switch Request procedure toward the MW AB AMF 1104, as the MW AB AMF 1104 already knows the target BH gNB 1103 as the new serving gNB for the MWAB-MT 1112.

At step 1150, the MW AB AMB 1104 may execute the Updated Authorization Status Transmission procedure described with reference to figure 8 and the reference 830.

When the MWAB-MT 1112 receives an updated authorization status, the MWAB-MT 1112 transmits the updated authorization status to the MWAB-gNB 1111 through the internal interface at the MW AB node 1110 and the Authorization Status message 1135. In case the MWAB-gNB 1111 is still “authorized” to operate without change in time and region of validity, there is no particular action. In case the time and/or region of validity has changed, the MWAB-gNB 1011 should take into account this information (checking the current time and the current location (known by the MWAB-MT 1012 from the SIB1 message broadcasted in each cell)). In case the MWAB-gNB 1111 becomes “authorized”, the MWAB-gNB 1111 can serve UEs and it start broadcasting synchronization signals and SIB1 message according to the content of the updated authorization status (e.g. according to the list of authorized PLMNs provided in the updated authorized status). Besides, the MWAB-MT 1112 can establish PDU sessions when necessary. In case the MWAB- gNB 1111 and/or the MWAB-MT 1112 become(s) “not authorized”, the procedure described with reference to figure 13, 15, or 17 may be applied. In case the MWAB-gNB 1111 and/or the MWAB- MT 1112 become(s) “authorized”, the procedure described with reference to figure 16 or 18 may be applied.

In this figure 11, the messages 1121, 1126, 1128 may correspond to the messages with the same name described in TS 38.331, the messages 1122, 1123, 1124, 1125, 1129 may correspond to the messages with the same name described in TS 38.413, and the RACH procedure 1127 may correspond to the RACH procedure described in TS 38.321.

At NG handover, the AMF serving the MWAB-MT 1112 may need to be changed as described in TS 23.502 section 4.9.1.3. In that case, some context information related to the MW AB node 1110 along with the current authorization status may be transferred from the old AMF to the new AMF. Also, this is the new AMF that may execute the Authorization Control step 1130 and/or 1140.

Figure 12 is a schematic and simplified diagram illustrating an example message flow 1200 for performing connection reestablishment for a MW AB node while providing an update of the authorization status at the MW AB node, in accordance with one or more embodiments of the invention. This figure shows a first gNB 1202 (or old backhaul gNB or old BH gNB or old backhaul RAN node or old BH RAN node) like the BH-gNB 502 of figure 5, a second gNB 1203 (or new backhaul gNB or new BH gNB or new backhaul RAN node or new BH RAN node) like the BH- gNB 503 of figure 5, a MW AB node 1210 composed of or including the gNB or RAN node or MWAB-gNB unit 1211 and the MT or MWAB-MT unit 1212 (or MWAB-UE), and the AMF 1204 of the MWAB-MT 1212 (MW AB AMF or BH AMF) like the AMF 521a of figure 5, in a 5G core network (5GC) like the core network 520 of figure 5.

At the beginning of the message flow 1200, the MW AB node 1210 is served by the gNB 1202 through a cell (e.g. serving cell) controlled by this gNB 1202. The MW AB node 1210 may serve one or several UEs (not represented in the Figure 12). The user data in downlink are provided by the 5GC to the gNB 1202 through a UPF (not represented in the Figure 12), then the user data are transmitted to the MWAB-MT 1212. Once transferred to MWAB-gNB 1211 through the internal interface between the MWAB-MT 1212 and the MWAB-gNB 1211, the user data are transmitted to the UE(s) through a radio bearer. The user data in uplink are similarly transmitted in the opposite direction from the UE(s) to the UPF in the 5GC.

When served by the gNB 1202, the MWAB-MT 1212 regularly performs measurement on signals received at the MWAB-MT 1212 from the serving cell and one or more target cells, such as the Signal Synchronization Block (SSB) transmitted in the serving cell and in the target cells. The target cells may be neighbouring cells to the serving or source cell (i.e. the current serving cell). It may happen that the SSB signal in the serving cell meets predefined criteria (for instance a received power that is below a predefined threshold) during a sufficient time to declare, at step 1220, a Radio Link Failure (RLF) for the link between the MWAB-MT 1212 and the gNB 1202. Besides, the MWAB-MT 1212 may have detected a SSB signal that meets predefined criteria (for instance a received power that is above a predefined threshold) sufficient to attempt a new connection in the corresponding target cell. In that case, the MWAB-MT 1212 triggers a reestablishment procedure as described in TS 38.300 section 9.2.3.3. It first consists in performing a random-access channel (RACH) procedure 1221 to obtain uplink resources, and then to transmit a RRC Reestablishment Request message 1222 in the target cell. This RRC message is received by gNB 1203 controlling the target cell.

The RRC Reestablishment Request message 1222 includes information to identify the gNB 1202 (i.e. the last serving gNB for the MWAB-MT 1212). Upon reception of the RRC Reestablishment Request message 1222, the gNB 1203 sends a Retrieve UE Context Request message 1223 to the gNB 1202 to retrieve the context of the requesting MW AB node 1210. In response, the gNB 1202 sends to the gNB 1203 a Retrieve UE Context Response message 1224 including the context information related to the MW AB node 1210. Based on the information related to the MW AB 1210, the gNB 1203 may execute the admission control step 1230 to decide to accept or to reject the connection request. The decision may be based on the same criteria as for the handover case described above with reference to figure 10.

If the gNB 1203 has rejected the request at step 1230, it will not respond to the MWAB-MT 1212 and the MWAB-MT 1212 will have to find another cell to try another reestablishment procedure. If the gNB 1203 has accepted the request, the gNB 1203 performs the Path Switch Request procedure toward the MW AB AMF 1204, with the exchange of Path Switch Request message 1225 and Path Switch Request Acknowledge 1226. It can be noted that the gNB 1203 knows the AMF 1204 of the MWAB-MT 1212 as the identifier of this AMF 1204 is included in the Retrieve UE Context Response message 1224.

Upon reception of the Path Switch Request message 1225, the MW AB AMF 1204 executes the authorization control step 1240 to determine the updated authorization status of the MW AB node 1210. For this purpose, the MW AB AMF 1204 uses the User Location Information, ULI, present in the Path Switch Request message 1225, defined in TS 38.413 section 9.3.1.16, and corresponding to the target cell through which the MWAB-MT 1212 is trying the reestablishment procedure. The MW AB AMF 1204 uses the other information it already knows from the registration of the MWAB-MT 1212 (as described with reference to figure 6). The outcome of the authorization control step 1240 updates the authorization status of the MW AB node 1210 with the same level of information as defined in the Figure 6. For example, as a result of executing the authorization control step 1240, the MW AB AMF 1204 provides authorization status information or updated authorization status information including information such as the information described with reference to one or more of the MW AB authorization status IE(s) discussed above with reference to figure 6. The updated authorization status may be included in the Path Switch Request Acknowledge message 1226. The target BH gNB 1203 may store the updated authorization status of the MW AB node 1210 at step 1250. The target BH gNB 1203 may also propagate the updated authorization status of the MW AB node 1210 to the MWAB-MT 1212 through the RRC Reconfiguration message 1228.

The MW AB AMF 1004 may also send the updated authorization status to the MWAB-MT 1012 through the second method described with reference to figure 8, with the Updated Authorization Status Transmission procedure 830.

When the MWAB-MT 1212 receives an updated authorization status, the MWAB-MT 1212 transmits the updated authorization status to the MWAB-gNB 1211 through the internal interface at the MW AB node 1210 and the Authorization Status message 1235. In case the MWAB-gNB 1211 is still “authorized” to operate without change in time and region of validity, there is no particular action. In case the time and/or region of validity has changed, the MWAB-gNB 1011 should take into account this information (checking the current time and the current location (known by the MWAB-MT 1012 from the SIB1 message broadcasted in each cell)). In case the MWAB-gNB 1211 becomes “authorized”, the MWAB-gNB 1211 can serve UEs and it start broadcasting synchronization signals and SIB1 message according to the content of the updated authorization status (e.g. according to the list of authorized PLMNs provided in the updated authorized status). Besides, the MWAB-MT 1212 can establish PDU sessions when necessary. In case the MWAB- gNB 1211 and/or the MWAB-MT 1212 become(s) “not authorized”, the procedure described with reference to figure 13, 15, or 17 may be applied. In case the MWAB-gNB 1211 and/or the MWAB- MT 1212 become(s) “authorized”, the procedure described with reference to figure 16 or 18 may be applied.

When authorized and once the Path Switch Request procedure is completed, the control and user data associated with the MW AB node 1210 and its served UEs will transit through the gNB 1203 (considered as the new serving BH gNB) and no more through the gNB 1202 (considered as the old serving BH gNB).

The gNB 1203 may send to the BH gNB 1202, a notification of the reconnection of the MW AB node 1210 through the UE Context Release message 1227. The gNB 1202 can then delete the stored context information related to the MW AB node 1210. In the meantime, the gNB 1203 may send a RRC Reconfiguration message 1228 containing the necessary information for the MWAB-MT 1212 to be served in the new cell, such as radio bearer(s), measurement configuration. The MWAB-MT 1212 then responds with a RRC Reconfiguration Complete message 1229 to the gNB 1203.

In this figure, the messages the messages 1222, 1228, 1229 may correspond to the messages with the same name described in TS 38.331, the messages 1223, 1224, 1227 may correspond to the messages with the same name described in TS 38.423, the messages 1225, 1226 may correspond to the messages with the same name described in TS 38.413, and the RACH procedure 1221 may correspond to the RACH procedure described in TS 38.321.

Figure 13 is a schematic and simplified diagram illustrating an example message flow 1300 for following the transition from “authorized” to not “authorized” at a MW AB node, in accordance with one or more embodiments of the invention. This figure shows a gNB 1302 (or backhaul gNB, or BH gNB or backhaul RAN node or BH RAN node) like the BH-gNB 502 of figure 5, a MW AB node 1310 composed of or including the gNB or RAN node or MWAB-gNB unit 1311 and the MT or MWAB-MT unit 1312 (or MWAB-UE), and the AMF 1304 of the MWAB-MT 1312 (MWAB AMF or BH AMF) like the AMF 521a of figure 5, in a 5G core network (5GC) like the core network 520 of figure 5. This figure also shows a UE 1301, like the UE 561, served by the MWAB-gNB 1311, a UPF 1303 (referred to as BH UPF) corresponding to the UPF providing access to the Data Network (not represented in the Figure 13) for the MWAB-MT 1312, and thus providing access to core network functions for the MWAB-gNB 1311, and access to core network functions and to the Data Network for the UEs (like UE 1301) served by the MWAB-gNB 1311. As an example with reference to figure 5, the BH UPF 1303 may be the UPF 522a. The AMF 1305 is an AMF handling UEs (like the UE 1301) served by the MWAB-gNB 1311. The AMF 1305 may be in the same or different core network as the core network of MWAB AMF 1304. The AMF 1305 (or UE’s AMF) and the MWAB AMF 1304 may be the same AMF (e.g. AMF 521a of figure 5).

At the beginning of the message flow, the MWAB-MT 1312 has registered toward the MWAB AMF 1304 as described with reference to Figure 6. At some point, the MWAB AMF 1304 may have detected a change in the conditions of operation of the MWAB node 1310 (e.g. because of mobility of the MWAB-MT 1312 as described with reference to figures 10, 11, 12) and an updated authorization status is to be transmitted to the MWAB-MT 1312. For example, the change may be due to a new location of the WAB node 1310 detected at RLF recovery or handover of the WAB- MT 1312.

The updated authorization status may be provided to the MWAB-MT 1312 by the MWAB AMF 1304 with the procedure 1320 corresponding to the procedure 830 described with reference to Figure 8. The MWAB-MT 1312 transmits the updated authorization status to the MWAB-gNB 1311 through the internal interface and the Authorization Status message 1311. In case the MWAB- MT 1312 is not in RRC_CONNECTED state and/or the MW AB AMF 1304 does not know the location of the MWAB-MT 1312, a paging procedure may be applied as described in TS 24.501 section 5.6.2 prior to the procedure 1320.

In the example of figure 13, it is assumed that the MWAB-gNB 1311 was authorized to operate and that the Authorization Status message 1311 contains the information that the MWAB- gNB 1311 is no more authorized to serve UEs.

Upon reception of this “not authorized” notification, the MWAB-gNB 1311 proceeds to the handover of all served UEs, like UE 1301, (e.g. it initiates handover of all of the UEs served by the MW AB node 1310) toward another gNB in the vicinity (step 1340). The selection of the target gNB for each UE like UE 1301 is based on the measurement reports (not represented in the Figure 13) provided by each UE and identifying target cell(s) and associated target gNB(s). The procedure to handover UEs (Xn handover or NG handover) is described in TS 38.300, TS 38.413. Depending on the location of the MW AB node 1310, the handover of all UEs may not be possible. For instance, with a MW AB node in an airplane flying, there may be no visible gNB for on-board UEs. Therefore, the step 1340 for UEs handover may be limited in time, for instance during 300 seconds, and this time may be configurable at the MWAB-gNB 1311. For example, on completion of handover of the UEs served by the mobile WAB node, or on expiry of a certain time period for performing handover of the UEs served by the MW AB node 1310, the handover procedure is terminated or determined to be completed and a reset message may be sent to the AMF handling the UEs served by the MW AB node 1310.

Once the step 1340 is completed (or terminated), the MWAB-gNB 1311 may proceed to the reset of NG interface with AMF(s), like AMF 1305, that were handling UEs (e.g. the served UEs). The procedure is similar to the procedure described with reference to figure 7 for NG interface setup. The MWAB-gNB 1311 sends a NG Reset message 1321 targeting the AMF 1305. This message 1321 is internally provided to the MWAB-MT 1312. To forward this message to the AMF 1305, the NG Reset message 1321 is embedded in PDU layer packet(s) to be transmitted to the BH UPF 1303 through the BH gNB 1302: packet(s) 1322 transmitted over the Uu interface between the MWAB-MT 1312 and the BH gNB 1302, packet(s) 1323 over the N3 interface between the BH- gNB 1302 and the BH UPF 1303. The NG Reset message 1321 is finally provided to the AMF 1305 through packet(s) 1324 transmitted over the N6 interface between the BH UPF 1303 and the AMF 1305. Upon reception of the NG Reset message 1321, the AMF 1305 responds to the MWAB-gNB 1311 with the message NG Reset Acknowledge 1328. The NG Reset Acknowledge 1328 is actually first provided to the BH UPF 1303 through packet(s) 1325 transmitted over the N6 interface, then embedded in PDU layer packet(s) transmitted to the MWAB-MT 1312 through the BH gNB 1302: packet(s) 1326 transmitted over the N3 interface between the BH UPF 1303 and the BH gNB 1302, and packet(s) 1327 transmitted over the Uu interface between the BH gNB 1302 and MWAB-MT 1312. The NG Reset Acknowledge 1328 is finally provided to the MWAB-gNB 1311 through the internal interface at the MW AB node 1310.

The MWAB-gNB 711 may then notify the MWAB-MT 1312 about the completion of NG Reset interface with the message 1332. This message 1332 may be sent when all NG interfaces with AMFs handling the served UEs have been reset.

At step 1350, the MWAB-MT 1312 may release the PDU session(s) it has previously established with BH UPF 1303. The procedure for PDU session release is described in TS 23.501. Once all PDU sessions have been released, the MW AB AMF 1304 may deregister the MWAB-MT 1312, following a procedure described in TS 23.501. The MWAB-MT 1312 may be kept registered so that the MWAB-MT 1312 may be handed over in RRC CONNECTED.

Figures 14a to 14c are examples of methods for use in managing authorization or authorization status of a mobile wireless access backhaul, WAB, node.

Briefly, at a mobile WAB node, a method for use in managing authorization of the mobile WAB node (which may be implemented as a Femto node), which mobile WAB node includes a MT component or unit and a gNB or RAN node component or unit for serving one or more UEs, comprises receiving authorization status information for indicating whether the mobile WAB node is authorized to operate as a mobile WAB node. See, for example, step 1402 of figure 14a. For example, with reference to the communication system 500 shown in and described with respect to figure 5, the mobile WAB node or MW AB node may be the MW AB node 540 including gNB or RAN node component or unit or entity MWAB-gNB 542 and MT component or unit or entity MWAB-MT 541. The method may be performed by software elements and/or hardware elements. The MW AB node may be implemented in a network node or base station 400 as shown in and described with reference to figure 4 with the method being performed by an apparatus for the MW AB node including one or more processing units, such as the processing unit 402. More details of the method are described below with reference to the example method described with reference to figure 14a.

The authorization status information may be received from a backhaul gNB to which the MW AB node 540 is connected or is to be connected. For example, when connected to a backhaul gNB, such as BH gNB 502, the MW AB node 540 may receive the authorization status information (or updated authorization status information) after registration of the MW AB node 540 via the BH gNB 502 (e.g. after registration with an AMF, such as an AMF associated with or related to a PLMN selected by the MW AB node). The authorization status information may be received in messages such as RRC Reconfiguration 832, DL Information Transfer 834, RRC Reconfiguration 1031, DL Information Transfer 1032, RRC reconfiguration 1126, RRC Reconfiguration 1228 as described above.

In an example where the MW AB node 540 is being served or was last served by a cell of a first backhaul gNB (e.g. source backhaul gNB such as BH gNB 502), the authorization status information may be received from a second backhaul gNB (e.g. target backhaul gNB such as BH gNB 503), to which the MW AB node 540 is or is to be connected (i.e. a target gNB to which communication has been or is to be established). The second backhaul gNB may be a second backhaul gNB selected for handover (such as described above with reference to figures 10 and/or 11), or may be a second backhaul gNB for reestablishing a RRC connection (on detecting RLF such as described above with reference to figure 12). The authorization status information may be received in messages such as RRC Reconfiguration 832, DL Information Transfer 834, RRC Reconfiguration 1031, DL Information Transfer 1032, RRC reconfiguration 1126, RRC Reconfiguration 1228 as described above.

The authorization status information may be received from an AMF (such as AMF 521a) of a core network (e.g. the AMF sending the authorization status information is the AMF associated with or related to the MW AB node (i.e. an AMF with which the MW AB has been registered), such as an AMF associated with a PLMN selected by the MW AB node). For example, the authorization status information may be received in messages such as NG AMF Configuration Update message 924 and/or a Downlink NAS Transport message 833 as described above. The NG AMF Configuration Update message 924 is received after registration of the MW AB node 540 and may provide updated authorization status information.

In an example, the MW AB node 540 may send a request, such as a connection setup request, including information for indicating the request is associated with a MW AB node. The request may indicate the MW AB node 540 intends to operate as a MW AB node. See for example, step 1401 of figure 14a. After sending the connection setup request, the MW AB node 540 receives a response, which response includes the authorization status information. See for example, step 1402 of figure 14a.

The request may be sent by the MW AB node 540 through a backhaul gNB (e.g. 502) to which the MW AB node is or is to be connected and the response may be received through the backhaul gNB. In this case, the request may be NAS Registration request sent in a RRC Setup complete message 621 and the response including the authorization status information may be included in a RRC Reconfiguration message 626 in the case where the MW AB node is authorized (i.e. RRC Reconfiguration message 626 with NAS registration accept) or in a DL Information Transfer message 625 in the case where the MW AB node is not authorized (i.e. DL Information Transfer message 625 with NAS registration reject), as described above. The request may be sent by the MW AB node 540 to an AMF of a core network (such as AMF 521a associated with or related to the MW AB node 540) in a NG Setup request message 721 and the response including the authorization status information from the AMF 521a may be included in a NG Setup response message 728 in the case where the MW AB node is authorized or in a NG Setup Failure message in a case where the MW AB node is not authorized, as described above.

In an example, the request further includes at least one of: information for identifying an AMF to which the MW AB node 540 is connected; information for indicating a location of the MW AB node 540 (e.g. region or area in which the MW AB node is located), such as the User Location Identifier, ULI; information for indicating the MW AB node supports local services; information indicating the expected trajectory or path of the MW AB node (and/or region(s)/area(s) in which the MW AB node will be located); information for identifying the MT component of the mobile WAB node, such as the 5G-GUTI for the MT; information identifying one or more Public Land Mobile Networks, PLMNs, in which the mobile WAB node may operate. The request may include one or more of the information elements of the available information discussed above with reference to figure 6 and the information used by the AMF to determine the authorization status of the MW AB node.

After registration, the authorization status of the MW AB node 540 may be changed. For example, due to mobility of the MW AB node 540, the MW AB node may be located in a new geographical area and so the authorization status of the MW AB node may need to be updated.

See, for example, the description above with respect to figures 8, 9, or 13.

In a case where the MW AB node 540 is in an authorized state in which the MW AB node is authorized to operate as a MW AB node (e.g. has been previously authorized), the MW AB node 540 may receive authorization status information (e.g. updated authorization status information) indicating the MW AB node 540 is not authorized or no longer authorized to operate as a MW AB node (e.g. the previously received authorization status information has been updated from authorized to non-authorized/unauthorized) and after receiving such authorization status information the MW AB node 540 changes its state to an unauthorized state. After receiving such authorization status information, the MW AB node 540 will take appropriate action. See for example the description with reference to figure 13. For example, the appropriate action may include performing handover of any served UEs as described with reference to step 1340. Thus, after receiving such authorization status information, the MW AB node 540 may initiate handover of the UEs served by the MW AB node. In addition, on completion of handover of the UEs served by the mobile WAB node, or on expiry of a certain time period for performing handover, the MW AB node may terminate handover to ensure handover is completed or terminated within a certain time. After receiving such authorization status information, the MW AB node 540 may also send a reset message (such as NG Reset message 1321). The NG Reset message is sent to the AMF 521a associated with the MW AB node 540 so as to reset the NG interface with the AMF that was handling the served UEs.

In a case where the MW AB node 540 is in a non-authorized or unauthorized state in which the MW AB node is not authorized to operate as a MW AB node (e.g. has been previously not authorized), the MW AB node 540 may receive authorization status information indicating the MW AB node 540 is authorized oris now authorized to operate as a MW AB node (e.g. the previously received authorization status information has been updated from non-authorized/unauthorized to authorized) and after receiving such authorization status information the MW AB node 540 changes its state to an authorized state. After receiving such authorization status information, the MW AB node 540 will take appropriate action. See for example the description with reference to figures 10, 11 or 12. For example, the appropriate action may include as the MW AB 540 can now serve UEs, the MW AB 540 starting broadcasting synchronization signals and SIB1 message according to the content of the authorization status information (e.g. according to the list of authorized PLMNs) and/or the MT of the MW AB node 540 can establish PDU sessions when necessary.

In a case where the MW AB node 540 is in an authorized state in which the MW AB node is authorized to operate as a MW AB node (e.g. has been previously authorized), the MW AB node 540 may receive updated authorization status information, and after receiving such updated authorization status information, the MW AB node 540 may change or may not change, based on the received updated authorization status information, the authorized state of the MW AB node or how the MW AB node operates. The updated authorization status information may include information indicating any one of the authorized PLMN(s), the region/area of validity, the time of validity, the local services authorization has changed. For example, when the updated authorization status information includes information indicating the MW AB node 540 can no longer provide local services (whereas before receiving the updated authorization status information, the MW AB node 540 was authorized to provide local services), the MW AB node 540 will change its operation so that it no longer provides local services. In case the time and/or region of validity has changed, the MW AB node 540 should take into account this information (checking the current time and the current location (known by the MW AB node 540 from the SIB1 message broadcasted in each cell)).

Briefly, at a AMF entity of a core network, a method for use in managing authorization of the mobile WAB node (which may be implemented as a Femto node), which mobile WAB node includes a MT component or unit and a gNB or RAN node component or unit for serving one or more UEs, comprises sending authorization status information for indicating whether the mobile WAB node is authorized to operate as a mobile WAB node. See, for example, step 1413 of figure 14b and step 1423 of figure 14c. The AMF entity sending the authorization status information is the AMF associated with or serving the MW AB node (i.e. an AMF with which the MW AB has been registered), such as an AMF associated with a PLMN selected by the MW AB node. For example, with reference to the communication system 500 shown in and described with respect to figure 5, the AMF entity may be the AMF 521a serving the MW AB node 540 including gNB component MWAB-gNB 542 and MT component MWAB-MT 541. The method may be performed by software elements and/or hardware elements. The AMF may be implemented in a network node 400 as shown in and described with reference to figure 4 with the method being performed by an apparatus for the AMF including one or more processing units, such as the processing unit 402. More details of the method are described below with reference to the example methods described with reference to figures 14b and 14c.

The AMF entity 521a may determine the authorization status for operation of the MW AB node 540 as a mobile WAB node (e.g. see step 1412 of figure 14b and step 1422 of figure 14c). For example, the AMF entity 521a may determine the authorization status for operation of the MW AB node 540 as a mobile WAB node based on information available to the AMF entity 521a, such as the available information described above with reference to figure 6. The AMF entity 521a may receive one or more IES of the available information from another entity of the core network 520 (such as a UDM) and/or from the MW AB node 540 and/or from a backhaul gNB (connected or to be connected to the MW AB node 540).

In an example, the AMF entity 521a receives a request including information for indicating the request is associated with a mobile WAB node and sends a response to the request including the authorization status information. The request may be a connection setup request received from a MW AB node (such as in a NG Setup request message 721) and the response may be sent to the MW AB node (such as in a NG Setup response message 728 in a case where the MW AB node is authorized or a NG Setup Failure message in a case where the MW AB node is not authorized). The request from the MW AB node may indicate the MW AB intends to operate as a MW AB node. The request may be a handover request associated with the MW AB node or a path switch request associated with the MW AB node which request may be received from a backhaul gNB connected to the MW AB node (in the case of a source gNB) or to be connected to the MW AB node (in the case of a target gNB or new gNB). The response to the handover request or path switch request is sent to the backhaul gNB.

In an example, the request further includes at least one of: information for identifying an AMF to which the MW AB node 540 is connected; information for indicating a location of the MW AB node 540 (e.g. region or area in which the MW AB node is located), such as the User Location Identifier, ULI; information for indicating the MW AB node supports local services; information indicating the expected trajectory or path of the MW AB node (and/or region(s)/area(s) in which the MW AB node will be located); information for identifying the MT component of the mobile WAB node, such as the 5G-GUTI for the MT; information identifying one or more Public Land Mobile Networks, PLMNs, in which the mobile WAB node may operate.

The AMF entity 521a may determine a change in conditions of operation of the MW AB node 540 (e.g. due to mobility of the MW AB node 54 as described with reference to figures 10, 11, 12 ). For example, the change may be due to a new location of the MW AB node 540 detected at RLF recovery or handover of the MT component of the MW AB node 540 or the authorization status change happens at a predefined time or at the expiry of a timer in the AMF (e.g. BH AMF) associated with the MT component of the MW AB node 540. As a result the AMF entity 521a may send updated authorization status information associated with the MW AB node. Figures 8, 9 and 13 and the accompanying description provide more details regarding updating the authorization status information. As an example, one or more of the authorization status information IES described above with reference to figure 6 may be updated, based on the change in operation conditions, compared to authorization status information sent previously.

Briefly, at a mobile WAB node, a method for use in managing authorization of the mobile WAB node (which may be implemented as a Femto node), which mobile WAB node includes a MT component or unit and a gNB or RAN node component or unit for serving one or more UEs, comprises: sending, to an AMF entity of a core network, a setup request including information for indicating the mobile WAB node intends to operate as a mobile WAB node and information for indicating a location of the mobile WAB node (e.g. region or area in which the MW AB node is located), such as the User Location Identifier, ULI; receiving, from the AMF entity, authorization status information for indicating whether the mobile WAB node is authorized to operate as a mobile WAB node. For example, with reference to the communication system 500 shown in and described with respect to figure 5, the mobile WAB node or MW AB node may be the MW AB node 540 including gNB or RAN node component or unit or entity MWAB-gNB 542 and MT component or unit or entity MWAB-MT 541 and the AMF entity may be AMF 521a. The method may be performed by software elements and/or hardware elements. The MW AB node may be implemented in a network node or base station 400 as shown in and described with reference to figure 4 with the method being performed by an apparatus for the MW AB node including one or more processing units, such as the processing unit 402.

In an example, the setup request further includes at least one of information for identifying an AMF to which the MT component 541 of the MW AB node 540 is connected; information for indicating the MW AB node supports local services.

Briefly, at a mobile WAB node in a case where the mobile WAB node is in an authorized state in which the mobile WAB node is authorized to operate as a mobile WAB node, a method for use in managing authorization of the mobile WAB node (which may be implemented as a Femto node), which mobile WAB node includes a MT component or unit and a gNB or RAN node component or unit for serving one or more UEs, comprises: receiving authorization status information indicating the mobile WAB node is not (or no longer authorized) to operate as a mobile WAB node; after receiving authorization status information indicating the mobile WAB node is not (or no longer) authorized to operate as a mobile WAB node, sending a reset message. The reset message may be sent to an AMF entity associated with or serving the mobile WAB node and may be a NG Reset message so as to reset the NG interface with the AMF entity that was handling the served UEs of the MW AB node. For example, with reference to the communication system 500 shown in and described with respect to figure 5, the mobile WAB node or MW AB node may be the MW AB node 540 including gNB or RAN node component or unit or entity MWAB-gNB 542 and MT component or unit or entity MWAB-MT 541 and the AMF entity may be AMF 521a. The method may be performed by software elements and/or hardware elements. The MW AB node may be implemented in a network node or base station 400 as shown in and described with reference to figure 4 with the method being performed by an apparatus for the MW AB node including one or more processing units, such as the processing unit 402.

As discussed above, after receiving authorization status information indicating the mobile WAB node is not (or no longer) authorized to operate as a mobile WAB node, the MW AB node 540 may initiate handover of the UEs served by the mobile WAB node 540. In an example, on expiry of a certain time period for performing handover of the UEs served by the mobile WAB node, the MW AB node 540 may terminate handover and send the reset message.

Briefly, at a mobile WAB node in a case where the mobile WAB node is in an authorized state in which the mobile WAB node is authorized to operate as a mobile WAB node, a method for use in managing authorization of the mobile WAB node (which may be implemented as a Femto node), which mobile WAB node includes a MT component or unit and a gNB or RAN node component or unit for serving one or more UEs, comprises: receiving authorization status information indicating the mobile WAB node is not (or no longer authorized) to operate as a mobile WAB node; after receiving authorization status information indicating the mobile WAB node is not (or no longer) authorized to operate as a mobile WAB node, initiating handover of the UEs served by the mobile WAB node sending a reset message; on expiry of a certain time period for performing a handover procedure for the UEs served by the mobile WAB node, terminating the handover procedure. For example, with reference to the communication system 500 shown in and described with respect to figure 5, the mobile WAB node or MW AB node may be the MW AB node 540 including gNB or RAN node component or unit or entity MWAB-gNB 542 and MT component or unit or entity MWAB-MT 541. The method may be performed by software elements and/or hardware elements. The MW AB node may be implemented in a network node or base station 400 as shown in and described with reference to figure 4 with the method being performed by an apparatus for the MW AB node including one or more processing units, such as the processing unit 402.

In an example, after terminating the handover procedure, the MW AB node 540 sends a reset message. The reset message may be sent to an AMF entity associated with or serving the mobile WAB node (such as AMF entity 521a of figure 5) and may be a NG Reset message so as to reset the NG interface with the AMF entity that was handling the served UEs of the MW AB node.

For the methods discussed above (e.g. at the MW AB node and the AMF entity), the authorization status information may include at least one of cause information for indicating a cause for non-authorization in a case where the MW AB node 540 is not authorized to operate (for example, such cause information may indicate the subscription associated with the MW AB node does not allow authorization, or a time period in which the authorization is valid has expired, or the MW AB node is no longer in a region for which the MW AB node is authorized); information for indicating the MW AB node 540 is authorized to operate as a mobile WAB node and the authorization is limited to providing local services (e.g. providing local services to the UEs served by the MW AB node). The information indicating the authorization is limited to providing local services may include a local services support indication to inform the MW AB node that it can provide local services onboard as discussed above with reference to figure 6. In such a case, one or more UPF entities are embedded in the MW AB node for communicating data between UEs served by the MW AB node and/or between a server coupled to the embedded UPF entity and one or more UEs served by the MW AB node.

In an example, the authorization status information includes authorization information for indicating whether at least one of the MT component and the gNB component of the MW AB node 540 is authorized to operate. For example, the authorization status information may include MW AB authorization status information for indicating whether the gNB component of the mobile WAB node is authorized to serve one or more UE and/or for indicating whether the MT component of the mobile WAB node is authorized to connect to one or more Public Land Mobile Networks, PLMNs and/or to support backhauling of the traffic to and from the gNB component of the MW AB node. The authorization status information may include at least one of gNB authorization status information for indicating whether the gNB component of the MW AB node 540 is authorized to serve one or more UE (i.e. operate as a gNB); MT authorization status information for indicating whether the MT component of the MW AB node 540 is authorized to connect to one or more Public Land Mobile Networks, PLMNs and/or to support backhauling of the traffic to and from the gNB component of the MW AB node (e.g. the gNB component that is co-located with the MT component). Thus, for example, the MW AB node may be authorized (e.g. both the MT component of the MW AB node and the gNB component of the MW AB node are authorized), or not authorized (e.g. both the MT component of the MW AB node and the gNB component of the MW AB node are not authorized), or the MT component of the MW AB node may be authorized but the gNB component of the MW AB node may be not authorized.

The MT authorization status information may include at least one of: information for indicating a region in which the MT of the MW AB node is authorized to connect to one or more Public Land Mobile Networks, PLMNs (e.g. region or area of validity of the authorization) and/or to support backhauling of the traffic to and from the gNB component of the MW AB node; time information for indicating a time period for which the MT of the MW AB node is authorized to connect to one or more PLMNs; PLMN information for indicating one or more PLMNs to which the MT component of the MW AB node is authorized to connect; unauthorized PLMN information for indicating one or more PLMNs to which the MT of the MW AB node is not authorized to connect.

The gNB authorization status information may include at least one of: information for indicating a region in which the gNB component of the MW AB node 540 is authorized to serve one or more UEs (e.g. region or area of validity of the authorization); time information for indicating a time period for which the gNB component of the MW AB node is authorized to serve one or more UEs; PLMN information for indicating one or more PLMNs for or with which the MW AB node (i.e. the gNB component of the MW AB node) is authorized to serve one or more UEs; unauthorized PLMN information for indicating one or more PLMNs for or with which the MW AB node (i.e. the gNB component of the MW AB node) is not authorized to serve one or more UEs; information for indicating the authorization for the MW AB node to serve one or more UE is limited to local services. The PLMN information included in the MT and/or gNB authorization status information may include a list of one or more PLMNs with which the MW AB node is authorized to operate. The unauthorized PLMN information included in the MT and/or gNB authorization status information may include a list of one or more PLMNs with which the MW AB node is not authorized to operate.

The authorization status information may include one or more of the authorization status IES as discussed above with reference to figure 6.

Figure 14a is a flowchart 1400 of an example method for managing at a MW AB node the reception of its authorization status. For example, with reference to the communication system 500 shown in and described with respect to figure 5, the MW AB node may be the MW AB node 540, and the AMF may be the AMF 521a. The method 1400 as shown in and described with respect to figure 14a may be performed by software elements and/or hardware elements. The MW AB node may be implemented in a network node or base station400 as shown in and described with reference to figure 4 with the method as shown in and described with respect to figure 14a being performed by an apparatus for the MW AB node including one or more processing units, such as the processing unit 402.

At step 1401, the MW AB node 540 sends a connection setup request to the AMF 521 indicating the intention to operate as a MW AB node. For example, the MW AB node 540 sends a connection setup request indicating the request is associated with a MW AB node (e.g. for indicating the MW AB node intends to operate as a MW AB node). It may be the MWAB-MT 541 of the MW AB node 540 sending a NAS message to the AMF 521a as described with respect to figure 6. For example, the request is sent to the AMF 521a in a NAS registration request message included in a RRC Setup Complete message 621 and the NGAP Initial UE message 622. It may be the MWAB-gNB 542 sending a NGAP message to the AMF 521a as described with respect to figure 7. For example, the request is sent to the AMF 521a in a NG Setup Request message 721.

At step 1402, the MW AB node 540 receives a response including the authorization status for the operation as a MW AB node. It may be the MWAB-MT 541 of the MW AB node 540 receiving a NAS message from the AMF 521a as described with reference to figure 6. For example, the response is received at the MWAB-MT 541 in the RRC Reconfiguration 626 message in a case where the MW AB node is authorized to operate as a MW AB node or the DL Information Transfer message 625 in a case where the MW AB node is not authorized to operate as a MW AB node (or at least the MWAB-gNB 542 is not authorized). It may be the MWAB-gNB 542 receiving a NG message from the AMF 521a as described with reference to figure 7. For example, the response is received at the MWAB-gNB 542 in a NG Setup Response message 728. Figure 14b is a flowchart 1410 of an example method for managing at an AMF the authorization status related to a MW AB node connecting to the network (i.e. a 5G core network through a Radio Access Network (RAN)). For example, with reference to the communication system 500 shown in and described with respect to figure 5, the MW AB node may be the MW AB node 540, and the AMF may be the AMF 521a of the 5G core network 520. The method 1410 as shown in and described with respect to figure 14b may be performed by software elements and/or hardware elements. The AMF 521a may be implemented in a network node or base station 400 as shown in and described with reference to figure 4 with the method as shown in and described with respect to figure 14b being performed by an apparatus for the AMF including one or more processing units, such as the processing unit 402.

At step 1411, the AMF 521a receives a connection setup request indicating the intention of the MW AB node 540 to operate as a MW AB node. For example, the AMF 521a receives a connection setup request indicating the request is associated with a MW AB node (e.g. for indicating the MW AB node intends to operate as a MW AB node). It may be the MWAB-MT 541 of the MW AB node 540 sends a NAS message to the AMF 521a as described with reference to figure 6. For example, the request is sent to the AMF 521a in a NAS registration message included in a RRC Setup Complete message 621 and the NGAP Initial UE message 622. It may be the MWAB-gNB 542 sends a NGAP message to the AMF 521a as described with reference to figure 7. For example, the request is sent to the AMF 521a in a NG Setup Request message 721.

At step 1412, the AMF 521a determines the authorization status for the operation of the MW AB node 540 as a MW AB node, based on the information elements received in the request at step 1411, and on subscription information related to the MW AB node 540 and stored in the 5G core network 520.

At step 1413, the AMF 521a sends a response including the authorization status for the operation as a MW AB node. It may be the MWAB-MT 541 of the MW AB node 540 receives a NAS message from the AMF 521a as described with reference to figure 6. For example, the response is sent by the AMF 521a in the RRC Reconfiguration 626 message in a case where the MW AB node is authorized to operate as a MW AB node or the DL Information Transfer message 625 in a case where the MW AB node is not authorized to operate as a MW AB node (or at least the MWAB-gNB 542 is not authorized). It may be the MWAB-gNB 542 receives a NG message from the AMF 521a as described with reference to figure 7. For example, the response is sent by the AMF 521a to the MWAB-gNB 542 in a NG Setup Response message 728.

Figure 14c is a flowchart 1420 of an example method for managing at an AMF the update of authorization status related to a MW AB node. For example, with reference to the communication system 500 shown in and described with respect to figure 5, the MW AB node may be the MW AB node 540, the AMF may be the AMF 521a of the 5G core network 520, the source gNB may be the BH-gNB2 502, and the target gNB may be the BH-gNB3 503. The method 1420 as shown in and described with respect to figure 14b may be performed by software elements and/or hardware elements. The AMF 521a may be implemented in a network node or base station 400 as shown in and described with reference to figure 4 with the method as shown in and described with respect to figure 14c being performed by an apparatus for the AMF including one or more processing units, such as the processing unit 402.

At step 1421, the AMF 521a receives handover request or a path switch request related to a MW AB node. It may be the source gNB 502 serving the MWAB-MT of the MW AB node 540 sends a handover required message 1122 (NGAP message) to the AMF 521a as described with reference to figure 11. It may be the target gNB 503 to serve the MWAB-MT of the MW AB node 540 sends a path switch request message 1027 (NGAP message) to the AMF 521a as described with reference to figure 10. It may be the new gNB 503 to serve the MWAB-MT of the MW AB node 540 sends a path switch request 1225 to the AMF 521a as described with reference to figure 12.

At step 1422, the AMF 521a determines the authorization status for the operation of the MW AB node 540 as a MW AB node, based on the information elements received in the request at step 1421, and on subscription information related to the MW AB node 540 and stored in the 5G core network 520.

At step 1423, the AMF 521a sends a response including the authorization status for the operation as a MW AB node. It may be a NGAP message sent to the target gNB (e.g. in Path Switch Request Ack 1028 of figure 10 or in Path Switch Request Ack 1226 of figure 12) as described with reference to figure 10 or 12. It may be a NGAP message sent to the target gNB (e.g. via the UE Context Modification procedure 831) or a NAS message (e.g. NAS message in Downlink NAS Transport message 833 and DL Information Transfer message 834) sent to the MWAB-MT of the MW AB node 540 as described with reference to figure 8.

The above description discusses how the authorization status of a MW AB node may change. In the following description with reference to figures 15-18, examples of how the MW AB node may behave when the authorization status changes, from authorized to non-authorized, and from nonauthorized to authorized are provided.

Figure 15 is a schematic and simplified diagram illustrating an example message flow 1500 for following the transition from “authorized” to not “authorized” at a WAB-MT component of a WAB node, in accordance with one or more embodiments of the invention. This figure shows a backhaul RAN node 1502 (or BH RAN node) like the BH-gNB 502 of figure 5, a WAB node 1510 composed of or including the gNB or RAN node or WAB-gNB unit 1511 and the MT or WAB-MT unit 1512, and the backhaul AMF 1504 of the WAB-MT 1512 (BH AMF) like the AMF 521a of figure 5, in a 5G core network (5GC) like the core network 520 of figure 5. This figure also shows a UE 1501, like the UE 561, served by the WAB-gNB 1511. The UE’s AMF 1505 is an AMF handling UEs (like the UE 1501) served by the MWAB-gNB 1511. The AMF 1505 may be in the same or different core network as the core network of BH AMF 1504. The UE’s AMF 1505 and the BH AMF 1504 may be the same AMF (e.g. AMF 521a of figure 5). In the description of figure 15 the WAB node 1510 may also be referred to as a mobile WAB node.

At the beginning of the message flow, it is assumed that the WAB-MT 1512 is authorized to support backhauling of the traffic related to the WAB-gNB 1511. The step 1521 covers first the detection of the authorization status change of the WAB-MT 1512 to “not authorized” to support backhauling of the traffic related to the WAB-gNB 1511, and then the transmission of this status to the WAB-MT 1512.

According to one embodiment, the BH AMF 1504 detects a change in the conditions of operation of the WAB node 1510 (e.g. because of mobility of the WAB-MT 1512 as described with reference to figures 10, 11, 12) and the updated authorization status is to be transmitted to the WAB- MT 1512. For example, the change may be due to a new location of the WAB node 1510 detected at RLF recovery or handover of the WAB-MT 1512. According to another example, the authorization status change happens at a predefined time or at the expiry of a timer in the BH AMF 1504. Then, the updated authorization status may be provided by the BH AMF 1504 to the WAB- MT 1512 with the procedure 830 described with reference to figure 8. Before applying the procedure 830, and in case the WAB-MT 1512 is not in RRC CONNECTED state and/or the BH AMF 1504 does not know the location of the WAB-MT 1512, a paging procedure may be applied as described in TS 24.501 section 5.6.2. Also, in case the WAB-MT 1512 was deregistered, a registration procedure may be applied as described in TS 24.501 section 5.5.1.2.

According to another embodiment, at a predefined time or at the expiry of a timer in the WAB- MT 1512, or at the detection of being located in a new geographical area (e.g. by reading the Tracking Area Code in the System Information Block broadcasted in the cell where the WAB-MT 1512 is located), the WAB-MT 1512 detects the need to check its authorization status. In case the WAB-MT 1512 is not registered, the WAB-MT 1512 may trigger a registration procedure toward the BH AMF 1504 as described in TS 24.501 section 5.5.1.2. Otherwise, the WAB-MT 1512 may trigger a mobility registration update procedure toward the BH AMF 1504 as described in TS 24.501 section 5.5.1.3. Then, the BH AMF 1504 checks the authorization status of the WAB-MT 1512 and transmits the authorization status update through, for instance, the procedure 830 described with reference to figure 8.

After the completion of step 1521, the WAB-MT 1512 transmits the updated authorization status to the WAB-gNB 1511 through the internal interface and the Notification message 1531.

In the example of figure 15, it is assumed that the WAB-MT 1512 is no longer authorized to support backhauling of the traffic related to the WAB-gNB 1511 (e.g. the WAB-MT 1512 determines the authorization status of the WAB-MT 1512 has changed to “not authorized” to support backhauling of the traffic related to the WAB-gNB 1511, such as via step 1521 described above). The Notification 1531 informs the WAB-gNB 1511, which is then no longer able to serve UEs regardless the authorization status of WAB-gNB 1511 itself.

If the WAB-gNB 1511 was authorized to serve UEs at the reception of Notification 1531, the WAB-gNB 1511 first disables the admission of any new UE. Then it proceeds to the handover of all served UEs, like UE 1501, (e.g. it initiates handover of all of the UEs served by the WAB-gNB 1511) toward another NG-RAN node in the vicinity (step 1522). The selection of the target NG- RAN node for each UE like UE 1501 is based on the measurement reports (not represented in the figure 15) provided by each UE and identifying target cell(s) and associated target NG-RAN node(s). The procedure to handover UEs (Xn handover or NG handover) is described in TS 38.300, TS 38.413. To handle UEs that are not in RRC CONNECTED state, the WAB-gNB 1511 may page the UEs previously set in a non RRC CONNECTED state by the WAB-gNB 1511. The paging may be limited to the cell(s) controlled by the WAB-gNB 1511. Then, the WAB-gNB 1511 may set back in RRC CONNECTED state the UEs that are still camping on a cell controlled by the WAB-gNB 1511, and that have answered to the paging message.

Depending on the location of the WAB node 1510, the handover of all UEs may not be possible. For instance, with a WAB node in an airplane flying, there may be no visible NG-RAN node for on-board UEs. Therefore, the step 1522 for UEs handover may be limited in time, for instance during 300 seconds, and this time may be configurable at the WAB-gNB 1511. For example, on completion of handover of the UEs served by the mobile WAB node, or on expiry of a certain time period for performing handover of the UEs served by the WAB-gNB 1511, the handover procedure is terminated or determined to be completed.

If the WAB-gNB 1511 was not serving any UEs at the reception of the Notification 1531 , the step 1522 may be limited to the configuration of the WAB-gNB 1511 to not accept the admission of any new UE.

Once the step 1522 is completed (or terminated), the WAB-gNB 1511 may proceed to the removal of the existing Xn connect! on(s) with other NG-RAN node(s) (including the BH RAN node 1502). This step 1523 may correspond to the procedure described in TS 38.423 section 8.4.6 repeated for each existing Xn connection. The step 1523 is only necessary when an Xn connection was previously established by the WAB-gNB 1511 through the backhaul link between the WAB- MT 1512 and the BH RAN node 1502.

Also, the WAB-gNB 1511 proceeds to the removal or the suspension of existing NG connect! on(s) with AMF(s), that were handling the served UEs, like the UE’s AMF 1505. This step 1524 is similar to the procedure described with reference to figure 7 for NG interface setup but using NG removal request and NG removal response messages instead of messages 721 and 728. In an alternative method, the existing NG connection(s) may be suspended, to be resumed later when the WAB-gNB 1511 is able again to served UEs. The step 1524 is only necessary when at least one NG connection was previously established by the WAB-gNB 1511 through the backhaul link between the WAB-MT 1512 and the BH RAN node 1502.

Besides, at step 1525 the WAB-gNB 1511 turns off the Uu interface and thus deactivates the controlled cell(s) and stops broadcasting Master Information Block (MIB) and System Information Block(s) (SIB(s) on the Uu interface.

If the WAB-gNB 1511 was not authorized to serve UEs at the reception of Notification 1531, the steps 1522, 1523, 1524, 1525 are not necessary.

Internal to the WAB node 1510, a Notification message 1532 is sent by the WAB-gNB 1511 to the WAB-MT 1512 to notify the completion of shut down operation at the WAB-gNB 1511.

At step 1526, the WAB-MT 1512 releases the PDU session(s) it has previously established. This step 1526 cannot be performed before the Notification 1532 from the WAB-gNB 1511. The procedure for PDU session release is described in TS 23.501. Once all PDU sessions have been released, the BH AMF 1504 may deregister the WAB-MT 1512, following a procedure described in TS 23.501.

Thus, in a case where the MT component 1512 of the mobile WAB node 1510 is in an authorized state in which the MT component 1512 of the mobile WAB node is authorized to support backhauling of traffic related to the gNB component of the mobile WAB node and the gNB component 1511 of the mobile WAB node 1510 is authorized to serve UEs, after receiving authorization status information indicating the MT component 1512 is not authorized to support backhauling of traffic related to the gNB component 1511 (step 1521), the mobile WAB node 1510 may disable admission of any new UEs to be served by the gNB component 1511 and/or initiating handover (1522) of the one or more UEs 1501 served by the mobile WAB node 1510. As discussed above, the authorization status information indicating the MT component 1512 is not authorized may be received from the AMF entity associated with the MT component 1512 (such as the BH or WAB AMF 1504) either based on the AMF 1504 detecting a change in operation conditions requiring a change in authorization status (e.g. because of mobility or at a certain time or expiry of a timer) or when the AMF 1504 checks the authorisation status in response to a request from the MT component (e.g. as part of registration procedure or mobility registration update procedure) and detects a change in operation conditions requiring a change in authorization status.

After initiating handover of the UEs 1501, on completion of handover of the UEs served by the mobile WAB node, or on expiry of a certain time period for performing handover of the UEs served by the mobile WAB node, the mobile WAB node 1510 terminates or completes handover. At least one of the following may be performed (e.g. by the gNB component 1511): sending a paging message to UEs in a non-connected RRC state (e.g. UEs in or in the vicinity of the cell(s) controlled by the gNB component 1511) so as to switch the state of the UEs to a RRC connected state; after handover is terminated or completed, initiating removal (1523) of one or more existing Xn connections with one or more other RAN nodes including a backhaul RAN node (e.g. BH RAN node 1502) to which the MT component of the mobile WAB node is connected; after handover is terminated or completed, initiating removal or suspension (1524) of one or more existing NG connections with one or more AMF entities (e.g. UE AMF 1505) managing the served UEs; after handover is terminated or completed, turning off or switching off (1525) a Uu interface at the gNB component of the mobile WAB node and/or deactivating cells controlled by the gNB component 1511. This results in the stopping of the broadcasting of information messages (e.g. MIB and/or SIBs).

In an example, after receiving authorization status information indicating the MT component 1512 is not authorized and when the gNB component is not operating to serve UEs (e.g. the operation of the gNB component 1511 to serve UEs has been shut down or terminated or the gNB component was not authorised to serve UEs), the MT component 1512 releases (1526) one or more previously established PDU sessions.

In an example, after receiving authorization status information indicating the MT component 1512 is not authorized, the MT component 1512 sends, to the gNB component 1511 (e.g. over an internal interface), a notification (e.g. notification 1531) indicating a change in authorization (e.g. change or update in authorization status) for the MT component 1512 to not authorized. After the gNB component 1511 receives the notification from the MT component 1512 and when the gNB component is not operating to serve UEs (e.g. the operation of the gNB component 1511 to serve UEs has been shut down or terminated or the gNB component was not authorised to serve UEs after the reception of the notification 1531 from the MT component 1512), the gNB component 1511 sends, to the MT component 1512, a notification (e.g. notification 1532) indicating the gNB component 1511 is not operating to serve UEs.

Figure 16 is a schematic and simplified diagram illustrating an example message flow 1600 for following the transition from “not authorized” to “authorized” at a WAB-MT component of a WAB node, in accordance with one or more embodiments of the invention. This figure shows a backhaul RAN node 1602 (or BH RAN node) like the BH-gNB 502 of figure 5, a WAB node 1610 composed of or including the gNB or RAN node or WAB-gNB unit 1611 and the MT or WAB-MT unit 1612, and the backhaul AMF 1604 of the WAB-MT 1612 (BH AMF) like the AMF 521a of figure 5, in a 5G core network (5GC) like the core network 520 of figure 5. This figure also shows a UE 1601, like the UE 561, served by the WAB-gNB 1611. The UE’s AMF 1605 is an AMF handling UEs (like the UE 1601) served by the MWAB-gNB 1611. The AMF 1605 may be in the same or different core network as the core network of BH AMF 1604. The UE’s AMF 1605 and the BH AMF 1604 may be the same AMF (e.g. AMF 521a of figure 5). In the description of figure 16 the WAB node 1610 may also be referred to as a mobile WAB node.

At the beginning of the message flow, it is assumed that the WAB-MT 1612 is not authorized to support backhauling of the traffic related to the WAB-gNB 1611. The step 1621 covers first the detection of the authorization status change of the WAB-MT 1612 to “authorized” to support backhauling of the traffic related to the WAB-gNB 1611, and then the transmission of this status to the WAB-MT 1612.

According to one embodiment, the BH AMF 1604 detects a change in the conditions of operation of the WAB node 1610 (e.g. because of mobility of the WAB-MT 1612 as described with reference to figures 10, 11, 12) and the updated authorization status is to be transmitted to the WAB- MT 1612. For example, the change may be due to a new location of the WAB node 1610 detected at RLF recovery or handover of the WAB-MT 1612. According to another example, the authorization status change happens at a predefined time or at the expiry of a timer in the BH AMF 1604. Then, the updated authorization status may be provided by the BH AMF 1604 to the WAB- MT 1612 with the procedure 830 described with reference to figure 8. Before applying the procedure 830, and in case the WAB-MT 1612 is not in RRC CONNECTED state and/or the BH AMF 1604 does not know the location of the WAB-MT 1612, a paging procedure may be applied as described in TS 24.501 section 5.6.2. Also, in case the WAB-MT 1612 was deregistered, a registration procedure may be applied as described in TS 24.501 section 5.5.1.2.

According to another embodiment, at a predefined time or at the expiry of a timer in the WAB- MT 1612, or at the detection of being located in a new geographical area (e.g. by reading the Tracking Area Code in the System Information Block broadcasted in the cell where the WAB-MT 1612 is located), the WAB-MT 1612 detects the need to check its authorization status. In case the WAB-MT 1612 is not registered, the WAB-MT 1612 may trigger a registration procedure toward the BH AMF 1604 as described in TS 24.501 section 5.5.1.2. Otherwise, the WAB-MT 1612 may trigger a mobility registration update procedure toward the BH AMF 1604 as described in TS 24.501 section 5.5.1.3. Then, the BH AMF 1604 checks the authorization status of the WAB-MT 1612 and transmits the authorization status update through, for instance, the procedure 830 described with reference to figure 8.

In the example of figure 16, it is assumed that the WAB-MT 1612 becomes authorized to support backhauling of the traffic related to the WAB-gNB 1611 (e.g. the WAB-MT 1612 determines the authorization status of the WAB-MT 1612 has changed to “authorized” to support backhauling of the traffic related to the WAB-gNB 1611, such as via step 1621 described above). Thus, after the completion of step 1621, the WAB-MT 1612 may establish PDU sessions through the BH AMF 1604. Then, the WAB-MT 1612 transmits the updated authorization status to the WAB-gNB 1611 through the internal interface and the Notification message 1631. The Notification message 1631 informs the WAB-gNB 1611, which is then able to serve UEs provided that the WAB-gNB 1611 is also authorized to serve UEs at that time.

If the WAB-gNB 1611 is authorized to serve UEs at the reception of Notification 1631, the WAB-gNB 1611 first turns on the Uu interface at step 1623, activates cell(s) and starts broadcasting Master Information Block (MIB) and System Information Block(s) (SIB(s) at the destination of UEs (e.g. to UEs in the vicinity of the WAB-gNB 1611).

At step 1624, the WAB-gNB 1611 can handle the admission of UEs and may establish (or resume) NG connection with one or several AMF(s) like the UE’s AMF 1605. The establishment of NG connection may be performed with the procedure defined in TS 38.413 section 8.7.1.

At step 1625, the WAB-gNB 1611 may establish Xn connection with other NG-RAN node(s) in the neighbourhood, including the BH RAN node 1602. The establishment of Xn connection may be performed with procedure defined in TS 38.423 section 8.4.1.

Thus, in a case where the MT component 1612 of the mobile WAB node 1610 is in a not authorized state in which the MT component 1612 is not authorized to support backhauling of traffic related to the gNB component 1611 of the mobile WAB node, after receiving authorization status information indicating the MT component of the mobile WAB node has become authorized to support backhauling of traffic related to the gNB component of the mobile WAB node (step 1621), the mobile WAB node 1610 establishes one or more PDU sessions (1622). For example, the MT component 1612 of the mobile WAB node 1610 establishes one or more PDU session through the BH or WAB AMF entity 1604 associated with the MT component 1612. As discussed above, the authorization status information indicating the MT component 1512 is not authorized may be received from the AMF entity associated with the MT component 1512 (such as the BH or WAB AMF 1504) either based on the AMF 1504 detecting a change in operation conditions requiring a change in authorization status (e.g. because of mobility or at a certain time or expiry of a timer) or when the AMF 1504 checks the authorisation status in response to a request from the MT component (e.g. as part of registration procedure or mobility registration update procedure) and detects a change in operation conditions requiring a change in authorization status.

In the case where the gNB component 1611 is authorised to serve UEs, after receiving authorization status information indicating the MT component 1612 has become authorized to support backhauling of traffic related to the gNB component 1611 and after at least one PDU session is available, the mobile WAB node 1610 broadcasts information message(s) (e.g. MIB and/or SIBs) in one or more cells activated by the gNB component. For example, the gNB component 1611 may activate one or more cells (after turning on or switching on a Uu interface if required (1623) and broadcast information message(s) in the one or more cells activated by the gNB component 1611 for UEs in or in the vicinity of the activated cells. At least one of the following may be performed (e.g. by the gNB component 1611): establishing or resuming (1624) one or more NG connections with one or more AMF entities (e.g. UE AMF 1605) associated with UEs to be served by the gNB component 1611; establishing (1625) one or more Xn connections with one or more other RAN nodes including a backhaul RAN node 1602 to which the MT component 1612 of the mobile WAB node is connected.

In an example, after establishing one or more PDU sessions, the MT component 1612 sends, to the gNB component 1611 (e.g. over an internal interface), a notification (e.g. notification 1631) indicating a change in authorization (e.g. change or update in authorization status) for the MT component 1612 to authorized. After the gNB component 1611 receives the notification from the MT component 1612, the gNB component 1611 may then broadcast information message(s) (e.g. MIB and/or SIBs) in one or more cells activated by the gNB component as discussed above.

Figure 17 is a schematic and simplified diagram illustrating an example message flow 1700 for following the transition from “authorized” to not “authorized” at a WAB-gNB component of a WAB node, in accordance with one or more embodiments of the invention. This figure shows a backhaul RAN node 1702 (or BH RAN node) like the BH-gNB 502 of figure 5, a WAB node 1710 composed of or including the gNB or RAN node or WAB-gNB unit 1711 and the MT or WAB-MT unit 1712, and the backhaul AMF 1704 of the WAB-MT 1712 (BH AMF) like the AMF 521a of figure 5, in a 5G core network (5GC) like the core network 520 of figure 5. This figure also shows a UE 1701, like the UE 561, served by the WAB-gNB 1711. The UE’s AMF 1705 is an AMF handling UEs (like the UE 1701) served by the MWAB-gNB 1711. The AMF 1705 may be in the same or different core network as the core network of BH AMF 1704. The UE’s AMF 1705 and the BH AMF 1704 may be the same AMF (e.g. AMF 521a of figure 5). Lastly, this figure shows the 0AM server 1703 controlling the WAB gNB 1711, and referred to as the WAB-gNB’s 0AM server. In the description of figure 17 the WAB node 1710 may also be referred to as a mobile WAB node.

At the beginning of the message flow, it is assumed that the WAB-gNB 1711 is authorized to serve UEs. The step 1721 covers first the detection of the authorization status change of the WAB- gNB 1711 to “not authorized” to serve UEs, and then the transmission of this status to the WAB- gNB 1711.

According to one embodiment, the 0AM server 1703 detects a change in the conditions of operation of the WAB node 1710 and the updated authorization status is to be transmitted to the WAB-gNB 1711. For example, the change may be due to a new location of the WAB node 1710 detected at RLF recovery or handover of the WAB-MT 1712. According to another example, the authorization status change happens at a predefined time or at the expiry of a timer in the 0AM server 1703. Then, the updated authorization status may be provided by the 0AM server 1703 to the WAB-gNB 1711 through a dedicated signaling. The transmission of the updated authorization status may be done only when the WAB-MT 1712 is supporting backhauling of the traffic related to the WAB-gNB 1711. The 0AM server 1703 may have to wait for this condition (i.e. when the WAB-MT 1712 is supporting backhauling of the traffic related to the WAB-gNB 1711) to transmit the updated authorization status.

According to another embodiment, at a predefined time or at the expiry of a timer in the WAB- gNB 1711, or at the detection of being located in a new geographical area (e.g. by notification from the WAB-MT 1712 reading the Tracking Area Code in the System Information Block broadcasted in the cell where the WAB-MT 1712 is located), the WAB-gNB 1711 detects the need to check its authorization status. When the WAB-MT 1712 is supporting backhauling of the traffic related to the WAB-gNB 1711, the WAB-gNB 1711 may send a message to the 0AM server 1703 to request the updated authorization status, and then to receive the response from the 0AM server 1703. In another example implementation, the WAB-gNB 1711 may not need to exchange messages with the 0AM server 1703 and may update itself its authorization status (based on time and/or location area).

After the completion of step 1721, the WAB-gNB 1711 transmits the updated authorization status to the WAB-MT 1712 through the internal interface and the Notification message 1731.

In the example of figure 17, it is assumed that the WAB-gNB 1711 is no longer authorized to serve UEs (e.g. the WAB-gNB 1711 determines the authorization status of the WAB-gNB 1711 has changed to “not authorized” to serve UEs, such as via step 1721 described above). The WAB-gNB 1711 first executes the step 1722 starting by disabling the admission of any new UE. Then, it proceeds to the handover of all served UEs, like UE 1701, (e.g. it initiates handover of all of the UEs served by the WAB-gNB 1711) toward another NG-RAN node in the vicinity. The selection of the target NG-RAN node for each UE like UE 1701 is based on the measurement reports (not represented in the figure 17) provided by each UE and identifying target cell(s) and associated target NG-RAN node(s). The procedure to handover UEs (Xn handover or NG handover) is described in TS 38.300, TS 38.413. To handle UEs that are not in RRC CONNECTED state, the WAB-gNB 1711 may page the UEs previously set in a non RRC_CONNECTED state by the WAB-gNB 1711. The paging may be limited to the cell(s) controlled by the WAB-gNB 1711. Then, the WAB-gNB 1711 may set back in RRC CONNECTED state the UEs that are still camping on a cell controlled by the WAB-gNB 1711, and that have answered to the paging message.

Depending on the location of the WAB node 1710, the handover of all UEs may not be possible. For instance, with a WAB node in an airplane flying, there may be no visible NG-RAN node for on-board UEs. Therefore, the step 1722 for UEs handover may be limited in time, for instance during 300 seconds, and this time may be configurable at the WAB-gNB 1711. For example, on completion of handover of the UEs served by the mobile WAB node, or on expiry of a certain time period for performing handover of the UEs served by the WAB-gNB 1711, the handover procedure is terminated or determined to be completed.

If the WAB-gNB 1711 was not serving any UEs at the reception of the updated authorization status, the step 1722 may be limited to the configuration of the WAB-gNB 1711 to not accept the admission of any new UE.

Once the step 1722 is completed (or terminated), the WAB-gNB 1711 may proceed to the removal of the existing Xn connect! on(s) with other NG-RAN node(s) (including the BH RAN node 1702). This step 1723 may correspond to the procedure described in TS 38.423 section 8.4.6 repeated for each existing Xn connection. The step 1723 is only necessary when an Xn connection was previously established by the WAB-gNB 1711 through the backhaul link between the WAB- MT 1712 and the BH RAN node 1702.

Also, the WAB-gNB 1711 proceeds to the removal or the suspension of existing NG connection(s) with AMF(s) that were handling the served UEs, like the UE’s AMF 1705. This step 1724 is similar to the procedure described with reference to figure 7 for NG interface setup but using NG removal request and NG removal response messages instead of messages 721 and 728. In an alternative method, the existing NG connection(s) may be suspended, to be resumed later when the WAB-gNB 1711 is able again to served UEs. The step 1724 is only necessary when at least one NG connection was previously established by the WAB-gNB 1711 through the backhaul link between the WAB-MT 1712 and the BH RAN node 1702.

Besides, at step 1725 the WAB-gNB 1711 turns off the Uu interface and thus deactivates the controlled cell(s) and stops broadcasting Master Information Block (MIB) and System Information Block(s) (SIB(s) on the Uu interface.

Internal to the WAB node 1710, a Notification message 1732 is sent by the WAB-gNB 1711 to the WAB-MT 1712 to notify the completion of shut down operation at the WAB-gNB 1711.

At step 1726, the WAB-MT 1712 may release the PDU session(s) it has previously established. This step 1726 cannot be performed before the Notification 1732 from the WAB-gNB 1711. The procedure for PDU session release is described in TS 23.501. Once all PDU sessions have been released, the BH AMF 1704 may deregister the WAB-MT 1712, following a procedure described in TS 23.501.

Thus, in a case where the gNB component 1711 of the mobile WAB node 1710 is in an authorized state in which the gNB component 1711 of the mobile WAB node 1710 is authorized to serve UEs (such as UE 1701), after receiving authorization status information indicating the gNB component 1711 is not authorized to serve UEs (step 1721), the mobile WAB node 1710 disables admission of any new UEs to be served by the gNB component 1711. As discussed above, the authorization status information indicating the gNB component 1711 is not authorized may be received from the 0AM server associated with the mobile WAB node 1710 and either based on the 0AM server detecting a change in operation conditions requiring a change in authorization status (e.g. new location of the mobile WAB node or at a certain time or expiry of a timer) or when the 0AM checks the authorisation status in response to a request from the gNB component 1711 (e.g. as part of registration procedure or mobility registration update procedure) and detects a change in operation conditions requiring a change in authorization status. Alternatively, the gNB component 1711 may determine itself that it needs to update its authorization status (e.g. due to a change in operation conditions, such as link quality, radio link quality). In this case, the gNB component 1711 does not receive authorization status information and after it determines a change in authorization status is required, the gNB component 1711 disables admission of any new UEs to be served by the gNB component 1711 and may perform one or more of other steps described for figure 17.

In an example, in the case the gNB component 1711 of the mobile WAB node 1710 is serving one or more UEs, the mobile WAB node 1710 (e.g. the gNB component 1711) initiates handover (1722) of the UEs served by the mobile WAB node. On completion of handover of the UEs served by the mobile WAB node, or on expiry of a certain time period for performing handover of the one or more UEs served by gNB component 1711, the mobile WAB node 1710 terminates or completes handover. At least one of the following may be performed (e.g. by the gNB component 1711): after handover is terminated or completed, initiating (1723) removal of one or more existing Xn connections with one or more other RAN nodes including a backhaul RAN node (e.g. BH RAN node 1702) to which the MT component 1712 of the mobile WAB node is connected; after handover is terminated or completed, initiating removal or suspension (1724) of one or more existing NG connections with one or more AMF entities (e.g. UE AMF 1705) managing the served UEs; after handover is terminated or completed, turning off or switching off (1725) a Uu interface at the gNB component 1711 of the mobile WAB node and/or deactivating cells controlled by the gNB component 1711.

In an example, after receiving authorization status information indicating the gNB component 1711 is not authorized and when the gNB component is not operating to serve UEs (e.g. the operation of the gNB component 1711 to serve UEs has been shut down or terminated or the gNB component was not authorised to serve UEs), the MT component 1712 releases (1726) one or more previously established PDU sessions.

In an example, after receiving authorization status information indicating the gNB component 1711 is not authorized to serve UEs and when the gNB component is not operating to serve UEs (e.g. the operation of the gNB component 1711 to serve UEs has been shut down or terminated (the Uu interface has been turned off and the cells deactivated), the gNB component 1711 sends, to the MT component 1712 (e.g. over an internal interface), a notification (e.g. notification 1732) indicating a change in authorization (e.g. change or update in authorization status) for the gNB component 1711 to not authorized and/or indicating the gNB component is not operating to serve UEs. After the MT component 1712 receives the notification from the gNB component 1711, the MT component 1712 releases (1726) one or more previously established PDU sessions.

Figure 18 is a schematic and simplified diagram illustrating an example message flow 1800 for following the transition from “not authorized” to “authorized” at a WAB-gNB component of a WAB node, in accordance with one or more embodiments of the invention. This figure shows a backhaul RAN node 1802 (or BH RAN node) like the BH-gNB 502 of figure 5, a WAB node 1810 composed of or including the gNB or RAN node or WAB-gNB unit 1811 and the MT or WAB-MT unit 1812, and the backhaul AMF 1804 of the WAB-MT 1812 (BH AMF) like the AMF 521a of figure 5, in a 5G core network (5GC) like the core network 520 of figure 5. This figure also shows a UE 1801, like the UE 561, served by the WAB-gNB 1811. The UE’s AMF 1805 is an AMF handling UEs (like the UE 1801) served by the MWAB-gNB 1811. The AMF 1805 may be in the same or different core network as the core network of BH AMF 1804. The UE’s AMF 1805 and the BH AMF 1804 may be the same AMF (e.g. AMF 521a of figure 5). Lastly, this figure shows the OAM server 1803 controlling the WAB gNB 1811, and referred to as the WAB-gNB’s 0AM server. In the description of figure 18 the WAB node 1810 may also be referred to as a mobile WAB node.

At the beginning of the message flow, it is assumed that the WAB-gNB 1811 is not authorized to serve UEs. The step 1821 covers first the detection of the authorization status change of the WAB- gNB 1811 to “authorized” to serve UEs, and then the transmission of this status to the WAB-gNB 1811.

According to one embodiment, the OAM server 1803 detects a change in the conditions of operation of the WAB node 1810 and the updated authorization status is to be transmitted to the WAB-gNB 1811. For example, the change may be due to a new location of the WAB node 1810 detected at RLF recovery or handover of the WAB-MT 1812. According to another example, the authorization status change happens at a predefined time or at the expiry of a timer in the OAM server 1803. Then, the updated authorization status may be provided by the OAM server 1803 to the WAB-gNB 1811 through a dedicated signaling. The transmission of the updated authorization status may be done only when the WAB-MT 1812 is supporting backhauling of the traffic related to the WAB-gNB 1811. The OAM server 1803 may have to wait for this condition to transmit the updated authorization status.

According to another embodiment, at a predefined time or at the expiry of a timer in the WAB- gNB 1811, or at the detection of being located in a new geographical area (e.g. by notification from the WAB-MT 1812 reading the Tracking Area Code in the System Information Block broadcasted in the cell where the WAB-MT 1812 is located), the WAB-gNB 1811 detects the need to check its authorization status. When the WAB-MT 1812 is supporting backhauling of the traffic related to the WAB-gNB 1811, the WAB-gNB 1811 may send a message to the OAM server 1803 to request the updated authorization status, and then to receive the response from the OAM server 1803. In another example implementation, the WAB-gNB 1811 may not need to exchange messages with the OAM server 1803 and may update itself its authorization status (based on time and/or location area).

After the completion of step 1821, the WAB-gNB 1811 transmits the updated authorization status to the WAB-MT 1812 through the internal interface and the Notification message 1831.

In the example of figure 18, it is assumed that the WAB-gNB 1811 becomes authorized to serve UEs (e.g. the WAB-gNB 1811 determines the authorization status of the WAB-gNB 1811 has changed to “authorized” to serve UEs, such as via step 1821 described above). The WAB-MT 1812 may establish PDU session(s) toward the BH AMF 1804, and then notify the WAB-gNB 1811 that at least one PDU session is available. This notification is performed with the internal message 1832. At step 1824, the WAB-gNB 1811 turns on the Uu interface, activates cell(s) and starts broadcasting Master Information Block (MIB) and System Information Block(s) (SIB(s) at the destination of UEs (e.g. to UEs in the vicinity of the WAB-gNB 1811).

At step 1825, the WAB-gNB 1811 can handle the admission of UEs and may establish (or resume) NG connection with one or several AMF(s) like the UE’s AMF 1805. The establishment of NG connection may be performed with the procedure defined in TS 38.413 section 8.7.1.

At step 1826, the WAB-gNB 1811 may establish Xn connection with other NG-RAN node(s) in the neighbourhood, including the BH RAN node 1802. The establishment of Xn connection may be performed with procedure defined in TS 38.423 section 8.4.1.

Thus, in a case where the gNB component 1811 of the mobile WAB node 1810 is in an not authorized state in which the gNB component 1811 of the mobile WAB node 1810 is not authorized to serve UEs (such as UE 1801), after receiving authorization status information indicating the gNB component 1811 is authorized to serve UEs (step 1821), the mobile WAB node 1810 establishes one or more PDU sessions (step 1822). For example, the MT component 1812 establishes one or more PDU sessions through the BH or WAB AMF entity 1804 associated with the MT component 1812. As discussed above, the authorization status information indicating the gNB component 1811 is not authorized may be received from the 0AM server associated with the mobile WAB node 1810 and either based on the 0AM server detecting a change in operation conditions requiring a change in authorization status (e.g. new location of the mobile WAB node or at a certain time or expiry of a timer) or when the 0AM checks the authorisation status in response to a request from the gNB component 1811 (e.g. as part of registration procedure or mobility registration update procedure) and detects a change in operation conditions requiring a change in authorization status. Alternatively, the gNB component 1811 may determine itself that it needs to update its authorization status (e.g. due to a change in operation conditions, such as link quality, radio link quality). In this case, the gNB component 1811 does not receive authorization status information and after it determines a change in authorization status is required, the gNB component 1811 establishes one or more PDU sessions and may perform one or more of other steps described for figure 18.

In an example, after receiving authorization status information indicating the gNB component 1811 is authorized to serve UEs (step 1821) and when at least one PDU session is available (e.g. at least one PDU session has been established), the mobile WAB node 1810 broadcasts information message(s) (e.g. MIB and/or SIBs) in one or more cells activated by the gNB component. For example, the gNB component 1811 may activate one or more cells (after turning on or switching on a Uu interface if required (1824) and broadcast information message(s) in the one or more cells activated by the gNB component 1811 for UEs in or in the vicinity of the activated cells. At least one of the following may be performed (e.g. by the gNB component 1811): establishing or resuming (1825) one or more NG connections with one or more AMF entities (e.g. UE AMF 1805) associated with UEs to be served by the gNB component 1811; establishing (1826) one or more Xn connections with one or more other RAN nodes including a backhaul RAN node 1802 to which the MT component 1812 of the mobile WAB node is connected.

In an example, after receiving authorization status information indicating the gNB component 1811 is authorized to serve UEs, the gNB component 1811 sends, to the MT component 1812 (e.g. over an internal interface), a notification (e.g. notification 1831) indicating a change in authorization (e.g. change or update in authorization status) for the gNB component 1811 to authorized. After the MT component 1812 receives the notification from the gNB component 1811 and the MT component 1812 has established one or more PDU sessions, the MT component 1812 sends a notification (e.g. notification 1832) indicating at least one PDU session is available (e.g. at least one PDU has been established and is available for the gNB component for communication). After the gNB component 1811 receives the notification 1832 from the MT component 1812, the gNB component 1811 may then broadcast information message(s) (e.g. MIB and/or SIBs) in one or more cells activated by the gNB component as discussed above.

Being able to control the authorization of the MT component of the WAB node separately to the authorization of the gNB component of the WAB node, the MT component can be authorised and can establish a connection with a BH RAN node even when the gNB component is not authorised. For instance, as the MT component may connect to a 5G core network and a PLMN that may be different from the 5G core network and PLMNs associated with the gNB component, separating the authorization status of the MWAB-MT and the MWAB-gNB would allow to double check the authorization to operate as a WAB node, involving both the MWAB-MT’ s core network and the MWAB-gNB’ s core network. This would avoid having a WAB node operating as a WAB node while it should not, because of a lack of coordination between two 5G core networks.

While the present invention has been described with reference to examples and embodiments, it is to be understood that the invention is not limited to the disclosed examples and embodiments. It will be appreciated by those skilled in the art that various changes and modification might be made without departing from the scope of the invention, as defined in the appended claims. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or steps are mutually exclusive. Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features.

In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be advantageously used.

In the preceding embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over, as one or more instructions or code, a computer-readable medium and executed by a hardware-based processing unit.

Computer-readable media may include computer-readable storage media, which corresponds to a tangible medium such as data storage media, or communication media including any medium that facilitates transfer of a computer program from one place to another, e.g., according to a communication protocol. In this manner, computer-readable media generally may correspond to (1) tangible computer-readable storage media which is non-transitory or (2) a communication medium such as a signal or carrier wave. Data storage media may be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, code and/or data structures for implementation of the techniques described in this disclosure. A computer program product may include a computer-readable medium.

By way of example, and not limitation, such computer-readable storage media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage, or other magnetic storage devices, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly termed a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave may be included in the definition of medium. It should be understood, however, that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transient media, but are instead directed to nontransient, tangible storage media. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc, where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

Claims

1. A method for use in managing authorization of a mobile wireless access backhaul, WAB, node, the mobile WAB node including a mobile termination, MT, component and a gNB component for serving one or more User Equipment, UE, the method at the mobile WAB node comprising: receiving authorization status information for indicating whether the mobile WAB node is authorized to operate as a mobile WAB node.

2. The method of claim 1, wherein the authorization status information includes at least one of: cause information for indicating a cause in a case where the mobile WAB node is not authorized to operate; information for indicating the mobile WAB node is authorized to operate as a mobile WAB node and the authorization is limited to providing local services.

3. The method of claim 1 or claim 2, wherein the authorization status information includes at least one of: gNB authorization status information for indicating whether the gNB component of the mobile WAB node is authorized to serve one or more UE;

MT authorization status information for indicating whether the MT component of the mobile WAB node is authorized to connect to one or more Public Land Mobile Networks, PLMNs or to support backhauling of traffic related to the gNB component of the mobile WAB node.

4. The method of claim 3, wherein the MT authorization status information includes at least one of: information for indicating a region in which the MT component of the mobile WAB node is authorized to connect to one or more Public Land Mobile Networks, PLMNs; time information for indicating a time period for which the MT component of the mobile WAB node is authorized to connect to one or more PLMNs;

PLMN information for indicating one or more PLMNs to which the MT component of the mobile WAB node is authorized to connect; unauthorized PLMN information for indicating one or more PLMNs to which the MT of the mobile WAB node is not authorized to connect.

5. The method of claim 3 or claim 4, wherein the gNB authorization status information includes at least one of: information for indicating a region in which the mobile WAB node is authorized to serve one or more UE; time information for indicating a time period for which the mobile WAB node is authorized to serve one or more UE;

Public Land Mobile Network information for indicating one or more PLMNs for which the mobile WAB node is authorized to serve one or more UE; unauthorized PLMN information for indicating one or more PLMNs for which the mobile WAB node is not authorized to serve one or more UE; information for indicating the authorization for the mobile WAB node to serve one or more UE is limited to local services.

6. The method of claim 4 or claim 5, wherein the PLMN information includes a list of one or more PLMNs with which the mobile WAB node is authorized to operate.

7. The method of any one of claims 4 to 6, wherein the unauthorized PLMN information includes a list of one or more PLMNs for which the mobile WAB node is not authorized to operate.

8. The method of any one of claims 1 to 7, wherein receiving the authorization status information comprises receiving, from a backhaul gNB to which the mobile WAB node is connected or is to be connected, the authorization status information.

9. The method of any one of claims 1 to 7, wherein in the case where the mobile WAB node is being served or was last served by a cell of a first backhaul gNB, receiving the authorization status information comprises receiving, from a second backhaul gNB to which the mobile WAB node is or is to be connected, the authorization status information.

10. The method of claim 8 or claim 9, wherein the authorization status information is included in at least one of: a RRC Reconfiguration message; a DL Information Transfer message.

11. The method of any one of claims 1 to 7, wherein receiving the authorization status information comprises receiving, from an entity of a core network, the authorization status information.

12. The method of claim 11, wherein the entity is an Access and Mobility management Function, AMF, of the core network.

13. The method of claim 12, wherein the authorization status information is included in at least one of: a NG AMF Configuration Update message; a Downlink NAS Transport message.

14. The method of any one of the claims 1 to 7, further comprising: sending a request including information for indicating the request is associated with a mobile WAB node; after sending the request, receiving a response including the authorization status information.

15. The method of claim 14, wherein sending a request comprises sending, to a backhaul gNB to which the mobile WAB node is or is to be connected, a request, wherein receiving a response comprises receiving, from the backhaul gNB, a response including the authorization status information.

16. The method of claim 15, wherein the request is included in a RRC Setup Complete message, and the response is included in a RRC Reconfiguration message including the authorization status information in a case where the mobile WAB node is authorized or in a DL Information Transfer message in a case where the mobile WAB node is not authorized.

17. The method of claim 14, wherein sending a request comprises sending, to an AMF entity of a core network, a request, wherein receiving a response comprises receiving, from the AMF entity of the core network, a response including the authorization status information.

18. The method of claim 17, wherein the request is included in a NG Setup request message, and the response is included in a NG Setup response message including the authorization status information in a case where the mobile WAB node is authorized or in a NG Setup Failure message in a case where the mobile WAB node is not authorized.

19. The method of any one of claims 14 to 18, wherein the request further includes at least one of: information for identifying an AMF to which the mobile WAB node is connected; information for indicating a location of the mobile WAB node; information for indicating the mobile WAB node supports local services; information indicating the expected trajectory of the mobile WAB node; information for identifying the MT component of the mobile WAB node; information identifying one or more Public Land Mobile Networks, PLMNs, in which the mobile WAB node may operate.

20. The method of any one of claims 1 to 7, wherein in a case where the mobile WAB node is in an authorized state in which the mobile WAB node is authorized to operate as a mobile WAB node, the method further comprising: after receiving authorization status information indicating the mobile WAB node is not authorized to operate as a mobile WAB node, changing the state of the mobile WAB node to an unauthorized state.

21. The method of claim 20, further comprising after receiving authorization status information indicating the mobile WAB node is not authorized to operate as a mobile WAB node, initiating handover of the UEs served by the mobile WAB node.

22. The method of claim 21, further comprising on expiry of a certain time period for performing handover of the UEs served by the mobile WAB node, terminating handover.

23. The method of any one of claims 1 to 19, wherein in a case where the MT component of the mobile WAB node is in an authorized state in which the MT component of the mobile WAB node is authorized to support backhauling of traffic related to the gNB component of the mobile WAB node and the gNB component of the mobile WAB node is authorized to serve UEs, the method at the mobile WAB node comprises: after receiving authorization status information indicating the MT component of the mobile WAB node is not authorized to support backhauling of traffic related to the gNB component of the mobile WAB node, disabling admission of any new UEs to be served by the gNB component and/or initiating handover of the UEs served by the mobile WAB node.

24. The method of claim 23, further comprising after initiating handover of the UEs, on completion of handover of the UEs served by the mobile WAB node, or on expiry of a certain time period for performing handover of the UEs served by the mobile WAB node, terminating or completing handover.

25. The method of claim 23 or claim 24, further comprising at least one of: sending a paging message to UEs in a non-connected RRC state for switching the state of the UEs to a RRC connected state; after handover is terminated or completed, initiating removal of one or more existing Xn connections with one or more other RAN nodes including a backhaul RAN node to which the MT component of the mobile WAB node is connected; after handover is terminated or completed, initiating removal or suspension of one or more existing NG connections with one or more AMF entities managing the served UEs; after handover is terminated or completed, turning off a Uu interface at the gNB component of the mobile WAB node.

26. The method of any one of claims 23 to 25, further comprising: after receiving authorization status information indicating the MT component of the mobile WAB node is not authorized to support backhauling of traffic related to the gNB component of the mobile WAB node and when the gNB component is not operating to serve UEs, releasing, by the MT component, one or more previously established PDU sessions.

27. The method of any one of claims 23 to 26, after receiving authorization status information indicating the MT component of the mobile WAB node is not authorized to support backhauling of traffic related to the gNB component of the mobile WAB node, sending, by the MT component of the mobile WAB node to the gNB component of the mobile WAB node, a notification indicating a change in authorization for the MT component to not authorized.

28. The method of claim 27, wherein, after receiving the notification indicating the change in authorization for the MT component to not authorized and when the gNB component is not operating to serve UEs, sending, by the gNB component to the MT component, a notification indicating the gNB component is not operating to serve UEs.

29. The method of any one of claims 1 to 19, wherein in a case where the MT component of the mobile WAB node is in a not authorized state in which the MT component of the mobile WAB node is not authorized to support backhauling of traffic related to the gNB component of the mobile WAB node, the method at the mobile WAB node comprises: after receiving authorization status information indicating the MT component of the mobile WAB node has become authorized to support backhauling of traffic related to the gNB component of the mobile WAB node, establishing one or more PDU sessions.

30. The method of claim 29, wherein in the case where the gNB component is authorised to serve UEs, the method further comprises: after receiving authorization status information indicating the MT component of the mobile WAB node has become authorized to support backhauling of traffic related to the gNB component of the mobile WAB node and after at least one PDU session is available, broadcasting information messages in one or more cells activated by the gNB component.

31. The method of claim 29 or claim 30, further comprising at least one of: establishing or resuming one or more NG connections with one or more AMF entities associated with UEs to be served by the gNB component; establishing one or more Xn connections with one or more other RAN nodes including a backhaul RAN node to which the MT component of the mobile WAB node is connected.

32. The method of any one of claims 29 to 31, wherein after establishing one or more PDU sessions, sending, by the MT component of the mobile WAB node to the gNB component of the mobile WAB node, a notification indicating a change in authorization for the MT component to authorized.

33. The method of claim 32, wherein after receiving the notification from the MT component, broadcasting, by the gNB component, information messages in one or more cells activated by the gNB component.

34. The method of any one of claims 1 to 19, wherein in a case where the gNB component of the mobile WAB node is in an authorized state in which the gNB component of the mobile WAB node is authorized to serve UEs, the method at the mobile WAB node comprises: after receiving authorization status information indicating the gNB component of the mobile WAB node is not authorized to serve UEs, disabling admission of any new UEs to be served by the gNB component.

35. The method of claim 34, wherein in the case the gNB component of the mobile WAB node is serving UEs, the method further comprises: initiating handover of the UEs served by the mobile WAB node.

36. The method of claim 35, further comprising after initiating handover of the UEs, on completion of handover of the UEs served by the mobile WAB node, or on expiry of a certain time period for performing handover of the UEs served by the mobile WAB node, terminating or completing handover.

37. The method of claim 35 or claim 36, further comprising at least one of: sending a paging message to UEs in a non-connected RRC state for switching the state of the UEs to a RRC connected state; after handover is terminated or completed, initiating removal of one or more existing Xn connections with one or more other RAN nodes including a backhaul RAN node to which the MT component of the mobile WAB node is connected; after handover is terminated or completed, initiating removal or suspension of one or more existing NG connections with one or more AMF entities managing the served UEs; after handover is terminated or completed, turning off a Uu interface at the gNB component of the mobile WAB node.

38. The method of any one of claims 34 to 37, further comprising: after receiving authorization status information indicating the gNB component of the mobile WAB node is not authorized to serve UEs and when the gNB component is not operating to serve UEs, releasing, by the MT component of the mobile WAB node, one or more previously established PDU sessions.

39. The method of any one of claims 34 to 38, further comprising: after receiving authorization status information indicating the gNB component of the mobile WAB node is not authorized to serve UEs and when the gNB component is not operating to serve UEs, sending, by the gNB component of the mobile WAB node to the MT component of the mobile WAB node, a notification indicating the gNB component is not operating to serve UEs.

40. The method of claim 39, further comprising: after receiving the notification indicating the gNB component is not operating to serve UEs, releasing, by the MT component, one or more previously established PDU sessions.

41. The method of any one of claims 1 to 19, wherein in a case where the gNB component of the mobile WAB node is in a not authorized state in which the gNB component of the mobile WAB node is not authorized to serve UEs, the method at the mobile WAB node comprises: after receiving authorization status information indicating the gNB component of the mobile WAB node has become authorized to serve UEs, establishing one or more PDU sessions.

42. The method of claim 41, wherein in the case where the gNB component is authorised to serve UEs, the method further comprises: after receiving authorization status information indicating the gNB component of the mobile WAB node has become authorized to serve UEs and when at least one PDU session is available, broadcasting information messages in one or more cells activated by the gNB component.

43. The method of claim 41 or claim 42, further comprising at least one of: establishing or resuming one or more NG connections with one or more AMF entities associated with UEs to be served by the gNB component; establishing one or more Xn connections with one or more other RAN nodes including a backhaul gNB to which the MT component of the mobile WAB node is connected.

44. The method of any one of claims 41 to 43, further comprising after receiving authorization status information indicating the gNB component of the mobile WAB node has become authorized to serve UEs, sending, by the gNB component of the mobile WAB node to the MT component of the mobile WAB node, a notification indicating a change in authorization for the gNB component to authorized.

45. The method of claim 44, after receiving the notification and after establishing one or more PDU sessions, sending, by the MT component of the mobile WAB node to the gNB component of the mobile WAB node, a notification indicating at least one PDU session is available.

46. The method of any one of claims 1 to 7, wherein in a case where the mobile WAB node is in an unauthorized state in which the mobile WAB node is not authorized to operate as a mobile WAB node, the method further comprising: after receiving authorization status information indicating the mobile WAB node is authorized to operate as a mobile WAB node, switching from the unauthorized state to an authorized state in which the mobile WAB node is authorized to operate as a mobile WAB node.

47. The method of any one of claims 1 to 7, wherein in a case where the mobile WAB node is in an authorized state in which the mobile WAB node is authorized to operate as a mobile WAB node, the method further comprising: after receiving authorization status information including updated authorization status information, changing or not changing, based on the received updated authorization status information, one of the authorized state of the mobile WAB node and how the mobile WAB node operates.

48. A method for use in managing authorization of a mobile wireless access backhaul, WAB, node, the mobile WAB node including a mobile termination, MT, component and a gNB component for serving one or more User Equipment, UE, the method at an Access and Mobility management Function, AMF, entity comprising: sending authorization status information for indicating whether the mobile WAB node is authorized to operate as a mobile WAB node.

49. The method of 48, further comprising: determining the authorization status for operation of the mobile WAB node as a mobile WAB node, wherein the authorization status information sent to the mobile WAB node is based on the determining.

50. The method of claim 48 or claim 49, further comprising: receiving a request including information for indicating the request is associated with a mobile WAB node; wherein sending includes sending a response to the request including the authorization status information.

51. The method of claim 50, wherein receiving a request comprises receiving, from the mobile WAB node, a connection setup request, wherein sending a response comprises sending, to the mobile WAB node, a response including the authorization status information.

52. The method of claim 51, wherein the request is included in a NG Setup request message, and the response is included in a NG Setup response message including the authorization status information in a case where the mobile WAB node is authorized or in a NG Setup Failure message in a case where the mobile WAB node is not authorized.

53. The method of claim 50, wherein receiving a request comprises receiving, from a backhaul gNB connected to or to be connected to the mobile WAB node, a request, wherein sending a response comprises sending, to the backhaul gNB connected to or to be connected to the mobile WAB node, a response including the authorization status information.

54. The method of claim 53, wherein the request is one of a handover request associated with the mobile WAB node or a path switch request associated with the mobile WAB node.

55. The method of any one of claims 50 to 54, wherein the request further includes at least one of: information for identifying an AMF to which the mobile WAB node is connected; information for indicating a location of the mobile WAB node; information for indicating the mobile WAB node supports local services; information indicating the expected trajectory of the mobile WAB node; information for identifying the MT component of the mobile WAB node; information identifying one or more Public Land Mobile Networks, PLMNs, in which the mobile WAB node may operate.

56. The method of any one of claims 48 to 55, wherein the authorization status information includes at least one of: cause information for indicating a cause in a case where the mobile WAB node is not authorized to operate; information for indicating the mobile WAB node is authorized to operate as a mobile WAB node and the authorization is limited to providing local services.

57. The method of any one of claims 48 to 56, wherein the authorization status information includes at least one of: gNB authorization status information for indicating whether the gNB component of the mobile WAB node is authorized to serve one or more UE;

58. The method of claim 57, wherein the MT authorization status information includes at least one of: information for indicating a region in which the MT component of the mobile WAB node is authorized to connect to one or more Public Land Mobile Networks, PLMNs; time information for indicating a time period for which the MT component of the mobile WAB node is authorized to connect to one or more PLMNs;

59. The method of claim 57 or claim 58, wherein the gNB authorization status information includes at least one of: information for indicating a region in which the mobile WAB node is authorized to serve one or more UE; time information for indicating a time period for which the mobile WAB node is authorized to serve one or more UE;

60. The method of claim 58 or claim 59, wherein the PLMN information includes a list of one or more PLMNs with which the mobile WAB node is authorized to operate.

61. The method of any one of claims 48 to 55, further comprising sending updated authorization status information after determining a change in conditions of operation of the mobile WAB node.

62. A method for use in managing authorization of a mobile wireless access backhaul, WAB, node, the mobile WAB node including a mobile termination, MT, component and a gNB component for serving one or more User Equipment, UE, the method at the mobile WAB node comprising: sending, to an Access and Mobility management function, AMF, entity of a core network, a setup request including information for indicating the mobile WAB node intends to operate as a mobile WAB node and information for indicating a location of the mobile WAB node; receiving, from the AMF entity, a response including authorization status information for indicating whether the mobile WAB node is authorized to operate as a mobile WAB node.

63. The method of claim 62, wherein the setup request further includes at least one of: information for identifying an AMF to which the MT component of the mobile WAB node is connected; information for indicating the mobile WAB node supports local services.

64. A method for use in managing authorization of a wireless access backhaul, WAB, node, the WAB node including a mobile termination, MT, component and a gNB component for serving one or more User Equipment, UE, wherein in a case where the gNB component of the WAB node is in an authorized state in which the gNB component of the WAB node is authorized to serve UEs, the method at the WAB node comprises: receiving information indicating the gNB component of the WAB node is not authorized to serve UEs; after receiving the information, initiating handover of the UEs served by the gNB component of the WAB node.

65. The method of claim 64, further comprising at least one of: after handover is terminated or completed, initiating removal of one or more existing Xn connections with one or more other RAN nodes including a backhaul RAN node to which the MT component of the WAB node is connected; after handover is terminated or completed, initiating removal or suspension of one or more existing NG connections with one or more AMF entities managing the served UEs; after handover is terminated or completed, turning off a Uu interface at the gNB component of the WAB node.

66. The method of claim 64, further comprising: after termination or completion of operations related to handover and removal of Xn and NG connections, releasing PDU sessions of the MT component of the WAB node.

67. The method of claim 64, further comprising: maintaining the PDU sessions of the MT component of the WAB node until termination or completion of operations related to the handover of UEs served by the WAB node, and related to the removal of Xn and NG connections of the WAB node.

68. The method of any one of claims claim 64 to 67, further comprising on expiry of a certain time period for performing handover of the UEs served by the WAB node, terminating handover.

69. A method for use in managing authorization of a mobile wireless access backhaul, WAB, node, the mobile WAB node including a mobile termination, MT, component and a gNB component for serving one or more User Equipment, UE, wherein in a case where the mobile WAB node is in an authorized state in which the mobile WAB node is authorized to operate as a mobile WAB node, the method at the mobile WAB node comprises: receiving authorization status information indicating the mobile WAB node is not authorized to operate as a mobile WAB node; after receiving authorization status information indicating the mobile WAB node is not authorized to operate as a mobile WAB node, initiating handover of the UEs served by the mobile WAB node; on completion of handover of the UEs served by the mobile WAB node, or on expiry of a certain time period for performing a handover procedure for the UEs served by the mobile WAB node, terminating the handover procedure.

70. The method of claim 69, further comprising sending, after terminating the handover procedure, a reset message.

71. A computer program comprising instructions which, when the program is executed by at least one processor unit, cause the at least one processing unit to carry out the method according to any one of claims 1 to 70.

72. A computer-readable medium carrying a computer program according to claim 71.

73. An apparatus for a Wireless Access Backhaul, WAB, node, the apparatus comprising: one or more processing units configured to perform the method as recited in any one of claims 1 to 47, claims 62 to 70.

74. An apparatus for an Access and Mobility management Function, AMF, entity, the apparatus comprising: one or more processing units configured to perform the method as recited in any one of claims

48 to 61.