First continuous integration platform end-to-end test completed.

The initial CI hardware platform build was completed back in August and we are pleased to report that the next milestone has been reached, whereby the srsRAN software is automatically built and deployed to a base station, together with eNodeB and EPC configuration, following which an end-to-end test is completed when a modem attaches to the network and a successful ping completes.

Jenkins log from successful ping test.

Getting up to speed with all the software components involved and making the necessary changes has been quite a learning curve. To summarise, the steps involved were roughly:

  • Manually configure the eNodeB+EPC and connect a modem using an Ofono test script to confirm hardware operation.
  • Install Jenkins, OsmoGSMTester and dependencies, including Ofono patched so that it works with network namespaces.
  • Understand osmo-ci software and job configuration and make changes, mostly:
    • Update builder job to point to MyriadRF repositories with necessary overrides to build srsRAN.
    • Update runner job to point to MyriadRF repositories.
    • Strip unneeded components out of both jobs.
  • Get to grips with osmo-gsm-tester setup and make changes, in the main:
    • Update srsRAN templates.
    • Add support for “lime” RF device type.
    • Update resources configuration.
    • Update ping test script to appropriately configure modem network interface.

We were fortunate in that we could reuse much of the test configuration provided by the Osmocom project, with mostly minor changes required. Trivial updates such as git repository locations aside, these were mostly concerned with configuring resources for our particular hardware setup. It would also seem that this may be the first time that a hardware modem driven by Ofono has been used for testing LTE with OsmoGSMTester, since it appears that previously only SDR UEs and Android handsets that are controlled via ADB have been used.

The OsmoGSMTester software is pretty impressive to see in action and the benefit provided over manual testing cannot be overstated. It is also clear that a lot of effort has gone into making this as flexible as possible. With thanks to the Osmocom community and sysmocom for developing OsmoGSMTester and providing test configurations, and to Pau Espin Pedrol at sysmocom for helping to get us up and running.

A page has been added to the documentation with details similar to those provided here and which will be updated as we make further progress.

Next steps

So far software has been manually installed and configured, so that we could better understand this and easily make the necessary changes as we went along. Now that we have confirmed basic operation, we will switch to using Ansible and Docker, as used by the Osmocom project and making use of the associated configuration that they provide. We also need to look at how closely we can track configuration used by the Osmocom project, so that we can contribute back upstream.