WO2021256985A1

WO2021256985A1 - Proactive radio access network configuration update

Info

Publication number: WO2021256985A1
Application number: PCT/SE2021/050611
Authority: WO
Inventors: Luca LUNARDI; Marco BELLESCHI; Pablo SOLDATI; Angelo Centonza
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2020-06-19
Filing date: 2021-06-21
Publication date: 2021-12-23

Abstract

A method, in a first node of a radio access network, RAN, comprises sending (510), to a second node of the RAN, configuration information indicating an activation status of each of one or more features of the first node of the RAN and/or of a third node of the RAN, the activation status indicating whether or not the corresponding feature is in use or activated by the corresponding node. In some embodiments, the method may further comprise receiving (530), from the second node, second configuration information, the second configuration information indicating an activation status of each of one or more features of the second node or a fourth node of the RAN.

Description

PROACTIVE RADIO ACCESS NETWORK CONFIGURATION UPDATE

TECHNICAL FIELD

This document is generally related to wireless communications networks and is more particularly related to the exchange and updating of configuration information among radio access network nodes in such a network.

BACKGROUND

The current architecture for the 5G radio access network (RAN), commonly referred to as the Next Generation (NG) RAN, or NG-RAN, as developed by members of the 3^rd-Generation Partnership Project, is described in 3GPP TS 38.401vl5.4.0

(www.3gpp.org/ftp//Specs/archive/38_series/38.401/38401-f40.zip). A simplified illustration of this architecture is provided in Figure 1.

The NG architecture can be further described as follows. The NG-RAN consists of a set of gNBs (base stations) 190, connected to the 5G core network (5GC) 190 through the NG interface 102. A gNB 100 can support frequency-division duplexing (FDD) mode, time-division duplexing (TDD) mode or dual mode operation. gNBs 100 can be interconnected through the Xn interface 140. A gNB 100 may consist of a gNB central unit (gNB-CU) 110 and gNB distributed units (gNB-DUs) 120. A gNB-CU 110 and a gNB- DU 120 are connected via the FI logical interface 122. Generally, a gNB-DU 120 is connected to only one gNB-CU 110, while one gNB-CU 110 may be connected to several gNB-DUs 120. For resiliency, a gNB-DU 120may be connected to multiple gNB-CUs 110 by appropriate implementation. NG, Xn and FI are logical interfaces.

The NG-RAN 180 is layered into a Radio Network Layer (RNL) and a Transport Network Layer (TNL). The NG-RAN architecture, i.e., the NG-RAN logical nodes and interfaces between them, is defined as part of the RNL. For each NG-RAN interface (NG, Xn, FI), the related TNL protocol and the functionality are specified. The TNL provides services for user plane transport and signaling transport.

A gNB 100 may also be connected to an LTE eNB via the X2 interface. Another architectural option is that an LTE eNB connected to the Evolved Packet Core network may be connected with a so- called nr-gNB, over the X2 interface. An nr-gNB is a gNB supporting 5G radio access technology, commonly referred to as "NR," but not connected directly to a core network and connected via X2 to an eNB for the sole purpose of performing dual connectivity.

The architecture illustrated in Figure 1 can be expanded by splitting the gNB-CU 110 into two entities: one for the user plane (gNB-CU-UP), which serves the user plane and hosts the Packet Data Convergence Protocol (PDCP), and one for the control plane (gNB-CU-CP), which serves the control plane and hosts the PDCP and Radio Resource Control (RRC) protocol. For completeness, it should be said that a gNB-DU 120 hosts the Radio Link Control (RLC), Medium Access Control (MACH), and physical layer (PHY) protocols.

XnAP and X2AP procedures are defined in 3GPP specifications so that a RAN node can provide another RAN with node, cell and cell relation configuration data. Relevant procedures are:

X2AP Setup: o the definition of the "X2 SETUP REQUEST" and "X2 SETUP RESPONSE" messages include:

^■ configuration data for E-UTRA cells served by the eNB sending the message ("Served Cell Information" IE)

^■ configuration data for E-UTRA neighbour cells of the E-UTRA cells served by the eNB sending the message ("Neighbour Information" IE)

^■ configuration data for NR neighbour cells of the E-UTRA cells served by the eNB sending the message ("NR Neighbour Information" IE)

X2AP ENB Configuration Update: o the definition of the "ENB CONFIGURATION UPDATE" message includes:

^■ configuration data for additional cells served by the eNB sending the message and/or updated configuration data for cells served by the eNB sending the message:

• for E-UTRA cells ("Served Cell Information" IE)

• for E-UTRA neighbour cells of the E-UTRA cells served by the eNB sending the message ("Neighbour Information" IE)

• for NR neighbour cells of the E-UTRA cells served by the eNB sending the message ("NR Neighbour Information" IE)

^■ "Coverage Modification List" for a list of E-UTRA cells with modified coverage, including an index "Cell Coverage State" to indicate the coverage configuration of the concerned cell, and optionally a "Replacing Cells" IE to identify the cells that may replace a serving cell.

- X2AP EN-DC X2 Setup: o the definition of the "EN-DC X2 SETUP REQUEST" and "EN-DC X2 SETUP RESPONSE" messages include: ^■ for an eNB:

• configuration data for E-UTRA cells served by the eNB sending the message ("Served E-UTRA Cell Information" IE within "List of Served E- UTRA Cells" IE)

• configuration data for NR neighbour cells of the E-UTRA cells served by the eNB sending the message ("NR Neighbour Information" IE within "List of Served E-UTRA Cells" IE)

• "Cell and Capacity Assistance Information" to request information about NR or E-UTRA cells

^■ for an en-gNB:

• configuration data for NR cells served by the en-gNB sending the message ("Served NR Cell Information" IE within "List of Served NR Cells" IE)

• configuration data for NR neighbour of the NR cells served by the en- gNB sending the message ("NR Neighbour Information" IE within "List of Served NR Cells" IE)

X2AP EN-DC Configuration Update: o the definition of the "EN-DC CONFIGURATION UPDATE" message includes:

^■ for an eNB:

• "Cell Assistance Information" to request information about NR cells

• configuration data for additional or modified E-UTRA cells served by the eNB sending the message ("Served E-UTRA Cell Information" IE respectively within "Served E-UTRA Cells To Add" and "Served E-UTRA Cells To Modify" lEs)

• configuration data for additional or modified NR neighbour cells of E- UTRA cells ("NR Neighbour Information" IE respectively within "Served E-UTRA Cells To Add" and "Served E-UTRA Cells To Modify" lEs)

^■ for an en-gNB:

• configuration data for additional or modified NR cells served by the en-gNB ("Served NR Cell Information" IE respectively within "Served NR Cells To Add" and "Served NR Cells To Modify" IE) • configuration data for additional or modified NR neighbour cells of NR cells served by the en-gNB ("NR Neighbour Information" IE respectively within "Served NR Cells To Add" and "Served NR Cells To Modify" IE)

• "NR Deactivation Indication" for NR cells switched off for energy saving o the definition of the "EN-DC CONFIGURATION UPDATE ACKNOWLEDGE" message includes:

^■ for an en-gNB:

• configuration data for NR neighbour cells of NR cells served by the en- gNB ("NR Neighbour Information" IE within "List of Served NR Cells"

IE)

- XnAP Setup: o the definition of the "XN SETUP REQUEST" and the "XN SETUP RESPONSE" messages include:

^■ configuration data for NR cells served by the gNB sending the message ("Served Cell Information NR" IE within "List of Served Cells NR" IE)

^■ configuration data for NR neighbour of the NR cells served by the gNB sending the message ("Neighbour Information NR" IE within "List of Served Cells NR" IE)

^■ configuration data for E-UTRA neighbour of the NR cells served by the gNB sending the message ("Neighbour Information E-UTRA" IE within "List of Served Cells NR" IE)

^■ configuration data for E-UTRA cells served by the ng-eNB sending the message ("Served Cell Information E-UTRA" IE within "List of Served Cells E-UTRA" IE)

^■ configuration data for NR neighbour of the E-UTRA cells served by the ng-eNB sending the message ("Neighbour Information NR" IE within "List of Served Cells E-UTRA" IE) ^■ configuration data for E-UTRA neighbour of the E-UTRA cells served by the ng- eNB sending the message ("Neighbour Information E-UTRA" IE within "List of Served Cells E-UTRA" IE)

^■ NR cell related assistance information ("Cell and Capacity Assistance Information NR" IE)

^■ E-UTRA cell related assistance information ("Cell and Capacity Assistance Information E-UTRA" IE)

XnAP NG-RAN node Configuration Update: o the definition of the "NG-RAN NODE CONFIGURATION UPDATE" message includes:

^■ for an gNB:

• updated configuration data for NR cells served by the node sending the message ("Served Cells To Update NR" IE)

• "Cell Assistance Information NR"

^■ for a ng-eNB:

• updated configuration data for E-UTRA cells served by the node sending the message ("Served Cells to Update E-UTRA" IE)

• "Cell Assistance Information NR" o the definition of the "NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE" message includes:

^■ for an gNB:

• configuration data for NR cells served by the node sending the message ("Served Cell Information NR" IE within "Served NR Cells" IE)

• configuration data for NR neighbour of the NR cells served by the node sending the message ("Neighbour Information NR" IE within "Served NR Cells" IE)

• configuration data for E-UTRA neighbour of the NR cells served by the node sending the message ("Neighbour Information E-UTRA" IE within "Served NR Cells" IE).

SUMMARY

Problems with existing solutions related to the exchange of data configuration include the following. First, there is a lack of support for some capabilities or features, resulting in sub-optimal RAN performance and end user experience. Second, there is a lack of proper means for proactive inter-node management, coordination and optimization of various important aspects for efficient operation of the network.

Solutions detailed below introduce methods to enable a proactive approach to steer RAN configuration concerning coverage, capacity and service capabilities at node, cell, or cell relation level.

Embodiments of the techniques disclosed herein include a method, in a first node of a radio access network, RAN, the method comprising sending, to a second node of the RAN, configuration information indicating an activation status of each of one or more features of the first node of the RAN and/or of a third node of the RAN, the activation status indicating whether or not the corresponding feature is in use or activated by the corresponding node.

Other embodiments include a method, in a second node of a RAN, method, in a second node of a radio access network, RAN, the method comprising receiving, from a first node of the RAN, configuration information indicating an activation status of each of one or more features of the first node of the RAN and/or of a third node of the RAN, the activation status indicating whether or not the corresponding feature is in use or activated by the corresponding node.

Other embodiments include base station apparatuses configured to carry out one or more of these methods or the other methods described herein.

Using the techniques and apparatuses described herein, neighbor nodes can mutually and dynamically influence the activation and deactivation of RAN node capabilities impacting coverage, capacity, supported services and associated resources. The detailed solutions provide the possibility to proactively update a RAN node configuration allowing to enable or disable a set of features available at a RAN node and/or at its neighbors, aiming to optimize network coverage, network capacity, network service capability and ultimately end user performance.

BRIEF DESCRIPTION OF THE FIGURES

Figure 1 illustrates the 5G-RAN architecture.

Figure 2 illustrates an example RAN node configuration.

Figure 3 illustrates details of an example application of the techniques described herein.

Figures 4A and 4B illustrate details of a second example application of the techniques described herein.

Figure 5 is a process flow diagram illustrating an example method according to some of the disclosed techniques. Figure 6 is a process flow diagram illustrating another example method according to some of the disclosed techniques.

Figure 7 illustrates an example base station according to some embodiments.

DETAILED DESCRIPTION

Exemplary embodiments of the present disclosure will now be described more fully hereinafter with reference to the accompanying drawings, in which examples of embodiments of inventive concepts are shown. Inventive concepts may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of present inventive concepts to those skilled in the art. It should also be noted that these embodiments are not mutually exclusive. Components from one embodiment can be tacitly assumed to be present/used in another embodiment. Any two or more embodiments described in this document may be combined with each other.

As noted above, the solutions described herein introduce methods to enable a proactive approach to steer RAN configuration concerning coverage, capacity and service capabilities at node, cell, or cell relation level. In various embodiments of these solutions, several or all of the following are considered:

-four (or more) RAN nodes, where a RAN node can be any of gNB, eNB, en-gNB, ng-eNB -any two RAN nodes are neighbors, i.e., a signaling connection exists between them, over XnAP or X2AP, in both directions -the first RAN node and the second RAN node are neighbors

-the third RAN node is a neighbor of the first RAN node and optionally a neighbor of the second RAN node

-the fourth RAN node is a neighbor of the second RAN node and optionally a neighbor of the first RAN node.

-coverage/capacity/service capabilities of a RAN node. Examples of such capabilities include (but are not limited to):

• availability and configuration for unlicensed spectrum

• availability and configuration of Transmission Points

• BWP configurations

• MIMO configurations • SSB configurations

• S-NSSAI configurations

• QoS attributes (e.g., min/max GBR in UL/DL, pre-emption capabilities and vulnerabilities)

• QoE attributes (e.g., policies O&M, non-real time Radio Intelligent Controller (non-real time RIC), near real-time Radio Intelligent Controller (near real-time RIC)

-traffic characteristics for a RAN node may include but has not to be limited to the type of traffic supported or served, traffic management configuration (e.g., a specific carrier may be reserved for public safety or for a Non Public Network), QoS aspects, QoE aspects, slicing aspects. Traffic performances for a RAN node include aspects such as accessibility, retainability, integrity, availability, to mobility between such RAN node and another RAN node, at node, cell and cell relation level congestion level for a RAN node.

A generic configuration to serve as a basis for discussing the presently disclosed techniques is depicted in Figure 2, where, for simplicity, two "capabilities" are shown for each RAN node. In this example, one of these capabilities is activated (ON), and the other is deactivated (OFF). It will be appreciated, of course, that the techniques described herein may be extended to any number of RAN nodes and any number of capabilities. Note that in the discussion that follows, the term "first RAN node" or "RAN node 1" may apply to any node (such as a base station, e.g., a gNB) in the system, while "second RAN node" or "RAN node 2" may be understood as referring to any RAN node that neighbors the first RAN node, in that the first RAN node may communicate directly with the second RAN node. The term "third RAN node" or "RAN node 3" may be used to refer to another node that also neighbors the first RAN node, in the sense that the first RAN node can communicate directly with the third RAN node. However, as shown in the figure, the third RAN node may not neighbor the second RAN node. Likewise, the "fourth RAN node" or "RAN node 4" neighbors the second RAN node but might not neighbor the first RAN node (or the third RAN node).

Various embodiments described herein include some or all of the following steps:

1) Exchange of configuration data

2) Exchange of traffic and performance data

