Public cloud + 5G core network, is the wolf really coming?

This article is reprinted from the WeChat public account "Xianzao Classroom", written by Wei Huangsong. Please contact the WeChat public account "Xianzao Classroom" to reprint this article.

Recently, Telefonica Germany announced that they are working with Ericsson and AWS to deploy the 5G core network (hereinafter referred to as "5GC") provided by Ericsson on the public cloud, which is expected to be commercially available in 2021.

When the news came out, the industry was shocked.

Although the telecommunications industry has been talking about NFV and core network cloudification, previous related practices have been concentrated on emerging operators and private network applications. The suppliers are mainly IT manufacturers, and the underlying hardware is basically private cloud.

This is the first time that a mainstream international operator has deployed the core network of a traditional equipment vendor on a public cloud, creating three "firsts" in the cloudification of communication networks:

The first mainstream operator to deploy cloud-native 5GC, the first traditional equipment vendor to provide support for 5GC public cloud deployment, and the first public cloud vendor to carry large-scale commercial 5GC.

This article will conduct an in-depth analysis and assessment of this incident.

Ideal 5GC

The initial design goal of 5GC in the 3GPP specification is to become a cloud-native application.

From an architectural perspective, 5GC, which separates forwarding and control, is an SDN network with a cloud-native controller.

5GC system architecture

The SBA architecture of the control plane is the microservice architecture commonly mentioned in the IT field. The NRF newly introduced by 5GC is the registration center in the microservice architecture.

The signaling between 5GC services uses the HTTP2 protocol commonly used in the IT field, rather than special protocols such as Diameter that were commonly used in the core network.

The various services of 5GC are stateless by design, so they can be seamlessly migrated between servers at any time.

The control plane adopts cloud-native deployment, and the forwarding plane UPF has very simple functions, so it is completely feasible to use white-box forwarding devices.

This kind of architectural design enables 5GC to be fully decoupled and supports distributed deployment, thereby helping 5G networks support two killer features: edge computing and network slicing.

The real 5G core network

Ideals are beautiful, but reality is often cruel.

At present, many provinces in China have deployed 5GC and carried out business. According to on-site feedback, there are mainly the following problems:

1. Insufficient adaptability of general hardware.

An operator deployed 5GC from Factory A in a certain province. The hardware used was Factory A's server (including virtualization layer and operating system), Factory B's switch, and Factory C's disk array.

Although this is a scaled-down version of hardware decoupling (because the most critical servers and middleware are all owned by Factory A, and it cannot even be considered two-layer decoupling), a lot of problems still occurred during the deployment process.

Most of these problems are hardware driver problems. Although driver problems are small problems, many small problems will become big problems.

The reason why there are so many small problems is that the current communications industry chain is not open enough.

In contrast, in the IT field, a typical IDC involves more manufacturers and requires more drivers, but there are far fewer incompatibility issues between different manufacturers.

2. Failure to integrate into the cloud-native ecosystem.

The transition from a highly integrated monolithic architecture to cloud-native architecture will inevitably lead to increased complexity as decoupling is fully achieved. For example, Netflix's overall IT architecture is composed of thousands of interdependent microservices.

[[341675]]

The complex architecture of Netflix, a well-known streaming platform

This added complexity requires effective management.

Currently, the complexity of 5GC deployment and operation and maintenance has been widely criticized. First, the skills and awareness of operators' maintenance personnel are still in the process of transformation, and they have not completely switched from traditional network maintenance to cloud-native application maintenance. Second, the core network provided by the manufacturer itself is not open enough and has not been combined with the mature full set of DevOps tool chains in the cloud-native field. Its supporting network management is still based on traditional ideas.

This is like replacing the motor with a Tesla motor, but the entire control system is still that of a traditional fuel vehicle, which naturally creates greater difficulties for operation.

3. The separation of forwarding and control is not complete.

In 5GC, the N4 interface between UPF and control plane is defined by 3GPP. However, due to various reasons, the decoupling of N4 interface is not sufficient.

At present, the first batch of commercial 5GC control planes and UPFs are from the same manufacturer, and UPF is still a dedicated device.

Considering that UPF will be deployed to a large number of edge nodes in the future, UPF white-boxization and compatibility with different manufacturers are a rigid demand for operators.

Therefore, we can see that the three major operators are vigorously promoting the decoupling of the N4 interface and have achieved certain results.

Telefónica's solution

At present, the official news from Telefonica and Ericsson is more of a commercial promotion, and no specific technical solutions have been disclosed.

However, the white paper AWS released this year, "AWS Enables 5G Evolution: Building Scalable, Secure, Reliable, and Efficient Cloud-Native Core and Edge Networks," provides a more detailed description of the deployment plan. It is initially expected that Telefonica's overall technical solution will be based on this.

In terms of the overall architecture, the control plane functions of 5GC will be hosted in the central computer room of the AWS region (AWS Region), while the UPF and CU part of the control plane of 5G NR can be hosted by AWS Outpost deployed at the edge node.

AWS Outpost is an integrated cabinet launched by AWS that can be deployed in the customer's computer room.

The cabinet is pre-integrated with servers and switches according to customer orders. After being delivered to the customer's room, it can be used after being connected to the power supply and network.

