E2 Service Model Abstraction

A radio access network (RAN) can comprise a type of broadband cellular communications network. An open radio access network (O-RAN) can comprise a system architecture for a RAN.

The following presents a simplified summary of the disclosed subject matter in order to provide a basic understanding of some of the various embodiments. This summary is not an extensive overview of the various embodiments. It is intended neither to identify key or critical elements of the various embodiments nor to delineate the scope of the various embodiments. Its sole purpose is to present some concepts of the disclosure in a streamlined form as a prelude to the more detailed description that is presented later.

An example system can operate as follows. The system can comprise a near real-time radio access network intelligent controller that comprises an application and a service model component, wherein the service model component is configured to receive respective indications of supported service models and key performance indicators from respective network nodes of a group of network nodes that is part of a radio access network, wherein the service model component is configured to receive a request from the application for a key performance indicator, wherein the service model component is configured to subscribe to a network node of the group of network nodes for the key performance indicator, wherein the network node supports a service model that is unsupported by the application and that is supported by the service model component, and wherein the key performance indicator is returned to the application via a communications protocol that is supported by the application.

An example method can comprise receiving, by a near real-time radio access network intelligent controller of a system comprising at least one processor, respective indications of supported service models and key performance indicators from respective network nodes of a group of network nodes in a radio access network. The method can further comprise receiving, by the by the near real-time radio access network intelligent controller, a request from an application of the near real-time radio access network intelligent controller for a key performance indicator. The method can further comprise subscribing, by the near real-time radio access network intelligent controller, to a network node of the group of network nodes for the key performance indicator, wherein the network node supports a service model that is unsupported by the application and that is supported by the near real-time radio access network intelligent controller. The method can further comprise returning, by the near real-time radio access network intelligent controller, the key performance indicator to the application.

An example non-transitory computer-readable medium can comprise instructions that, in response to execution, cause a system comprising a processor to perform operations. These operations can comprise receiving respective indications of supported service models and key performance indicators from respective network nodes of a group of network nodes. These operations can further comprise receiving a request from an application of the near real-time radio access network intelligent controller for a key performance indicator. These operations can further comprise subscribing to a network node of the group of network nodes for the key performance indicator. These operations can further comprise returning the key performance indicator to the application.

The present examples generally relate to broadband cellular communications, particularly fifth-generation (5G) networks. It can be appreciated that the present techniques can be applied to other types of cellular networks. An Open Radio Access Network (O-RAN) can comprise an implementation of a cellular network. An O-RAN can comprise a disaggregated network where different vendors are used to supply components such as a radio unit (RU), a distributed unit (DU), and a centralized unit (CU).

An O-RAN can comprise an E2 interface, which can comprise an open interface between two end points, such as a near-real time RAN intelligent controller (near-RT RIC) and E2 nodes (e.g., distributed units (DUs), centralized units (CUs), and e-NodeBs (eNBs, sometimes referred to as base stations)). An E2 interface can facilitate a RIC in controlling procedures and functionalities of E2 nodes.

In an O-RAN, rApps can comprise specialized microservices operating on a non-RT RIC. Then extended applications (xApps) can be hosted on a near-RT RIC, and optimize radio spectrum efficiency.

In a near real-time RIC, third parties can be allowed to design xApps that run on a RIC platform to optimize a RAN by subscribing to and analyzing data being reported by E2 nodes. In some examples, this data can be standardized and can be scattered across multiple service models, making it difficult to cover all bases, as it can be that E2 nodes might not support all versions of all service models.

However, an xApp may not be updated to be aware of newly available service models, and what parameters are available in them. This can cause a problem of interoperability issues between some xApps and some E2 nodes that might not support the service model the xApp expects, although the E2 nodes might still have the data the xApp needs.

The present techniques can be implemented to mitigate this problem. The present techniques can be implemented to facilitate abstracting service models from xApps, where xApps are concerned only with the parameters they need. This can involve implementing a service model abstraction layer and a service model calculator.

