1.1 Data-driven network management

In addition to the challenges from the scalability point of view (ie, the autonomous management of the network shall be performed on many and potentially large network instances), another fundamental technical barrier relates to the interfaces needed across different network domains. While the term domain has been extensively used in the literature to distinguish individual network segments by technology, implementation architecture, or administrative ownership (tenant concept),¹⁰ in this article, we use the term network domain to refer to different functionality within and beyond the considered network. The new challenges that the operation of the network poses to all the elements entails a deep revision of how different parts inside and outside the network interact with each other, enabling a much higher granularity that goes beyond the pure ownership of the infrastructure and involves, instead, different network domains, as discussed next.

1.2 The need for a new exposure paradigm

Traditionally, procedures related to network management, network orchestration, and network control have been developed by different tracks of the standardization activities. Hence, the functions that execute these procedures (ie, OSS functions, element managers, orchestrators, or radio and core NFs) have been designed in a domain-specific and, in some cases, even proprietary manner, with possible optimizations happening only in a “per domain” way, leaving the interaction limited to peer-to-peer reference points within a domain, for example, between control plane (CP) and UP (eg, the S11 interface between MME and S-GW functions as defined in 3GPP 4G evolved packet core¹¹).

In such reference-point-based setups, optimizations are either open-loop (ie, no feedback among different modules in the system) or require very expensive human engineering procedures to close the loop. This approach has been deemed as valid within legacy networks, due to their limited number of possible configurations. However, in a 5G environment, this approach clearly falls short. Also, as legacy NFs either have function-specific data acquisition and processing procedures or no procedure at all, simple configurations or rulesets are usually sufficient to achieve optimization goals.

Self-organizing network (SON)¹² functions were the first step toward that goal. Frequently, however, the legacy approach is insufficient for the 5G environment with network slicing. With legacy SON, configurations mainly concern “physical” parameters (eg, radio transmission power, radio conditions, handover thresholds, cell-individual offsets, and antenna tilt, to only name a few), while per-slice configuration or the self-optimization of the NFV infrastructure is simply out of the scope of existing SON concepts. Still, SON is a first step toward the flexible management of the network without the human in the loop.

We remark that the current, state-of-the art network architectures are currently defined in a “silo”-based way: they may have some analytics feature within one domain (such as the notable case of NWDAF in the core), but they are lacking the open exchange among them. Thus the motivation of this work encompasses aspects such as: (i) identifying the possible data exchanges among different domains, classified according to their purpose, (ii) finding an architecture that overcomes this issue, and (iii) exemplify it in a compelling way.

1.3 Contributions

In this article, we make the case for a novel, network-exposure native, network architecture, that bridges the gaps that are traditionally found across different Standard Developing Organizations (SDOs), which often focus on a specific domain only.

Hence, this article provides a holistic view on the advantages provided by enabling a native network exposure architecture, joining state of the art discussion with a feasibility study in a real-world scenario. Hence, the role of the deployed system discussed in Section 6 is to provide a feasibility analysis of the overall network exposure system, effectively showcasing one of the provided case studies. In other words, we discuss a real-world implementation of a specific algorithm, with the goal of providing qualitative evidence of the advantages provided by the service based capability exposure framework proposed in this article.

2.1 The domains

With the arrival of the network softwarization concept, different functionalities in the network adopted a software-driven approach. Among the most important examples, we can list the Service Based Architecture (SBA) in the network core,¹⁴ and the xApps defined in the O-RAN controller hierarchy.¹⁵ However, the flexible interaction guaranteed by the open interfaces devised by these approaches are traditionally confined into one specific domain (eg, network functions), while the software landscape in the context of mobile networks is much broader, as discussed next (Figure 2).

2.1.4 The service provider domain

The novel network softwarization paradigm introduced by 5G and beyond 5G networks allowed for a diverse and heterogeneous landscape of tenants.²⁷ That is, different service providers such as industrial verticals, are now a fundamental piece involved in the network operation, in clear contrast with what has been traditionally happening up to the legacy 4G networks.

