Zero-trust service management and orchestration service

Abstract

According to an example method for maintaining security in a radio access network, RAN, in an entity operating within a Service Management and Orchestration, SMO, framework, traffic and / or data generated within the SMO framework by at least one SMO service (SMOS) is monitored, and anomaly detection is performed, based on the monitored traffic and / or data. Further, a security alert is triggered and / or a security operation is carried out, based on the anomaly detection.

Description

[0001] ZERO-TRUST SERVICE MANAGEMENT AND ORCHESTRATION SERVICE

[0002] TECHNICAL FIELD

[0003] This disclosure is directed to techniques for maintaining security in a radio access network (RAN) in an entity operating within a Service Management and Orchestration (SMO) framework.

[0004] BACKGROUND

[0005] The need for flexibility and scalability of cloud services in Radio Access Networks (RAN) operations is increasing. Vendors are looking to cloud-based RAN solutions to offer the openness and flexibility that operators and new verticals require. The Service Management and Orchestration (SMO) platforms and the RAN intelligent controller (RIC) architecture, which are both standardized by the O-RAN Alliance, are fundamental to creating an open framework designed to further improve the cost-effectiveness of Open RAN, as well as to expand supply chain diversity and promote innovation.

[0006] The Open RAN architecture introduces two new types of automation applications: rApps, which are specialized microservices running as functions of the Non-Real-Time (Non-RT) RAN Intelligent Controller (RIC); and xApps, running as functions of the (near-)Real-Time (RT) RIC. Today, rApps mainly interact with SMO through API services exposed at the R1 interface. An rApp subscribes to specific services (either consuming services or publishing services). The RT RIC handles events requiring action on a real-time or near-real-time basis, e.g., from 10 milliseconds (ms) to 1 second, and provides policy guidance back to the non-RT RIC through xApps. xApps operate to enhance the performance of the RAN, e.g., its spectrum efficiency.

[0007] The Service Management and Orchestration (SMO) framework has been developed to provide functionality for managing and maintainingthe RAN. Functions performed within the SMO framework include RAN configuration, inventory, topology, and orchestration policy, as well as Fault, Configuration, Accounting, Performance, Security (FCAPS) management. The SMO framework has the capability to retrieve data from the 5G Core network and other external data sources, which makes it a powerful information (intelligence) repository where analytic capabilities can be applied to improve the performance and security of Open-RAN network functions and cloud infrastructure.

[0008] The SMO incorporates functions named rApps, special applications that support RAN services and optimization procedures. rApps can be native from the SMO vendor or developed by third parties. The SMO contains SMO services (SMOS), which are a cohesive set of management, orchestration, and automation capabilities. These are realized via SMO functions. A document published by the O-RAN Alliance and titled “Decoupled SMO Architecture, ’’Technical Report, O- RAN Alliance, July 2024, provides further details.

[0009] The SMO is responsible for RAN domain management, as discussed in the O-RAN Alliance document, “O-RAN Architecture Description,” 2022. Key capabilities of the SMO that provide RAN support in O-RAN are:

[0010] • FCAPS interface to O-RAN Network Functions

[0011] • Non-RT RIC, with rApps, for RAN optimization

[0012] • O-Cloud Management, Orchestration and Workflow Management

[0013] • Service Exposure between producers and consumers

[0014] • Data Exposure between producers and consumers

[0015] The SMO is a centralized point in the O-RAN architecture that collects Fault Management (FM), Performance Management (PM), and Configuration Management (CM) data from O-RAN Cloudnative Network Functions (CNFs), using the O1 interface, and Fault, Configuration, Accounting, Performance, and Security (FCAPS) data from O-Cloud, using the 02 interface. Logs are also collected at the SMO. This data is collected from all O-RAN vendors deployed in a multi-vendor network. This data can be leveraged by a SMOS or rApp to detect security events and CNFs and the underlying O-Cloud infrastructure.

[0016] The O-RAN Alliance is conscious that there are several potential SMO services and SMO functions, which can be implemented in different ways by SMO vendors, operators, and third parties. Recently, the O-RAN Alliance has provided an improved O-RAN SMO service-based architecture with service-based interface to support multi-vendor interoperability. Some SMO Services have been identified but notyet specified in O-RAN. Figure 1 shows this proposition. Security is not yet a defined SMO service. This creates a gap, and potential security risks, in SMO solutions and O-RAN network deployments.

[0017] Securing the internal and external assets and traffic for the SMO is of high importance because the SMO is responsible for all service management and orchestration across the O-RAN architecture. (See the O-RAN Alliance document, “Study on Security for Service Management and Orchestration (SMO),” 2023.) The SMO can be used to enhance RAN security, but it should be properly secured as well, so a threat actor cannot take control of the RAN and use it as entry point to attack RAN components or to move laterally towards the 5G core. (See S. Poretsky and J. Jardal, “Why SMO provides an ideal platform for intelligent Open RAN security,” 2023.) In patent publication number W02023007452A1 , the SMO and other monitoring entities are used to deploy time-sensitive Self Organizing Network (SON) functional elements to E2 nodes via E2 interface. This publication does not address the security of the SMO itself or the traffic that is being exchanged between the SMOSs.