The service model (SM) abstraction layer can involve implementing a centralized service that gathers data on service models and versions, and maps out a compatibility between parameters across xApps and E2 nodes.

The service model calculator can comprise a service that is responsible for determining how each parameter can be derived—e.g., determine it from already-existing parameters, or by subscribing directly to it.

The present techniques can be implemented to facilitate an abstraction of an NRT-RIC service model from xApps, such that the xApps can be concerned with the parameters that they subscribe on rather than the service models themselves. This can facilitate removing service model version monitoring and interoperability efforts from an xApp development experience.

Beyond secure registrations by xApps, the present techniques can be implemented to facilitate an abstraction of an E2 service model within an NRT-RIC (from the perspective of an xApp). This can provide value in a form of an improved development experience, avoiding subscribing to data according to multiple service models, and instead communicating with an abstraction layer that provides one unified standard interface. This can mitigate against interoperability problems, where developers must monitor the version of the service models available at the E2 node, since the abstraction layer can handle the mapping of the requested data to the appropriate subscription messages following the SM version.

Additionally, the present techniques can provide value in cases where an xApp requires a KPI that is not directly offered by an E2 node, but is derivable from available parameters. In this case, the abstraction layer can determine the required KPIs, and the SM calculator can perform the derivation using the set of input KPIs.

An SM abstraction layer can operate as a platform function. Therefore, xApp developers intending to make use of the present techniques can follow a clear documentation on the messaging interface between a given xApp and said platform functions. A messaging protocol as described herein can be integrated as part of an xApp use case.

There can be problems with prior approaches. There can be problems relating to data collection limitations. RAN data can be scattered across multiple E2 service models (E2SM). It can be that, for an xApp to obtain a parameter, it must support that E2SM. For an xApp with complex logic and/or use-cases, it can be that the xApp must support a great number of E2 service models, and handle all those different subscriptions for those parameters.

xApps can limited to what E2 nodes support. In order to successfully obtain that information from the RAN, it can be that the E2 nodes must support those same exact E2 service models with the exact versions to be able to provide the xApp with any data.

There can be problems relating to interoperability limitations. That is, interoperability across vendors can be complicated since subscriptions can add an extra alignment step across the different vendors.

There can be problems related to xApp development limitations. It can be that xApp developers must have a knowledge of how the information they need is presented in particular E2 service models, and it can be that they must support all those E2 service models accordingly. Furthermore, it can be that xApp developers must stay up to date on any new version releases of the E2 service models post-development and even post-deployment to evaluate whether they need to upgrade or not.

illustrates an example system architecturethat can facilitate E2 service model abstraction, in accordance with an embodiment of this disclosure. In some examples, part(s) of system architecturecan be used by part(s) of system architectureofto facilitate E2 service model abstraction.

System architecturecomprises NRT-RIC, xApp, E2 node, and E2 service model abstraction component(which can implement part(s) of the present techniques).

It can be in system architecturethat xAppcan receive KPIs from E2 nodeonly where xAppand E2 nodeuse a same service model.

illustrates another example system architecturethat can facilitate E2 service model abstraction, in accordance with an embodiment of this disclosure.

An example system architecture that implements the present techniques can be as follows. A SMO can comprise a management and orchestration layer that controls configuration and automation aspects of RIC and RAN elements.

A controller can comprise a database, an xApp, a service model abstraction layer, and a service model calculator. The database can store data needed by a RIC, including information about a RAN, and can store KPIs. An xApp can comprise an application deployed in the RIC that handles optimizations for specific use cases.

A service model abstraction layer can map out E2 spec parameters across xApps and E2 nodes from different E2 service models and different versions of those models. The service model abstraction layer can maintain a relation between SM parameters, and send (at least some of) them to the SM calculator when a parameter is to be derived from other parameters.

A service model calculator can calculate requested parameters from already-available parameters that are exposed by E2 nodes and/or E2SMs.

A RAN can comprise a DU, a CU, and a RU as E2 nodes.