The 4G network provisioning is characterized by a full over the top (OTT) service delivery model. Instead, the new model can provide a more integrated view of the system from the tenant and service provider perspective, who can, by leveraging on novel configuration primitives, act on the underlying network slices. From the standardization point of view, this concept has been increasingly attracting more attention. For instance, 3GPP²¹ currently defines two management models: network operator internals (ie, the legacy solution, in which the tenant has no visibility on the underlying system) and NSaaS in which the tenant can manage the network slice as manager via an exposed management interface, and optionally provide network slicing capabilities to other tenants.

Furthermore, industrial initiatives such as 5G-ACIA²⁶ describe the requirements for a 5G exposure reference point toward enterprise tenants to promote better integration between 3rd party service providers and network operators. Envisioned for Industrial Internet of Things (IIoT) use cases, the concept currently under development in 5G-ACIA, depicted in Figure 3, proposes the exposure of selected functionality from a 5G nonpublic network or from the UE toward IIoT applications in the IT enterprise domain. Among these exposed functionalities we have

• The exposure of selected 5GC control plane functionality (eg, NWDAF data analytics)
• The exposure of the 5GC capability as a whole (eg, provide a specific QoS for an AS session, influence traffic routing, provision service/UE specific information, etc.)
• The exposure of the 5GS management capability (eg, slice configuration)

However, 5G-ACIA does not mandate any specific solutions to be used for the exposure reference point. Rather, usability, simplicity, modularity, and extensibility are listed as key requirements. The specific capabilities to be exposed depend on the envisioned use case. Among them, device provisioning and onboarding, device connectivity management, device connectivity monitoring, device group management, device location information, network monitoring, and network maintenance can be listed. Thus, the proposed exposure framework shall also take into account the requirements of 5G-ACIA. Currently, 3GPP only envisions the traditional network operator model with minimum interaction of NFs with external functions and the NSaaS model. As for example, 5G-ACIA requirements show, more flexible interfacing may be beneficial for different business models (eg, hybrid private public deployments).