[0018] In patent publication number EP4122169A1 , the SMO entity uses a trained AI / ML model (within the SMO entity) and the non-RT RIC to transfer configuration parameters to a near-RT RIC. The publication does not address the security of the SMO itself or the traffic that is being exchanged between the SMOSs, or the usage of AI / ML to achieve this end.

[0019] In patent publication number US20210337420A1 , the SMO and the non-RT RIC collect and process RAN data and non-RAN data and, during a data transfer phase, transfer processed data to an external AI / ML server via an interface. During a training model input phase, the SMO entity receives a trained AI / ML model, metadata, and training results from the external AI / ML server via an interface. During a configuration phase, the SMO entity uses the trained AI / ML model within the SMO entity and the non-RT RIC to transfer configuration parameters to a near- RT RIC. The publication does not address the security of the SMO itself or the traffic that is being exchanged between the SMOSs, or the usage of AI / ML to achieve this end.

[0020] SUMMARY

[0021] As demonstrated above, existing publications regarding the SMO do not consider network security for the SMO or the traffic that is exchanged among their internal components.

[0022] Moreover, they do not address the Zero Trust Architecture (ZTA) paradigm, particularly its Tenet 4 (dynamic policy) and Tenet 5 (continuous monitoring). (See “Zero Trust Architecture,” NIST SP 800-207, US NIST, Aug. 2020.) Adopting the ZTA paradigm is key to achieve the target security posture of the O-RAN architecture.

[0023] From an architectural point of view, the O-RAN Alliance technical report on Decoupled SMO lacks a security mechanism to guarantee the trustworthiness of internal / external data traffic and the trustworthiness of the rApps / services inside it, which can be provided by third party vendors. In simple terms, the SMO cannot automatically trust the data or the rApps or the SMO functions (provided by different solution providers) that are inside of it. In addition, the SMO has interactions with external components, and the trustworthiness of those interactions must be assessed before granting access. For this, the Zero Trust paradigm should be adopted. Thus, a key motivation for this disclosure is to add the Zero Trust paradigm to the SMO, which can contribute to achieve these security objectives. This disclosure focuses on solutions to address Tenet 4 (dynamic policy) and Tenet 5 (continuous monitoring) implemented in the SMO as cornerstones to enhance O-RAN security. Another important ZTA principle is covered by Tenet 7 (data collection), which is already addressed by the RAN NF OAM SMOS, and is leveraged for the solutions described herein.

[0024] Embodiments described herein provide SMO Services (SMOS) for security to achieve a ZTA (ZT- SMOS) within the SMO framework, with the following functionality:

[0025] • Continuous monitoring of the traffic between SMOS and rApps on the SMOS internal communication based interface. This is consistent with NIST Zero Trust Tenet 5.

[0026] • Continuous monitoring of the data collected by other SMOS, including the RAN NF OAM SMOS and RAN Analytics SMOS.

[0027] • Anomaly detection due to external and internal threats to the O-RAN deployment. Anomalies can be internal to the SMO, external to O-RAN, O-Cloud, or other O-RAN network functions.

[0028] • Detection of security events using Al-based decision-making and the AI / ML Workflow SMOS.

[0029] • Alerting of security events

[0030] • Triggering of dynamic policy, leveraging the PM I SMOS, to respond to a security event. Policy is pushed across the A1 interface via the Non-RT RIC. This is consistent with NIST Zero Trust Tenet 4.

[0031] The techniques described herein satisfy NIST ZTA tenets 4, for dynamic policy, and 5 for continuous monitoring, and CISA Cybersecurity Framework (CSF) core functions to Detect and Respond. Thanks to these functionalities, the disclosed solutions address external and internal threats, which must be considered to achieve a ZTA:

[0032] • External threats coming from external interfaces (that connect to external systems), addressing the use case when the SMO acts as a consumer of those external systems. Specifically, external systems can be (i) security monitoring and intelligence entities (SIEM, activity logs, threat intelligence); (ii) Operation, Administration and Management (OAM) entities that issue configuration commands to implement / instantiate something; and (iii) AI / ML training data, its enrichment information, and ML models that are consumed and imported into the SMO. This is crucial to detect attempts to poison internal ML data.

[0033] • Internal threats to the SMO from SMO Services, including rApps. • Internal threats to the O-RAN deployment from O-RAN architectural elements such as O-Cloud and O-RAN Network Functions. Broad visibility across the O-RAN deployment, including O-Cloud enables detection of many security events, including lateral movement.

[0034] Methods described in detail below include an example method for maintaining security in a RAN, as implemented in an entity operating within an SMO framework, and includes the steps of monitoring traffic and / or data generated within the SMO framework by at least one SMO service (SMOS) and performing anomaly detection, based on the monitored traffic and / or data. The method further comprises triggering a security alert and / or carrying out a security operation, based on said anomaly detection.

[0035] Corresponding apparatuses and systems are also described in detail below, including apparatuses for maintaining security in a RAN, in an entity operating within an SMO framework. An example apparatus comprises at least one processing circuit and memory operatively coupled to the at least one processing circuit, where the memory comprises program code for execution by the at least one processing circuity. The apparatus is thereby configured to monitor traffic and / or data generated within the SMO framework by at least one SMO service (SMOS) and perform anomaly detection, based on the monitored traffic and / or data. The apparatus is further configured to trigger a security alert and / or carrying out a security operation, based on said anomaly detection.