3) Estimation of changes in configuration data

4) Suggestion of configuration data 5) Confirmation of changes in configuration data

Each of these steps is described below.

1) Exchange of configuration data

In various embodiments, the first RAN node sends, to the second RAN node, configuration information or updates in configuration concerning the activation/deactivation status of coverage/capacity/service capabilities in the first RAN node. Correspondingly, in various embodiments, the first RAN node may receive, from the second RAN node, configuration or updates in configuration concerning the activation/deactivation status of coverage/capacity/service capabilities in the second RAN node.

In some embodiments or instances, the first RAN node may send, to the second RAN node, configuration information or updates in configuration concerning the activation/deactivation status of coverage/capacity/service capabilities in the third RAN node. This may be instead of in addition to corresponding information sent regarding coverage/capacity/service capabilities in the first RAN node. As one variant of this technique, as disused in further detail below, the transfer of the information related to the third RAN node from the first RAN node to the second RAN node may be allowed only if the third RAN node has provided the first RAN node with an authorization indication indicating that the information can be provided to the third RAN node.

Similarly, in some embodiments, the first RAN node may receive, from the second RAN node, configuration information or updates in configuration information concerning the activation/deactivation status of coverage/capacity/service capabilities in the fourth RAN node.

The configuration information or updates in configuration information described above and in the remainder of this document includes activation status information indicating whether each of one or more features applicable to the respective node are activated. These features, which may be understood as "capabilities," may relate to any of a wide variety of coverage-related features, capacity-related features, or service-related features of the node or cell provided by the node; these features may be collectively referred to as coverage/capacity/service capabilities, or, more simply, as "capabilities."

A non-exhaustive list of capability information that may be included in the configuration information exchanged between RAN nodes is provided below:

• the characteristics of available unlicensed spectrum (e.g., the operating unlicensed band) and its current activation status (e.g., if it is in use or not) • a range of supported Transmission Point, along with their current activation

• a range of supported BWP, along with the ones currently selected

• a range of supported MIMO configurations, along with the ones currently preferred

• a range of supported SSB configurations, along with the one currently selected

• a range of supported S-NSSAI, along with the ones currently in use

• a range of supported QoS attributes (e.g., min/max GBR in UL/DL, pre-emption capabilities and vulnerabilities), along with the ones currently in use

• A range of supported radio resource management policies per cell such as o radio resource partitioning between different PLMNs, where each PLMN may be associated to an operator sharing the RAN node with other operators and/or o Radio resource partitioning between different network slices, namely how resources are partitioned between UEs that connect to different network slices (In this context a network slice may be identified by an S-NSSAI or a PLMN ID or a Subscriber Profile ID for RAT/Frequency priority index or by an Additional RRM Policy Index or by any other identifier able to identify a network slice portion in the RAN node) and/or o Radio resource partitioning between different types of traffic, for example resources dedicated to GBR traffic and resources dedicated to non GBR traffic o Hardware resource characteristics, for example the maximum amount of processing power available to the RAN node

