Skip to content

1. Writing the xApp Core in a different language

We have built the xApp Framework with the objective to simplify the development of xApps for developers. Hence, most of the lower level details of the xApps interfaces with the dRAX RIC are abstracted into simpler and easy to use methods. These methods are implemented using the xApp Library, which was written in Python. The xApp Library and the developer code are then located inside the xApp Core, a Docker image which containirizes the code in a environment with all the prerequisites installed. The xApp Core, song with the xApp Database, are then deployed using the xApp Helm Chart, which takes care of automating the deployment, by for example discovering the URLs and ports used by the dRAX RIC. That way the developer does not need to worry about such details.

However, if the developer wishes, the xApp can be written in any other programming language, and can be deployed in any other form that suits the developer. The developer, in that case, needs to implement all the necessary functionality to interface with the dRAX RIC alone. Here, we briefly summarize the different approaches and what the developer, beside the functionality and algorithm they bring, need to implement for the xApp to work properly with the dRAX RIC.

1.1 Changing the xApp Library - Using a different programming language

The developer can write an equivalent of the xApp Library in a different programming language. This means that the developer will need to define the following:

  • A Kafka client: A Kafka client which is used to receive or send data from/to the dRAX RIC Databus. The developer also needs to properly configure the client, set the Kafka URL, port, etc. used by the Kafka in the dRAX RIC.
  • A NATS client: The dRAX RIC also has a NATS databus. Hence, the developer needs to have a NATS client, properly configured to send or receive data to/from it. Of course the developer might not need to use the NATS databus, but just the Kafka one, in which case this component becomes optional.
  • A REDIS client: As the xApp uses REDIS as its xApp Database, the xApp should have a REDIS client to interface to this database. The developer has to properly configure thai client as well. Of course, the developer can choose not to have a xApp Database (a scenario we will explain later), so this is optional
  • An API client: To communicate to the dRAX RIC API Gateway, the xApp needs an API client. The developer needs to take care of properly configuring the client.
  • NetConf client: If the developer wants to communicate to the NetConf servers in dRAX via the NetConf protocol, a NetConf client is needed. Again, the developer also needs to take care of the configuration of the client.
  • A protobuf client: The dRAX Commands, such as the handover and sub-band masking one, are issued by creating a protobuf message and sending it via NATS tpo the correct topic. The developer would need to create the protobuf message based on the proto definition of thos messages, have a properly configured NATS client to send that messages, and finally know the topic on NATS where the message needs to be sent.
  • An API: The xApp needs to have API endpoints, especially the /config and /metadata which are used by the dRAX Dashboard to configure the xApp. Hence, the developer needs to create such endpoints for their xApp. If these are not present, compatibility with teh dRAX Dashboard cannot be achieved.

Of course, each of the components is optional, depending on what the xApp is supposed to do.

Once the xApp is written in another language, the developer also needs to take care of generating the xApp Core Docker image, which we will explain in the following subsection. The developer may also choose to run its xApp locally, without integrating it into the Kubernetes where dRAX is running, however the support for such a scenario is limited. For example, the dRAX Dashboard will not be able to discover the xApp, hence it will not appear in the dRAX Dashboard. You will not be able to configure the xApp via the dashboard or via the API endpoints.

1.2 Changing the xApp Core

The developer is free to take the Dockerfile and Dockerfile.dev from the xApp framework as a starting point to generate their own xApp Core. The developer is in charge of creating the xApp Core that has all the requirements installed to run the xApp they have created in another language.

1.3 Changing the xApp Helm Chart

Once an xApp Core Docker image is generated, the developer is in charge of editing the Helm Chart to include this new xApp Core Docker image. This can be as simple as changing the image.repository field in the values.yaml file. However, if additional information needs to be passed to the xApp Core Docker image on deployment, the developer has to edit the Helm Chart manually.

1.4 Changing the whole xApp Framework

The developer may also choose to run the xApp in a completely different way, and not use any of the xApp Framework blocks. In this case, the developer needs to take care of where the xApp is deployed, and how it would integrate into dRAX. If the xApp is run locally, without integrating it into the Kubernetes where dRAX is running, the support for such a scenario is limited. For example, the dRAX Dashboard will not be able to discover the xApp, hence it will not appear in the dRAX Dashboard. You will not be able to configure the xApp via the dashboard or via the API endpoints.

If the xApp developer chooses to run the xApp inside Kubernetes, the developer is in charge of setting up the proper labels for the pods, in order for the dRAX Dashboard to discover the xApp. For the pods, they should have the following additional labels:

drax/role: xapp
drax/xapp-name: xapp-name
xapp/mode: Production # or Developer in case the xApp is in development

For the Kubernetes Services, besides the same labels as for the pods, we add the component name:

drax/role: xapp
drax/xapp-name: xapp-name
xapp/mode: Production # or Developer in case the xApp is in development
drax/xapp-component-name: xapp-dev-ssh

NOTE: The xApp framework has some default services, such as the service where its own API is exposed, the optional development mode ssh service, etc. All this is up to the developer to implement.

NOTE 2: Note that the API endpoints of the xApp such as /config and /metadata are required for proper functionality with the dRAX Dashboard. Hence the developer needs to implement the equivalents, and provide the same information as described in the xApp Configuration In-depth section.