[0036] Other embodiments and advantages flowing from these and others of the disclosed embodiments are described in further detail below and illustrated in the attached figures.

[0037] BRIEF DESCRIPTION OFTHE FIGURES

[0038] Figure 1 illustrates the decoupled SMO architecture, per the O-RAN Alliance.

[0039] Figure 2 shows the decoupled SMO architecture with a ZT-SMO service (ZT-SMOS), according to some embodiments.

[0040] Figure 3 illustrates the ZTO-SMOS and important interactions, according to some embodiments.

[0041] Figure 4 illustrates continuous monitoring within the SMO framework.

[0042] Figure 5 shows anomaly detection within the SMO framework, based on the continuous monitoring. Figure 6 is a sequence diagram illustrating how the ZT-SMOS can provide input to an artificial intelligence / machine-learning (AI / ML) workflow, according to some embodiments.

[0043] Figure 7 shows authentication, authorization, and health verification of input data in the ZT- SMOS.

[0044] Figure 8 illustrates features of an example implementation of an AI / ML-based process.

[0045] Figure 9 shows policy updating within the SMO framework, based on anomaly detection.

[0046] Figure 10 is a diagram of an example sequence for policy updating.

[0047] Figure 11 illustrates an example of policy enforcement, at the A1 interface.

[0048] Figure 12 is a diagram of an example sequence for policy enforcement.

[0049] Figure 13 illustrates two alternatives for implementation of the ZT-SMOS in the SMO.

[0050] Figure 14 shows possible vendor implementation of an SMO Function.

[0051] Figure 15 is a process flow diagram illustrating an example method according to some embodiments.

[0052] Figure 16 is a block diagram illustrating an example apparatus for maintaining security, according to some embodiments.

[0053] DETAILED DESCRIPTION

[0054] In International Patent Application publication no. WO2024 / 03812, authors address Tenet 6 of the Zero Trust concept, as described in “Zero Trust Architecture,” NIST SP 800-207, US NIST, Aug. 2020. To address this requirement, certain network functions (NFs) need to implement extra functions to comply with Zero Trust Architecture (ZTA) requirements. ZT requires other controls to measure and verify trust of the NFs. But, it is desirable to not break existing standards by adding new interfaces or functionalities. Thus, the idea discussed in this publication is to verify the revocation status of client / server certificates before connectivity. The Network Repository Function (NRF) can be used to validate authorization, which can help to validate other ZTA controls, e.g., by extending the functionality of Online Certificate Status Protocol (OCSP) and Certificate Revocation Lists (CRL). A trust policy can be enforced based on the Certificate status of a NF. In our approach, besides being focused on the SMO (key entity in O-RAN), we propose a procedure to assure that the interaction with external systems complies with a certain policy via control points, and enforcement points. This is not written in O-RAN specifications and constitutes improvement of the architecture from a security point of view.

[0055] The ZTA may be extended to the SMO framework by placing a Zero-Trust SMO Service (ZT-SMOS) inside the SMO, with the other SMOS along the SMO Internal Communication Service Based Interface (SBI). This is shown in Figure 2. The ZT-SMOS may also be implemented as an rApp anchored in the Non-Real-Time RAN Intelligent Controller (Non-RT-RIC ) internal to the SMO. If a rApp is used, it should include R1 service support, and it can communicate with other rApps (e.g., from another vendor) directly.

[0056] Figure 3 shows, in a simplified manner, where the ZT-SMO Service sits in the architecture and the elements it interacts with to perform the intended functionality. The ZT-SMOS for Continuous Monitoring has some or all of the following functions, in various embodiments:

[0057] • performs continuous monitoring from SMOS of interest to have access to traffic and characteristics of the requests by a consumer SMOS ( SMOSc) towards a provider SMOS (SMOSp).

[0058] • performs anomaly detection, (leveraging information collected from the RAN NF OAM, RAN Analytics) using ML models and ML workflow, supported by policy information.

[0059] • triggers a security event and issues alert.

[0060] • informs the PMI for Dynamic Policy.

[0061] The ZT-SMOS for Dynamic Policy has some or all of the following functions, in various embodiments:

[0062] • reaches a policy decision.

[0063] • updates the Service Management and Exposure (SME) SMOS to quarantine (block) a “risky” SMOS or external entity from producing or consuming services from other SMOS.

[0064] • updates the Data Management (DME) SMOS to quarantine (block) a “risky” SMOS or external entity from producing or consuming data from other SMOS.

[0065] • updates the Non-RT RIC to push policy to O-RAN network functions via the A1 interface to the Near-RT RIC to block access to a UE, network peer, or management system.

[0066] Key interactions of an example ZT-SMO Service are described in detail below.