• The list of features supported per cell by the RAN node, also indicated as FeatureSet in 3GPP TS 38.331, vl6.0.0 (March 2020). The FeatureSet is a set of indexes that define available features for a number of configurations, for example the FeatureSet indicates features available per Radio Access Technology (RAT) - e.g., E-UTRAN, NR, or the features available per Ul and DL. As an example, features that could be indicated via the feature set are cross carrier scheduling and the capability of receiving signals on both normal and supplementary UL carriers.

• In one extension of the feature set indication above, the feature set per band combination could be exchanged. That is the set of features per cell that would be available for a UE given a certain band combination selection for the same UE. 2) Exchange of traffic and performance data

In various embodiments, the first RAN node sends, to the second RAN node, traffic characteristics and performances of the first RAN node at the node, cell, or cell relation level. This information may be referred to generally as "traffic information." An authorization indication indicating that the second RAN node may provide this traffic information for the first RAN node to one or more other RAN nodes may be also provided, either with the information or separately.

In some embodiments and/or instances, the first RAN node may receive, from the second RAN node, traffic characteristics and performances of the second RAN node at the node, cell, or cell relation level. In some embodiments or instances, the first RAN node may send, to the second RAN node, traffic characteristics and performances of the third RAN node at the node, cell, or cell relation level, in some cases contingent upon receiving or having received an authorization indication indicating that the information can be provided to the third RAN node. Likewise, in some embodiments or instances, the first RAN node may receive, from the second RAN node, traffic characteristics and performances of the fourth RAN node at the node, cell, or cell relation level.

A non-exhaustive list of traffic and performance data that might be exchanged between RAN nodes is provided below (information available in existing solution may also be used): o Traffic characteristics data:

^■ type of traffic served (MBB, URLLC, NB-loT)

^■ traffic management configuration (e.g., certain services are segregated or prioritized in certain carrier, certain carriers are reserved to certain users, e.g., public safety or Non-Public Network)

^■ QoS attributes

^■ QoE attributes o Performance: accessibility, retainability, integrity, availability, mobility between a RAN node to another RAN node, at node, cell and cell relation level, o (Example of legacy information): resource utilization o Indication of congestion status, wherein the congestion status may depend on the number of active bearers allocated, on the number of active RRC connections, on the PRB utilizations and other physical layer resources, such as CCEs, PUCCH resources, RACH resources, etc. 3) Estimation of changes in configuration data

In various embodiments, the first RAN node may estimate/determine the need to activate or deactivate any of various coverage/capacity/service capabilities in the second RAN node. Likewise, the first RAN node may estimate/determine the need to activate/deactivate coverage/capacity/service capabilities in the third RAN node. Similarly, the second RAN node may estimate the need to activate/deactivate coverage/capacity/service capabilities in the first RAN node and/or estimate the need to activate/deactivate coverage/capacity/service capabilities in the fourth RAN node. Likewise, the first RAN node may estimate the need to activate/deactivate coverage/capacity/service capabilities in the fourth RAN node.

The estimation performed by a RAN node can be based on any of the various traffic information described above. In some embodiments, this may be based on the recognition of certain fingerprints. Examples can be: o the traffic patterns in certain areas, e.g., considering the service mix, the resource utilization and associated performance o the traffic patterns during a day o the presence or the absence of a certain type of service.

4) Suggestion of configuration data

In various embodiments, the first RAN node may send, to the second RAN node, suggestions on how to modify the coverage/capacity/service configuration/policies of the second RAN node, with the aim of optimizing them and coordinating them with the traffic and neighbor node conditions, possibly along with the associated timing and probability. These suggestions may be triggered by the estimating/determining step described above.

In some embodiments, the first RAN node may send, to the second RAN node, suggestions to modify the coverage/capacity/service configuration/policies of the fourth RAN node, with the aim of optimizing them and coordinating them with the traffic and neighbor node conditions, possibly along with the associated timing and probability. Correspondingly, in some embodiments or instances, the second RAN node sends, to the first RAN node, suggestions to modify the coverage/capacity/service configuration/policies of the first RAN node and/or the third RAN node, with the aim of optimizing them and coordinating them with the traffic and neighbor node conditions, possibly along with the associated timing and probability. 5) Confirmation of changes in configuration data

In various embodiments, the first RAN node may receive, from the second RAN node, a confirmation of coverage/capacity/service configurations/policies or changes in those policies. This may be in response to one of the suggestions discussed above. In some embodiments or instances, the first RAN node may receive, from the second RAN node, coverage/capacity/service configurations/policies confirmed by the fourth RAN node. Similarly, in various embodiments the second RAN node may receive, from the first RAN node, the coverage/capacity/service configurations/policies confirmed by the first RAN node and/or the coverage/capacity/service configurations/policies confirmed by the third RAN node. Any of these may be in response to one or more of the suggestions discussed above.

In some embodiments, the first RAN node may send, to the second RAN node, the coverage/capacity/service configurations/policies confirmed by the third RAN node, as received from the third RAN node. Likewise, the second RAN node may send, to the first RAN node, coverage/capacity/service configurations/policies confirmed by the fourth RAN node, as received from the fourth RAN node.

6) Optimization based on known supported policies/features

In various embodiments, a a RAN node that is informed about one of its neighbor node's or cell's policies and features can adopt optimized configurations towards UEs based on interactions with such neighbor nodes and cells. As an example, the RAN node may serve UEs in a given cell by using a preferred band combination and feature set, based on the fact that neighbour cells with which dual connectivity (DC) or carrier aggregation (CA) can be established support a certain set of features. For example, for a given UE supporting 4 x 4 MIMO configurations, a serving RAN node may decide to serve such UE with a 2 x 2 MIMO configuration, in view of the fact that a neighbor cell with which DC can be configured can support also 2 x 2 MIMO towards the UE. This may optimize performance with respect to, for example, configuring one cell with 4 x 4 MIMO and the other cell used for DC with no MIMO configuration.

Following is a more detailed description of several methods to enable the steering of RAN configuration concerning coverage, capacity and service capabilities at node, cell, or cell relation level. Once more, in the description of these techniques, the following characteristics are considered: four (or more) RAN nodes, where a RAN node can be any of gNB, eNB, en-gNB, ng-eNB any two RAN nodes are neighbors, i.e., a signaling connection exists between them, over XnAP or X2AP, in both directions. the first RAN node and the second RAN node are neighbors the third RAN node is a neighbor of the first RAN node and optionally a neighbor of the second RAN node the fourth RAN node is a neighbor of the second RAN node and optionally a neighbor of the first RAN node. coverage/capacity/service capabilities of a RAN node relate to aspects such as unlicensed spectrum, multiple BWPs, multiple transmission points, slicing, QoS aspects, QoE aspects, whose configuration may be the responsibility of different entities or functions, such as a RAN node, O&M, non-real time Radio Intelligent Controller (non-real time RIC), near real time Radio Intelligent Controller (near real-time RIC). traffic characteristics for a RAN node may include but has not to be limited to the type of traffic supported or served, traffic management configuration (e.g., a specific carrier may be reserved for public safety or for a Non Public Network), QoS aspects, QoE aspects, slicing aspects. Traffic performances for a RAN node include aspects such as accessibility, retainability, integrity, availability, to mobility between such RAN node and another RAN node, at node, cell and cell relation level. information concerning time and frequency dynamics of the traffic offered by a RAN node, at node, cell, or cell relation level may include but has not to be limited to aspects such as distribution of users per 5QI, distribution of throughput per 5QI, distribution of latency per 5QI, distribution of incoming and outgoing mobility events per 5QI and neighbor relation, etc.

In various embodiments, one or several of the following steps may be performed at a first RAN node:

• sending, to a second RAN node, configuration data or updates of configuration data concerning the activation or deactivation of capacity, coverage, and/or service-related characteristics of the first RAN node, at node, cell, or cell relation level.

• sending, to the second RAN node, an authorization indication indicating whether the configuration data or updates of configuration for the first RAN node should be propagated to other nodes that are not neighbors of the concerned first RAN node. • receiving, from the second RAN node, configuration data or updates of configuration data concerning the activation or deactivation of capacity, coverage, and/or service- related characteristics of the second RAN node

• sending, to a second RAN node, configuration data or updates of configuration data concerning activation or deactivation of capacity, coverage, and/or service-related characteristics of the third RAN node. In some cases, this may be contingent on having received an authorization indication from the third RAN node indicating that this data may be shared. In some of these cases, the authorization indication may be specific to a RAN node or group of RAN nodes, in which case this step may be contingent on this authorization indication being valid for the second RAN node.

