Need for Automation of 5GC - EMCO role

Disaggregation and distribution of 5GC using Edges is new thinking in 5G industry to achieve aggregated performance. Telcos going to Hyperscaler infrastructure supporting edges (onPrem) depend on this architecture to achieve very high aggregate performance. On packet processing of 5GC, this post https://www.dhirubhai.net/feed/update/urn:li:ugcPost:6792142517640007680?updateEntityUrn=urn%3Ali%3Afs_feedUpdate%3A%28*%2Curn%3Ali%3AugcPost%3A6792142517640007680%29 briefly touched upon the zero touch and few security aspects that are to be considered. I believe distributed architecture leveraging edges is also needed for AMF and SMF too. That is, these would be deployed in multiple edges too. Cloud native, scale-out in a K8s cluster and scale-out across Edges is the recipe for success for Telcos moving to leverage Hyperscaler infrastructure.

It is to be noted that Telcos leveraging the Hyperscaler infrastructure are very careful in putting all the eggs in one basket. They like to ensure that the solution is multi-cloud friendly. For that reason, my understanding is that Telcos are increasingly limiting themselves using Hyperscaler infrastructure (Up to Kubernetes infrastructure) and bringing their own 5GC, Service Orchestration, OSS/BSS solutions. Telcos are also bringing their own K8s Telco extensions to ensure that they don't depend too much on Hyperscalers K8s distributions.

Essentially, orchestration of 5GC & associated automation of connectivity and security are still taken care by Telcos. My intention of this post is in this context and talk about some of the automation needs.

I am taking one example here. free5GC deployment by Platform9 is described here. You can see the complexity of deploying 5GC on one K8s edge. There are many manual operations done to make free5GC work on an edge. Some of manual items I see are:

• Static assignment of IP addresses to AMF and SMF via annotations in AMF and SMF Podspec.
• Manual editing of AMF and SMF files with IP addresses.
• GTP-U LKM installation
• SCTP enablement
• Issuing multiple kubectl commands to deploy multiple CNFs.
• Manual monitoring to ensure that CNFs are brought up successfully.

Note that those are assuming that you have one edge and one node. Think of Edges with multiple nodes and think of multiple edges. Complexity goes up further if you are depending on manual steps above. Those are just the tip of iceberg. There are even more complex steps in real deployments.

• Replica count can't be 1 if one likes to have scale-out. Hence, no, manual editing of IP addresses is preferred.
• UPF needs to be accessed from CU-UP which can in another K8s cluster/edge. So, there could be steps required to ensure the UPF can be placed on provider networks, Enable IPSEC to secure the traffic from CU-UP and UPF. It may also be required to enable firewall/NAT rules to allow traffic to/from CU-UP and UPF.
• AMF and SMF can be brought up with UPF while other control plane cores are brought up in more central edges/K8s-clusters. This would need more additional manual steps to allow communication between AMF/SMF and other 5GC control plane functions. It is possible that one needs to automate ISTIO/Envoy if they are used to secure the 5GC Control plane CNFs. It also requires automation of firewall/SNAT/DNAT and SDWAN QoS rules to allow traffic to/from CNFs across Edges.

Since Edges may get dynamic public IP addresses, it may also require to discover these IP addresses and program DNS Servers in automated fashion.

Akraino/ICN and EMCO are addressing the challenges listed above. It will make the entire experience of 5GC disaggregated and multi-cloud deployment simple - one click deployment. Comprehensive monitoring of disaggregated 5GC avoids administrators looking for the health of each CNF across edges by providing a single API/GUI to look into the status.

Zero touch deployment is even critical to support dynamic network slicing. Industry started to look at implementation of slicing with no dependency on CNF capabilities. Talked to a few operators and their choice is to go with infrastructure that can support slicing with no help from CNFs. This is achieved via dedicated CNFs for each slice and ensuring that security & performance isolation aspects are taken care of at the slice level. This also ensures that CNFs from different vendors can present across slices, which is a requirement for few Enterprises. In this case, Enterprises getting slices from operators can go with their own CNFs across operators.

EMCO being open source, you would not have to get locked-in yourself to a particular vendor. Being open source, you are free to contribute and leverage the work done so far. EMCO is becoming part of LFN (around September, 2021) and that is good news for the Industry. Please look at my Linkedin blog space for more details.