I have recently read a very interesting white paper, ‘Cloud-native 5G – Management of Constant Change’ from HPE, on applying the tools and techniques of CI/CD to 5G. In this, they are demonstrating how the microservice architecture of a 5G network enables them, and by extension their CSP customers, to utilise CI/CD to deliver rapid software updates to separate network functions; these might be to address defects in previous versions, or to introduce new features and capabilities. It is acknowledged that “Ideally, the operator will employ automatic tools that can be used to validate software changes before uploading them to production”, but I think they are missing a big chunk of the challenges that operators will face.

Zero-Touch Service Assurance Environments

Operators will want to ensure that they can provision, monitor, configure, and operate these new software versions from NEVs or ISVs. Especially in the arena of operations, there will likely be (at least some of the time) significant changes in what the operator might need to monitor, and how it will need to respond to events in that monitoring. As operators are moving towards zero-touch service assurance environments, it is crucial that they have the agility in their service assurance platforms to rapidly adopt and adapt to software changes. It is important to emphasise that the change in the VNF is not the only thing that needs validating – other entities in its operating environment will need validating – and possibly changing – as well.

Full Control over Network Functions

Operators may want control over when the new software instance is actually used in production operations. HPE gives an example related to modifications in an NRF, and identifies that when that changes, operators “will only need to update and restart this specific agent microservice in each one of the network functions”. Leaving aside the possible challenges in identifying all the network functions using the agent microservice, operators may want to manage when those other network functions will be (even momentarily) out of contact with the NRF. For some functions they may want those changes to take effect immediately; but for others the urgency may not be so great (or vice versa, for some functions they may want actively to delay the use of the new NRF by some other network functions). And it’s not just functions: different network slices may require separate VNF deployment rules, as many different service types, and even some customer contracts may restrict whether, or when, such updates may be applied, for example.

Compatibility with 3G – 5G

Clearly, if an operator is running a pure 5G network then a CI/CD approach as outlined might be beneficial. But until then, while operators run a mix of 3G, 4G, and 5G, alongside a variety of core and fixed-access network architectures it would be imprudent to just ignore that other stuff. Even small changes to the 5G core may have a large impact upon non-5G network elements that are used to access or deliver services. Changes to the 5G core need to be carefully managed and orchestrated alongside changes to these other components, too. And that’s not something that a 5G VNF provider on their own would necessarily be able to do: it the operator that needs to own the responsibility for that orchestration.

Agility to work with Future and Legacy Systems 

And finally, even though – as HPE points out – CI/CD has been in use in the IT world for many years now, it has not solved all the problems. There are still failures in operationalising new software, in part because the data and legacy systems on which the CD processes depend are prone to quality, accuracy, and availability issues. And typical CD automation does not cope well when it encounters such issues.

Cloud-Native 5G requires Intelligent Automation

So, while CI/CD may have a place to play in a 5G Operators processes, it is not the panacea to all their problems. Automation really is critical if operators are going to be able to cope with the implied rate of change espoused in the HPE white paper, but more than that, the automation will need to be agile – to cope with each operator’s specific organisational and operational context (which itself will be continuously changing) – and intelligent – to be able to handle possibly inaccurate or incomplete information from a wide variety of data sources and systems as part of its day-to-day function. This is exactly the approach we’ve considered when developing the Cortex Intelligent Automation platform.