• receiving, from the second RAN node, configuration data or updates of configuration data concerning activation or deactivation of capacity, coverage and and/or service- related characteristics of the fourth RAN node.

• sending, to the second RAN node, information concerning time and frequency dynamics of the traffic offered by the first RAN node at node, cell, or cell relation level, possibly along with an authorization indication for provisioning to other RAN nodes that are not neighbors with the concerned first RAN node.

• receiving, from the second RAN node, information concerning time and frequency dynamics of the traffic offered by the second RAN node at node, cell, or cell relation level.

• sending, to the second RAN node, information concerning time and frequency dynamics of the traffic offered by the third RAN node at node, cell, or cell relation level. In some cases this may be contingent on having received an authorization indication permitting such from the third node; in some of these cases it may be further contingent on the authorization indication from the third RAN node being valid for the second RAN node.

• receiving, from the second RAN node, information concerning time and frequency dynamics of the traffic offered by the fourth RAN node at node, cell, or cell relation level.

• evaluating, e.g., based on the traffic information received from the second RAN node and/or or traffic information concerning the first RAN node or one or more other RAN nodes, the need to update the activation/deactivation of coverage, capacity, service capabilities of the second RAN node at the node, cell, or cell relation level.

• evaluating e.g., based on the traffic information received from the second RAN node and/or or traffic information concerning the first RAN node or one or more other RAN nodes, the need to update the activation/deactivation of coverage, capacity, service capabilities of the third RAN node at node, cell, or cell relation level.

• evaluating, e.g., based on the traffic information received from the second RAN node and/or or traffic information concerning the first RAN node or one or more other RAN nodes, the need to update the activation/deactivation of coverage, capacity, service capabilities of the fourth RAN node at node, cell, or cell relation level.

• sending, to the second RAN node, a proposal to update the activation/deactivation of capacity, coverage and service characteristics of the second RAN node, at node, cell, or cell relation level, where this proposal may be based on the evaluating described above.

• sending, to the second RAN node, a proposal to update the activation/deactivation of capacity, coverage and service characteristics of the fourth RAN node, at node, cell, or cell relation level, where this proposal may be based on the evaluating described above.

• receiving, from the second RAN node, a response to the proposed update for the second RAN node. This response may include an indication of any changes, e.g., with respect to activation status of any of the second RAN node's features.

• sending, to the second RAN node, a confirmation of updated activation/deactivation of capacity, coverage and service characteristics of the third RAN node, at node, cell, or cell relation level. In some cases this may be contingent on having received an authorization indication from the third RAN node that is valid for the second RAN node.

• receiving, from the second RAN node, a response to the confirmation of updated activation/deactivation of capacity, coverage and service characteristics of the fourth RAN node (such as a non-neighbor node of the first RAN node), at node, cell, or cell relation level. This response may include an indication of any changes, e.g., with respect to activation status of any of the fourth RAN node's features. In various embodiments, one or several of the following steps may be performed at the second RAN node:

• receiving, from the first RAN node, configuration data or updates of configuration data concerning activation or deactivation of capacity, coverage, service characteristics of the first gNB, at node, cell, or cell relation level.

• sending, to the first RAN node, configuration data or updates of configuration data concerning activation or deactivation of capacity, coverage and service characteristics of the second RAN node, at node, cell, or cell relation level.

• receiving, from the first RAN node, configuration data or updates of configuration data concerning activation or deactivation of capacity, coverage, service characteristics of the third RAN node.

• sending, to the first RAN node, configuration data or updates of configuration data concerning activation or deactivation of capacity, coverage and service characteristics of the fourth RAN node.

• receiving, from the first RAN node, information concerning time and frequency dynamics of the traffic offered by the first RAN node at node, cell, or cell relation level.

• sending, to the first RAN node, information concerning time and frequency dynamics of the traffic offered by the second RAN node at node, cell, or cell relation level.

• receiving, from the first RAN node, information concerning time and frequency dynamics of the traffic offered by the third RAN node at node, cell, or cell relation level.

• sending, to the first RAN node, information concerning time and frequency dynamics of the traffic offered by the fourth RAN node, cell, or cell relation level.

• receiving, from the first RAN node, a proposal to update the activation/deactivation of capacity, coverage and service characteristics of the second RAN node, at node, cell, or cell relation level.

• sending, to the first RAN node, a response to the proposed update for the second RAN node. This response may include an indication of any changes, e.g., with respect to activation status of any of the second RAN node's features. • receiving, from the first RAN node, a confirmation of updated activation/deactivation of capacity, coverage and service characteristics of the third RAN node, at node, cell, or cell relation level.

• sending, to the first RAN node the confirmation of updated activation/deactivation of capacity, coverage and service characteristics of the fourth RAN node, at node, cell, or cell relation level.

Example scenario 1

A first example to illustrate the steps of the proposed solution is shown in Figure 3, where only three gNB nodes are considered. In this figure and its description that follows, "gNB A" represents the first gNB, "gNB B" represents the second gNB, and "gNB C" is a neighbor node for both "gNB A" and "gNB B" and represents both the third and the fourth gNB. For simplicity, only the interaction between "gNB A" and "gNB B" is described. It will be appreciated that similar interactions between other RAN nodes may occur.

A continuous, or periodic, or event-triggered evaluation is ongoing in each node with respect to the criteria used to monitor the traffic dynamics, e.g., the incoming and/or outgoing mobility events between the cells of the node and the cells of the neighbors. In the picture, only a qualitative example of an evaluation is reported for simplicity, with the analysis done in "gNB A" of the mobility dynamics between "gNB A" and "gNB B" and between "gNB A" and "gNB C". It is also assumed that same type of evaluation and trigger levels are used for all gNBs. Note that the specific messages described in the examples below for communicating the various information, updates, and indications are only examples - other messages could be used.

Below is a description of the steps for the provided example:

1) Xn Setup or NG-RAN Node Configuration Update procedure. In the "XN SETUP

REQUEST" (or in the "NG-RAN NODE CONFIGURATION UPDATE") message the "gNB A" sends to the "gNB B" its configuration data, including the indication that a particular capacity/ coverage/service capability at "gNB A" is currently used (ON), i.e., the activation status for that capacity/coverage/service capability. The "gNB B" responds to the "gNB A" with an Xn SETUP RESPONSE (or an "NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE") message, indicating that it has some capacity and/or coverage capability is currently not used (OFF), i.e., an activation status for one or more features of gNB B. 2) At time tO, "gNB A" knows that some capacity and/or coverage capability potentially available at "gNB B" is not in use and the mobility dynamics monitored in "gNB A" between the "gNB A" and the "gNB B" indicate a level good enough for the "gNB A" to suggest to the "gNB B" the activation of such capacity and/or coverage.

3) The "gNB A" sends to the "gNB B" an "NG-RAN NODE CONFIGURATION UPDATE" with the suggestion to activate the available capacity and/or coverage.

4) The "gNB B" decides to activate the suggested capacity and/or coverage as suggested by "gNB A" and it replies to the "gNB A" with an "NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE" indicating that this is now in use (ON). This is an updated activation status for this feature.

5) At time tl, the "gNB A" knows that some capacity and/or coverage capability available at "gNB B" is still in use and the mobility dynamics monitored in "gNB A", between the "gNB A" and the "gNB B" indicates a level good enough for "gNB A" to suggest to the "gNB B" the deactivation of such extra (capacity and/or coverage).

6) The "gNB A" sends to the "gNB B" an "NG-RAN NODE CONFIGURATION UPDATE" with the suggestion to deactivate the some capacity and/or coverage capability.

7) The "gNB B" decides to deactivate the suggested extra as suggested by "gNB A" and it replies to the "gNB A" with an "NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE" indicating that the capability and/or coverage capability is now not in use (OFF).

Example scenario 2

A second example of the proposed solution is provided in Figures 4A and 4B, below.

The "gNB C" monitors the presence of the traffic served by its cells. At a certain time, "gNB C" detects that the traffic has a certain pattern. Such a detection can be based on external inputs, or as a result from internal RAN measurements, or a combination of both. This knowledge is (optionally) translated in a change of configuration in "gNB C" and communicated to "gNB A". The "gNB A" has now the possibility to change its own configuration and further suggest a change in the configuration for "gNB B".

Below is a description of the steps for the provided example:

1) the "gNB C" recognizes that a traffic with certain characteristics is present and moving towards the "gNB A" 2) the "gNB C" sends to the "gNB A" a "NG-RAN NODE CONFIGURATION UPDATE" message to (optionally) indicate that some capabilities have been activated in "gNB C" and to suggest the activation of certain capabilities in "gNB A" (capacity/coverage/service related) in order to serve the traffic estimated to reach "gNB A" within a certain time interval and/or with a certain probability