Although Outpost is deployed in the customer's room, it is part of the AWS public cloud service. The customer does not own the equipment itself, nor is he responsible for its maintenance.

Outpost is connected to AWS Region through a dedicated line or public line, and logically acts as an extension of AWS Region.

For the control plane, AWS recommends EKS (Amazon's managed version of K8S). In its white paper, it describes in detail how to meet the high performance requirements of 5GC through horizontal expansion.

For the forwarding plane, AWS recommends virtual machine hosting (with a forwarding capacity of up to 100 Gbps and network optimization instances that support SR-IOV, DPDK, etc.).

Given the Nitro virtualization technology currently used by AWS, by offloading the virtualization-related loads to dedicated hardware boards, the performance of virtual machines has basically been made equivalent to that of physical machines.

Therefore, in terms of performance, it can also be regarded as a physical machine directly carrying the data.

Taking into account the business needs of Telefonica, it is not ruled out that white box switches can be used as UPF to achieve Tbps-level forwarding (for example, Facebook's self-developed white box switch consists of 4 Xeon CPUs plus a high-performance forwarding ASIC, which is basically equivalent to a high-performance server plugged in a Tbps-level forwarding ASIC, which can fully meet UPF requirements).

It is worth noting that AWS has not launched any customized products for the deployment of 5GC, and all components used in the entire solution are mature products of AWS.

This means that AWS's existing operation and maintenance and DevOps tool chain can be perfectly applied to 5GC hosted by AWS. Operating and maintaining such 5GC will be as simple as operating and maintaining any IT application on AWS.

In the white paper, AWS also specifically discussed how to apply its cloud operation and maintenance best practices framework to 5GC operation and maintenance. From the relevant content, it can be seen that in AWS's eyes, 5GC, as a cloud-native application, has far more commonalities than characteristics with other cloud-native applications.

Currently, Wavelength, a MEC product jointly developed by AWS and operators, has been put into commercial trial in many locations, providing MEC application developers with an experience and tool chain that is consistent with application development in the AWS Region.

If Telefonica can really put 5GC on AWS this time, its 5G industry solution will achieve huge scale advantages.

The slow pace of network cloudification

Network cloudification has been proposed for many years.

The communications industry has been talking about NFV and SDN, and 5G has basically embodied the design concept of cloud native in its related technical architecture. However, even the latest 5GC equipment delivered by major manufacturers still lacks support for cloud native and its own openness.

In my opinion, there are three reasons for this:

1. The vested interests are very resistant to reform.

To put it more concretely, the forces led by the four major equipment manufacturers are very resistant to the trend of ecological openness caused by network cloudification. After all, in terms of profit margin, closedness is definitely the best.

Of course, we cannot remain completely indifferent to the trend.

The current situation is that the weaker a company is in traditional fields, the faster its pace of reform is.

For example, Nokia is currently the only equipment manufacturer among the Big Four that has opened the eCPRI interface of base station fronthaul to operators. It also seems to be the first equipment manufacturer to promote FPGA in 5G base station chips.

Unfortunately, if you take one step early, you are a pioneer, but if you take two steps early, you become a martyr. Due to the performance and cost issues of FPGA, Nokia's products lagged behind in cost performance, which eventually led to a sharp drop in its stock price.

Ericsson is relatively stable in its technology route, but has recently been accelerating its evolution towards cloud native.

This time, Ericsson is willing to cooperate in deploying products on the public cloud, which also shows his attitude.

As for the undisputed big brother in the wireless field, it has always criticized the cloud-native concept on the grounds of performance and cost, and continues to promote its own non-decoupled or fake-decoupled solutions in order to serve customers in an all-round way.

2. The entire industry still lacks understanding of network cloudification.

Many people say that operators’ employees lack the skills to perform the operations and maintenance of cloud-native networks.

But what is more important is the attitude.

IT skills are not more complicated than traditional communications. As long as you are willing to learn, transformation is not a problem. The problem is that many people do not think that cloud native represents the future. They think that highly coupled integrated solutions have better performance and everything else is just bragging.

The solutions that European and American operators have adopted to solve this problem are relatively crude. For example, AT&T requires all employees to learn, and then lays off older employees who don’t learn. Chinese operators are relatively mild in their approach, mainly encouraging internal learning and natural iteration of personnel.

3. The shadow brought by pan-politicization.

Currently, except for Cisco, which still has a certain share in the wireless market, there are no wireless equipment manufacturers in the United States.

In order to realize the MAGA (Make America Great Again) vision and suppress Huawei, the US government has been advocating open-RAN while excluding China, the world's largest producer and consumer of wireless equipment.

This not only artificially divides the technical community, but also imposes political factors on technology selection. In the long run, the negative impact on the development of network cloudification is quite large.

Conclusion

Thousands of ships pass by the sunken boat, and thousands of trees bloom in front of the dead tree.

The cloudification of the core network is an inevitable trend, and the entire communication network is moving in this direction.

A few days ago, the 5G lightweight core network jointly developed by Alibaba XG Lab and Zhejiang Unicom was launched in Zhoushan Port, Zhejiang. This is also a strong signal that not only foreign competitors will take action, but domestic manufacturers will not miss the opportunity of network cloudification.

I believe that with the continuous deepening of 5G construction, the industrial Internet will generate more network cloud demands. The market structure of the core network will undergo earth-shaking changes!