Finally, we remark that the quest for a tighter interaction between service providers and network operators is also pursued by industrial consortia besides beyond the factory ones: the NetApps²⁸ concept introduced by many research projects nowadays is also promoting the usage of open APIs between these traditionally separated domains. Among them, we can certainly consider new providers that make use of edge computing technologies, for example, offloading use cases that require very low latency, that is the case also for other providers such as vehicular ones, to provide example autonomous driving services. In this case, the open interactions between such applications and the underlying access technology²⁹ is paramount. For instance, as already discussed in Reference 30, the integration of MEC with relevant architectures such as O-RAN is still being discussed, and still, these efforts are targeting a specific architectural element (the O-RAN xApp controller, but it lacks exposure functionality toward other domains, such as the Core.

2.2 The capability types

As previously discussed, although different elements of the state-of-the-art network architectures already provide data-driven functionality, their limited scope (very often bounded to one specific domain) may hinder the automated operation of the network that involve cross-domain activities such as reactive orchestration upon network triggers, or service-driven network re-configurations that are at the basis of the autonomous operation of the network.

Thus, owing to the data-driven vision of the network, we introduce four types of capabilities that summarize what kind of interaction shall happen across domain boundaries. Cross-domain interaction shall be enabled by inter-domain message buses. Please note that registered capabilities are associated with authorization levels for potential consumers from the same and other domains.

Capability type 1: Monitoring and data collection: This capability is related to the provisioning of raw monitoring data from and to different Network Elements, and it is already implemented for some network domains. For instance, NFs can provide KPIs related to the cell performance (eg, handover failure rates, cell load, etc.), user-centric KPIs (eg, per user throughput, latency, etc.) and KPIs related to the end-to-end service performance. Also, monitoring data of the infrastructure (eg, CPU and RAM utilization) falls into this category. Finally, this capability type includes the capability to define customized measurement jobs, trace collection configurations, or real-time performance measurements on the monitored element.

Capability type 2: Triggers, alarms, and fault supervision: While the data collection capability discussed before provides a way for collecting information from Network Elements at full granularity, there is the need for a more refined way of accessing it. That is, most of the elements in the network need to react according to well-defined state machines upon triggering events. This includes the normal network operation (eg, RRC state handling and radio link failures), but it is of particular importance when dealing with fault supervision. Thus, providing event notifications, such as, alarm information, alarm state changes, alarm correlation information can be categorized in this capability type, which can be further enriched to include notifications on associated trouble-shooting actions.

Capability type 3: Actions, control, and configurations: Besides exposing data as well as alarms and events, Network Elements of different domains shall also expose configuration and control capabilities to other elements. Generically, this capability type comprises capabilities to act, that is, to create, modify, delete objects as well as their parameters and configuration attributes. The definition of an object then depends on the specific domain that is exposing this capability. For instance, in the orchestration domain an object is, for example, a VNF, a resource, a network service and so on. Similarly, in the network domains, an object is, for example, a parameter of an NF or a network slice instance.

Capability type 4: Network intelligence and policy recommendations: Future network operations will be intelligent. This means that most of the tasks that currently require human intervention to achieve optimality in the network will be handled automatically and with some kind of AI in the loop. Thus, Network Elements shall expose the capability of performing complex analytics on inputs coming from other elements (ie, the ones exposed by capability types 1-3 above). For instance, intelligent elements in the networks shall include root cause analysis or impact analysis. Individual data analytics capabilities can be combined to process incoming events and other information related to faults and performance of the monitored objects, aggregate, and analyze the information and derive novel information required for enhanced operations, for example, failure prediction to prevent faulty network states. Policy recommendations exposed through this capability are eventually consumed by other elements in each domain or across domains

2.3 Network data exposure beyond standardization

With the increasing interest on network automation research topics, also the research in the field of network data exposure has grown. However, this topic has been mostly addressed from a very specific point of view: network security.³¹

Indeed, the security aspect is paramount when opening up information between network domains that have been traditionally separated. Moreover, this problem is made even more complex by the fact that those domains may be operated by different operators and tenants.³²

These works are however complementary to ours, as the interaction between consumers and Registry and Exposure functions can be made secure with state of the art solutions for authentication and encryption.

A work similar to ours is the one in Reference 31 which, however, focuses on just the core domain, enhancing the current NWDAF-based solution. Still, one of the most important areas of interest for network exposure research is the one targeting service providers, as discussed in Reference 33. As we also discuss in our experiment, exposure functionality for autonomous networking is very beneficial for private deployment of 5G networks, where service providers can create control loops between application and network deployments.

4.1 Capability registration, discovery, and exposure through the inter-domain bus

Enabling closed control loops among different domains means enabling a flexible way of exchanging capabilities among them. This goes beyond the current standard architectures, which often rely on a standalone design in each individual domain, not fully capitalizing on possible advantages discussed in Section 3. Our proposed architecture thus adapts, extends, and integrates current service-based approaches for different domains (ie, the 5GC, the 5G Management System, and ETSI NFV MANO) by means of an inter-domain message bus that connects them, enabling the capability exposure and consumption across domains. All the domains that use capability exposure interface the inter-domain bus with two types of functions, that is, they shall be included in each of them: the capability registration and discovery function and the exposure function:

The capability registration and discovery function (CRDF) provides a registration service for available capabilities within each domain and, if required, also capabilities exposed by other domains using the inter-domain bus. It maintains a list of registered capabilities and responds to the service discovery inquiries from the consumers in its domain. The CRDF also acts as a proxy for discovery requests, when these are targeting capabilities that are available outside the source domain. Capabilities can be listed using a taxonomy such as the one we propose in this article, following an approach similar to the one used by NWDAF to list the available analytics within the 5G Core domain, and implemented using frameworks such as the OpenAPI⁶ one.

The exposure function makes a capability available to other consumers both within the same domain (as it is partially the case with state-of-the-art technologies) and to other domains. The exposure function can enable access-controlled communication across different domains.

The aforementioned functionality has to be provided within all the domains. In the 3GPP CN domain, NRF and NEF already provide similar features within the CN and between the CN domain and Service Provider domain (for instance, to allow data collection from application to the NWDAF or analytics exposure from NWDAF to the application), so they have to be extended to support the access by other capability consuming functions (CCF) from other domains and allow the exposure toward them. For the radio access network domain, O-RAN architecture already realizes selected features of the proposed framework. However, O-RAN does not provide exposure, registration, and discovery functions beyond the interfaces toward the orchestration domain. Additionally, other open source implementations of the RAN network functions, such as OpenAirInterface (OAI) are also not providing this kind of functionality.³⁹ Thus, the exposure, registration, and discovery functions can be implemented through specific applications from the non-real-time controller that then interfaces with the other (both real-time and nonreal-time) applications. The RAN bus can also interface with the (virtualized) access domain functions, for example, the centralized unit (CU) of the 3GPP architecture, compare Figure 4.

On the network management side, an existing module in the 3GPP architecture (ie, the Exposure Governance Management Function, EGMF) can be extended in a similar way as the NEF (ie, to support the exposure of capabilities to other domains). Nevertheless, an additional registration module needs to be included, as it is currently not (yet) specified by 3GPP SA5 in the required manner. Then, these elements interact with other management entities through the Service-Based Management Architecture (SBMA) bus.

The orchestration domain, as specified by standard developing organization such as ETSI NFV, currently does not provide an exposure and registration functionality. Hence, such functionality needs to be added entirely to this domain. Also, as the ETSI NFV architecture currently uses peer-to-peer reference points, we envision an orchestration bus to provide capability consumption within the domain. This includes elements such as NFVO, VNFM, and VIM, but also SDN controllers and WAN controllers.

Finally, in the service provider/vertical domain, these elements will need to be added as well to support the proposed architecture framework vision. This could enable, for example, analytics exposure between the service provider domain and the network domains. As discussed before, an additional capability registration and discovery function, operating at intra-domain level may be added. This allows registering functions of each domain making them mutually discoverable. Alternatively, registration and discovery functions of each domain can discover themselves dynamically through the inter-domain bus.

The most similar concept compared to ours is the one promoted by ETSI ZSM,⁴⁰ through the integration fabric across different orchestrators. However, there are two fundamental differences between our proposal and the work done by ETSI ZSM: (i) the ZSM proposal mostly focuses on the synchronization between management, orchestration, and network control, while we also include user plane functions and, especially, service providers. As discussed previously, the openness of the system toward service providers is a fundamental feature for next generation networks. Then, (ii) ETSI ZSM proposal is highly hierarchical, with the management domain playing a master role in the system: our framework instead fosters an open exchange among domains, leveraging network programmability concepts, without a predominant role of the party that operates the management domain.

4.2 Procedures

In the following, we briefly discuss how the most fundamental procedures can be achieved using the proposed architecture.

Capabilities (de)registration: The registration functions that operate in each domain take care of maintaining a current list of consumable capabilities. Thus, the APIs register, deregister, update, and notify, shall be extended with the capabilities that have to be registered. These APIs shall be available also on the inter-domain bus.

Routing, forwarding, and load balancing: In order to support the mechanisms discussed previously, the CRDFs and the exposure functions perform request routing and forwarding of capability discovery or consumption requests across the domains. Then, the final capability exposure will happen directly between the different entities: if end-to-end connectivity is available, then the communication is direct, otherwise, the registration functions of the two domains take care of routing this traffic as well. Finally, CRDFs and exposure functions of each domain handle load balancing by pointing the requests to the final instance of the NFs following for example, a round-robin policy.

The consumption procedure may happen in two ways: the exposure function can directly hand off the capability consumption to the consumer function or handle it directly. In the latter case, as the complexity is handled by the exposure function, no protocol translation is required among domains (which use the exposure function as proxy).

Access control: Authentication and authorization of CCFs: Capability discovery and consumption requests are handled in the first place by the CRDF, which keeps the authorization information regarding CCFs for each registered capability. Such capability authorization information is configured as one of the components of the registration profile of capability producer in CRDF. The profile should include the CCF type(s) and CCF realms (the domain of origin) that are allowed to consume the registered capability. Moreover, CRDF also performs CCF authentication in order to verify the identity of the requesting entity, for example, using Extensible Authentication Protocol (EAP). This latter point is of particular importance when different service providers want to gain access to the capability exposure (which may be part of a subscription plan offered by the network operator).

5.1 Edge applications for service provider integration

This use case describes a scenario where an edge application such as one of the proposed by the ETSI multiaccess edge computing (MEC)⁴¹ shall interact with a 3GPP network. Here, cell trace data are produced in the RAN domain and first consumed by a management domain function. There, data is further enhanced, for example, by means of data analytics, which allows for offering an according management domain capability. This can then be consumed by entities outside the 3GPP operator domain, for example, an Edge Application in the service provider/vertical domain. To this end, we take the trace management as an example to illustrate a functional interaction.

5.2 An enriched interface for service providers

In the following, we exemplify this with a video streaming service provider using a richer interface that introduces several advantages compared to OTT operation, (following the steps depicted in Figure 5).

In this case, three domains (the network functions, the management, and the orchestration) are still under the same stakeholder (ie, the network operator) which offers access to the inter-domain bus (through, eg, an IP network) to the vertical service provider.

Thus, the service provider can subscribe to continuous monitoring (capability type 1, steps 5-12 in Figure 5) from the Orchestration and Network Functions domain to observe the current KPI and map them with QoE metrics available at the application layer.

The service provider also subscribes to dynamic SLA events (capability type 2) coming from the operator BSS Management, which informs about different subscription options. For instance, the Video Service Provider could be offering the service using a “Silver” plan subscription, and the Operator could offer an upgrade to a “Gold” plan (with the information of the increased cost and the QoS improvements) or the downgrade to a cheaper and less powerful plan.

Finally, through re-orchestration suggestions (Capability type 4), the service provider has access to a rich version of the traditional OTT paradigm, and also go beyond the NSaaS paradigm. So, the service provider (by accessing the configuration parameters, offered through the capability type 2, steps 1-4 in Figure 5) can apply its business logic, taking re-orchestration and dynamic SLA decisions based also on metrics such as the current revenue flows, the subscribers' churn rate or the expected popularity of a video.

5.3 Enhanced radio management system

5G is meant to support use cases where mission-critical communication, such as remote vehicle control, is done through the 5G network. These types of use cases require very high reliability from the network, as delay or loss of information could lead to fatal accidents. One of the main causes of service degradation in mobile networks are shadowing effects, which occur from the movement of the UEs and unfavorable conditions in their environment. These degradations need to be prevented or accounted for to achieve high reliability. Currently, much of the necessary knowledge (prediction of UE movements and radio conditions) resides in the management domain. Hence, the RAN domain cannot use this information to rapidly adjust the configuration of the radio link.

For improving radio coverage, 5G-NR supports various forms of beamforming. This capability allows the radio network to dynamically change the radio coverage to focus on hotspots, or low visibility areas in order to boost signal strength, overcoming interference or environmental shadowing effects. In order to combine management-domain analytics capabilities with (radio) network-domain beam control capabilities, we propose here an enhanced radio management system that considers a few targeted high-importance users, whose radio metrics are exposed to the management domain. In the management domain, an AI-based module performs medium to long term prediction of the radio conditions for each user, that are hence exposed back to the network function domain (the radio network, in this case) to perform beamforming reconfiguration and proactively mitigate shadowing effects.

6.1 The PLANAR testbed

The PLANAR concept is envisioned to be used in a smaller scale, privately-owned campus networks, such as factories, however many of the used interfaces can be extended to support any kind of Non Public Network (NPN) scenario. In NPN scenarios, the creation of a digital twin of the network (such as the one deployed for PLANAR) is likely possible, as the network is deployed in a limited area with available detailed information about the layout of the environment (such as a digital 3D floorplan). However, a specificity of the PLANAR framework is the one related to coverage, as areas with limited coverage are not easily fixed by additional cells, because of cost constraints, interference considerations, or dynamically changing environments, with shadowing objects moving around.

The testbed consisted of two cells, both housed in the Heinrich Hertz tower, overlooking the port of Hamburg, each using four beams (as depicted in Figure 6). Because the cells were covering the relatively large area from a single direction, some sections of the port's waterways were occluded by large buildings, cranes, or the terrain. When barges ventured into these areas, emission sensor readings would often be delayed or completely lost.

6.2 PLANAR implementation

Before discussing the need for enhanced network exposure, we first introduce the implementation of PLANAR from a system-level perspective, discussing the algorithmic choices behind it. The PLANAR system relies on an AI module that collects, merges, and analyzes data from different domains in order to predict the above-mentioned service impairments, such as radio quality indicators and position of the terminals. As a matter of fact, prior research involving the prediction of RSRP (reference signal received power) or other radio quality KPIs approach this problem as a time-series prediction. Works such as References 43 and 44 try to predict from highly granular measurements, frequently from a single domain, utilizing the same KPIs that were predicted without additional contextual information (such as location). Since the radio quality is subject to rapid changes both in time and in space, these time-series prediction-based approaches are only able to predict radio quality for a short timeframe forward, usually on the scale of a few hundred milliseconds to a few seconds. This short timeframe is not enough to undertake the larger-scale network reconfigurations that we envisioned for PLANAR, such as power control and beam re-configuration.

For longer predictions, the predictive system has to take into account data that allows the isolation of the noise-like variance from the actual cause of the radio quality changes. As mentioned earlier, the biggest cause of radio quality degradation is environmental shadowing,⁴⁵ which occurs when the UEs move behind large objects. Longer-term prediction of radio link quality can be achieved by splitting the task: first, the location of the users is predicted precisely far in the future and using this predicted location the expected radio quality is inferred through a location-dependent model of the radio environment.

6.2.2 PLANAR machine learning

Using the recorded locations, an MPP (mobility pattern prediction) module was created using a deep CNN (convolutional neural network)⁴⁶ to predict the movement of the barges. The input to the MPP consisted of a fixed-length sequence of historical locations of one of the barges, up to the most recent location. The output was a fixed-length prediction of future locations the barge will visit. The deep CNN was able to learn context-dependent routes around the port, such as recognizing when a barge was aligning to the shore for docking, and correctly predicting its movement even in this unusual situation (Figure 7). The MPP module is our own implementation, using the PyTorch library for the CNN implementation and hardware acceleration in the Python scripting language. The CNN is a 3-layer deep network, the architecture of which can be seen on Figure8⁷

To model the radio quality in a location-specific way, a digital twin of the city of Hamburg was created, complete with the precise modeling of buildings (including cranes and other large-scale equipment) and terrain. Using this digital twin and the radio quality measurements the barges collected, a model was fine-tuned to be able to precisely recreate the radio environment of the whole port. The digital twin is used as most of the physical systems that are deployed in the harbor and its surroundings cannot be constantly polled and measured by our system (such as the orientation of cranes, which heavily impact the radio signal quality). So, PLANAR builds on this model to have a reliable feedback of the channel quality along time, in addition to the live measurements.

Both the MPP and the model were implemented as separated AI modules in the management domain (Figure 9). After their training phases, the MPP module fed predicted location information to the model (intra-domain consumption of capability type 4), which gave the predicted radio quality as output. The model output is consumed by “actors” for NF control (inter-domain exposure and consumption of capability type 4), which changed the beam configuration and transmission power settings in the cells. These control functions do not only take as input predicted radio conditions from the model, but also feed the executed re-configurations back to it. All the communication between the different modules (which go beyond the interfaces defined by major SDOs), were implemented with ad-hoc Python modules.

Before enforcing the configuration in the network, we perform several training loops in the model, to make sure that the taken decisions are optimal in the whole network. For this purpose, we are not only taking into consideration the target barges but other users or the requirements of other slices in the network. Because the radio quality predictions were far ahead in the future, the actors had plenty of time to converge to a balanced configuration, at which point the configuration was deployed in the actual network.

Without realizing the capability exposure framework for the specific sea port setup, we could not have directly fed the PLANAR modules running in the management and NF domains, nor have interacted with the base stations deployed in the port. Without the secure, but open and uniform interfaces of the proposed framework, AI modules would have had to be placed in the service provider domain (ie, the port authority). The same would have been applied to the PLANAR Actors that control the beam adjustment. The chosen setup has allowed to include a broader set of data sources as well as a quicker and more effective reaction to events, as the individual control loop components could interact very seamlessly despite being placed in different domains: the PLANAR AI modules (MPP and the model) are directly deployed in the management domain and interact with the PLANAR actors as well as the data collectors implemented in the network functions domain).