System architecturecomprises service management and orchestration (SMO), controller (RIC), xApp, database, service model abstraction layer, service model calculator, RAN, DU (cell)A, DU (cell)B, DU (cell)C, CU, RU, O1, E2, and E2 service model abstraction component(which can be similar to E2 service model abstraction componentof).

illustrates another example system architecturethat can facilitate E2 service model abstraction, in accordance with an embodiment of this disclosure. In some examples, part(s) of system architecturecan be used by part(s) of system architectureofto facilitate E2 service model abstraction.

Prior approaches can depend on E2 nodes advertising the exact E2 service models and versions they support through a RIC. Then, the xApps can use this information to subscribe to the nodes accordingly.

System architecturecomprises E2 node, RIC, xApp, and E2 service model abstraction component(which can be similar to E2 service model abstraction componentof).

In prior approaches, it can be that the subscribing xApp must support the same service model and version as the E2 node that the xApp is trying to subscribe to. So, it can be in system architecturethat xAppcan receive KPIs from E2 nodeonly where xAppand E2 nodeuse a same service model.

illustrates another example system architecturethat can facilitate E2 service model abstraction, in accordance with an embodiment of this disclosure. In some examples, part(s) of system architecturecan be used by part(s) of system architectureofto facilitate E2 service model abstraction.

System architecturecomprises NRT-RIC, xApp, e2 node, and E2 service model abstraction component(which can be similar to E2 service model abstraction componentof).

illustrates another example system architecturethat can facilitate E2 service model abstraction, in accordance with an embodiment of this disclosure. In some examples, part(s) of system architecturecan be used by part(s) of system architectureofto facilitate E2 service model abstraction.

System architecturecomprises NRT-RIC, xApp, e2 node, and E2 service model abstraction component(which can be similar to E2 service model abstraction componentof).

In prior approaches, it can be that, if the xApp supports a different service model, or even a different version of the same SM, the subscription is rejected.

illustrates another example system architecturethat can facilitate E2 service model abstraction, in accordance with an embodiment of this disclosure. In some examples, part(s) of system architecturecan be used by part(s) of system architectureofto facilitate E2 service model abstraction.

System architecturecomprises E2SM abstraction layerand calculator.

In some examples, the present techniques can be implemented as follows. xApps can be developed by third party software engineers, who can lack the knowledge to identify how to get the needed KPIs for the xApps. To alleviate this problem, the present techniques can be implemented to abstract the process of identifying the needed KPIs and identifying how to calculate these KPIs from existing KPIs. This solution can be based on creating a pipeline of components, such as the following.

An E2SM abstraction layer can be responsible for abstracting a process of getting the needed KPIs by the developers. It can be able to do so by fetching the needed KPIs from the E2 node and reporting them back to the xApp.

A calculator can be responsible for deriving the needed KPIs by the xApp from pre-existing KPIs that are supported by the E2SM abstraction layer.

The service model Abstraction Layer can abstract the service models from the xApps and allow xApp developers to focus on requesting KPIs rather than how to request them. This can allow xApps to work on an E2 Node regardless of what service model it supports, where the KPIs required by the xApps are available. The service model abstraction layer can comprise look-up tables that are passed KPIs, and service models supported by the E2 nodes, in order to identify O-RAN compliant KPIs that can be derived and are not directly available.

The service model abstraction layer can comprise a KPI-to-service-model component that converts KPI requests from an xApp into a subscription that fits the service models that are available in a corresponding E2 node.

illustrates another example system architecturethat can facilitate E2 service model abstraction, in accordance with an embodiment of this disclosure. In some examples, part(s) of system architecturecan be used by part(s) of system architectureofto facilitate E2 service model abstraction.

System architecturecomprises service model abstraction layer, KPI to service model, and LuT.

illustrates another example system architecturethat can facilitate E2 service model abstraction, in accordance with an embodiment of this disclosure. In some examples, part(s) of system architecturecan be used by part(s) of system architectureofto facilitate E2 service model abstraction.