Versions Compared

Old Version 28

changes.mady.by.user Zhe Huang

Saved on

compared with

New Version 29

changes.mady.by.user Zhe Huang

Saved on

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.  If the controls section is not empty, the xApp developer must provide the schema file for the controls section. Please refer to Schema for xApp Descriptor for creating such schema file. The following is an example for the controls section.

    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 the communication ports for each containers. It may define list of RX and TX message types, and the A1 policies for RMR communications implemented by this xApp. Each defined port will creates a K8S service port  that are mapped to the container at the same port number. This section requires ports that contains the port name, port number, which container it is for. For RMR port, it also requires tx and rx message types, and A1 policy list.

    Note
    titleStop gap solution for bronze release

    The messaging section replaces the previously RMR section in the xApp descriptor. It requires appmgr to modify its codes to parse the new messaging section. Before the new version of appmgr is released, as a stop gap solution, we will also include a compatible RMR section with the same information in the xApp descriptor. Please refer to the stop-gap-MCxApp descriptor for example.  


    Warning
    titleport naming convention

    In the bronze release the rmr port names are hardcoded in appmgr. Therefore, in this release please make sure to use rmr_data for RMR data port, rmr_route for RMR route port so that appmgr can pick up the correct port numbers. 


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


  • liveness probes: (OPTIONAL) The liveness probe section defines how liveness probe is defined in the xApp helm charts. You can provide 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/rmr_probe"]
    		},
    		"initialDelaySeconds": "5",
    		"periodSeconds": "15"
		},


  • readiness 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
        "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"]
    		},
    		"initialDelaySeconds": "5",
    		"periodSeconds": "15"
		},


...