Server Accelerators Feed 5G’s Need for Speed

The future of 5G + Edge, you might say, is in the cards. Server accelerator cards—graphical processing units (GPUs), field programmable gate arrays (FPGAs), and application-specific integrated circuits (ASICs)—have an important role to play in reducing latency and improving bandwidth at the edge of the 5G network. With the volume of data generated by IoT and far-edge devices exploding, telcos must be prepared to accelerate the edge. Implementing server accelerator cards, as part of 5G new wave spectrum strategy, will help telcos deliver more data, faster.

Making the Far Edge Faster

 Let’s consider the use case of a disaggregated RAN at the far edge using an Open RAN (O-RAN) with a 7-2x functional spit option (as defined in 3GPP). To serve the O-RAN distributed unit (O-DU) portion of the RAN, an accelerator card must satisfy three requirements:

  • A network interface card (NIC) with multiple ports of 10GbE, 25GbE, or even 100GbE;
  • Enhanced timing via G.8275.1 telecom grandmaster (T-GM) clock featuring Synchronous Ethernet (SyncE), IEEE 1588 precision time protocol (PTP), and physical layer (PHY) timestamping;
  • Network processing acceleration using FPGA, GPU, or ASIC.

Until we have a card that can satisfy these three requirements, in the short-term, multiple server plug-in cards can be used with memory sharing or a pipeline between them. Each card could handle one or more of the above requirements, or the telco might choose to integrate some or all of these cards on the motherboard.

The diagram below illustrates how DU processing with a portion of the processing offloaded inline to accelerator cards might look. (Image courtesy of the O-RAN Alliance).

For the central unit (CU) portion of the RAN, a multi-core smart NIC (sNIC) card should suffice for accelerating control plane operations such as ciphering and encryption.

As you look at other RAN split configuration options, the requirements for acceleration will change but roughly follow the DU and CU needs described above. When weighing accelerator card and server options, it’s best to consider it from the business point of view rather than the technology point of view. For example, which choice gives you the best total cost-of-ownership for workloads in a vRAN use case (e.g., microcells, picocells) and how many radio sectors will it cover? The answer could be a base station multi-input multi-output (BS-MIMO) method using 2 or 4 transmitter (Tx) and receiver (Rx) devices or 64 Tx/Rx devices using millimeter wave mmMIMO. The flexibility of software vs. hardware optimization needs to be reviewed carefully for decision making.

As further aggregation takes place along the data path from the edge toward the network core, we start seeing more common data center models for acceleration with the need for storage optimization, caching, and so on. Many advanced NICs like the ones that are used successfully in enterprise use cases are applicable here.

Managing Infrastructure

Management and manageability of an advanced acceleration infrastructure are critical factors in the adoption of 5G edge solutions. Telcos expect to manage the complete hardware pipeline from the far edge (e.g., radio towers) to the network core data center using a single management interface for all control operations. An abstraction layer above the hardware is needed to take full advantage of disaggregation.

For servers, this requires out-of-band management through DMTF’s Redfish for all server components, including sNICs and accelerators of every kind. Because accelerators are plugged into a server, these too must be capable of being managed using a single, consistent interface. To that end, Dell Technologies has designed its integrated Dell Remote Access Controller (iDRAC) solution to manage servers including all accelerators and sNIC devices within them.

DMTF standards, such as the Network Controller Sideband Interface (NC-SI) and Platform Level Data Model (PLDM) protocols, are used internally to enable the iDRAC controller to access, configure, and manage these advanced components. The details of how that works are not visible to users, as their interactions with the server are done through the Redfish interface.

For hardware management tooling, some telcos utilize the standalone Ironic project, Bifrost, or have hardware management integrated within the platform (e.g., OpenStack). For Kubernetes bare-metal deployments, it is expected that Metal3 will be used for hardware management and integrated via the Kubernetes Cluster API. Central to this approach is the ability to use the Redfish protocol for out-of-band management for servers, networking gear, and even dedicated storage.

Another aspect that needs to be considered is the operational usage of accelerators or sNICs. We expect that hardware management will prepare these accelerators so they’re ready for use in a server. As part of that management process, telcos need to consider how users will program those accelerators to handle server workloads, particularly with a platform like Kubernetes or OpenStack. In order to prepare accelerators to handle application workloads, two criteria must be met:

  • A data pipeline must exist between the CPU and the accelerator card;
  • The application code must be executed on the card itself.

Open Network Foundation’s Stratum is commonly used for accelerators or sNIC stream building. The OneAPI model can be used for application development. Vendor-specific device programming and management tools can also be used for both device programming and stream management of accelerators and sNICs.

A follow-on consideration is the method used to achieve platform integration. In the Kubernetes environment, CustomResourceDefinition (CDR) APIs can be used to instruct the operator framework to prepare a smart device for its intended use. Similarly, for OpenStack, the device-specific driver in OpenStack’s Cyborg can be used.

As you can see, there is a lot be considered when accelerating the edge for 5G services. Fortunately, Dell has taken all these things into consideration when building its edge servers and solutions. Think of it as a built-in “turbo” button that you can activate to give your network a competitive edge.

About the Author: Arkady Kanevsky

Arkady has 25+ years of experience in a variety of areas of the computer industry. He has been with Dell Technologies since 2010. He is currently focused on Telco technologies including Cloud and Edge computing. He is on the board of directors of Open Infrastructure Foundation, part of oRAN and CNCF. Prior to Telco Arkady worked on Cloud, HPC, Big Data, AI, Real Time Computing, Storage, Networking, and IETF. He was a chair of DAT Collaborative, MPI/RT, on the boards of InfiniBand Trade Association and OpenFabric. Arkady has a Ph.D. from the University of Illinois, holds 20+ granted and pending patents and has published over 60 papers.