Anomaly Detection in Offshore Open Radio Access Network Using Long Short-Term Memory Models on a Novel Artificial Intelligence-Driven Cloud-Native Data Platform

The RAN is a critical component of a typical mobile communication network, enabling UE to connect to the core network, which then delivers services to users. The evolution of wireless communication systems from 1G to 5G highlights increasing modularity and virtualization of network functionalities.

Key advancements in RAN architecture include distributed RAN (D-RAN), centralized (or Cloud) RAN (C-RAN), and virtual RAN (vRAN). The distinctions among these architectures are detailed in [11].

In the 3GPP 5G new radio (NR) specifications, the traditional base station (BS) is composed of three main components: the centralized unit (CU), distributed unit (DU), and radio unit (RU). The CU and DU together perform the functions of the baseband unit (BBU), while the RU is responsible for signal conversion and radio frequency (RF) transmission.

O-RAN aims to address vendor lock-in issues by promoting the decoupling of hardware and software. This approach advocates for open, standardized interfaces, virtualized network elements, and white-box hardware, driven by principles of intelligence and openness. By doing so, O-RAN seeks to transform the RAN industry, fostering a more flexible and interoperable ecosystem.

AI is becoming increasingly important in O-RAN compared to traditional RAN due to its capability to address complex network demands and enhance overall performance. Several key aspects benefit from the integration of AI [4, 15]:

• •

  Reducing Complexity: O-RAN networks have a more complex, disaggregated architecture compared to traditional RAN, making manual management and optimization more challenging. Also, building traditional applications that process the data will be challenging. AI algorithms can automate and optimize these processes. it also compensates for the shortage of skilled engineers to manage such novel networks [15].

• •

  Real-Time capability: The new O-RAN architecture supports Real-time and near real-time RIC allowing AI algorithms to respond to network changes in real-time, allowing for more efficient and effective management of the network, like traffic steering [16].

• •

  Cross-Layer Optimization: The intelligence executed in O-RAN is expected to perform cross-layer optimization over the network, which outperforms the classical optimization focusing on solely communication blocks.

• •

  Future Possibilities: The programmability, openness, and disaggregation enable opportunities for innovation especially when utilizing AI. One of the most important ideas that will change the shape of networks is autonomous management which will provide advanced capabilities compared to the traditional methods. Some of these capabilities are as follows:

  • –

    Improved Network Performance: AI-based algorithms can be used to optimize network performance by dynamically allocating network resources and adjusting network parameters based on real-time network conditions such as autonomous QoE and QoS resource optimization [4, 15].

  • –

    Cost Savings: By fitting autonomous network management in O-RAN, this will reduce the need for human intervention to manage the complex networks, being an essential concept to scale up the number of O-RAN networks and their size. It will also provide additional means to reduce cost by deploying specific AI applications such as automatic energy-saving applications and efficient resource utilization  [17].

  • –

    Energy Efficiency Improvement: The AI capability embedded in O-RAN will be assisting in reducing the overall operational energy consumption of the O-RAN system. Apart from the software design of optimizing the network elements and control signal configuration, with AI, more flexible and fine-grained network function operation methods can be supported, for instance, the toggling off and on of carriers and cells in O-RAN can be conducted in the RIC with a non-real-time fashion [18].

In summary, the use of AI in O-RAN allows for more powerful automation, optimization, and insights compared to traditional RAN, making it a key enabler for the development and growth of the O-RAN market [19, 20, 21, 22, 23].

In this publication, in light of the authors’ engineering background, we focus on engineering challenges, notwithstanding the whole plethora of challenges related to legal, regulatory, business models, etc. As we progressed toward implementing AI in O-RAN, we encountered several hurdles and challenges:

• •

  Multi-vendor RAN Model: The multi-vendor model involves deploying and operating RAN equipment and software from different vendors within the same network. This raises significant challenges, especially in centralizing management and collecting data from these systems. Data integration becomes more difficult, delaying the development of AI applications. Additionally, having multiple O-RAN models can isolate each component, limiting the data available for building holistic applications.

• •

  Big Data Characteristics: O-RAN networks generate highly complex, diverse, and voluminous data, such as network performance data, configuration management data, fault management data, infrastructure data, and user equipment trace data. The big data characteristics of these data sources pose challenges in processing and analyzing information in real-time or in large volumes. Moreover, the varied structures and formats of data make integration into existing analytics platforms difficult. Consequently, many existing platforms may not meet the unique data requirements of O-RAN networks, slowing AI model development and complicating the integration of developed models with other O-RAN systems from different vendors.

