Cloud native 5G extends beyond containerization and Helm charts, emphasizing strategies to prevent vendor lock-in, reduce costs, and promote flexible architectural designs.
When compared to previous generations of Core Network technology, designing, and implementing a 5G Core Network on cloud platforms offers unparalleled simplicity and scalability. Aside from the ease of cloud development, it is critical to understand and address Software Architects' strategies and goals. Developers and telecom operators must deal with several issues, including potential cloud vendor lock-in and fluctuating performance and cost optimization concerns. Furthermore, operators must consider regulatory norms and data sovereignty while selecting solutions. A successful cloud-native 5G rollout requires balancing agility and security while also offering a smooth interface with older telecom technologies. This article investigates these critical topics, offering insights into the thinking processes of both software architects and operators.
What does cloud native 5G mean for software architects?
When Cloud Software Architects design a 5G solution to be deployed on a public cloud platform, they consider the following areas:
Scalability: Architects understand that adding or removing resources from a Cloud platform is simple if a 5G solution can manage scale in and scale out events in the architecture. Architects determine the many features that may be deemed scale out or scale in events. For example, the number of subscribers handled by the 5G Core, the CPU usage of Network Functions (NF), and the memory use of NF.
Reliability: Public cloud providers are recognized for delivering dependable service and disaster recovery technologies, which can improve the resilience of cloud native 5G systems. 5G architects create redundancy architectures employing cloud services to achieve the requisite number of 9s of dependability.
Flexibility: Developers get the freedom to use the cloud services, APIs, and third-party tools, enabling faster development. Of course, every time developers use some service of a specific cloud provider they always think about cloud lock in.
Security: They prioritize security measures provided by cloud providers, like data encryption, identity, and access management (IAM), security monitoring tools, to ensure the protection of subscriber’s personal information and to handle cyber threats.
Overall, architects view the cloud as a valuable platform that offers scalability, flexibility, cost-efficiency, reliability, and security, empowering them to build and deploy a 5G core network more efficiently and effectively.
What do proprietary hardware base 5G solutions entail for Software Architects?
Below are some of the key challenges of 5G Core solutions developed for proprietary hardware:
Resource constraints: Developers face resource constraints when designing software architecture for non-cloud solutions due to limited hardware resources, such as processing power and memory. Often solutions developed in this case are highly optimized and sometimes proprietary. Memory footprint & CPU usage is audited to avoid running out of memory & CPU.
Scalability: Scalability is often constrained by the capacity of on-premises servers, hindering the ability to handle sudden spikes in demand. Scalability always means adding extra hardware and cannot be done in a short time. Operators need to be well prepared to handle scale events.
Maintenance: Maintaining and upgrading physical infrastructure can be costly and requires specialized solutions which can avoid subscriber loss during maintenance.
High availability: High availability and fault tolerance may be challenging to achieve given limited blades/cards in the proprietary hardware. This leads to increasing the risk of downtime.
In summary architects are challenged to give the best possible subscriber density in each hardware and provide required redundancy for the operator. Sometimes this is challenging, and innovative solutions are built to achieve these goals.
What do architects overlook or fail to consider when designing cloud-native applications?
When architecting Cloud Native 5G Core Networks, some aspects that may not be considered or given enough attention are:
Optimizing applications or workload: Constraints on the resources required to provide 5G Core service. Typically, if a solution requires more memory, then new instances are created with more memory. If more CPU is required, then new instances are added or more CPU added to existing instances. So effectively instead of optimizing the program new resources are added to meet the needs.
Cost: Developers may not be completely aware about the cost of each & every service selected to build the solution. Mapping precise cloud usage to specific cost matrix could be also difficult to come up with. While developers may initially optimize costs by leveraging cloud services, they might not continuously monitor and optimize costs as applications scale, potentially leading to unexpected expenses over time. Keeping check on the usage and having clear mapping of needed number of 5G subscribers vs cloud cost would be ideal for the operator.
Cloud provider lock-in: Due to the time constraints of delivering the solution, it may take some time for the developer to pick cloud services and create the solution. This leads to cloud provider lock-in. Developers may not always consider the possibility of vendor lock-in when implementing certain cloud provider services or proprietary technologies, which may limit their ability to switch to alternate platforms in the future.
Data sovereignty and compliance: This is one of the important aspects and falls under the Dev Ops team and developers may overlook the importance of data sovereignty and compliance requirements, such as regulations governing the storage and processing of data in different geographic regions, which could impact application architecture and deployment strategies. If any automation scripts are developed to deploy the 5G Core, then precaution needs to be taken to make sure the right regions are used for service deployment. Also, right deployment settings should be done to avoid accidental deployment of service in any unintended region. 5G Core should provide flexibility in terms of placing the network functions.
Legacy telecom service provider system integration: Developers may not always anticipate the challenges involved in integrating cloud-native applications with existing legacy systems or on-premises infrastructure, which could require additional effort and resources during implementation. Not to forget many telecom operators still operate 3G, 4G solutions and old billing servers or old network operations tools. It is important to consider the integration of those tools/endpoints with newer solutions.
Performance: There are multiple dimensions to performance. One is control plane performance, and the other one is user plane performance. A point to note is that there is a possibility of performance variations with different Cloud providers, region and type of deployment selected by operators. A typical cloud environment may have fluctuations in network latency, resource contention, and shared infrastructure, which could affect core network performance and reliability. In some of the cases, services may have limits on the usage and if a solution needs more API calls to the service, then we would see degradations in API failures.
Operational complexity: While focusing on development, developers may not always consider the operational complexity involved in managing and monitoring cloud-native applications in production, including deployment automation, continuous integration/continuous deployment (CI/CD), and logging/monitoring configurations.
Protocol specific handling: User Plane Function (UPF) & Session Management Function (SMF) talk to each other over the N4 interface. N4 interface uses PFCP protocol to configure UPF. A point to remember here is that PFCP works over UDP transport protocol and there is possible substantial latency when UPF is placed at a remote site. The same is true when the gNodeB is placed far in the field and Access Management Function (AMF) is placed in the cloud. So, latency and sometimes retransmissions should be considered but are often forgotten.
Considering these factors during the development of cloud-native applications can help developers build more resilient, scalable, and cost-effective solutions that meet the evolving needs of their organizations and end-users.
What an operator should know before deploying cloud native 5G?
Apart from 5G Core compliance, there are multiple other things operators should consider when leveraging Cloud Native solutions:
Deployment ease: Complete deployment should be zero touch to reduce the operational cost. Deployment of 5G core should not need multiple touchpoints. Also, it should be possible to select the flavor of deployment with Network function placements and capacity of deployment.
Scaling: To achieve cost efficiency, the solution should be completely automated, with the capacity to scale in and out. It is important to highlight that the goal is not just to offer automatic scale in or scale out, but also to ensure that no subscribers are lost during these occurrences. For example, if the network experiences a subscription spike, auto scaling should occur, with no impact on existing subscribers. Similarly, as the number of subscribers decreases, scaling in events should be triggered without creating any degradation in service for current customers.
Cloud expense: When an operator is building the Cloud Native 5G solution, they should be aware of cloud expenses to operate the network. Typically cloud providers do provide the cost estimates but these are often estimates at the solution level and not at the individual service level. This will help operators in planning the right SLAs for the network and adjusting the cost of solution.
Cloud vendor lock-in: Operators should look be aware if a given 5G solution can be deployed with any other cloud vendor or if it is tied with one specific vendor.
Conclusion
It may be simple to say that 5G deployments are cloud native, but actual cloud native deployments includes several features, and operators should create a set of criteria to assess the solution's cloud readiness. We should not categorize solutions as cloud native or not cloud native; instead, operators should seek full information on the 5G solution matrix.