[0067] Continuous monitoring - Continuous monitoring is necessary to have a ZT paradigm and to collect the information needed for anomaly detection and interaction authorization, e.g., using a machine-learning (ML) model. To make this happen, step 1 of an example process, as shown in Figure 4 shows the flows of traffic from key SMOS that the ZT-SMO uses. Continuous monitoring is performed for internal SMO traffic and SMOS behavior to detect security events internal to the SMO. This is particularly important in a SMO service-based architecture that enables multi-vendor SMO. Continuous monitoring is also performed on the FM, PM, and CM data collected from cloud-native network functions (CNFs) and FCAPS data collected from O- Cloud to detect security events across the O-RAN architecture. Security events detectable as anomalies can include supply chain attacks, advanced persistent threats, volumetric DDoS attacks, unauthorized access. The ZTA-SMO can detect and respond to lateral movement by a threat actor across O-Cloud, CNFs, and SMO.

[0068] Important KPIs to be maintained across the SMO SBI are:

[0069] • Endpoint IP addresses

[0070] • Protocols

[0071] • Session rate

[0072] • Session volume

[0073] • Packet rate

[0074] • Packet volume

[0075] • Important data to be collected (and not excluded to) are:

[0076] • Authentication credentials

[0077] • Token information

[0078] • Target API endpoint

[0079] • Type of operation, e.g., create, read, update, delete (CRUD)

[0080] • Role Based Access Control (RBAC) - Identity and Access Management (IAM) information of the consumer

[0081] • Resource availability

[0082] • Content (Payload)

[0083] • Type of service

[0084] • Contextual - environmental information, such as time of day, location of request.

[0085] • Results from vulnerability databases.

[0086] • API vulnerability testing and auditing results

[0087] • Important log data to be collected (and not excluded to) are:

[0088] • Authentication attempts

[0089] • Authentication failures

[0090] • Authorization attempts Authorization failures

[0091] This information is not currently specified in the O-RAN standards, but any or all these could be specified in future versions. Elements from this list could be added to O-RAN standards to implement ZTA based use cases to secure O-RAN from the SMO. As an example, 3GPP has technical specifications that stipulate mandatory input data, for example, 3GPP TS 28.552 (Management and orchestration; 5G performance measurements), 3GPP TS 28.554 (5G end to end Key Performance Indicators), TR 23.791 (Study of Enablers for Network Automation for 5G), and 3GPP TS 23.288 (Architecture enhancements for 5G System (5GS) to support network data analytics services). From an ML perspective, this input information can be classified as features for the ML models to be used.

[0092] Anomaly detection - In step 2 of an example process, the collected data is fed to the AI / ML workflow. Policy is fed to the AI / ML workflow, to inform the benchmarks and criteria to mark traffic or interactions as safe. Interactions according to this step are shown in Figure 5.

[0093] To succeed at this task, the ZT-SMO Service can provide input to the artificial intelligence / machine learning (AI / ML) workflow, for example: specifying the features that are necessary, suggesting an appropriate model according to the situation, and suggesting an update of the model in case the performance and accuracy decreases. These steps are part of the ML pipeline executed (partially) in the AI / ML Workflow SMOS. In the sequence diagram illustrated in Figure 6, the AI / ML workflow and how the ZT-SMO participates in the model selection, feature engineering and triggering improvements for the model are shown, according to policy. Note that steps of an ML pipeline are: data collection, data preprocessing, feature engineering, model selection, model training, model evaluation, model deployment, monitoring and maintenance.

[0094] It should be appreciated that suspicious behavior may be manifested directly in the type, frequency, and / or target of communications among the SMOS’s. For instance, an rApp contacting another SMOS in a frequent manner could suggest the beginnings of a reconnaissance attack, a security problem. If it is trying to access all other SMOS or rApps for information, suspicions may be raised further. Other anomalous behavior may be an rApp targeting a certain access request, e.g., in a very periodic or frequently repeated manner. Anomalous behavior relative to any one or more of the KPIs listed above may be detected, for example, or anomalous combinations of certain values or ranges of any two or more of these KPIs. A well-trained ML model may detect combinations of KPIs that are anomalous, for instance, where a human observer would be unable to discern an anomalous pattern.

[0095] A purpose and effect of the anomaly detection is to monitor the use of resources within the SMO, to detect potentially malicious behaviors. These resources, which may be monitored directly and / or indirectly, in various embodiments, include power usage, bandwidth, memory, etc. Excessive or otherwise anomalous usage by one or more SMOS’s, e.g., as implemented by one or more rApps, might reveal a malicious app, or perhaps an app that has been compromised and which may thus be a potential source of an internal attack.

[0096] An unusual frequency of requests from an rApp or other entity providing an SMOS to one or more other SMOS’s may suggest a malicious application. But, the monitoring of communications and the detection of anomalies is not limited to counting requests - other resource usages, such as CPU load, energy consumption may be reflected in other ways in the communications among the SMOS’s in the SMO, and another anomalous behaviors, such as a change in the target of communications by a particular SMOS, may indicate a possible security issue. In addition, it is not only new applications that need to be monitored - a particular rApp or other SMOS may be trusted for a time and subsequently compromised - by observing its parameters (operational, behavior), this compromising can be detected, and the app then viewed as a potential threat, e.g., as a source of a denial-of-service (DoS) attack withing the SMO.

[0097] If anomalous usage in the consumption of resources, (including energy, bandwidth, CPU load, etc.), an app or other SMOS with the anomalous use of resources can be isolated. This is a resource-centric view of the monitoring and anomaly detection described herein. The logic is “monitoring the resources used for SMOS” - the anomaly is found at the resource level but otherwise communications may look normal at the application / service level. Nevertheless, it may be necessary to isolate those resources on which multiple SMOS are running.