• •

  Integration with Existing Systems: Building certain AI models with specific algorithms requires data from external sources not directly accessible to the O-RAN platform, such as UE and network functions of other domains such as transmission networks or core networks. This external data is essential for comprehensive analysis and characterization of performance across the overall network ecosystem but poses integration challenges.

• •

  Standardization: The lack of standardization in AI for O-RAN and RIC APIs presents significant challenges. There is no guarantee that developed xApps or rApps will be reusable across different RICs. Additionally, the industry is still in the early stages of establishing a centralized RIC system for the multi-vendor O-RAN model, further complicating standardization efforts.

• •

  Skilled Resources: Managing AI algorithms in O-RAN networks requires specialized skills and expertise, which may not be readily available in the market. A deep understanding of O-RAN is essential for those involved in AI development for O-RAN, making it difficult to find qualified personnel.

The primary challenge lies in the absence of suitable data analytics platforms capable of accommodating the distinct data needs of managing multiple O-RAN networks built using multiple O-RAN vendors. To overcome this obstacle, it is imperative to develop new data analytics platforms specifically designed to meet the unique data demands of O-RAN networks. These platforms must seamlessly integrate with existing O-RAN network systems and associated infrastructure components. They should have the ability to process and analyze vast quantities of complex and varied data to deliver use cases that depend both on real-time (or near-real-time) capabilities, and other use cases that are not real-time in nature, whilst facilitating the integration of data from other non-ORAN diverse sources.

Given that the approach to O-RAN is still an evolving technological concept there is ample opportunity to contribute to the development of more robust systems. These challenges have driven us to create a unique cloud-native data analytics platform. Our goal is to directly address these difficulties and provide an environment that supports the development and execution of AI applications within the O-RAN ecosystem.

Despite the layered depiction, the order or positioning of the layers does not necessarily indicate a hierarchy or sequence. Each layer can be accessed directly, independent of its position in the stack. The layers are broken down as follows:

The platform is designed to offer flexibility in working with O-RAN data and includes the following features and benefits:

• •

  Unification: The platform can collect, store, and process all types of data from various sources, regardless of volume, velocity, and variety, thanks to its modern open data architecture. This feature contributes to:

  • –

    The development of batch and real-time processing for network applications.

  • –

    Enabling data analysts to process and access data for advanced analytics tasks.

  • –

    Supporting the development and deployment of AI models, paving the way for advanced federated learning in multi-vendor networks.

  • –

    Handling operational needs ranging from reporting of complex processed metrics, performance, or fault events to interactive visualization with these dashboards and data cubes.

• •

  Cost-effective: Built on commodity servers, the platform leverages Kubernetes (K8s) container orchestration and other tools to simplify management, reducing the resources required. On the other hand, Using open data architecture and data lakehouse technology reduces costs by consolidating data, optimizing query performance, reducing bandwidth usage, leveraging scalable cloud storage, utilizing cost-effective open-source tools, and improving collaboration and usability.

• •

  Automation and Standardization: Using DevOps and GitOps [26] technologies, all infrastructure, setup, data, and AI pipelines are fully automated. This reduces the operational workload for development and deployment, making the development cycle predictable. Business owners can collaborate more effectively with developers to create solutions, ultimately reducing the resources needed.

• •

  Scalability: As the number of O-RAN networks deployed increases the platform’s scalability is crucial. It has been thoroughly evaluated to ensure it meets the increased demands for AI, data processing, and storage.

Fig. 5 depicts the architectural building blocks of the cloud-native data management platform. This platform is further detailed as follows.

The first tier, following a bottom-up order, contains the K8s infrastructure and its automation toolset. we utilized Terraform for defining and provisioning our infrastructure as code enabling efficient management and automation of infrastructure resources that run the operating system (second tier of the architecture) Talos OS. Talos OS is a modern, Linux-based operating system that is specifically designed for K8s. It provides a secure, minimal, and immutable platform to enhance security. Its major feature is that it automates and simplifies the management and operations of K8s clusters. On top of this, K8s is installed to deploy the microservices and applications that implement K8s cluster management functions and data management applicational system (this being the third tier). The following applications and services are implemented in the third tier:

Fig. 7 illustrates the use case of deploying a commercial O-RAN-based MPN in an offshore location, serving the UEs that are located in vessels that navigate around the windfarm attending to wind turbines for infrastructure operational and maintenance activities. These vessels spend most of the time navigating close to the windfarm and carry tens of people who work at sea for periods of 15 days. Therefore, these people rely on this connectivity to do their work, to communicate with their colleagues working onshore, their families, and for their entertainment. The connectivity provided by this network also supports business and operational critical processes to the organizations responsible for operating and maintaining the network, across an area of around 300 Km2. Many factors such as weather conditions, sea conditions, distance to the site, and MPN operational faults may affect the quality of the connectivity service as experienced by the end-users, which might impact the: ability of running business and operational critical processes work according to the requirements or the ability of people working productively in their floating offices. Despite these challenges, the MPN’s network operator is responsible for managing, operating, and maintaining the network’s performance as per the contracted service level agreement.

