R0 MVP functional description




The Control component controls every other component in the Routing Manager by:

  • Initializing and configuring components (e.g. by providing parameters originally retrieved from environment variables)
  • Handling incoming events and data from components
  • Directing components to perform tasks on data (e.g. send an HTTP GET method, render the routing policies)
  • Keeping track of connections towards xApps (e.g. administering the context table)
  • Performing the activities above in a well defined way to realize the Routing Manager specific services (e.g. by implementing a finite state machine)

HTTP Client

The HTTP Client component contacts xApp Manager to retrieve the list of deployed xApps and their properties (which matter from routing point of view)

Routing Policy Engine

The Routing Policy Engine component generates the routing table based on the xApp list, retrieved from xApp Manager.


The Messaging component connects to the xApp instances, and sends the routing table.

Use cases


Periodic check

R0.1 functional description



New components

HTTP Server

The HTTP Server component is introduced as part of the Routing Manager's R0.1 architecture. The HTTP Server is responsible to:

  • Accept HTTP POST methods that are meant to provide callbacks with regards to xApp related changes

Changed components


The scope of Control component is extended with the introduction of HTTP Server and the callback mechanism:

  • Control has to launch HTTP Server and
  • Facilitate in the data flow related to incoming HTTP requests and
  • Take on an asynchronous behavior to implement the callback mechanism realized together with xApp Manager

HTTP Client

The scope of HTTP Client is extended with the capability to

  • Initate HTTP POST method towards xApp Manager in order to subscribe to xApp related events

Use Cases



Callback timeout

Invoked services

xApp Manager's subscription service


xApp Manager provides a subscription based service which enables the services user to subscribe for changes related to xApps' life-cycle. To invoke this service Routing Manager has to send a subscription request to xApp Manager in a form of an HTTP POST method with appropriate payload.

Subscription request and response

Routing Manager has to send the following HTTP POST method to subscribe to xApps's life-cycle related changes:

POST /ric/v1/subscriptions
  "targetUrl": "<scheme>://<Routing Manager's IP adress>/<Routing Manager API's basePath>/handles/xapp-handle/",
  "eventType": "all",
  "maxRetries": 5,
  "retryTimer": 10

Please note that the scheme is going to be http until further notice. Routing Manager's basePath (based on Routing Manager's Swagger API definition) is /v1.

A successful response to Routing Manager's Subscription Request could be the following example:

200 OK
  "id": "1ILBltYYzEGzWRrVPZKmuUmhwcc",
  "version": 0,
  "eventType": "all"

Provided services

Routing Manager's callback service

Routing Manager provides a callback service to let xApp Manager to notify about xApp related changes. The service is based on a HTTP-based RESTful API.

Callback request and response

To notify Routing Manager about xApp related changes, xApp Manager has to initiate a HTTP POST method on Routing Manager's HTTP-based RESTful API:

POST /<Routing Manager API's basePath>/handles/xapp-handle/
  "id": "1ILBltYYzEGzWRrVPZKmuUmhwcc",
  "event": "created",
  "version": 1,
  data: "[
             "name": "xapp-dummy",
             "status": "unknown",
             "version": "1.2.3",
             "instances": [
               "name": "xapp-dummy-6cd577d9-4v255",
               "status": "pending",
               "ip": "",
               "port": 32300,
               "txMessages": [
               "rxMessages": [

Routing Manager would respond to such POST method with the following:

201 Created
  • No labels

1 Comment

  1. Hi, Abdul Wahid W

    I'm working in Samsung, and also currently investigating a1 mediator. (Our corp email seems somehow does not allowing the confirmation email for the signing up, so I signed up with external email.)

    I found out that rtmgr is adding the subId for xApp in to the table separately every time when the xApp being onboarded.

    So, if the xApps are subscribing on the same subid(a.k.a Policy type id in a1mediator which osc implemented), same message type & sub id are being registered on the separate line.

    And also when if A1 mediator sends rmr meesage to xApps, rmr library sends only to the first encountered endpoint in the loop.

    Which means that the other xApp on the other line on the table can not receive the RMR message.

    We are guessing that it is one of these 2 cases.

    The first case is that xApp is intended to be onboarded per usecases. So it may only subscribe there own unique policy type id.

    And another case we are guessing is that it might can be a bug.

    May I ask you how rtmgr should work when multiple xApp are subscribing the same subId?

    Thank you in advance.