While the implementation discussed in this article is limited in scope due to the constraints related to the real-world sea port testbed, the network exposure concept we discuss is widely applicable to any network deployment, including the public mobile networks providing, for example, network slicing capabilities.

6.3 Evaluation results

As discussed before, we evaluated PLANAR taking into account a subset of barges location traces that were not used for training, which were fed to our system that

recreated the real network conditions for these traces and by predicted and avoided service degradation for the barges. Out of the 493 RLF (radio link failure) events that may have been taking place in our validation data, only 12 were not detected using the farthest (ie, most future-looking) predictions, achieving a success rate. Later, as the barges got closer to the problematic areas, the incorrect predictions were also corrected, still before the actual RLF happened.

In Figure 10, an example of a prevented RLF is shown. The dark blue lines depict the actual measurements, while the light blue lines depict the predicted values as forecast 40 seconds before. In this example, one of the barges was on a trajectory that led behind a steep riverbank, which could have caused a complete radio link failure. The ship's route was immediately accurately predicted by the MPP module. Using this prediction, the RLF was avoided by increasing the serving beam's power and down tilting the beam to better target the ship.

Conceptually, the use of data from multiple domains in two separate modules (MPP and model) for the prediction of future network states has strong benefits. The proposed unified capability registration, discovery, and exposure framework allows for a modular setup, where multiple data sources and NF actors can be present in the system (and dynamically added/removed/reconfigured), each optimizing network parameters through relatively simple logic. By trying out configurations in the simulated environment first, the NF actors can converge to a mutually optimal solution, avoiding transient states in the actual network. However, all of this is not possible without a flexible, controllable data exchange between the different modules residing in different domains, as well as data gathered from the different layers and slices of the network.