3) the "gNB A" activates the suggested capabilities and sends to the "gNB C" a "NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE" message including the indication that the suggested capabilities (capacity/ coverage/service related) at "gNB A" are currently used (ON)

4) the "gNB A" sends to the "gNB B" a "NG-RAN NODE CONFIGURATION UPDATE" message to indicate that some capabilities have been activated in "gNB A" and to suggest the activation of certain capabilities in "gNB B" (capacity/coverage/service related) in order to serve the traffic estimated to reach "gNB B" within a certain time interval and/or with a certain probability

5) the "gNB B" activates the suggested capabilities and sends to the "gNB A" a "NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE" message including the indication that the suggested capabilities (capacity/ coverage/service related) at "gNB B" are currently used (ON).

Some of the above-described embodiments and example scenarios involve transfer of information between base stations. A good scenario to illustrate when this can be beneficial is when multiple gNBs in sequence cover a highway or a railroad. When, for example, a train comes into the coverage area of one of the base stations and many UEs get connected to the base station, this base station may inform the next base station along the railroad in the direction the train is traveling, which in turn can inform the next base station and so forth, so that these base stations may prepare for the coming train, e.g., by handing over currently connected UEs at the cell edge to neighbor cells/base stations to free up resources for the coming train riding UEs.

To further facilitate the information exchange between base stations in such scenarios, the multi-hop information transfer can serve as a trigger to establish inter-base station interfaces between previously not directly inter-connected base stations in the chain of base station conveying the information transfer. For instance, referring to Figure 3, if information is passed from gNB C to gNB A and further to gNB B, which informs gNB D, this information transfer may trigger gNB D to request a direct interface (e.g., an Xn interface) to be established with gNB C. Similarly, this chain of information transfer may trigger establishment of an Xn interface between gNB C and gNB B and between gNB A and gNB D. This way, inter-base station interfaces may be triggered and established solely (or mainly) for the purpose of efficient exchange of information for tuning, coordination, optimization and proactive configuration or load management, even though no handovers are expected to occur directly between the base stations.

To facilitate such triggering of new inter-base station interfaces, the transferred information may include information about the base station that is the source of respective parts of the information, to enable direct contact between previously not inter-connected base stations in a similar fashion as when UEs provide such enabling information through the ANR feature. If there is no information that is actually transferred through multiple hops, but the scenario is rather that a a first base station triggers/informs a second base station and this triggers the second base station to trigger/inform a third base station and so forth, then indications of the chain of triggering base stations may accumulate and be passed on for each hop, so that the entire chain of base stations can be derived from the accumulated indications.

Normally, UEs are used in LTE and NR to discover new neighbor cells, including cells belonging to other base stations than the base station serving the UE. The feature which enables a base station to request a UE to retrieve and report information about such a new neighboring cell, to enable the base station to request an interface to be established to base station controlling the concerned cell (unless the cell belongs to the base station currently serving the UE) is called Automatic Neighbor Relations (ANR). This is the normal way to trigger establishment of new inter-base station interfaces for support of handovers of UEs. The above-described alternative way to trigger and establish inter- base station interfaces thus represents a novel trigger, a novel enabling mechanism and a novel purpose.

In view of the detailed examples and illustrations provided above, it will be appreciated that Figure 5 illustrates an example method according to several of these techniques, as might be implemented by a first RAN node in a wireless network.

As shown at block 510, the method comprises sending, to a second node of the RAN, configuration information indicating an activation status of each of one or more features of the first node of the RAN and/or of a third node of the RAN. Note that as used herein, the terms "configuration information" and "configuration data" may be considered interchangeable. The activation status indicates whether or not the corresponding feature is in use or activated by the corresponding node. In various embodiments, the configuration information may indicate any one or more of any of: an activation status of unlicensed spectrum available to the first node or the third node; an activation status of each of one or more transmission points or ranges of transmission points; an activation status of each of one or more bandwidth parts, BWPs; a range of supported MIMO configurations and an indication of one or more preferred MIMO configurations; a range of supported synchronization signal blocks and an indication of a currently selected SSB configuration; a range of identifiers for supported network slices and an indication of one or more network slices in use; a range of supported quality-of-service (QoS) attributes and an indication of one or more QoS attributes in use; a range of supported radio resource management policies per cell, and an indication of one or more RRM policies in use; a list of features supported per cell by the node; and a feature set supported by the node per cell per band.

In some embodiments, the configuration information indicates an updated activation status for at least one of the features, the updated activation status updating an activation status previously sent to the second node. In some embodiments, at least part of the configuration information relates to features of the first node, and the method further comprises sending an authorization indication to the second node, the authorization indication indicating whether the second node should propagate the configuration information to other network nodes that are not neighbors of the first node. This is shown at block 520.

Similarly, in some embodiments or instances, at least part of the configuration information relates to features of the third node and the method further comprises, prior to sending the configuration information, receiving the at least part of the configuration information and an authorization indication from the third node, where the authorization indication indicates that the first node should propagate the configuration information to other network nodes that are not neighbors of the third node.

In some embodiments, the method may further comprise receiving, from the second node, second configuration information, the second configuration information indicating an activation status of each of one or more features of the second node or a fourth node of the RAN. This is shown at block 530 of Figure 5. In some embodiments or instances, this second configuration information may indicate an updated activation status for at least one of the features, the updated activation status updating an activation status previously received from the second node.

In some embodiments or instances, the second configuration information indicates an activation status for each of one or more features of the fourth node of the RAN, and the method further comprises initiating an establishment of an inter-base-station interface between the first node and the fourth node, in response to receiving the second configuration information. This is shown at block 540.

As shown at block 550, the method may further comprise sending, to the second node, first traffic information indicating time and frequency dynamics of traffic at the first node and/or at the second node, at a node level, cell level, or cell relation level. At least part of the first traffic information may indicate time and frequency dynamics of traffic at the first node and the method may further comprise sending an indication to the second node authorizing the second node to provision the at least part of the first traffic information to other network nodes that are not neighbors of the first node. At least part of the first traffic information may indicate time and frequency dynamics of traffic at the third node, in which case the method may further comprise, prior to sending the first traffic information to the second node, receiving the at least part of the first traffic information and an indication from the third node authorizing the first node to propagate traffic information to other network nodes that are not neighbors of the third node.

As shown at block 560, the method may further comprise receiving, from the second node, second traffic information, the second traffic information indicating time and frequency dynamics of traffic at the second node and/or at a fourth node, at a node level, cell level, or cell relation level. As shown at block 570, the method may comprise sending, to the second node, an indication proposing a change to an activation status for at least one feature of the second node and/or proposing a change to an activation status for at least one feature of a fourth node, neighboring the second node. This indication may propose a change to an activation status for at least one feature of the second node, where the method comprises determining to propose the change to the activation status of the second node based on evaluating traffic information for at least one of the first node and the second node. In addition or alternatively, this indication may propose a change to an activation status for at least one feature of the fourth node, where the method further comprises determining to propose the change to the activation status of the fourth node based on evaluating traffic information for at least one of the first node, the second node, and the fourth node. The method may comprise receiving, from the second node, confirmation of an updated activation status for at least one feature of the second node and/or the fourth node, in response to the indication proposing the change.

As shown at block 580, the method may comprise receiving, from the second node, an indication proposing a change to an activation status for at least one feature of the first node and/or proposing a change to an activation status for at least one feature of a third node, neighboring the first node. The indication may propose a change to an activation status for at least one feature of the first node, where the method further comprises determining whether to change the activation status for at least one feature of the first node, in response to the indication. This determining whether to change the activation status for at least one feature of the first node, which is shown in block 590, may comprise evaluating traffic information for at least one of the first node, the second, node, and the third node.

The received indication may propose a change to an activation status for at least one feature of the third node, where the method further comprises forwarding the indication to the third node.

As shown in block 590, the method may further comprise sending, to the second node, confirmation of an updated activation status for at least one feature of the first node and/or the third node, in response to the indication proposing the change.

Figure 6 illustrates an example method according to several of the techniques described herein, as might be implemented by a second RAN node in a wireless network. It will be appreciated that the illustrated techniques may directly complement those shown in Figure 5, in some embodiments or instances.

As shown at block 610, the method may comprise receiving, from a first node of the RAN, configuration information indicating an activation status of each of one or more features of the first node of the RAN and/or of a third node of the RAN, the activation status indicating whether or not the corresponding feature is in use or activated by the corresponding node. In various embodiments, the configuration information may indicate any one or more of any of an activation status of unlicensed spectrum available to the first node or the third node; an activation status of each of one or more transmission points or ranges of transmission points; an activation status of each of one or more bandwidth parts, BWPs; a range of supported MIMO configurations and an indication of one or more preferred MIMO configurations; a range of supported synchronization signal blocks and an indication of a currently selected SSB configuration; a range of identifiers for supported network slices and an indication of one or more network slices in use; a range of supported quality-of-service (QoS) attributes and an indication of one or more QoS attributes in use; a range of supported radio resource management policies per cell, and an indication of one or more RRM policies in use; a list of features supported per cell by the node; and a feature set supported by the node per cell per band. The configuration information may indicate an updated activation status for at least one of the features, the updated activation status updating an activation status previously sent to the second node. At least part of the configuration information may relate to features of the first node, where the method further comprises receiving an authorization indication from the first node, the authorization indication indicating whether the second node should propagate the configuration information to other network nodes that are not neighbors of the first node.

