This post discusses the first 5G architecture pattern – where both the 5G Core and the Radio Access Network (RAN) are deployed on the cloud. We will also examine how it solves the major usage scenarios defined for 5G by 3GPP while designing for the seven architecture domains we discussed in the previous blog.
The “Everything In The Cloud” Pattern
The first pattern is also the most basic one. We will discuss its suitability when we do the discussion of the various criteria but in this pattern, the 5G RAN and the 5G Core are both brought together within one cloud deployment.
As shown above, the 5G network which is composed of the central 5G Core and the edge cloud with 5G NR (New Radio) are deployed on one physical cloud on different network partitions. The core manages the edge workloads from the central control with the edge running RAN NFs.
Detailed Design
Illustration – “Everything in a cloud pattern’ where both the 5G Core and RAN components are deployed on a hyperscaler cloud region
- The business usecase – This pattern is suitable for small deployments where the usecase is not latency sensitive. Prominent examples include – a) a non CSP (typically a private enterprise looking) to own and control (but not operate) 5G network for their internal use, b) for DevOps and validation testing environments where instances can be spun up or down and then migrated over to one of the other patterns for full production deployment.
- The kind of workload – The kinds of workloads or 5G applications supported will obviously be around private usecases such as mining, manufacturing etc, where the number of users expected is small such as a greenfield B2B business and serves a departmental capability etc. This deployment pattern is unsuitable for applications that have real-time requirements or intend to provide immersive user experience such as VR/AR and HD Video.
- Networking requirements -5G networking is complex as it covers instance level networking, pod level networking and network policy management. Please refer this blogpost for more details – https://www.vamsitalkstech.com/5g/why-5g-implementations-will-need-a-meta-cni-aka-multus/ Both control and the data plane have their own individual subnets
- Performance Requirements – The performance of this architecture would be dependent on the number of users and instances that need to be supported
- Operational ease of use – We covered this topic at some depth in the blog – https://www.vamsitalkstech.com/5g/infrastructure-as-code-iac-for-5g-core-and-radio-network-setup/. All of the standard concerns raised in that blogpost apply. The IaC (e.g. Cloudformation, Terraform) templates will define the Worker node group for control plane network functions, such as MME, SGW-c, SMF, etc., with additional control plane subnet network. Worker node group for user plane network functions, such as SGW-u and UPF, with additional control plane subnet and user plane subnet networks.
- Security – Security around container/compute layer apply majorly here as it is a pure cloud based deployment. E.g. control plane security, pod security policies, secure OSs, network etc.
- Cost – This deployment model usually follows the least cost pattern as it has only cloud based components intended for small deployments.
AWShas provided a reference implementation of this pattern at the following – https://aws.amazon.com/blogs/opensource/open-source-mobile-core-network-implementation-on-amazon-elastic-kubernetes-service/
Conclusion
The next blogpost will discuss the next architecture pattern “Everything Managed but Hybrid” where the 5G Core runs on the cloud provider and the RAN on premises on managed hardware.
Featured image by Robynne Hu on Unsplash