[0098] As a more concrete view of this anomaly detection phase, a possible approach to implementation can be based on three tasks: (1) authentication, authorization, and health verification; (2) aggregation and result; and (3) decision. This breakdown of the tasks is shown in Figure 7.

[0099] Authentication, authorization, and health verification -The ZT-SMOS captures the input information (features) provided by other information systems and managers. Then, the ZT-SMOS evaluates those inputs against information systems and existing M L models. The evaluation and assessment occur in parallel, resulting in a score for each feature. The information is processed as information becomes available or updated. This is important since networks are dynamic, and measurements from these features are updated by managers as soon as possible. There is “no waiting” or “data sync” to have all parameters with fresh data at a certain point of time and continue the process. The steps are executed as information arrives. Here, data comes in a stream, collected as much as possible, in order to do the corresponding calculations in the following steps.

[0100] Figure 7 portrays an example of the input data; other input data of various types can be processed in the same way. While the details of the score calculation method are outside the scope of this disclosure, security management systems can derive a score according to various pre-established methodologies, leveraging industry best practices, standard guidance, etc.

[0101] Once the score is calculated, the ML model may provide a confidence level for every score, which may go leaning to 0 or 1 (this means it is not absolute 0 or 1 ), for example. Again, details of the confidence level calculation are outside the scope of this disclosure: like the case of the score calculation, a security management system can provide this value, leveraging historical data, current configurations, and well-known ML techniques. Historical confidence level values are important for prediction of this parameter in further steps. This confidence level will show the probability that the input / feature complies with a certain safe reference, so the incoming information is catalogued as adequate for storage and consumption by the SMO.

[0102] Aggregation and result -All scores and confidence levels are aggregated into one. Methods to do so include averaging values, calculating a weighted average, or calculating custom values, e.g., according to the interests and priorities of the operator. This aggregated value provides a global view of the health / safe status of the incoming information to the ZT-SMOS. There is a configurable safety threshold for these values, so a communication service provider (CSP) can adjust it as needed, permitting it to take risk-based decisions according to it. Having this threshold value set, the whole process can occur without human intervention, due to the nature of the information received by the ZT-SMOS, which must be processed without delay.

[0103] Decision - Finally, the ZT-SMOS decides, according to the score, confidence level, and the threshold from the operator, whether incoming information to the ZT-SMOS is safe to be stored into the Security Data Repository and consumed by the internal SMOF.

[0104] Figure 8 provides insights about the rationale behind the three-step process described above.

[0105] The process has two different dimensions, in time and in features. The features, which are the input data to the model, can arrive at different times, i.e., in an asynchronous way. A batch of time series embeddings may be taken, and well-known machine-learning algorithms applied. They are aggregated as part of the machine-learning process, to then carry on the score calculations and confidence level calculation, the latter of which describes the probability that the score is correct. This process results in output, which may take the form of a classification indicatingwhether the input data to the SMO is benign or dangerous and an indication of the probability that that the classification is correct. Techniques for designing, training, and applying machine-learning models to real-world data elements are well known. For example, the feasibility of performing network intrusion detection using machine-learning is demonstrated in C. M. K. Ho, K.-C. Yow, Z. Zhu, and S. Aravamuthan, “Network Intrusion Detection via Flow-to-lmage Conversion and Vision Transformer Classification,” IEEE Access, vol. 10, pp. 97780-97793, 2022, doi: 10.1109 / ACCESS.2022.3200034.

[0106] Policy update - If required, step 3 of the overall process discussed above consists of an update of policy. It is important to update security requirements or rules according to the environmental status of the SMO and its interactions. Figure 9 illustrates an example of this.

[0107] One example for the use of this step relates to the detection of an interference in the RAN. The ZT-SMO leverages the data that has been collected and information gathered from the outputs of the AI / ML workflow service. It triggers the modification of the policy in the PM I and triggers its enforcement via the A1 interface. This is shown in the sequence diagram of Figure 10

[0108] An example policy for a base station may be represented as [BS_ID: 10; BS_FR: n1], where this example policy Indicates that base station 10 uses a frequency band n1 (FDD 2100 MHz). In the case interference is detected, an updated policy might be represented as [BS_ID: 10; BS_FR: n7], which indicates that base station 10 uses a different frequency band n1 (FDD 2600 MHz). Evidently, there must be an internal verification that the new operational band is free for use and free of interference, prior to updating the policy.

[0109] Enforcement - Step 4 of the overall process covers the reception of results from the AI / ML workflow SMOS. Results involve predictions about a certain feature of interest. For example, it can involve signaling an anomalous behavior of a certain interaction or traffic. In step 5, the ZT- SMO enforces a decision to the A1 Policy Management service, to act over the A1 interface. In a similar way, the SMO may enforce a decision to a SMOSp to act over requests from a SMOSc (not depicted). Figure 11 shows an example process for these steps. A detailed flow is shown in Figure 12. As seen here, the ZT-SMO queries the AI / ML workflow SMOS for predictions about a certain feature (radio interference, anomalous traffic for its detection, among others). According to policy provided by the PMI, the ZT-SMO can enforce a security policy and action to stop the threat.