6.4 Final considerations

The PLANAR system embodies the network capability exposure concepts discussed throughout this article, implementing the functions and procedures needed to enhance the state of the art technologies. PLANAR implements a subset of the full network exposure framework discussed in Section 3. Table 2 details the consumer and producer roles of the PLANAR components, depending on the capability needed for the use case. PLANAR eminently involves capability exposure at the management domain, as its goal is to optimize the long term behavior of the network, but also includes interactions toward the Network Functions domain as well as the Service Provider domain, where the data provisioning capabilities are produced by the systems and sensors of the port authority.

More specifically, PLANAR uses capabilities of all kinds for its operation. The first kind of exposed data is the monitoring of the signal quality from the gNB. Exposing such information is fundamental for the training of the model and it is currently not possible with the state-of-the-art architecture, which only provides slow file-transfer based solutions for the exposure of such data. Instead, by directly exposing such data to the management functions, even public cloud based machine learning platforms could be used (although this is not the case for the PLANAR implementation).

Similar considerations apply also for the data coming from the sensors, which belong to the service provider (in this case the Port of Hamburg). With an over the top solution, with sensor data fully confined in the operator premises and SNR data only available to the operator the PLANAR solution could not have been possible, with a lose-lose situation: the service provider had an overall worse coverage in the area, with a possibly higher deployment cost for the network operator.

Finally, the decisions taken by the PLANAR system need to be enforced: this involves the effective exposure of the QoS analytics from the service provider to the network operator that, in turn, offers the needed interfaces to effectively inject such decisions in the network functions through proper APIs toward the RAN NFs.