This is shown at block 620. As shown at block 630, the method may further comprise forwarding the at least part of the configuration information to a fourth node, responsive to determining that the authorization indication indicates that the second node should propagate the configuration information to other network nodes that are not neighbors of the first node. At least part of the configuration information may relate to features of the third node. In some embodiments or instances, the method may further comprise initiating an establishment of an inter-base-station interface between the second node and the third node, in response to receiving the configuration information.

As shown at block 640, the method may further comprise receiving, from the first node, first traffic information indicating time and frequency dynamics of traffic at the first node and/or at the second node, at a node level, cell level, or cell relation level. At least part of the first traffic information may indicate time and frequency dynamics of traffic at the first node, where the method further comprises receiving an indication from the first node authorizing the second node to provision the at least part of the first traffic information to other nodes that are not neighbors of the first node. In these embodiments or instances, the method may further comprise sending the at least part of the first traffic information to a fourth node, responsive to determining that the indication authorizes the second node to provision the at least part of the first traffic information to other nodes. This is shown at block 650.

The method may further comprise sending, to the first node, second traffic information, the second traffic information indicating time and frequency dynamics of traffic at the second node and/or at a fourth node, at a node level, cell level, or cell relation level.

As shown at block 660, the method may comprise receiving, from the first node, an indication proposing a change to an activation status for at least one feature of the second node and/or proposing a change to an activation status for at least one feature of a fourth node, neighboring the second node. This indication may propose a change to an activation status for at least one feature of the second node, where the method further comprises determining whether to change the activation status for at least one feature of the second node, in response to the indication. Determining whether to change the activation status for at least one feature of the first node may comprise evaluating traffic information for at least one of the first node, the second, node, and the fourth node.

The indication may propose a change to an activation status for at least one feature of the third node, where the method further comprises forwarding the indication to the third node.

As shown at block 670, the method may comprise sending, to the second node, confirmation of an updated activation status for at least one feature of the first node and/or the third node, in response to the indication proposing the change.

Figure 7 shows a network node 30, which may be configured to carry out all or parts of one or more of these disclosed techniques. More particularly, network node 30, which in the illustrated example is a radio network node (because it includes a radio for communicating with one or more UEs), such as a gNB or eNB, may perform those operations attributed in the above discussion to a network node. In particular, network node may carry out a method according to Figure 5 and/or Figure 6, in various embodiments.

Network node 30 may be an evolved Node B (eNodeB or eNB), Node B, or gNB. While a radio network node 30 is shown in Figure 7, the operations can be performed by other kinds of network nodes, including a radio network node such as base station, radio base station, base transceiver station, base station controller, network controller, NR base station (BS), Multi-cell/multicast Coordination Entity (MCE), relay node, access point, radio access point, Remote Radio Unit (RRU) Remote Radio Flead (RRH), or a multi-standard BS (MSR BS).

Network node 30 facilitates communication between wireless terminals (e.g., UEs), other network access nodes and/or the core network. Network node 30 may include communication interface circuitry 38 that includes circuitry for communicating with other nodes in the core network, radio nodes, and/or other types of nodes in the network for the purposes of providing data and/or cellular communication services. Some embodiments of network node 30 communicate with wireless devices using antennas 34 and transceiver circuitry 36. Some of these and some other embodiments may communicate with one or more relay nodes using antennas 34 and transceiver circuitry 36, e.g., using antennas 34 and transceiver circuitry 36 to communicate with an MT part of a relay node. Transceiver circuitry 36 may include transmitter circuits, receiver circuits, and associated control circuits that are collectively configured to transmit and receive signals according to a radio access technology, for the purposes of providing cellular communication services.

Network node 30 also includes one or more processing circuits 32 that are operatively associated with the transceiver circuitry 36 and, in some cases, the communication interface circuitry 38. Processing circuitry 32 comprises one or more digital processors 42, e.g., one or more microprocessors, microcontrollers, Digital Signal Processors (DSPs), Field Programmable Gate Arrays (FPGAs), Complex Programmable Logic Devices (CPLDs), Application Specific Integrated Circuits (ASICs), or any mix thereof. More generally, processing circuitry 32 may comprise fixed circuitry, or programmable circuitry that is specially configured via the execution of program instructions implementing the functionality taught herein, or some mix of fixed and programmed circuitry. Processor 42 may be multi-core, i.e., having two or more processor cores utilized for enhanced performance, reduced power consumption, and more efficient simultaneous processing of multiple tasks.

Processing circuitry 32 also includes a memory 44. Memory 44, in some embodiments, stores one or more computer programs 46 and, optionally, configuration data 48. Memory 44 provides non-transitory storage for the computer program 46 and it may comprise one or more types of computer-readable media, such as disk storage, solid-state memory storage, or any mix thereof. Here, "non-transitory" means permanent, semi-permanent, or at least temporarily persistent storage and encompasses both long-term storage in non-volatile memory and storage in working memory, e.g., for program execution. By way of non-limiting example, memory 44 comprises any one or more of SRAM, DRAM, EEPROM, and FLASH memory, which may be in processing circuitry 32 and/or separate from processing circuitry 32. Memory 44 may also store any configuration data 48 used by the network access node 30. Processing circuitry 32 may be configured, e.g., through the use of appropriate program code stored in memory 44, to carry out one or more of the methods and/or signaling processes detailed herein.

Processing circuitry 32 of the network node 30 is configured, according to some embodiments, to perform all or part of the techniques described herein for one or more network nodes of a wireless communication system, including, for example, the methods described in connection with Figures 5 and 6.

The techniques described herein, e.g., as illustrated in the process flow diagrams of Figures 5 and 6, may be implemented, in whole or in part, using computer program instructions executed by one or more processors. It will be appreciated that a functional implementation of these techniques may be represented in terms of functional modules, where each functional module corresponds to a functional unit of software executing in an appropriate processor or to a functional digital hardware circuit, or some combination of both, where the functional unit is carrying out one or several of the steps described above. ABBREVIATIONS

3GPP 3^rd Generation Partnership Project

ANR Automatic Neighbor Relations

CA Carrier Aggregation

CAC Composite available capacity

CU-CP Centralized unit - control plane

CU-UP Centralized unit - user plane

DC Dual Connectivity

DL Downlink

DU Distributed unit

ECID Enhanced cell identity eNB Evolved NodeB

E-UTRAN Evolved Universal Terrestrial Radio Access Network gNB A radio base station in NR.

GNSS Global navigation satellite system

LTE Long term evolution

MCG Master cell group

MDT Minimization of drive test

ML Machine learning

MN Master node

NR New radio

O&M Operation and Maintenance

PDCP Packet data convergence protocol

QoE Quality of Experience

QoS Quality of Service

RAN Radio access network

RSRP Reference signal received power

RSRQ Reference signal received quality

SCG Secondary cell group

SINR Signal to interference and noise ratio

SN Secondary node

TNL Transport network layer UE User equipment

UL uplink

WLAN Wireless local area network

X2 The interface between two eNBs.

X2AP X2 Application Protocol

Xn The interface between two gNBs

XnAP Xn Application Protocol

EXAMPLE EMBODIMENTS

Example embodiments of the techniques and apparatuses described above include, but are not limited to:

1. A method, in a first node of a radio access network, RAN, the method comprising: sending, to a second node of the RAN, configuration information indicating an activation status of each of one or more features of the first node of the RAN and/or of a third node of the RAN, the activation status indicating whether or not the corresponding feature is in use or activated by the corresponding node.

2. The method of example embodiment 1, wherein the configuration information indicates any one or more of any of: an activation status of unlicensed spectrum available to the first node or the third node; an activation status of each of one or more transmission points or ranges of transmission points; an activation status of each of one or more bandwidth parts, BWPs; a range of supported MIMO configurations and an indication of one or more preferred MIMO configurations; a range of supported synchronization signal blocks and an indication of a currently selected SSB configuration; a range of identifiers for supported network slices and an indication of one or more network slices in use; a range of supported quality-of-service (QoS) attributes and an indication of one or more QoS attributes in use; a range of supported radio resource management policies per cell, and an indication of one or more RRM policies in use; a list of features supported per cell by the node; a feature set supported by the node per cell per band.