[0110] The solutions described herein may be deployed according to at least two deployment options. First, the solution may be implemented as an rApp SMOS anchored in the Non-RT RIC. Second, the solution may be implemented as an SMOS. Figure 13 illustrates these scenarios.

[0111] The proposed ZT-SMOS for Continuous Monitoring and Dynamic Policy may also be bundled by a vendor as a SMO Function (SMOF), as shown in Figure 14.

[0112] In view of the detailed examples and explanation provided above, Figure 15 will be understood to illustrate an example method for maintaining security in a RAN, in an entity operating within a SMO framework. The method shown in Figure 15 is intended to be a generalization of and to encompass the techniques described above, and thus where the terminology used in Figure 15 and below differs from that used above, the former should be understood to at least encompass the corresponding terminology used above.

[0113] As shown at block 1510, the illustrated method comprises the step of monitoring traffic and / or data generated within the SMO framework by at least one SMO service (SMOS). The SMOS or SMOS’s being monitored may be implemented by an rApp or rAPPs, in some embodiments. Note that the term “monitoring,” as used herein, refers to an ongoing evaluation of the traffic and / or data generated within the SMO framework. While not necessarily strictly continuous, this monitoring takes place over an extended period of time, e.g. seconds, minutes, etc., and thus involves repeated evaluations of the data and / or traffic, as opposed to a one-shot collection and evaluation of information.

[0114] As shown at block 1520, the method further comprises the step of performing anomaly detection, based on the monitored traffic and / or data. As shown at block 1530, the method still further comprises the step or steps of triggering a security alert and / or carrying out a security operation, based on the anomaly detection.

[0115] In some embodiments or instances, the method comprises enforcing a security policy on the A1 interface between the SMO and a near-real-time RAN intelligent controller, based on the anomaly detection. In these and in some other embodiments, the monitoring of traffic and / or data shown in block 1520 comprises monitoring SMOS communication traffic. The SMOS communication traffic may comprise one or more of: traffic on an SMOS communication bus within the SMO framework; traffic exchanged in a mesh network within the SMO framework; and traffic exchanged via one or more point-to-point interfaces within the SMO framework.

[0116] In some embodiments or instances, the method comprises informing a dynamic policy management function of the security alert. In some of these embodiments or instances, the method comprises the dynamic policy management function updating a security policy or rule in response to the security alert. As an example, updating the security requirement or rule may comprise quarantining at least one SMOS operating within the SMO service, where the quarantining blocks service discovery for the quarantined SMOS. As another example, updating the security requirement or rule may comprise updating a policy so as to block access to one or more of any of a LIE, network node, NF, and management system.

[0117] In some embodiments or instances, performing anomaly detection, as shown at block 1520, comprises providing at least a portion of the monitored traffic and / or data to at least one machine-learning (ML) model that has been trained on data collected from and / or representative of operation of the RAN.

[0118] In some embodiments or instances, the monitoring of traffic and / or data shown at block 1510 comprises monitoring one or more of any of the following parameters relating to the at least one SMOS: endpoint Internet Protocol (IP) addresses utilized by the at least one SMOS; a protocol employed by the at least one SMOS; a session rate for the at least one SMOS; a session volume for the at least one SMOS; a packet rate for the at least one SMOS; a packet volume for the at least one SMOS; and log events, CM, FM, and / or PM data from network functions (NFs).

[0119] In some of these and in some other embodiments, the monitoring of traffic and / or data comprises monitoring one or more of any of the following parameters relating to the at least one SMOS: authentication credentials applied by or to the at least one SMS; token information; a target API endpoint; a type of operation; a resource availability; a traffic content; a type of service; contextual and / or environmental information; results from vulnerability databases; API vulnerability testing and auditing results; number of authentication attempts; number of authentication failures; number of authorization attempts; and number of authorization failures.

[0120] In some embodiments of the method shown in Figure 15 and its variants, the entity operating within the SMO framework is an SMOS. In some embodiments, the entity operating within the SMO framework is an rApp anchored in a non-real-time (non-RT) RAN Intelligent Control (RIC). Figure 16 is a block diagram illustrating an example apparatus for maintaining security in a RAN, within an SMO framework. Apparatus 1610, which may be configured to carry out one or more of the methods described above may be or comprise various combinations of hardware and / or software, including a standalone server, a blade server, a cloud-implemented server, a distributed server, a virtual machine, container, or processing resources in a server farm.

[0121] Apparatus 1600 includes processing circuitry 1602 that is operatively coupled via a bus 1604 to an input / output interface 1606, a network interface 1608, a power source 1610, and a memory 1612. Other components may be included in other embodiments.

[0122] The memory 1612 may include one or more computer programs including one or more application programs 1614 and data 1616. Embodiments of the host 1600 may utilize only a subset or all of the components shown. In some embodiments, application programs 1614 may be implemented in a container-based architecture.

[0123] In various embodiments, the memory 1612 comprises program code for execution by at least one processing circuit of the apparatus, whereby the apparatus is configured to monitor traffic and / or data generated within the SMO framework by at least one SMO service (SMOS), and perform anomaly detection, based on the monitored traffic and / or data. The at least one processing circuit may be further configured to trigger a security alert and / or carry out a security operation, based on the anomaly detection.

