Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • xapp_name: (REQUIRED) this is the unique identifier to address an xApp. A valid xApp descriptor must includes the xapp\_name attribute. The following is an example.

    Code Block
    "xapp_name": "example_xapp"


  • version: (REQUIRED) this is the semantic version number of the xApp descriptor. It defines the version numbers of the xApp artifacts (e.g., xApp helm charts) that will be generated from the xApp descriptor. Together with the xapp\_name, they defines the unique identifier of an xApp artifact that can be on-boarded, distributed and deployed. The following is an example.

    Code Block
    "version": "1.0.0"


  • containers: (REQUIRED) This section defines a list of containers that the xApp will run. For each container, a structure that defines the container name, image registry, image name, image tag, and the command that it runs is defined. The name and images are REQUIRED. The  command field is optional. The following is an example that defines two containers. 


  • Code Block
    "containers": [
        {
            "name": "example_container_1",
            "image": {
                "registry": "example_image_registry_1",
                "name": "example_image_name_1",
                "tag": "example_image_tag_1"
            },
            "command": "example_command_1"
        },
        {
            "name": "example_container_2",
            "image": {
                "registry": "example_image_registry_2",
                "name": "example_image_name_2",
                "tag": "example_image_tag_2"
            }
        }
    ]


  • controls: (OPTIONAL) The control section holds the internal configuration of the xApp. Therefore, this section is xApp specific. This section can include arbitrary number of xApp defined parameters. The xApp consumes the parameters by reading the xApp descriptor file that will be injected into the container as a JSON file. An environment variable XAPP_DESCRIPTOR_PATH will point to the directory where the JSON file is mounted inside the container. The following is an example.

    Code Block
        "controls": {
            "active": True,
            "requestorId": 66,
            "ranFunctionId": 1,
            "ricActionId": 0,
            "interfaceId": {
                "globalENBId": {
                    "plmnId": "310150",
                    "eNBId": 202251
                }
            }
        }


  • metrics: (OPTIONAL) The metrics section of the xApp descriptor holds information about metrics provided by the xApp. Each metrics item requires the \textit{objectName}, \textit{objectInstance}, \textit{name}, \textit{type} and \textit{description} of each counter. The metrics section is required by VESPA manager (RIC platform component) and the actual metrics data are exposed to external servers via Prometheus/VESPA interface. The following is an example. 

    Code Block
        "metrics": [
            {
                "objectName": "UEEventStreamingCounters",
                "objectInstance": "SgNBAdditionRequest",
                "name": "SgNBAdditionRequest",
                "type": "counter",
                "description": "The total number of SG addition request events processed"
            },
            {
                "objectName": "UEEventStreamingCounters",
                "objectInstance": "SgNBAdditionRequestAcknowledge",
                "name": "SgNBAdditionRequestAcknowledge",
                "type": "counter",
                "description": "The total number of SG addition request acknowledge events processed"
            }
        ]


  • messaging: (OPTIONAL) This section defines parameters for messaging and communications such as service ports, list of RX and TX message types, and the A1 policies implemented by this xApp. Ports defines the service port opened for each container. maxSize defines the RMR buffer size, numWorkers defines the number of RMR worker. txMessages lists the message type that this xApp sends out, rxMessages lists the message type that it receives, and policies defines the list of policies that this xApp will accept. This section requires ports, maxSize, numWorkers, txMessages, rxMessages, and policies.

    Code Block
    	"messaging": {
    		"ports": [
    			{   
    				"name": "http",
    				"container": "mcxapp",
    				"port": 8080,
    				"description": "http service"
    			},
    			{
    				"name": "rmr_data",
    				"container": "mcxapp",
    				"port": 4560,
    				"description": "rmr data port for mcxapp"
    			},
    			{
    				"name": "rmr_route",
    				"container": "mcxapp",
    				"port": 4561,
    				"description": "rmr route port for mcxapp"
    			}
    		],
    		"maxSize": 2072,
    		"numWorkers": 1,
    		"txMessages": [
    			"RIC_SUB_REQ",
    			"RIC_SUB_DEL_REQ"
    		],
    		"rxMessages": [
    			"RIC_SUB_RESP",
    			"RIC_SUB_FAILURE",
    			"RIC_SUB_DEL_RESP",
    			"RIC_INDICATION"
    		],
    		"policies": [1,2]
    	},


  • liveness probes: (OPTIONAL) The liveness probe section defines how liveness probe is defined in the xApp helm charts. You can provide any ether a command or a http helm liveness probe definition in JSON format. This section requires initialDelaySeconds, periodSeconds, and either httpGet or exec.The following is an example for http-based liveness probes. 

    Code Block
        "livenessProbe": {
            "httpGet": {
                "path": "ric/v1/health/alive",
                "port": "8080"
            },
            "initialDelaySeconds": "5",
            "periodSeconds": "15"
        },

    The following is an example for rmr-based liveness probes.

    Code Block
    		"livenessProbe": {
    			"exec": {
    				"command": ["/usr/local/bin/healthrmr_ckprobe"]
        		},
        		"initialDelaySeconds": "5",
        		"periodSeconds": "15"
    		},


  • internal xApp parameters sections: the xApp descriptor can include arbitrary number of xApp defined parameters sections that contains the configurations that will only be consumed by the xApp containers. The xApp descriptor will be injected into the contianer as a JSON file, and an environment variable XAPP_DESCRIPTOR_PATH will point to the directory where the JSON file is mountedreadiness probes: (OPTIONAL) The readiness probe section defines how readiness probe is defined in the xApp helm charts. You can provide ether a command or a http helm readiness probe definition in JSON format. This section requires initialDelaySeconds, periodSeconds, and either httpGet or exec.The following is an example for http-based readiness probes.

    Code Block
        "logger": {readinessProbe": {
            "httpGet": {
                "path": "ric/v1/health/alive",
                "port": "8080"
            },
            "initialDelaySeconds": "5",
            "periodSeconds": "15"
        },

    The following is an example for rmr-based readiness probes.

    Code Block
    
    		"readinessProbe": {
    			"exec": {
    				"command": ["/usr/local/bin/rmr_probe"]
        		},
        		"levelinitialDelaySeconds": 3"5",
        		"periodSeconds": "15"
    		},


xApp Descriptor Example:

You can download the xApp descriptor for MC xApp herehere 

View file
nameconfig-file.json
height250
.

You can find the corresponding schema from here:here 

View file
nameschema.json
height250