5G Software Architecture

Previously, we’ve looked at the hardware requirements of 5G. This week, we will take a look at the software infrastructure targeted for 5G deployments. There are published concepts and specifications by vendors like Intel and standards organizations such as O-RAN and OpenRAN. However these concepts are a bit nebulous, and these concepts may not work with all the potential use cases of future 5G deployment. Many of these concept and specs are focused on carrier grade deployments, and there are many potential 5G customers outside of telecom applications such as manufacturing campus or huge vessels.

There is a common trend among the different designs: the software stack is going away from bare-metal and moving towards virtualization or containerized software stack with centralized management software to easily deploy and manage all the nodes. Solutions from RedHat, VMware, and other leading software vendors all coming with VM and container management solution that can host customized 5G software stack. Intel is in on the action as well with the virtualized FlexRAN solution. The aim of these software stack is chaining together a cohesive stack of centrally managed software.

One of the leading VM software suite vendor, VMware, is integrating container support into their vSphere virtualization platform, showing how the container concept is catching on and can no longer be ignored by virtualization specialists. Red Hat, another juggernaut in enterprise OS and virtualization platforms introduced OpenShift container management platform. Even Microsoft got in on the container band wagon, integrating OpenShift into their Azure hybrid cloud computing platform.

For those with limited scale or budgets, Docker containers deployed through Kubernetes orchestration system are available freely. These open source alternatives don’t give up on features. The biggest difference, as usual in the open source landscape, is support. Professional support is available from the boxed software vendors, where as in open source alternative you will rely on documentations and community support for debugging issues that may arise.

The software stack is paramount moving away from proprietary vendor solutions and towards open standards software and hardware. This will bring down the hurdle for enterprises and business who wish to build private 5G networks for their internal needs. This allows open competition on the hardware front. It is great for hardware vendors, despite the increased competition. It forces vendors to innovate to attract customers as well as building on their own vision of 5G hardware to carve out specific niche markets. One size fits none and through the competition, it will allow customers to find hardware that fits their exact needs and choose software that will integrate well into their existing software infrastructure. What we’re envisioning is enterprises will choose to run a base OS they’re familiar with, such as RHEL or CentOS, then run a vendor provided KVM or, more likely, containers that bundles all the software required. Software and hardware vendors will need to work closely to provide application optimized solutions.

Thanks for joining us again for another look at 5G. We’ll revisit this topic as industry trends becomes more concrete. All-in-one small-cell looks like the next hot 5G topic, and we’ll definitely look deeper into that in a future blog post.

這篇文章 5g Software Architecture 最早出現於 AEWIN。

O-RAN, OpenRAN, and OTII, are the 3 most prominent specifications published so far and each has high profile members. We’ll look into each from the perspective of RAN hardware design considerations for 5G private enterprise networks and highlight some key specs and compare them as we go through the specs.

O-RAN published specs: https://www.o-ran.org/specifications

O-RAN by the O-RAN Alliance, favored by many major telecom operators, such as AT&T, Verizon, T-Mobile, Sprint, Orange, Vodaphone, NTT Docomo and more. It envisions the 5G network broken down into RU feeding to DU (distributed units) and then up stream to CU (central units) which then feeds into the core network. Due to the telecom focus, it defined a wide temperature range of -5~55C typical for equipment for this sector. This is a departure for most data center oriented manufacturers who typically does not validate against such high temperature. Another notable change is -48v DC power input. Hyperscalers has been moving towards DC in a bid to reduce inefficiencies of AC/DC conversions, so many manufacturers already have experience dealing with DC power. This should be just validation of CRPS -48v DC PSU with power cables rated for the increased current. In a move that would make many typical server manufacturers unhappy, it defined the chassis depth to <750mm. Not very far from off the shelf servers, but it still requires change of design and tooling to fit into the specified depth along with the associated cost of validating a new platform. Overall, this is very telecom focused specs. It remains to be seen that whether or not enterprises will request hardware that strictly follows this spec.

OTII published specs: http://www.opendatacenter.cn/work-group/p-1143085492931629057.html

OTII is published by the Chinese Open Data Center Committee with aim to use whitebox servers for the 5G network infrastructure. It is initiated by 3 major Chinese telecoms: China Mobile, China Telecom, and China Unicom along with Intel and CAIST. These 3 telecoms are also members of O-RAN. OTII specs departs from the others with its more modest temperature range requirement of 5~40C (-5~45C short term). This spec does not meet the minimum requirements for western telecoms or NEBS, therefore OTII is unlikely to gain traction outside of China even though this may be a more realistic operating environment for these equipment. It also has restrictive 450mm chassis depth requirement (specifying 2U for to fit all the required components). This lowers compute density and appears to be bespoke for the participating telecoms. Spec compliant servers are already being delivered, and likely be the largest current deployment for the 3 specifications today. The fast deployment is likely due to the specs defined by the telecoms themselves and as mentioned above, likely bespoke for their environment to allow the fast deployment of these servers to meet the aggressive 5G rollout schedule.

TIP – OpenRAN: https://telecominfraproject.com/openran/

Telecom Infrastructure Project defined a competing RAN specification. It is an open project and free to join as opposed to O-RAN’s paid membership, allowing it to gather a sizable membership. To note, many prominent members of OpenRAN are also O-RAN members.The specs are still in the early stages with tentative published specs. Out of the 3 specs today, this is the most incomplete with some DU specs defined and very little of CU specs. There are also some oddities inside the specs. For the power requirements, it defined -48v DC like the O-RAN spec, however it added 110v AC as well. Very odd to include only 110v but not 220v that is more common for data centers and majority of European countries. It also required -40~55C operating range for the DU. -40C low temperature range will be a harsh spec for manufacturers, requiring heaters to avoid low temperature issues. OpenRAN seems to picture that DU will be exterior pole mounted along with the RU, exposing the system to the weather extremes. The specification should be separated into interior and exterior mounted systems, as making a single system to serve both environments will drive up cost needlessly.

Here is chart that summarize the important specs from each:

There are a lot of similar concepts shared by all 3 specifications. On the power side, all have specified telecom focused -48v inputs. This makes sense as the specs are heavily telecom focused and it is a standard for the industry. However, OTII has included 220/110VAC support to allow more flexibility of placement due to the ubiquity of AC power. It will allow placement outside of telecom operator controlled locations or where it may be financially inadvisable to add -48v DC power.

For the physical form factor, all of them have specified shorter depth of the chassis. However only OTII have specified system that will fit into standard 600mm depth telecom racks. OTII did get a little too ambitious on the depth, which will limit the versatility of the system for other applications. We believe chassis depth of around just under 600mm is probably the most versatile along with front access design for ease of service and thermal consideration. This size will be big enough to pack in enough features and compute density but small enough for majority of deployments. Of course, physical sizes are highly dependent on end customer’s location for the deployment. This is probably where most obvious segmentation happens in the overall hardware landscape, and where manufacturers can differentiate themselves by choose the right size vs feature set.

Thanks for joining us for a quick look at the 3 main specifications for 5G RAN architecture. As the specifications mature, we’ll definitely revisit and do some more comparison in the future.

這篇文章 A look into published 5G vRAN specs 最早出現於 AEWIN。