[0124] In some embodiments or instances, the apparatus is configured to enforce a security policy on the A1 interface between the SMO and a near-real-time RAN intelligent controller, based on the anomaly detection. In some of these and in some other embodiments or instances, the apparatus may be configured to monitor traffic and / or data by monitoring SMOS communication traffic, where the SMOS communication traffic comprises one or more of: traffic on an SMOS communication bus within the SMO framework; traffic exchanged in a mesh network within the SMO framework; and traffic exchanged via one or more point-to-point interfaces within the SMO framework.

[0125] In some embodiments, the apparatus may be configured to inform a dynamic policy management function of the security alert. The dynamic policy management function may be configured to update a security policy or rule in response to the security alert, for instance. In some instances or embodiments, updatingthe security requirement or rule may comprise quarantining at least one SMOS operating within the SMO service, where this quarantining blocks service discovery for the quarantined SMOS. In some of these and in some other embodiments or instances, updating the security requirement or rule may comprise updating a policy so as to block access to one or more of any of a UE, network node, NF, or management system.

[0126] In some example embodiments or instances, the apparatus is configured to perform anomaly detection by providing at least a portion of the monitored traffic and / or data to at least one ML model that has been trained on data collected from and / or representative of operation of the RAN.

[0127] In various embodiments or instances, the apparatus may be configured to monitor one or more of any of the following parameters relating to the at least one SMOS: endpoint Internet Protocol, IP, addresses utilized by the at least one SMOS; a protocol employed by the at least one SMOS; a session rate for the at least one SMOS; a session volume for the at least one SMOS; a packet rate for the at least one SMOS; a packet volume for the at least one SMOS; and log events, CM, FM, and / or PM data from network functions (NFs).

[0128] In various embodiments or instances or embodiments, the apparatus may be configured to monitor one or more of any of the following parameters relating to the at least one SMOS: authentication credentials applied by or to the at least one SMS; token information; a target API endpoint; a type of operation; a resource availability; a traffic content; a type of service; contextual and / or environmental information; results from vulnerability databases; API vulnerability testing and auditing results; number of authentication attempts; number of authentication failures; number of authorization attempts; and number of authorization failures.

[0129] The foregoing merely illustrates the principles of the disclosure. Various modifications and alterations to the described embodiments will be apparent to those skilled in the art in view of the teachings herein. It will thus be appreciated that those skilled in the art will be able to devise numerous systems, arrangements, and procedures that, although not explicitly shown or described herein, embody the principles of the disclosure and can be thus within the spirit and scope of the disclosure. Various embodiments can be used together with one another, as well as interchangeably therewith, as should be understood by those having ordinary skill in the art.

[0130] The term unit, as used herein, can have conventional meaning in the field of electronics, electrical devices and / or electronic devices and can include, for example, electrical and / or electronic circuitry, devices, modules, processors, memories, logic solid state and / or discrete devices, computer programs or instructions for carrying out respective tasks, procedures, computations, outputs, and / or displaying functions, and so on, as such as those that are described herein.

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

[0132] As described herein, device and / or apparatus can be represented by a semiconductor chip, a chipset, or a (hardware) module comprising such chip orchipset; this, however, does not exclude the possibility that a functionality of a device or apparatus, instead of being hardware implemented, be implemented as a software module such as a computer program or a computer program product comprising executable software code portions for execution or being run on a processor. Furthermore, functionality of a device or apparatus can be implemented by any combination of hardware and software. A device or apparatus can also be regarded as an assembly of multiple devices and / or apparatuses, whether functionally in cooperation with or independently of each other. Moreover, devices and apparatuses can be implemented in a distributed fashion throughout a system, so long as the functionality of the device or apparatus is preserved. Such and similar principles are considered as known to a skilled person.

[0133] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. It will be further understood that terms used herein should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

[0134] In addition, certain terms used in the present disclosure, including the specification, drawings and embodiments thereof, can be used synonymously in certain instances, including, but not limited to, e.g., data and information. It should be understood that, while these words and / or other words that can be synonymous to one another, can be used synonymously herein, that there can be instances when such words can be intended to not be used synonymously. Further, to the extent that the prior art knowledge has not been explicitly incorporated by reference herein above, it is explicitly incorporated herein in its entirety. All publications referenced are incorporated herein by reference in their entireties.

Claims

CLAIMS1 . A method for maintaining security in a radio access network, RAN, in an entity operating within a Service Management and Orchestration, SMO, framework, the method comprising: monitoring traffic and / or data generated within the SMO framework by at least one SMO service (SMOS); performing anomaly detection, based on the monitored traffic and / or data; and triggering a security alert and / or carrying out a security operation, based on said anomaly detection.

2. The method of claim 1 , wherein the method comprises, based on the anomaly detection, enforcing a security policy on the A1 interface between the SMO and a near-real-time RAN intelligent controller.

3. The method of claim 1 or 2, wherein said monitoring traffic and / or data comprises monitoring SMOS communication traffic, wherein the SMOS communication traffic comprises one or more of: traffic on an SMOS communication bus within the SMO framework; traffic exchanged in a mesh network within the SMO framework; and traffic exchanged via one or more point-to-point interfaces within the SMO framework.

