It has been two years since I started this journey of defining a Software Architecture for the Telecom domain in the Cloud. There are challenges in providing a Telecom platform in the Cloud you will not generally find in the IT world. Two years ago my team was tasked to look in the future and see to what extent the Cloud Programming Principles could be applied to the telecom world. We started from a white sheet and look at the potential building a small proof of concept prototype. Last year Ericsson unveiled its Software Model. You can find a video on YouTube on the Ericsson Software Model. You can also read the Ericsson Software Model press release. We looked at how our approach was supporting that model as well as taking it as a form of requirement specifications as what a Telecom Cloud platform should provide.
The Ericsson Software Model promotes a number of concepts which we looked at while developing our cloud-based software architecture:
Virtualization: The Ericsson press release states that “network evolution is increasingly driven through new software functionality with application virtualization”. With our research we wanted to go further and look at it from the angle of an application natively built for the cloud not solely virtualized. Thus the software architecture we propose is built for the cloud. Since from the point of view of a telecom vendor, telecom application should be deliverable on any operator owned cloud platform or mix of platforms it became obvious that the need to provide an hyper-heterogeneous cloud architecture enabling software to be deployed independently of the platform without having to rework it was a must.
Upgrades: The Ericsson press release also mentions the importance of easy regular upgrades. Building our research approach as a cloud platform we looked how far we could go with this. We came up with principles that allow upgrade of network software for a single subscriber, or even for a single service instance of a subscriber. Thus we could upgrade a network in a staged fashion while keeping an eye on key performance indications and instantaneously go back to a previous version if anything goes wrong. The high granularity of our upgrade approach means fewer risks while upgrading which enables more regular upgrades.
Better Resource Utilisation: The Ericsson Software Model video states better resource utilisation as a driver for the future. Virtualization helps in that matter, however since the scalability increments would still be in the thousands of subscribers at a time, it limits how small a network function can become. In the context of the Networked Society where billions of devices are connected, it becomes obvious that the usage patterns will be multiple and non-obviously predictable. Our highly granular approach allows for efficient resource utilisation since only the software processes are instantiated on a need basis anywhere in the cloud of available resources. Hence free resource can be used for any service scenario and are never tied to a specific one.
Performance: The Ericsson press release states that the Ericsson Software Model “builds on the software performance benefits by making it simpler and faster for operators”. Since our research approach is based on a cloud deployment it became obvious we needed to address availability. As such we build in our architecture ways to allow the application to cope with availability issues, being able to be deployed or migrated anywhere in the cloud if servers crash or becomes unavailable. These facilities are built to be transparent to the application thus making it simpler to the application developer and consequently to the operator as well.
Predictability: The Ericsson Software Model video states the need for predictability. Our approach also allows for a high degree of observability which is important to provide a predictable network and eventually to have a self-healing system.
First to Market: The Ericsson Software Model video states the need for operators to quickly have new functionality available to the customers. For this to be possible we need to look at the development cycle from the start and developers needs build their software based on software independency concepts if they are to deliver it as quick as possible. The software independency is built-in our approach and we think this is a necessity if a platform is to allow rapid development.
There would be much more to say as some more principles made it in the architecture, but if you think those are important principles I invite you to read the two papers we submitted to the S2CT.org conference and should shortly be published. We defined software architecture and build a proof of concept which address those business needs and could become a software platform for the future telecom products. The papers describe at a high level view of the architecture as well as some results from the proof-of-concept.
Preliminary versions of the papers are available on arXiv.org: Hyper Heterogeneous Cloud-based IMS Software Architecture: A Proof-of-Concept and Empirical Analysis and Micro Service Cloud Computing Pattern for Next Generation Networks.