The problem addressed by the solution described in this paper occurred in an MPN service deployed by Boldyn Networks in a windfarm located in the North Sea. This network is composed of 3-cellular sites of 3 sectors each and one cellular carrier per sector, totaling 9 macro cells that cover the whole extension of the windfarm. Each cell operates in the LTE B3 and implements a 20MHz channel. The cellular sites are installed across the windfarm in three different turbines, where commercial-of-the-shelf (COTS) servers are used to run the containerized O-DU, and three O-RUs are installed to implement a sector each. The O-DUs deployed offshore connect, via dark-fibre light-up using long-haul SFPs, to an infrastructure of COTS servers that run the O-CU container. On the other hand, each relevant vessel’s network is composed of a Wi-Fi network that provides IP connectivity across the vessel. This Wi-Fi network connects to Boldyn’s customer premise equipment (CPE) that acts like an LTE broadband router back-hauling the vessels’ IP traffic to connect to the internet and the MPN customer’s enterprise network. This CPE is installed inside the vessel, near the bridge, and it’s connected to external 4x4 multiple-input-multiple-output (MIMO) antennae that increase the coverage and capacity of the network. Each CPE is dual-modem capable for connection resilience and traffic load balancing reasons and one MPN SIM is inserted in each modem. The problem resides in the connection recovery procedure implemented by the CPE when one of the modems drops its link to the LTE network. This procedure takes 5 minutes to re-establish an LTE connection to the macro network which is a long period of time and in some conditions increases the likelihood of disconnections occurring in both modems at the same time. In studying the problem, it was found the following:

• •

  These disconnections weren’t always correlated with the performance of the network, the radio link conditions, or the distance to the site.

• •

  It could be observed drift in the behavior of radio link performance, between the two modems of the CPE, verified by monitoring indicators such as latency and throughput even if most of the time these were connected to the same cell and benefiting from similar radio conditions.

• •

  Updating the configuration of the modem on the CPE via its API, forced the modem connection to restart and established a new radio link improving the performance of the modem in all the indicators.

• •

  The process of restarting the modem is much quicker to implement than the process of re-connection in case of radio link drop and has the additional advantage that can be done pre-emptively whilst the other modem is showing good performance.

• •

  The automation of this process of analysis and decision-making could reduce significantly the number of disconnections thus having a great impact on the quality of experience (QoE) of the users being served by the network system.

The automation of this process enabled us to develop a self-healing mechanism that implements an ML model, for the detection of the event of this type of performance anomaly in the modem, trained on available historical performance data merged with data that showed the timestamps where actions were taken to resolve the issue, which resulted in a set of labeled data emphasizing the relationship between patterns of behavior of the relevant performance indicators and the need for decision-making action. Some of the relevant performance indicators were reference signal received power (RSRP), reference signal received quality (RSRQ), IP packet data latency, timestamp, location, and cell to which the modem is connected to, and others from different parts of the network.

The process of collecting the data from the CPE device via the API every 5 seconds, preparing and enriching the data to stream this data to the application layer to be consumed by the ML model for online decision-making and direct provisioning, benefited from all the features and capabilities offered by the data management platform.

Network anomaly detection or prediction is a complicated task. Anomalies are referred to as patterns in data that do not conform to a well-defined characteristic of normal patterns. Anomalies can be classified into three types: (1) point anomaly can be considered as a particular data instance deviation from the normal pattern of the dataset; (2) contextual anomaly is defined when a data instance behaves anomalously in a particular context; (3) collective anomaly happens when a collection of similar data instances behave anomalously with respect to the entire dataset, the group of data instances is termed a collective anomaly [27]. Existing anomaly detection methods include NN, support vector machine or rule-based classification, statistical signal process method and clustering. In this case, the prediction task is based on the historical records of network states and automated actions, so it can be regarded as a point anomaly issue, and NN is the preferred method. Moreover, to exploit the temporal correlations of the historical samples, the LSTM is the selected learning model.

This case study has benefited from utilizing data from a real-life network based on O-RAN standards. The O-CU, O-DU, and O-RU provide FCAPS data, which describes network performance and operational behavior. This FCAPS data is a fundamental building block for the AI model’s development cycle, playing a crucial role in the training and validation process. Once deployed, the AI model uses this data for inference. Another important data source comes from the CPE equipment in the vessel, which provides measurements of the modem’s performance and its location as a time series, mapped with the FCAPS information collected from the O-RAN network.