3. The method of example embodiment 1 or 2, wherein the configuration information indicates an updated activation status for at least one of the features, the updated activation status updating an activation status previously sent to the second node.

4. The method of any of example embodiments 1-3, wherein at least part of the configuration information relates to features of the first node, and wherein the method further comprises sending an authorization indication to the second node, the authorization indication indicating whether the second node should propagate the configuration information to other network nodes that are not neighbors of the first node.

5. The method of any of example embodiments 1-3, wherein at least part of the configuration information relates to features of the third node and wherein the method further comprises, prior to said sending, receiving the at least part of the configuration information and an authorization indication from the third node, the authorization indication indicating that the first node should propagate the configuration information to other network nodes that are not neighbors of the third node.

6. The method of any of example embodiments 1-5, further comprising receiving, from the second node, second configuration information, the second configuration information indicating an activation status of each of one or more features of the second node or a fourth node of the RAN.

7. The method of example embodiment 6, wherein the second configuration information indicates an updated activation status for at least one of the features, the updated activation status updating an activation status previously received from the second node.

8. The method of example embodiment 6, wherein the second configuration information indicates an activation status for each of one or more features of the fourth node of the RAN, the method further comprising: initiating an establishment of an inter-base-station interface between the first node and the fourth node, in response to receiving the second configuration information.

9. The method of any of example embodiments 1-8, the method further comprising: sending, to the second node, first traffic information indicating time and frequency dynamics of traffic at the first node and/or at the second node, at a node level, cell level, or cell relation level.

10. The method of example embodiment 9, wherein at least part of the first traffic information indicates time and frequency dynamics of traffic at the first node and wherein the method further comprises sending an indication to the second node authorizing the second node to provision the at least part of the first traffic information to other network nodes that are not neighbors of the first node.

11. The method of any of example embodiment 9, wherein at least part of the first traffic information indicates time and frequency dynamics of traffic at the third node and wherein the method further comprises, prior to sending the first traffic information to the second node, receiving the at least part of the first traffic information and an indication from the third node authorizing the first node to propagate traffic information to other network nodes that are not neighbors of the third node.

12. The method of any of example embodiments 1-11, further comprising receiving, from the second node, second traffic information, the second traffic information indicating time and frequency dynamics of traffic at the second node and/or at a fourth node, at a node level, cell level, or cell relation level.

13. The method of any of example embodiments 1-12, further comprising: sending, to the second node, an indication proposing a change to an activation status for at least one feature of the second node and/or proposing a change to an activation status for at least one feature of a fourth node, neighboring the second node.

14. The method of example embodiment 13, wherein the indication proposes a change to an activation status for at least one feature of the second node and wherein the method further comprises determining to propose the change to the activation status of the second node based on evaluating traffic information for at least one of the first node and the second node. 15. The method of example embodiment 13, wherein the indication proposes a change to an activation status for at least one feature of the fourth node and wherein the method further comprises determining to propose the change to the activation status of the fourth node based on evaluating traffic information for at least one of the first node, the second node, and the fourth node.

16. The method of any of example embodiments 13-15, further comprising receiving, from the second node, confirmation of an updated activation status for at least one feature of the second node and/or the fourth node, in response to the indication proposing the change.

17. The method of any of example embodiments 1-16, further comprising: receiving, from the second node, an indication proposing a change to an activation status for at least one feature of the first node and/or proposing a change to an activation status for at least one feature of a third node, neighboring the first node.

18. The method of example embodiment 17, wherein the indication proposes a change to an activation status for at least one feature of the first node and wherein the method further determining whether to change the activation status for at least one feature of the first node, in response to the indication.

19. The method of example embodiment 18, wherein determining whether to change the activation status for at least one feature of the first node comprises evaluating traffic information for at least one of the first node, the second, node, and the third node.

20. The method of example embodiment 18, wherein the indication proposes a change to an activation status for at least one feature of the third node and wherein the method further comprises forwarding the indication to the third node.

21. The method of any of example embodiments 17-20, further comprising sending, to the second node, confirmation of an updated activation status for at least one feature of the first node and/or the third node, in response to the indication proposing the change.

22. A method, in a second node of a radio access network, RAN, the method comprising: receiving, from a first node of the RAN, configuration information indicating an activation status of each of one or more features of the first node of the RAN and/or of a third node of the RAN, the activation status indicating whether or not the corresponding feature is in use or activated by the corresponding node.

23. The method of example embodiment 22, wherein the configuration information indicates any one or more of any of: an activation status of unlicensed spectrum available to the first node or the third node; an activation status of each of one or more transmission points or ranges of transmission points; an activation status of each of one or more bandwidth parts, BWPs; a range of supported MIMO configurations and an indication of one or more preferred MIMO configurations; a range of supported synchronization signal blocks and an indication of a currently selected SSB configuration; a range of identifiers for supported network slices and an indication of one or more network slices in use; a range of supported quality-of-service (QoS) attributes and an indication of one or more QoS attributes in use; a range of supported radio resource management policies per cell, and an indication of one or more RRM policies in use; a list of features supported per cell by the node; a feature set supported by the node per cell per band.

24. The method of example embodiment 22 or 23, wherein the configuration information indicates an updated activation status for at least one of the features, the updated activation status updating an activation status previously sent to the second node.

25. The method of any of example embodiments 22-24, wherein at least part of the configuration information relates to features of the first node, and wherein the method further comprises receiving an authorization indication from the first node, the authorization indication indicating whether the second node should propagate the configuration information to other network nodes that are not neighbors of the first node. 26. The method of example embodiment 25, further comprising forwarding the at least part of the configuration information to a fourth node, responsive to determining that the authorization indication indicates that the second node should propagate the configuration information to other network nodes that are not neighbors of the first node.

27. The method of any of example embodiments 22-26, wherein at least part of the configuration information relates to features of the third node.

28. The method of example embodiment 27, wherein method further comprises initiating an establishment of an inter-base-station interface between the second node and the third node, in response to receiving the configuration information

29. The method of any of example embodiments 22-28, the method further comprising: receiving, from the first node, first traffic information indicating time and frequency dynamics of traffic at the first node and/or at the second node, at a node level, cell level, or cell relation level.

30. The method of example embodiment 29, wherein at least part of the first traffic information indicates time and frequency dynamics of traffic at the first node and wherein the method further comprises receiving an indication from the first node authorizing the second node to provision the at least part of the first traffic information to other nodes that are not neighbors of the first node.

31. The method of example embodiment 30, wherein the method further comprises sending the at least part of the first traffic information to a fourth node, responsive to determining that the indication authorizes the second node to provision the at least part of the first traffic information to other nodes.

32. The method of any of example embodiments 22-31, further comprising sending, to the first node, second traffic information, the second traffic information indicating time and frequency dynamics of traffic at the second node and/or at a fourth node, at a node level, cell level, or cell relation level.

33. The method of any of example embodiments 22-32, further comprising: receiving, from the first node, an indication proposing a change to an activation status for at least one feature of the second node and/or proposing a change to an activation status for at least one feature of a fourth node, neighboring the second node.

34. The method of example embodiment 33, wherein the indication proposes a change to an activation status for at least one feature of the second node and wherein the method further comprises determining whether to change the activation status for at least one feature of the second node, in response to the indication.

35. The method of example embodiment 34, wherein determining whether to change the activation status for at least one feature of the first node comprises evaluating traffic information for at least one of the first node, the second, node, and the fourth node.

36. The method of example embodiment 33, wherein the indication proposes a change to an activation status for at least one feature of the third node and wherein the method further comprises forwarding the indication to the third node.

37. The method of any of example embodiments 33-36, further comprising sending, to the second node, confirmation of an updated activation status for at least one feature of the first node and/or the third node, in response to the indication proposing the change.

38. A base station adapted to carry out a method according to any of claims 1-37.

39. A base station comprising: radio circuitry configured to communicate with one or more wireless devices; interface circuitry configured to communicate with one or more other base stations; and processing circuitry operatively coupled to the radio circuitry and the interface circuitry and configured to carry out a method according to any of claims 1-37.

40. A computer program product comprising program instructions for execution by a processor of a base station, the program instructions being configured to cause the base station to carry out a method according to any of claims 1-37. 41. A computer-readable medium comprising, stored thereupon, a computer program product according to claim 40.

Claims

CLAIMS What is claimed is:

1. A method, in a first node of a radio access network, RAN, the method comprising: sending (510), to a second node of the RAN, configuration information indicating an activation status of each of one or more service-related features of the first node of the RAN and/or of a third node of the RAN, the activation status indicating whether or not the corresponding feature is in use or activated by the corresponding node.

