- The xAPP docker run time **must** be configured with a json configuration file appropriate to the test environment which injects various environment variables including the RMR routes (an example is provided under init/config-file.json).
- - Once such a file is available (say under directory /home/user/test-config), the docker image can be invoked as *docker run --net host -it --rm -v "/home/user/test-config:/opt/ric/config" --name "AC-xAPP" <image>*. See REAMDE.md under the init directory for more details.
+ - Once such a file is available (say under directory /home/user/test-config), the docker image can be invoked as *docker run --net host -it --rm -v "/home/user/test-config:/opt/ric/config" --name "AC-xAPP" <image>*. See README.md under the init directory for more details.
3. **Invoking docker xAPP container in RIC Kubernetes environment** :
- ./run_tests.sh
- If gcovr is installed (https://github.com/gcovr/gcovr) the script will also generates a coverage report (as ../coverage_report.html)
-In order to run integration tests, the AC-xAPP requires *three* components : an *E2 Termination point* to send and receive RAN messages, an *A1 mediator* to send policy updatesd and a *VES collector* to receive metrics. The *test/*
+In order to run integration tests, the AC-xAPP requires *three* components : an *E2 Termination point* to send and receive RAN messages, an *A1 mediator* to send policy updates and a *VES collector* to receive metrics. The *test/*
directory contains mock-ups for these three components which can be build and executed from the *test/* directory as follows :
1. **E2 Termination** : The E2 termination is responsible for forwarding messages to and fro between the RAN and RIC. A mock-up of the E2 termination is provided in *test/* that
- - listens and responds to E2AP subscribption requests.
+ - listens and responds to E2AP subscription requests.
- upon receiving an E2AP subscription request, starts sending E2AP Indication messages that contain the X2AP SgNB Addition Request Message.
- monitors E2AP control messages from the AC xAPP.
2. **A1 Mediator** : The A1 mediator is responsible for sending policies to the xAPPs over RMR to configure their behaviour. A mock-up of the A1 mediator can be built and executed as follows :
- - *make mock-a1-server* builds the executable.
- - The executable can be run as *./mock-a1-server -p <port number>* where port number can be any port not conflicting with the xAPP and E2 Term.
- - Note that the A1 mediator also uses RMR and hence the environment variable *RMR_SEED_RT* must also be set when executing *mock-a1-server* (if static routes are being used).
- - On start up, the *mock-a1-mediator* will send a stream of valid/invalid JSON messages containing policies to test the xAPP.
+ - *make mock-a1-tool* builds the executable.
+ - The executable can be run as *./mock-a1-tool -p <port number> <options>* where port number can be any port not conflicitng with the xAPP and E2 Term ports.
+ - Note that the A1 mediator also uses RMR and hence the environment variable *RMR_SEED_RT* must also be set when executing *mock-a1-tool* (if static routes are being used).
+ - Run ./mock-a1-tool -h to see various options.
-3. **VES Collector** : This component is responsible for receiving metrics from xAPPs as JSON payloads. A simple mock-up is available under *test/* which is basically a *cherrypy* web-server that receives JSON and prints out relevant messages. It can be invoked as *python ./mock_ves_collector.py*.
+3. **VES Collector** : This component is responsible for receiving metrics from xAPPs as JSON payloads. A simple mock-up is available under *test/* which is basically a *cherrypy* web-server that receives VES messages from the Admission Control Xapp and prints out relevant messages. It can be invoked as *python ./mock_ves_collector.py*.
- Pre-requisites for the VES collector are the *cherrypy* and *requests* Python modules. They can be installed via pip : *pip install cherrypy requests*.