The CPEs are at sea, and their location is monitored continuously. A couple of months of this data is shown in Fig. 8¹¹1The latitude and longitude values are removed for the consideration of the users privacy.. This data shows records of vessels connected to the network even when they are outside the coverage area. It contains many outliers that need to be removed, specifically those indicating locations far from the nearest site.

The development of the LSTM model adopts the manner of offline development and online deployment. The historical data stored by the platform is used for the model’s training. After the trained model meets the training criteria, the natural model will be deployed in the further step. Historical data includes two parts, the network state data and corresponding actions. Actions here are operations recorded by the engineers manually when the QoS is lower than the threshold. Some of the network state data is exported using the template shown in table 1, where WAN ID indicates the ID of the devices that need an action; the carrier is the carrier frequency; LTE-RSRP, LTE-SINR, LTE-RSRQ, Latency, Latitude and Longitude are UE related information; Time refers the timestamp for that record.

The next anomaly must be forecasted according to the hidden pattern of historical network state records, so a reasonable solution is to formalize a sequence prediction task, where multiple discrete records on sequential timestamps will be cascaded as one training sequence. Then these training sequences are labelled by using manual operations. The training sequence is labeled as ‘0’ if there is an action needed, otherwise, the label is ‘1’.

For the features in table 1, the WAN ID, LTE-RSRP, LTE-SINR, LTE-RSRQ, and Latency indicators are some of the taken features for training, while removing the carrier, latitude, and longitude because they are unlikely correlated with the occurrence of the anomaly. The recording interval of raw data is 5 seconds. Two months of records were stored and then processed in the cloud-native data platform. The data pre-processing process is illustrated in Fig. 9.

First, for the given raw dataset, there are some records missing. So, the process needs to pad these missing values and remove the records that are obviously out of the normal range. Then as a step of de-noising, the data is downsampled to $1/N$ of the initial one. Then assemble every $L$ sample as one training sequence. Lastly, the training sequence is labeled. It is worth mentioning that the criteria of labeling, are the manual actions taken by the engineer, which may lag over the first occurrence of the anomaly of $5$ to $20$ minutes. So, $10$ minutes is taken as the average delay applied to data labeling. The training sequence will be a matrix with size $1\times 5\times L$, and the labels will be binary values. In this use case, after validation, $N=2$ and $L=6$ are reasonable options.

The architecture of the NN model is depicted in Fig. 10, wherein the LSTM module inherits from the LSTM function in Pytorch and the input size equals $1\times 5\times 6$, hidden size equals 2. Two linear layers follow the LSTM module, and the output is the indicator of taking action or not. The last layer adopts the activation function ’sigmoid’.

For the model’s training, the training/validation dataset is divided according to the 80%/20% rule. The loss function is the binary cross entropy (BEC) [28]. The training is on the two RTX 2080Ti GPUs, the batch size is $2048$ and Adam is taken as the optimizer. In the batch sampling process, the weighted batch sampler is used because this dataset is an imbalanced dataset, which means that labels ’$1$’s are far more than labels ’$0$’s. The above training dataset is used to train the LSTM model, and the test set is used to evaluate the trained model. In the training stage, the training data is shuffled before batch sampling. Fig. 11 shows the model’s accuracy plots in the training and test. The convergence is reached after $100$ epochs.

The real-world deployment is relatively straightforward using the Boldyn data analytic platform. As illustrated in Fig. 4, the development happens in its application layer. In validation and deployment, the model is dockerized to an image and serves as a part of the DevOps pipeline and is hosted directly in the processing layer. This microservice continuously receives the real-time data and feeds it to the LSTM model. The generated actions will trigger the change in the networks. After deploying the model in production the complaints and network dis-connectivity decreased significantly to a very acceptable limit. Table 2 shows the improvement in the service performance and that validates the model in production.

It is evident that connectivity significantly improved due to proactive measures taken when the model identifies potential connection drops. This has effectively prevented simultaneous loss of connection for both modems. Occasionally, such drops occur concurrently due to weather conditions or specific spatial factors, albeit infrequently and under unique circumstances.

Due to the innovative nature of this research and the emerging O-RAN technology, there is currently no publicly available dataset that closely matches the specific requirements of our study. Consequently, the data used in this research is proprietary and was collected from real-world deployments by Boldyn Networks. This limitation underscores the need for future efforts to develop and share standardized datasets to facilitate broader validation and comparison of AI models in similar contexts.