4. The method of any one of claims 1-3, wherein the method comprises: informing a dynamic policy management function of the security alert.

5. The method of claim 4, wherein the method comprises the dynamic policy management function updating a security policy or rule in response to the security alert.

6. The method of claim 5, wherein updating the security requirement or rule comprises quarantining at least one SMOS operating within the SMO service, wherein said quarantining blocks service discovery for the quarantined SMOS.

7. The method of claim 5 or 6, wherein updating the security requirement or rule comprises updating a policy so as to block access to one or more of any of a user equipment, UE, network node or network function, NF, or management system.

8. The method of any one of claims 1-7, wherein performing anomaly detection comprises providing at least a portion of the monitored traffic and / or data to at least one machine-learning, ML, model, trained on data collected from and / or representative of operation of the RAN.

9. The method of any one of claims 1-8, wherein said monitoring traffic and / or data comprises monitoring one or more of any of the following parameters relating to the at least one SMOS: endpoint Internet Protocol, IP, addresses utilized by the at least one SMOS; a protocol employed by the at least one SMOS; a session rate for the at least one SMOS a session volume for the at least one SMOS; a packet rate for the at least one SMOS; a packet volume for the at least one SMOS; and log events, CM, FM, and / or PM data from network functions (NFs).

10. The method of any one of claims 1-9, wherein said monitoring traffic and / or data comprises monitoring one or more of any of the following parameters relating to the at least one SMOS: authentication credentials applied by or to the at least one SMS; token information; a target API endpoint; a type of operation; a resource availability; a traffic content; a type of service; contextual and / or environmental information; results from vulnerability databases;API vulnerability testing and auditing results; number of authentication attempts; number of authentication failures; number of authorization attempts; and number of authorization failures.11 . The method of any one of claims 1 -10, wherein said performing anomaly detection comprises detecting anomalous use of one or more of any of the following resources by the at least one SMOS: central-processing-unit, CPU, resources; memory resources; and energy resources.

12. The method of any one of claims 1-11 , wherein the entity operating within the SMO framework is an SMOS.

13. The method of any one of claims 1-11 , wherein the entity operating within the SMO framework is an rApp anchored in a non-real-time (non-RT) RAN Intelligent Control (RIC).

14. An apparatus for maintaining security in a radio access network, RAN, within a Service Management and Orchestration, SMO, framework, the apparatus comprising: at least one processing circuit; and memory operatively coupled to the at least one processing circuit; the memory comprising program code for execution by the at least one processing circuit whereby the apparatus is configured to: monitor traffic and / or data generated within the SMO framework by at least one SMO service (SMOS); perform anomaly detection, based on the monitored traffic and / or data; and trigger a security alert and / or carry out a security operation, based on said anomaly detection.

15. The apparatus of claim 14, wherein the apparatus is configured to, based on the anomaly detection, enforce a security policy on the A1 interface between the SMO and a near-real-time RAN intelligent controller.

16. The apparatus of claim 14 or 15, wherein the apparatus is configured to monitor traffic and / or data by monitoring SMOS communication traffic, wherein the SMOS communication traffic comprises one or more of: traffic on an SMOS communication bus within the SMO framework; traffic exchanged in a mesh network within the SMO framework; andtraffic exchanged via one or more point-to-point interfaces within the SMO framework.

17. The apparatus of any one of claims 14-16, wherein the apparatus is configured to: inform a dynamic policy management function of the security alert.

18. The apparatus of claim 17, wherein the dynamic policy management function is configured to update a security policy or rule in response to the security alert.

19. The apparatus of claim 18, wherein updating the security requirement or rule comprises quarantining at least one SMOS operating within the SMO service, wherein said quarantining blocks service discovery for the quarantined SMOS.

20. The apparatus of claim 18 or 19, wherein updating the security requirement or rule comprises updating a policy so as to block access to one or more of any of a user equipment, UE, network node or network function, NF, or management system.21 . The apparatus of any one of claims 14-20, wherein the apparatus is configured to perform anomaly detection by providing at least a portion of the monitored traffic and / or data to at least one machine-learning, ML, model, trained on data collected from and / or representative of operation of the RAN.

22. The apparatus of any one of claims 14-21 , wherein the apparatus is configured to monitor one or more of any of the following parameters relating to the at least one SMOS: endpoint Internet Protocol, IP, addresses utilized by the at least one SMOS; a protocol employed by the at least one SMOS; a session rate for the at least one SMOS; a session volume for the at least one SMOS; a packet rate for the at least one SMOS; a packet volume for the at least one SMOS; and log events, CM, FM, and / or PM data from network functions (NFs).

23. The apparatus of any one of claims 14-22, wherein the apparatus is configured to monitor one or more of any of the following parameters relating to the at least one SMOS: authentication credentials applied by or to the at least one SMS;token information; a target API endpoint; a type of operation; a resource availability; a traffic content; a type of service; contextual and / or environmental information; results from vulnerability databases;API vulnerability testing and auditing results; number of authentication attempts; number of authentication failures; number of authorization attempts; and number of authorization failures.

24. The apparatus of any one of claims 14-23, wherein said performing anomaly detection comprises detecting anomalous use of one or more of any of the following resources by the at least one SMOS: central-processing-unit, CPU, resources; memory resources; and energy resources.

Images