Softwarization of Core Telecom

Posted By :

Telecom has evolved from ancient pure hardware play to previous semi-software/hardware play to current exclusive software solutions to the future cloud-native software platforms.

GSM / 3GPP has evolved from 1G networks tightly bound to hardware to 2G SS7 based IN solutions with ability to manage subscribers using real-time software to 3G Sigtran IP Signalling networks, 4G Pure-play IP networks and 5G Cloud Native CNF based automatic networks.

Service Creation has always been the forte of Telecom Marketing Managers to differentiate their offerings from the competitors. Friends & Family, Homezone used to be the buzzwords in 2G, buckets & bundles in 3G, Unlimited plans in 4G and the new Network Slices in 5G. The complexity of Service Design and Creation has increased tremendously in 5G and industry leaders have formed open source platforms for offering Network Slicing.

The scope of software in the RAN, Transport and Core Network / Service Logic domains has also increased from 2G to 5G. 2G Networks enabled software based controls only in the IN Service Logic domain. Pure-play software based GGSN expanded the scope in 3G Core Domain. Diameter software and SDN enabled end-to-end hardware agnostic 4G Networks. Telco grade internet technologies such as HTTP2 are now enabling Cloud Native 5G Networks.

Having designed products and solutions in CAMEL, USSD, INAP, WIN2 / IS41 (CDMA), MAP, Diameter and GTP, I am excited to integrate Internet Technologies into Telecom Signaling with HTTP2.

Signaling Backbone for 5G

3GPP started study of NextGen Architecture from 2015. 3GPP 23.501 Release 15 published Service Based Architecture as the basis for 5G system. 5G Service Based Architecture is defined as combination of Network Function Service and Service Based Interface.

Network Function Service is exposed by Network Function Service Producer to Network Function Service Consumer. Network Function Service supports two primitive operations – a) Request – Response and b) Subscribe – Notify. Network Functions are self-contained microservices and enable auto-scaling and auto-healing management services.

Service Based Architecture enables a) Modularity & Reusability, b) Cloud-nativity (CI/CD & Containerization), c) Extensibility and d) Openness (standard APIs 3rd party integrations).

Service Based Interface forms the signaling backbone for Service Based Architecture. The requirements of Service Based Architecture include a) Support for bi-directional communication, b) Reliable Communication, c) Low Response Time, d) Scalability, e) Ease of Upgrade, f) Quick Deployment, g) Resource efficiency, h) Stateless Operation and i) Security.

With the convergence of key capabilities in virtualization, containerization and Internet Technologies based Open Architecture, we have designed and implemented HTTP/2 Stack to provide seamless Cloud Native Performance and Availability for the Operators.

Comparison between Diameter and HTTP/2

Diameter has matured for over 10+ years in LTE networks. Diameter enables high-performance, high-reliability and priority-based overload control. Diameter is also widely deployed in 3GPP Operator community enabling reusability.

In spite of the above benefits of Diameter, 3GPP favored HTTP2 over Diameter for Service Based Interface. The benefits provided by HTTP2 over Diameter include a) Cloud-Native and Service Based Architecture, b) Availability of large user community for web services ensuring rich innovation and future-proofing and c) Wide adoption of HTTP in large enterprise ecosystems which comprise the ultimate beneficiaries of 5G.

We have leveraged the capabilities built in architecting and implementing Tier1-Networks proven Diameter stack and Kubernetes containerization to offer cloud native, carrier grade HTTP/2 signaling stack.

HTTP2 Signaling Stack

The Service Based Interfaces use HTTP2 protocol with JSON as the application layer serialization Protocol. For security protection at the transportation layer, 3GPP Network Functions shall support TLS, in case network security is not provided by other means. API Design Style is RESTful APIs with CRUD operations. HTTP2 stack supports notifications such as for Callback messages.

Application
HTTP2
TLS
TCP
IP
L2

The TCP layer in the HTTP2 Service Based Interface provides transport level congestion control mechanisms. End to end overload control is supported per NF instance. An NF Producer may mitigate overload status by sending HTTP Status Codes 503 (Service Unavailable), 429 (Too Many Requests) or 307 (Temporary Redirect) to requests received during an overload condition. Message Priority provides guidance to the NFs for making throttling decisions. Custom HTTP header is used for setting and carrying the message priority.

My passion in core Telecom is ignited with the innovative application of the containerized in-house HTTP2 stack in both Core and Edge Networks.

Leave a Reply

Your email address will not be published.