2. The method of claim 1, wherein the configuration information indicates any one or more of any of: an activation status of unlicensed spectrum available to the first node or the third node; an activation status of each of one or more transmission points or ranges of transmission points; an activation status of each of one or more bandwidth parts, BWPs; a range of supported MIMO configurations and an indication of one or more preferred MIMO configurations; a range of supported synchronization signal blocks and an indication of a currently selected SSB configuration; a range of identifiers for supported network slices and an indication of one or more network slices in use; a range of supported quality-of-service (QoS) attributes and an indication of one or more QoS attributes in use; a range of supported radio resource management policies per cell, and an indication of one or more RRM policies in use; a list of features supported per cell by the node; a feature set supported by the node per cell per band.

3. The method of claim 1 or 2, wherein the configuration information indicates an updated activation status for at least one of the features, the updated activation status updating an activation status previously sent to the second node.

4. The method of any of claims 1-3, wherein at least part of the configuration information relates to features of the first node, and wherein the method further comprises sending (520) an authorization indication to the second node, the authorization indication indicating whether the second node should propagate the configuration information to other network nodes that are not neighbors of the first node.

5. The method of any of claims 1-3, wherein at least part of the configuration information relates to features of the third node and wherein the method further comprises, prior to said sending, receiving the at least part of the configuration information and an authorization indication from the third node, the authorization indication indicating that the first node should propagate the configuration information to other network nodes that are not neighbors of the third node.

6. The method of any of claims 1-5, further comprising receiving (530), from the second node, second configuration information, the second configuration information indicating an activation status of each of one or more features of the second node or a fourth node of the RAN.

7. The method of claim 6, wherein the second configuration information indicates an updated activation status for at least one of the features, the updated activation status updating an activation status previously received from the second node.

8. The method of claim 6, wherein the second configuration information indicates an activation status for each of one or more features of the fourth node of the RAN, the method further comprising: initiating (540) an establishment of an inter-base-station interface between the first node and the fourth node, in response to receiving the second configuration information.

9. The method of any of claims 1-8, the method further comprising: sending (550), to the second node, first traffic information indicating time and frequency dynamics of traffic at the first node and/or at the second node, at a node level, cell level, or cell relation level.

10. The method of claim 9, wherein at least part of the first traffic information indicates time and frequency dynamics of traffic at the first node and wherein the method further comprises sending an indication to the second node authorizing the second node to provision the at least part of the first traffic information to other network nodes that are not neighbors of the first node.

11. The method of any of claim 9, wherein at least part of the first traffic information indicates time and frequency dynamics of traffic at the third node and wherein the method further comprises, prior to sending the first traffic information to the second node, receiving the at least part of the first traffic information and an indication from the third node authorizing the first node to propagate traffic information to other network nodes that are not neighbors of the third node.

12. The method of any of claims 1-11, further comprising receiving (560), from the second node, second traffic information, the second traffic information indicating time and frequency dynamics of traffic at the second node and/or at a fourth node, at a node level, cell level, or cell relation level.

13. The method of any of claims 1-12, further comprising: sending (570), to the second node, an indication proposing a change to an activation status for at least one feature of the second node and/or proposing a change to an activation status for at least one feature of a fourth node, neighboring the second node.

14. The method of claim 13, wherein the indication proposes a change to an activation status for at least one feature of the second node and wherein the method further comprises determining to propose the change to the activation status of the second node based on evaluating traffic information for at least one of the first node and the second node.

15. The method of claim 13, wherein the indication proposes a change to an activation status for at least one feature of the fourth node and wherein the method further comprises determining to propose the change to the activation status of the fourth node based on evaluating traffic information for at least one of the first node, the second node, and the fourth node.

16. The method of any of claims 13-15, further comprising receiving, from the second node, confirmation of an updated activation status for at least one feature of the second node and/or the fourth node, in response to the indication proposing the change.

17. The method of any of claims 1-16, further comprising: receiving (580), from the second node, an indication proposing a change to an activation status for at least one feature of the first node and/or proposing a change to an activation status for at least one feature of a third node, neighboring the first node.

18. The method of claim 17, wherein the indication proposes a change to an activation status for at least one feature of the first node and wherein the method further determining (590) whether to change the activation status for at least one feature of the first node, in response to the indication.

19. The method of claim 18, wherein determining whether to change the activation status for at least one feature of the first node comprises evaluating traffic information for at least one of the first node, the second, node, and the third node.

20. The method of claim 18, wherein the indication proposes a change to an activation status for at least one feature of the third node and wherein the method further comprises forwarding the indication to the third node.

21. The method of any of claims 17-20, further comprising sending (590), to the second node, confirmation of an updated activation status for at least one feature of the first node and/or the third node, in response to the indication proposing the change.

22. A method, in a second node of a radio access network, RAN, the method comprising: receiving (610), from a first node of the RAN, configuration information indicating an activation status of each of one or more features of the first node of the RAN and/or of a third node of the RAN, the activation status indicating whether or not the corresponding feature is in use or activated by the corresponding node.

23. The method of claim 22, wherein the configuration information indicates any one or more of any of: an activation status of unlicensed spectrum available to the first node or the third node; an activation status of each of one or more transmission points or ranges of transmission points; an activation status of each of one or more bandwidth parts, BWPs; a range of supported MIMO configurations and an indication of one or more preferred MIMO configurations; a range of supported synchronization signal blocks and an indication of a currently selected SSB configuration; a range of identifiers for supported network slices and an indication of one or more network slices in use; a range of supported quality-of-service (QoS) attributes and an indication of one or more QoS attributes in use; a range of supported radio resource management policies per cell, and an indication of one or more RRM policies in use; a list of features supported per cell by the node; a feature set supported by the node per cell per band.

24. The method of claim 22 or 23, wherein the configuration information indicates an updated activation status for at least one of the features, the updated activation status updating an activation status previously sent to the second node.

25. The method of any of claims 22-24, wherein at least part of the configuration information relates to features of the first node, and wherein the method further comprises receiving (620) an authorization indication from the first node, the authorization indication indicating whether the second node should propagate the configuration information to other network nodes that are not neighbors of the first node.

26. The method of claim 25, further comprising forwarding (630) the at least part of the configuration information to a fourth node, responsive to determining that the authorization indication indicates that the second node should propagate the configuration information to other network nodes that are not neighbors of the first node.

27. The method of any of claims 22-26, wherein at least part of the configuration information relates to features of the third node.

28. The method of claim 27, wherein method further comprises initiating an establishment of an inter- base-station interface between the second node and the third node, in response to receiving the configuration information

29. The method of any of claims 22-28, the method further comprising: receiving (640), from the first node, first traffic information indicating time and frequency dynamics of traffic at the first node and/or at the second node, at a node level, cell level, or cell relation level.

30. The method of claim 29, wherein at least part of the first traffic information indicates time and frequency dynamics of traffic at the first node and wherein the method further comprises receiving an indication from the first node authorizing the second node to provision the at least part of the first traffic information to other nodes that are not neighbors of the first node.

31. The method of claim 30, wherein the method further comprises sending the at least part of the first traffic information to a fourth node, responsive to determining that the indication authorizes the second node to provision the at least part of the first traffic information to other nodes.

32. The method of any of claims 22-31, further comprising sending (650), to the first node, second traffic information, the second traffic information indicating time and frequency dynamics of traffic at the second node and/or at a fourth node, at a node level, cell level, or cell relation level.

33. The method of any of claims 22-32, further comprising: receiving (660), from the first node, an indication proposing a change to an activation status for at least one feature of the second node and/or proposing a change to an activation status for at least one feature of a fourth node, neighboring the second node.

34. The method of claim 33, wherein the indication proposes a change to an activation status for at least one feature of the second node and wherein the method further comprises determining (660) whether to change the activation status for at least one feature of the second node, in response to the indication.

35. The method of claim 34, wherein determining (660) whether to change the activation status for at least one feature of the first node comprises evaluating traffic information for at least one of the first node, the second, node, and the fourth node.

36. The method of claim 33, wherein the indication proposes a change to an activation status for at least one feature of the third node and wherein the method further comprises forwarding the indication to the third node.

37. The method of any of claims 33-36, further comprising sending (670), to the second node, confirmation of an updated activation status for at least one feature of the first node and/or the third node, in response to the indication proposing the change.

38. A base station (30) adapted to carry out a method according to any of claims 1-37.

39. A base station (30) comprising: radio circuitry (36) configured to communicate with one or more wireless devices; interface circuitry (38) configured to communicate with one or more other base stations; and processing circuitry (32) operatively coupled to the radio circuitry (36) and the interface circuitry (38) and configured to carry out a method according to any of claims 1-37.

40. A computer program product (46) comprising program instructions for execution by a processor (32) of a base station (30), the program instructions being configured to cause the base station (30) to carry out a method according to any of claims 1-37.

41. A computer-readable medium (44) comprising, stored thereupon, a computer program product (46) according to claim 40.