Abstract

Open-source software development tools can be used to implement a Continuous Integration (CI) environment for the IMS for quality IMS service development.

Introduction

Continuous integration (CI) is a widely used practice by software development teams. In this practice, the development team integrates their code many times a day into a shared repository. On each integration, an automated process is initiated to build and test the check-in. This process verifies the changes and provides immediate feedback so the team can locate and address problems quickly. A test environment that is as close as possible to the production environment results in higher confidence in the verification.

In core networks of mobile and fixed network operators, it is the norm to have very few environments that are close in configuration to the production environment. Many factors limit the number:

• Licensing practices of vendors, e.g. charging for each test environment
• Custom hardware such as Digital Signal Processing (DSP) hardware accelerators
• Vendor managed manual installations
• Complex systems interdependencies
• Overall system complexity
• Project constrained delivery of change rather than continuous delivery
• Traditional software development practices

Most operators now recognise that these issues have a detrimental effect on their businesses due to the high cost of change and inability to compete with over-the-top (OTT) service delivery. The issues inhibit effective practices such as CI, but the problem is much broader.

Many initiatives are being undertaken by operators to address the broader issues. Three of the most important are:

• Agile methodologies
• Network Function Virtualisation (NFV) - typically a type of private cloud for the network
• Dev-ops - breaking down the barriers between development and operations teams

These initiatives are interlinked and need to be implemented together to deliver the outcomes desired by network operators.

Continuous integration is one of the practices that will become ubiquitous as these initiatives gain traction.

Continuous Integration before achieving Network Nirvana

I have found that it is possible to implement CI for applications on a Telecommunications Application Server (TAS) for the Ericsson IMS.

The Metaswitch Rhino Sentinel VoLTE TAS provides an IMS service development platform that permits operators to create and extend services either with internal or 3rd party development teams. Metaswitch provides an excellent testing tool, the Scenario Simulator, that can be used to simulate all of the network elements that connect to an IMS AS: I/S-CSCF, MRF, HSS, online and offline charging systems.

Unfortunately, simulation of all network interfaces to the TAS does not provide a high degree of confidence for CI.

The level of confidence can be raised by including as many of the actual systems as possible.

CI can include how much of the network environment?

My initial thought was to go all the way from the customer equipment inward. In the IMS, including the customer equipment in CI testing has some limitations that make it difficult to achieve in practice. It is difficult to create a set of tests that integrate automatically with analogue interfaces. There are some excellent tools in the market for this type of testing, but it is difficult to integrate these tools into a useful CI test suite. For operational monitoring, it is far more beneficial. My conclusion is that, while useful, it does not provide sufficient improvement in the confidence of verification for the time and effort required to implement it in a small network operator. Of course, for large operators with fewer resource constraints, it is more feasible.

When working within the constraints of a small development team, the optimal integration point is to simulate the client interface to the IMS Session Border Controller (SBC). At this integration point, the testing uses IP interfaces: SIP and RTP. Tools are available for simulating these protocols.

A toolchain for IMS CI

The essential elements of a CI toolchain are:

• Automation server
• Configuration/Deployment management tool
• Test harness
• Traffic simulator
• Reporting tool

IMS traffic simulation for test execution

Metaswitch’s Scenario Simulator is a capable tool for stand-alone TAS testing, but the tool cannot test both signalling and media interfaces in the IMS. Fortunately, there are tools available that support these interfaces. Two of these tools are:

• SIPp - open source license
• SipInspector - commercial license

SIPp is the most reliable tool of these two but SipInspector, while sometimes unreliable, does support some scenarios that SIPp cannot.

Both of these SIP/RTP simulators are only manual tools out-of-the-box. It is necessary to wrap the simulators with scripts to create a toolchain that is fully automated. I choose Python to implement the glue scripts. With Python scripts, multiple UACs and UASs could be automatically set up with support for registration/de-registration as well as single or multiple calls.

Python provides excellent data analysis and plotting tools for complex reporting capabilities on the collected test data.

An automation platform is an essential part of CI

The Jenkins automation server hosts all the IMS CI jobs. I selected Jenkins because of prior experience of the team and support from the TAS vendor. The team used Jenkins for:

• TAS service build from source in GitLab and publication into the Nexus Repository
• IMS test suite job execution and reporting

Automated deployment with one click

Automated deployment of service components is necessary for a correctly functioning CI environment. I choose Ansible tool for this function. With Ansible the entire TAS environment could be automatically deployed with a single call. The deployment included the TAS platform, web servers, element managers, database cluster and any additional platform configuration.

When I design this environment, I considered containerization tools such as Docker. The team did not implement containerisation due to project constraints. However, I consider this to be a better approach for service deployment as it:

• reduces deployment effort and time
• minimises differences between test and production environments
• decouples service components from VMs for flexible maintenance of deployment environments
• improves scalability
• reduces operational overheads

NFV has the potential for improved CI and Continuous Delivery

As the network equipment vendors move to supporting NFV, it will be possible to improve the capabilities of CI. Currently, without NFV CI is constrained due to limitations in availability of IMS test environments. However, with NFV, there is some hope that the application of continuous delivery, a capability that has transformed the delivery of internet services, will be possible in the network.

Metaswitch has been an early innovator in this space by creating an IMS platform that is cloud native. With this technology, the limited number of test and staging environments in network operators that hamper service delivery today will be a thing of the past. I hope that other IMS vendors will provide similar capabilities so that modern, proven practices are available to development teams for network service development.

Conclusion

It is possible for a modest-sized team in a small operator to implement CI in an IMS environment. NFV will improve cloud capabilities in networks, enabling development teams to realise the full potential of continuous integration and open up the possibility of continuous delivery in the core network.